Project and Portfolio III: Web Development at Full Sail University

This post covers my experience with Project and Portfolio III: Web Development at Full Sail University. The course is structured around Agile project management: weekly SCRUM meetings, tickets, milestones, and peer code review. The suggested project was a Spotify API integration. I chose a different direction. By this point in the program I had built enough individual features in isolation that what I wanted was a project that required all of them to work together as a coherent product. A Full Sail Alumni Networking App gave me that. User registration, social profiles, a blog, and a collaborative project board meant that authentication, data modeling, API design, and frontend integration all had to operate as a single system rather than four separate assignments. Below is a breakdown of each week and what the experience contributed.

---

Week 1: Choosing the Project and Building the Agile Foundation

My thoughts at the time

Week one was about deciding what I was actually going to build and then making that decision legible as a plan. The Agile pre-production phase required more than a vague concept. It required tickets written clearly enough to be actionable, milestones scoped realistically enough to be achievable, and a project foundation set up to support four weeks of feature work without accumulating structural debt from the start.

Choosing to build an alumni networking platform instead of the Spotify integration was a deliberate trade. The Spotify project had a defined API contract and a known set of requirements. The alumni app had neither. I would be designing the data model, defining the API surface, and making the scope decisions myself. That meant more pre-production work but a more meaningful outcome. The features I settled on, user registration, social profile links, a community blog, and a collaborative project board, were chosen because each one required a different backend capability and because together they added up to something I would actually want to exist.

Setting up the repository, establishing the branching strategy, and writing the initial ticket backlog in week one created the scaffolding that made the development weeks possible. Doing that work properly meant I was never deciding what to build next. I was always executing against a plan.

Retrospective insight

The pre-production phase is the part of project work that is easiest to underinvest in and most expensive to skip. On small course projects the consequences are manageable. On real projects they are not. The habit of making decisions explicitly before writing code, and capturing those decisions in a way that is reviewable and adjustable, is one I have carried directly into professional work. The SCRUM structure also introduced me to the mechanical discipline of standing meetings: short, focused, designed to surface blockers rather than report status at length.

---

Week 2: OAuth, JWT, and Getting Users Into the System

My thoughts at the time

Week two was authentication. For the alumni networking app that meant designing a registration flow, issuing JWTs on login, and persisting session state in a database. Every backend course leading up to this one had touched JWT at some point: it appeared in Deployment of Web Applications as one layer of a multi-platform authentication system, and the Advanced Server-Side Languages work on structured Express architecture gave me a pattern for keeping the auth middleware clean and separate from route handlers.

The decision to build user registration from scratch rather than delegate it to a managed service was conscious. This was a portfolio project, and understanding the full authentication flow, hashing passwords, issuing tokens, validating them on subsequent requests, and handling expiry gracefully, was more valuable than getting it working quickly through an abstraction. By the end of the week the registration and login endpoints were functional, the JWT was persisting in the database, and the social profile fields were part of the user schema.

Retrospective insight

Implementing authentication end to end, including the parts that are easy to get wrong, is different from using a library that handles it for you. The knowledge of what is actually happening inside the token issuance and validation cycle changes how you read code that uses authentication, how you think about edge cases, and how confidently you can debug problems when they surface. This week also reinforced that security hygiene in environment variables is not an afterthought. API keys, JWT secrets, and database connection strings that live in a .env file and never touch the repository are a foundational habit, not a best practice to revisit later.

---

Week 3: API Endpoints, the Blog, and the Project Board

My thoughts at the time

Week three was the most features-dense week of the course. With authentication in place, the remaining data surfaces could be built out on top of it: the blog endpoint for creating and retrieving posts tied to alumni user accounts, and the project board endpoints for creating collaborative project listings that other users could discover and express interest in joining. Each required different considerations around data ownership, access control, and what an authenticated versus unauthenticated request should be permitted to do.

The JWT refresh logic also landed in week three. Tokens expiring mid-session and throwing the user back to a login screen is the kind of small friction that makes an application feel unfinished. Building automatic token refresh meant the session stayed alive as long as the user was active, which was a behavioral detail that mattered for the networking use case specifically. The SCRUM meeting this week surfaced useful peer feedback on the project board feature: the initial approach to indicating interest in a project was ambiguous in a way I had not noticed from inside the work.

Retrospective insight

Building multiple related API endpoints in a single week under milestone pressure clarified something about API design that building one endpoint at a time does not: the decisions you make about naming conventions, response shapes, and error handling in the first endpoint set expectations that every subsequent endpoint has to meet. Inconsistency in an API surface is not just a style problem. It is a maintenance problem. The feedback loop from SCRUM also proved its value here in a concrete way. Another set of eyes on a feature, even a brief check-in, surfaces assumptions that are invisible to the person who wrote the code.

---

Week 4: The Frontend, Integration, and Shipping the Finished Product

My thoughts at the time

Week four was frontend integration and finishing. The backend was functional and tested. The job was now to build the interface that exposed those endpoints to a user who had no idea what was happening underneath. The alumni networking context shaped every design decision: the registration and profile page needed to feel personal and professional at the same time, the blog needed to be readable and structured, and the project board needed to communicate enough about a project to make joining it feel like a real possibility rather than an abstract button.

Connecting the frontend to the backend introduced the familiar integration friction where things that worked perfectly in isolation do not quite fit together without adjustment. CORS configuration, request headers carrying the JWT, loading states while endpoints resolved. None of those problems are hard in isolation, but encountering them all together while trying to hit a week-four milestone is a good representation of what integration work actually feels like on a real deadline.

The final SCRUM presentation required walking through the project from concept to completion: what was planned in week one, what changed, what I would do differently, and what the finished product demonstrated. Having a project I had designed myself rather than followed a template made that presentation feel like something I actually had opinions about.

Retrospective insight

Frontend integration is not a phase that happens after backend development is complete. It is a set of decisions that should inform the backend from the beginning, and vice versa. The experience of building the alumni app end to end, where I owned every layer of the stack, made that interdependence more obvious than it had ever been in a course where the backend and frontend assignments were separate. The finished application, user registration, social profiles, a blog, a project board, deployed and accessible, was the most complete thing I had shipped by that point in the program, and it existed because the pre-production planning in week one had been specific enough to make it achievable.

---

Closing Thoughts

Project and Portfolio III was the course that made the server-side block feel complete. The Node.js foundations from Server-Side Languages, the architectural discipline from Advanced Server-Side Languages, the deployment experience from Deployment of Web Applications, and the cloud integration patterns from Cloud Application Development all fed into the four weeks of this course in ways that were visible in the final product. The Agile structure was not overhead around the development work. It was the mechanism that made four weeks of ambitious scope actually deliverable. The Full Sail Alumni Networking App is the project I point to when I want to demonstrate that I can design, build, and ship a full stack application with real features. That is what the course was designed to produce, and it did.

Credits and Collaboration

A huge thank you to Esther Allin for designing the blog banner art! If you're looking for a professional digital media specialist, Connect with her on LinkedIn!