Overview
Most portfolio pieces document months of work. This one documents two days.
Giftify is a deployed, production-grade web application: real database, real auth, real AI. A user who doesn’t know how it was built would have no way of knowing it wasn’t built by a dev team. It wasn’t. It was designed and built by one person, a senior designer midway through learning to code, over a single weekend.
Day one was design and build. Day two was infrastructure: deployment, external database, and a demo environment with daily-reset dummy data so anyone can try it without creating an account.
The goal was to test a specific end-to-end workflow: structured OOUX methodology feeding directly into AI-assisted development. But the result goes beyond proving a process. Giftify includes a working AI suggestion engine, a gift status pipeline, passwordless auth, serverless Edge Functions, and file storage. It’s the kind of product feature set that shows up in funding decks.
Most designers operate at one layer of AI: using it as a process tool, designing features that use it, or building with it. This project is the third. The other two are also on the resume.
Timeline
Day 1: Design and build
Day 2: Deployment and demo environment
Methodology
OOUX (Sophia Prater), vibecoding workshop facilitated by Maryann Bell
My Role
Solo. Brief through deployment.
Stack
React + Vite, Tailwind CSS, Supabase (PostgreSQL, auth, storage, Edge Functions), Claude API (Haiku), Vercel
The Problem
I’ve given a copy of Paulo Coelho’s The Alchemist to at least six people. I have no idea which six.
That’s not a quirky anecdote. It’s a genuinely under-served problem. Many of us have a short list of things we love to give: a book, a kitchen tool, a great candle. And most of us have completely lost track of who got what, when, and on what occasion. Layered on top of that is the perennial problem of holidays arriving faster than expected with no plan in place.
The concept: a personal gift management app that lets users track what they’ve given to whom, plan upcoming occasions, and surface smart suggestions based on their own giving history. No social layer, no marketplace. A focused personal tool.
Good POC problems aren’t arbitrary. Giftify has the right kind of complexity: simple enough to scope in a day, with enough real design tension to stress-test the methodology.
The recurring occasions logic alone is genuinely hard. If you add a holiday template and attach it to a contact, what happens when that contact’s birthday is entered incorrectly and later corrected? Does it cascade? What’s the user’s mental model of a “template” versus an “event”? These aren’t trivial questions. Surfacing them before a single line of code was written was the point.
The process
This project came out of a two-part learning experience: an OOUX intensive led by Sophia Prater, followed by a vibecoding workshop facilitated by Maryann Bell. The OOUX work happened in breakout groups, with each round resolved against Sophia’s working model. The vibecoding workshop outlined a structured methodology for moving from design artifacts into an AI-assisted build. I followed that pipeline end to end, on my own, with Giftify as the problem.
I’ve had enough front-end background (HTML, CSS, JS, some PHP and WordPress) to read what AI-generated code is doing and know when to redirect it. But this was my first time building and deploying an actual application. That context matters. This workflow didn’t require me to already be a developer. It required me to be a disciplined designer.
01
Brief
Sophia Prater wrote the project brief as the workshop’s shared starting point: a product description, user research quotes, and client constraints. Everyone in the workshop worked from the same problem. What each person built from it was their own. This is the real-world analog of a client kickoff: a defined problem, handed to a designer, with no predetermined solution.
02
OOUX Object Modeling
Before writing requirements or touching a build environment, the brief was decomposed into primary objects using the OOUX methodology: their attributes, relationships, and calls to action. This happened in breakout groups, with each round resolved against Sophia’s working model, pressure-testing the thinking before moving forward. The work ran in FigJam rather than Orcastra (the dedicated OOUX tool introduced in the workshop) because FigJam mirrors how this kind of collaborative work happens on a real team: sticky notes on a shared board. The resulting object model was exported as a structured JSON file to serve as the AI’s build context.
03
PRD
With the object model as the foundation, the brief was refined into a proper PRD through iterative questioning with Claude, one question at a time. The object modeling had already surfaced the hard design problems (recurring occasion logic, cascade behavior, template vs. event mental models), so the PRD could address them explicitly rather than defer them. Scope was pared to an MVP, future features sequenced into later milestones. Nothing was built until the PRD was agreed on.
04
Tech Spec
Stack decisions were locked in writing before any code was written: free and low-cost options only, React and Vite for the frontend, Supabase for the database and auth, Vercel for hosting. Agreeing to the stack explicitly meant no mid-build surprises about cost, compatibility, or scope creep into mobile or native territory.
05
Style Guide
With the stack agreed on, visual direction came next. Claude asked questions to narrow the feel: tone, warmth, use case context. The output was a style guide HTML file covering color tokens, typography scale (DM Sans), component states, buttons, inputs, cards, tags, border radius, and shadow specs. Fast to produce, immediately usable as a constraint during the build.
06
CLAUDE.md Context File
All prior artifacts were linked into a single structured markdown file: the PRD, tech spec, OOUX JSON, and style guide. This became the AI’s source of truth for the build. Instead of describing the product in natural language at the start of every session, the context file meant the AI was always working from the full design model. The build started from structure, not from a prompt.
07
Build
With all context in place, the build proceeded in Claude for VS Code through natural language prompting. No code was written by hand. The app was built incrementally: CRUD first, then AI integration, then auth, then photo support. The data layer started as mock data for fast UI iteration and migrated to a real Supabase database once the UI was solid. The OOUX model drove the data structure. The PRD defined the feature scope. The style guide constrained the visual output.
08
Deployment
Day two was getting it off localhost. Supabase for the external database, Vercel for hosting, magic link auth plus a demo account with daily-reset dummy data. Two serverless Edge Functions keep the Anthropic API key and the photo-fetch logic server-side, away from the browser. First time deploying a real application. It worked.
The OOUX Design Process
Object extraction → Attribute definition → Relationship mapping → CTA matrix
What Shipped
Shipped
- Full CRUD for five objects: recipients, products, holidays, occasions, and gifts, each with list view, detail page, and slide-in edit panel
- Gift status pipeline (idea → purchased → wrapped → shipped → received) with one-click advancement
- Product photos via file upload, URL paste, or auto-fetch of og:image from a purchase link
- Auto-create occasions across three years when a holiday is added
- Auto-create placeholder gifts from a holiday’s default recipients
- AI gift suggestions at the recipient level and the individual gift level, with one-click save to library
- Magic link authentication (passwordless)
- Two serverless Edge Functions keeping API keys server-side
- Supabase PostgreSQL with row-level security, deployed to Vercel
Three Remaining Gaps
- System holiday list (only Christmas and Easter pre-seeded; no curated picker)
- Total spend rollup on occasions (individual costs shown, no sum)
- Gift auto-naming from context (“Garlic Press for Luke”)
I stopped here intentionally. These gaps are real but minor. The goal was to demonstrate what the methodology could produce in a day, not to finish the product. The hard problems (auth, persistence, recurring occasion logic, AI suggestions) are all working. The three remaining items are polish, not architecture.
What this Demonstrates
For the methodology reader
OOUX isn’t a process tax. It’s a forcing function that surfaces design decisions before they become code problems. The recurring occasion logic that could have derailed the build was resolved at the object modeling stage, not during debugging. The AI built from a model, not from a wish.
For the AI-skeptic
Vibe coding without design thinking produces vibe results. The object model, the PRD, the tech spec, the style guide, the CLAUDE.md: each one was a design decision that constrained the build in a useful direction. The designer’s job didn’t shrink. It moved upstream.
For teams building AI products
The AI suggestion layer in Giftify isn’t a chatbot widget dropped into a corner. It’s a designed feature with two distinct entry points: suggestions at the recipient level (“get ideas for Luke”) and at the individual gift level (“ideas for Luke’s Christmas gift”). Results save directly to the product library with one click. The API call routes through a serverless Edge Function so credentials never touch the browser. That’s not a demo. That’s a shipped AI product feature, designed and implemented by a designer.
For the "can you actually build things" question
The app is live. Anyone can log in with the demo account and use it. That’s the answer.
What’s Next
If Giftify were a real project, the next phase would be bringing the design up to a proper standard. The current UI is coherent but not finished. DM Sans and the warm neutral palette were good instincts, and the component system has bones worth keeping. But it needs a real design pass: tighter spacing, better hierarchy, states and edge cases properly handled.
That’s actually a different and equally interesting portfolio story: a designer inheriting a vibe-coded MVP and bringing it up to production standard. I may document that process as a follow-on piece.
Solo. Brief to deployment, two days.
Working from Sophia Prater’s project brief, I collaborated on the PRD, ran the OOUX process, produced the FigJam documentation, defined the style guide, assembled the context files, built the working application in Claude for VS Code, and deployed it to Vercel with Supabase as the backend.
The methodology came from Sophia Prater’s OOUX framework and Maryann Bell’s vibecoding workshop. The execution, and the decision to actually do it rather than just attend the workshop, was mine.