MagicPath gave me a blank check: build whatever. I picked Contra because it’s messy in the right ways: payments, trust signals, discovery, publish flows, and social exports. Rebuilding it inside MagicPath would either prove the platform or expose it. I built the real bits, wired the interactions, and left a kit the platform team could reuse. That’s it. No fluff. Real work.

Demos are jokes if they don’t behave like products. MagicPath needed something believable: a multi-surface example that handles real product friction. Payments. Metadata. Discoverability. Social exports. And the prototype had to be reusable not glued together for one demo and thrown away.

Constraints: one month, 4×30m syncs, and a prototype that’s polished enough to demo and practical enough to reuse.

Week 1 — Decide the scope. Pick the surfaces: invoice/metadata, project pages, library, discovery UI, social composer. Decide fidelity: realistic, not perfectionist.

Week 2 — Component map. Break Contra into plug-and-play blocks: header, invoice strip, gallery, discovery chip, composer. Design them to be reusable.

Week 3 — Build in MagicPath. Wire pages, data stubs, exports, and interactions. Make it feel like a product you can click through.

Week 4 — Polish & handoff. Fix edge cases, add tiny accessibility prompts (alt text nudge, contrast hints), and write a short reuse guide.

No showy micro-animations. No theatrics. Just the stuff that makes a prototype actually useful.

Invoice / metadata strip — author, linked job, payment timeline, discovery score (hero shot above).

Project detail flow — Context → Challenge → Process → Outcome, with gallery, metrics, and ownership cues.

Showcase library — filterable grid, surfaced discovery score, job links.

Social composer — one-click social cards, caption templates, and auto-tag behavior so creators actually publish.

Component kit — headers, metadata strip, galleries, metrics strips — drop-in parts for future prototypes.

Everything was wired-up: data stubs, interactions, export flows. Not a static mock. A usable kit.

I cared about this one because prototypes often lie. They look like products but don’t behave like them. So I built a prototype that behaves. It has invoices that read like invoices, discovery that surfaces real decisions, and a sharing flow people can actually use.

That made the work useful to MagicPath: they didn’t just get a pretty example, they got a kit that sped up demos and reduced the friction of future prototypes.

If there’s a takeaway: build prototypes that earn their keep. This one does.