Project and Portfolio V: Web Development at Full Sail University

Project and Portfolio V was less about proving that I could build a feature and more about proving that I could manage a product as it moved toward release.

That distinction matters. A feature can work in isolation. A product has to be explainable, measurable, defensible, and ready for people who were not present while it was being built. It needs a pitch, a plan, a business model, a security posture, a change process, a release strategy, and a postmortem that is honest enough to make the next version better.

For this course, the project was Our Heritage Kitchen, a family recipe archive designed to preserve recipes, cooking notes, origins, family connections, timing, photos, utensils, and the small details that tend to disappear when recipes are passed around casually.

The project started from a simple product problem: family recipes are usually stored in fragile places. They live in notebooks, screenshots, text messages, memory, or one person's kitchen routine. That works until it does not. Our Heritage Kitchen treats recipes as family knowledge worth structuring and preserving.

The course gave that idea a more professional frame. It pushed the project from "I can build this" toward "I can release, evaluate, protect, and explain this."

---

Week 1: Pitch, Plan, and Statement of Work

My thoughts at the time

Week one focused on the pitch and plan. The course framing included a formal statement of work, change order thinking, peer review, and a project kickoff. That made the first milestone feel closer to product planning than normal coursework.

For Our Heritage Kitchen, the pitch was not "recipe website." That would have been too generic and too weak. The stronger idea was a family recipe archive. The difference is meaningful. A recipe website is mostly about consumption: search, cook, move on. A family archive is about preservation: who made the recipe, where it came from, what details matter, what should survive beyond the next meal, and how the content can remain understandable to someone who did not grow up in the kitchen where it originated.

That framing shaped the early plan. The product needed public browsing so visitors could explore recipes without friction. It also needed contributor accounts because preserving recipes requires ownership and editing. It needed metadata beyond ingredients and steps: family name, origin, category, cook time, photos, practical notes, and searchable filters. Without that structure, the archive would collapse into a generic list.

The statement of work forced those decisions into writing. That was useful because it made scope visible. The project could not be everything. It did not need social networking, meal planning, grocery ordering, or a full cooking community in the first beta. It needed to prove the core loop: browse recipes, preserve a recipe, organize it with meaningful metadata, and make the archive feel trustworthy.

Retrospective insight

The most important lesson from week one was that a good pitch narrows the product. It does not just make the product sound attractive. It defines what the product is allowed to ignore.

Our Heritage Kitchen became easier to build once I stopped treating it like a broad food platform and started treating it like a preservation tool. That gave every design and technical decision a test: does this help families preserve and rediscover recipes, or is it just another feature a recipe app could have?

That same planning discipline connects directly to my earlier work in Project and Portfolio IV, where the discovery process taught me to define success before trying to ship. PP5 made that habit more product-focused by connecting the plan to viability, metrics, compliance, and release readiness.

---

Week 2: Metrics, Marketing, Logs, and Business Viability

My thoughts at the time

Week two moved into metrics and business viability. This was the week where the project had to be evaluated as something that might need to attract users, prove value, and produce signals after launch.

For Our Heritage Kitchen, the obvious vanity metric would be total recipes. That number matters, but it is not enough. A recipe archive can have a lot of entries and still fail if nobody can find what they need, if contributors stop adding detail, or if browsing feels like work.

The better metrics were tied to the product loop:

• how many recipes are created
• how many recipes include origin and family metadata
• how often visitors use filters
• which categories are searched most often
• whether public browsing leads to recipe creation
• whether visitors return to the archive

Those metrics connect directly to the business model because Our Heritage Kitchen is not trying to compete with giant food content sites. Its value is specificity. A family, community, church group, reunion, or small cultural archive does not need millions of recipes. It needs the right recipes preserved with the right context.

The marketing angle followed from that. The product is not selling "better cooking." It is selling memory, continuity, and ownership of family knowledge. That changes the voice, the interface, and the kind of features that matter. Filters by origin, family, and culinary category are not just search conveniences. They are the structure that makes the archive feel personal.

Retrospective insight

This week helped me think about metrics as product evidence instead of dashboard decoration. Logs and analytics are useful only when they answer decisions the product actually needs to make.

If visitors browse but do not create recipes, the onboarding or value proposition may be weak. If contributors create recipes without origin or family details, the form may not be communicating why those fields matter. If certain filters are used heavily, those categories may deserve stronger navigation. The point is not to collect data because data sounds professional. The point is to create feedback loops that tell the builder what to improve.

That thinking also connects to the SEO and portfolio work I have been doing across this site. Discoverability matters, but discoverability without a clear product path is incomplete. Our Heritage Kitchen needed both: a public surface people could understand quickly and an underlying product loop that could turn interest into preserved content.

---

Week 3: Compliance, Security, and Use Cases

My thoughts at the time

Week three focused on compliance, security, and use cases. That was the right pressure point for a project like this because Our Heritage Kitchen accepts user-generated content and account-based contribution.

Even a relatively quiet family recipe archive has responsibilities. If users can sign in, the application has to think about authentication, session handling, and account boundaries. If users can submit recipes, the application has to think about validation, moderation, ownership, and what content is safe to publish. If photos are involved, the application has to think about file handling and whether uploaded media exposes anything unintended. If analytics are involved, the product has to consider what is collected and why.

The use cases made those responsibilities more concrete:

