Project and Portfolio IV: Web Development at Full Sail University

This post covers my experience with Project and Portfolio IV: Web Development at Full Sail University. Every Project and Portfolio course in the program had asked me to build something. This one asked me to take something that already existed and make it genuinely production-ready. That is a different challenge. Building features from scratch is a familiar loop at this point in the program. Returning to an existing application with fresh scrutiny, identifying what is missing, and systematically closing the gap between "it works" and "it holds up" is closer to what professional software maintenance actually looks like. The four-week milestone structure, from discovery through final showcase and postmortem, gave the work a shape that felt less like a course project and more like a real delivery cycle. Below is a breakdown of each week.

---

Week 1: Project Discovery, Specifications, and Workflow

My thoughts at the time

Week one started with a review of the principles and practices that the program had built up across the previous courses and a structured process for applying them to a specific project. The discovery milestone required more than identifying what I wanted to build. It required documenting what the existing application was, what it lacked, and what the four weeks would deliver. Writing those specifications clearly enough to be reviewable was harder than the building that followed, because vague plans produce vague deliverables.

The version control and workflow component grounded the work in the kind of discipline that Project and Portfolio III had introduced through Agile sprints but that this course took further by connecting it to professional git workflows, branch naming conventions, and the documentation habits that make a repository readable to someone encountering it for the first time. GitHub as a portfolio artifact, not just a code backup, was a perspective this week made explicit.

Retrospective insight

Discovery as a formal phase has influenced how I start every project since. The instinct to begin writing code immediately is strong and almost always counterproductive. Spending time in week one writing specifications, defining success criteria, and mapping out the gap between the current state and the desired state created a document I referenced throughout the remaining weeks. That document also became part of the final presentation, which meant the planning work served double duty. A well-written project discovery document is both a development tool and a communication tool.

---

Week 2: Application Architecture, Design, and Iterative Development

My thoughts at the time

Week two was about the structure and style of what I was building before the implementation work began in earnest. Application architecture decisions made at this stage, how the codebase would be organized, how cloud-native services would be integrated, how access control and user activity auditing would be layered into the existing system, determined the quality of everything that followed. The course framing around iterative development and deconstruction encouraged approaching the existing codebase as something to understand deeply before extending rather than something to work around.

The access control and auditing requirements from the course description were the pieces that pushed the architectural thinking furthest. Adding permission levels to an application that was not originally designed around them is a retrofit that exposes the assumptions built into every earlier design decision. The places where that retrofit required the most structural adjustment were exactly the places where the original architecture had been loosest. That correspondence between architectural debt and integration difficulty was a pattern I had not seen as clearly in any previous course.

Retrospective insight

This week reinforced something that the testing-focused Web Application Integration course had introduced from a different angle: the design decisions you make when building a feature determine how much it costs to change that feature later. Architecture is not a planning phase distinct from development. It is a constraint that development either works within or works against at every subsequent step. Having spent a week explicitly thinking about structure and branding before writing implementation code produced a more coherent final product than any previous project where those decisions had been made implicitly along the way.

---

Week 3: Prototype, Integrations, and Testing

My thoughts at the time

Week three was where the specifications and architecture from the first two weeks made contact with working code. Building toward a proof of concept prototype that demonstrated the proposed integrations required the cloud service decisions from week two to become actual implementations. The testing component of this week connected directly to what Web Application Integration had introduced: integration tests that verified the new cloud-native services were behaving correctly under the conditions the application would encounter in production, not just in isolation.

Deconstructing existing frontend product work alongside the integration development gave the week a dual focus that was occasionally difficult to balance. Time spent auditing the frontend for completeness and consistency was time not spent on integration work, and vice versa. Managing that tradeoff deliberately, deciding which pieces of the frontend review were worth addressing before the final milestone and which could wait, was a project management skill that the course's milestone structure was quietly demanding without stating it directly.

Retrospective insight

The proof of concept prototype as a deliverable forced an honest accounting of what was actually built versus what had been planned. Demos do not benefit from qualifications about what the final version will do. They show what exists now. Arriving at week three with a working prototype that accurately represented the planned final product required that weeks one and two had been used well. When they had been, the prototype milestone felt like a natural step. The integration testing work from this week also produced artifacts that fed directly into the final deployment, which meant the testing was never purely an academic exercise.

---

Week 4: Deployment, Final Showcase, and Postmortem

My thoughts at the time

The final week brought the project to a deployed, presentable state and then required reflecting on the full process in a postmortem. Deployment into a scalable test environment was the technical capstone. Connecting access control, user activity auditing, cloud-native services, and performance-aware design into a deployable artifact that could handle load gracefully was the highest bar the program had set up to this point. The work from Cloud Application Development on scalable serverless infrastructure and from Web Application Integration on load testing and stress testing fed directly into knowing whether the deployed application was actually ready.

The showcase presentation and postmortem were the parts of the week that felt most professionally authentic. Presenting the work to peers and instructors with a formal postmortem required articulating not just what was built but what decisions were made, what tradeoffs were accepted, and what would be done differently with more time. That kind of structured reflection is how professional teams close a delivery cycle, and practicing it in an academic context made the format feel familiar rather than foreign when it appeared later in professional settings.

Retrospective insight

The postmortem from this course is something I have returned to in thinking about subsequent projects. The gap between what I planned to build in week one and what I actually shipped in week four was informative in ways that no amount of forward-looking planning could have predicted. Documenting that gap honestly, naming the decisions that worked, the ones that did not, and the places where the estimate had been optimistic, produced the most useful single artifact of the course. Postmortems are not a way of assigning blame for what went wrong. They are a way of building better estimates and better plans for the next time, and that accumulated self-knowledge compounds across every project that follows.

---

Closing Thoughts

Project and Portfolio IV was the course that asked the question the program had been building toward: given everything you have learned, what does it look like when you apply all of it to a single project at a professional standard? The answer involved access control, cloud services, testing, scalable deployment, structured documentation, and a formal presentation with a postmortem. Every piece of that list traces back to a specific earlier course in the series: Project and Portfolio III, Cloud Application Development, Application Integration and Security, and Web Application Integration all had direct contributions to what this course required. Seeing how those pieces fit together under one deadline was the most complete learning experience the program had delivered, and the project that came out of it was the strongest single artifact I had produced by that point.

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!