Project and Portfolio III: Web Development at Full Sail University

The suggested project for Project and Portfolio III was a Spotify API integration. I built an alumni networking platform instead. That was not a casual decision. By this point in the program I had enough individual features working to know what I actually wanted to prove: that I could design a system where authentication, data modeling, and multiple API surfaces operated together as a single coherent product, not as four separate assignments that happened to exist in the same repository.

---

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.

---

Where I Use This Now

PUG Empire is the closest real equivalent to what I built in this course: community features, user accounts, content owned by specific users, and access rules that distinguish logged-in users from public visitors. The Agile sprint discipline also carried forward: Echo Effect was built in milestone increments with tickets organized before any feature was written. That habit came from this course.

---

Code: JWT Middleware and Route-Level Auth

The full authentication loop that the alumni app required:

// Issue token on login
async function login(req, res) {
  const { email, password } = req.body
  const user = await User.findOne({ email })

  if (!user || !await bcrypt.compare(password, user.passwordHash)) {
    return res.status(401).json({ error: 'Invalid credentials' })
  }

  const token = jwt.sign(
    { sub: user._id, role: user.role },
    process.env.JWT_SECRET,
    { expiresIn: '7d' }
  )

  res.json({ token })
}

// Protect routes that require auth
const requireAuth = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1]
  if (!token) return res.status(401).json({ error: 'Missing token' })

  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET)
    next()
  } catch {
    res.status(401).json({ error: 'Invalid token' })
  }
}

// Route definitions
router.get('/profile', requireAuth, getProfile)
router.post('/posts', requireAuth, createPost)
router.get('/posts', getPosts) // public

---

FAQ

What is Agile development and why do teams use it? Agile is a framework for managing software projects through short, iterative cycles called sprints. Instead of planning everything upfront and delivering at the end, Agile teams deliver working pieces frequently and adjust the plan based on feedback. It reduces the risk of building something that does not meet needs and keeps work visible to stakeholders.

What is SCRUM and how is it different from Agile? SCRUM is one specific Agile methodology. It structures work into fixed-length sprints (usually one to four weeks), with defined roles (product owner, scrum master, development team), daily standups, sprint planning, and retrospectives. Agile is the broader philosophy. SCRUM is one way to practice it.

Why build your own authentication instead of using a library? Understanding what authentication does underneath, token issuance, signature verification, expiry handling, and session persistence, is different from knowing how to configure a library that does it for you. Building it once from scratch means you understand the mechanism, which matters when something breaks or when you need to evaluate whether a library is handling things correctly.

What makes a full stack project different from frontend and backend work separately? Full stack means owning every layer: the database schema, the API design, the frontend that consumes it, and the deployment infrastructure that runs it. The difficulty is not in any single layer but in the integration points. Data shapes that work in MongoDB need to be consistent with what the API returns and with what the frontend expects. Keeping those contracts aligned across all three layers is the actual skill.

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!