• a visitor browsing public recipes without signing in
• a contributor preserving a family recipe
• a user editing their own recipe details
• a visitor filtering by origin, family, or category
• a recipe page displaying cooking information clearly
• a future administrator reviewing or correcting content

Those are not just user stories. They are trust boundaries. A visitor should not need an account to browse public recipes. A contributor should not be able to edit someone else's content. A recipe form should not accept arbitrary unsafe input. A public archive should not expose private account information.

That security mindset came directly after Secure Application Development, which made the timing useful. Secure development is not only about dramatic vulnerabilities. It is about making ordinary product decisions with an understanding of what can go wrong around them.

Retrospective insight

The biggest lesson from week three was that compliance and security are easier to handle when the product model is clear.

If the product does not know the difference between visitor, contributor, owner, and administrator, security becomes guesswork. If the content model does not distinguish public recipe data from account data, privacy becomes fragile. If the application does not define what a recipe submission is allowed to contain, validation becomes inconsistent.

Our Heritage Kitchen made those concerns concrete without needing to pretend the project was a high-risk enterprise system. It is still a real application with real users, real content, and real trust decisions. That is enough to require care.

---

Week 4: Beta Release, Versioning, Showcase, and Postmortem

My thoughts at the time

Week four focused on beta release, formal versioning, showcase, and postmortem. This was the point where the product had to stop being an idea under development and become something that could be shown, tested, and discussed as a release.

The live version of Our Heritage Kitchen demonstrated the core beta experience:

• public recipe browsing
• search and filtering
• recipe cards with origin, family, category, timing, and notes
• contributor sign-in
• a recipe creation path
• a preservation-first product identity

That did not mean the product was finished. Beta is not finished. Beta means the core value is visible enough for feedback to be meaningful. The archive could show what it wanted to become, and the remaining questions were product questions rather than imagination questions.

Versioning mattered because the project had moved beyond "whatever is currently on my machine." A beta release needs a known state. If something breaks, I need to know what changed. If feedback comes in, I need to know which version the feedback describes. If a feature gets revised, I need to separate the change from everything else that happened during development.

The postmortem was the most valuable part of the release process. It required looking back at the original plan, the actual release, the decisions that worked, and the areas that needed another pass. For Our Heritage Kitchen, the successful decision was narrowing the product around preservation instead of building a generic recipe platform. The area that still needs continued attention is contribution flow: making recipe creation feel low-friction while still capturing enough detail to make the archive meaningful.

Retrospective insight

This week reinforced the value of shipping a coherent beta instead of chasing a larger unfinished product. A smaller release with a clear purpose is easier to evaluate than a larger product that has too many incomplete ideas competing for attention.

The release process also made the product more marketable. A deployed project with a clear pitch, measurable goals, security considerations, and a postmortem says more than a code repository alone. It shows that I can think beyond implementation and into delivery.

That is the professional value of PP5. It connected development to release management, metrics, risk, and product communication.

---

Closing Thoughts

Project and Portfolio V was a useful progression from the earlier portfolio courses because it treated the project as a product under management.

The technical build still mattered, but it was no longer the whole story. Our Heritage Kitchen needed a reason to exist, a defined beta scope, a plan for measuring whether the product worked, a security and compliance posture, and a release process that made the final state understandable.

That is a different skill set than writing components or endpoints. It is the skill set that turns software into something other people can use, evaluate, and trust.

The course also arrived at the right point in my development path. By this stage, I had already built full-stack applications, worked through authentication, testing, deployment, cloud services, connected devices, and secure application development. PP5 asked me to pull those pieces together around a product that was public, personal, and practical.

Our Heritage Kitchen became the right project for that because the concept has both emotional and technical weight. The emotional side is preserving family recipes before they disappear. The technical side is building the archive, account flow, content model, filters, release process, and trust boundaries that make that preservation usable.

That combination made the work feel real.

---

Where I Use This Now

Our Heritage Kitchen is the clearest artifact from this course. It shows how I approach a product that needs more than a homepage: structured content, user contribution, filtering, authentication, release discipline, and a clear reason for someone to care.

It also connects to the broader direction of my portfolio. I am not only trying to show that I can build pages. I am trying to show that I can understand a problem, define the product shape, make technical decisions around that shape, and release something that can improve through real feedback.

That is the kind of work I want my portfolio to represent.

---

FAQ

What is Project and Portfolio V at Full Sail University?

Project and Portfolio V is a web development course focused on moving an existing project toward staged delivery. The course emphasizes pitch and planning, metrics, business viability, compliance, security, versioning, release preparation, and postmortem reflection.

What did you build for Project and Portfolio V?

I built Our Heritage Kitchen, a family recipe archive where visitors can browse public recipes and contributors can preserve recipes with ingredients, steps, origins, family context, timing, photos, and practical cooking notes.

Why build a recipe archive instead of a standard recipe app?

A standard recipe app focuses mostly on cooking instructions. Our Heritage Kitchen focuses on preservation. The goal is to keep family recipes, origins, and practical kitchen knowledge from disappearing over time.

What does this project demonstrate technically?

It demonstrates full-stack product thinking: content modeling, public browsing, filtering, contributor workflows, authentication-aware design, release planning, metrics, security considerations, and a beta-ready product surface.

How does this connect to professional development work?

Professional development is not only feature delivery. It also involves planning, versioning, risk review, metrics, user feedback, and release communication. PP5 made those responsibilities part of the project instead of treating them as separate from development.