When a Prototype Replaces a PowerPoint
A client showed us their designs. Among them, an animated globe. Core to the UI delightfulness, technically non-trivial, the kind of thing that usually gets a “we’ll figure it out during development” footnote in proposals. I decided to check how hard it actually was.
Two hours later, I wasn’t just playing with a spinning globe. I had built a working prototype of the entire application, filled not with mock user data, but with our proposal. Timeline. Cost breakdown. Tech stack. Team composition. All wrapped in an interface that looked like the product the client wanted to build.
Instead of sending slides or a PDF, we sent a link.
Why This Worked
The context mattered. This wasn’t an RFP with strict deliverable formats. The client had shown us designs, not requirements documents. They were visual thinkers building a visual product. A clickable demo spoke their language.
There was also timing. We delivered the prototype a day after our initial call. The speed itself was part of the message: this is how we work.
And there was proof embedded in the delivery. The animated globe, the thing they cared about most was already spinning. No promises, no “we’ve done similar things before.” Just the thing, working.
How?
I used Cursor. The flow was surprisingly fast, especially with a clear Figma design reference to work from. Most components came together in minutes. Layout, navigation, colors, assets, data display, even some fancy animations matching the style of the produt - all straightforward when you’re not inventing, just translating.
The globe was different. Getting the 3D rendering to behave, the rotation to feel right, the layers to not overlap incorrectly: that took most of the time. I eventually had to step in and fix some things manually. AI got me 90% there, but the last 10% needed human judgment.
What it looked like:
Below is a different demo I built for this article, a fitness app “proposal” with completely made-up (even bullshit) content. The real client project looked similar in structure, but I can’t share it here.
There’s another reason this worked so well: the output didn’t need to be bulletproof. No edge cases. No error handling. No production-readiness. Just a clickable thing that looks right and tells a story. AI-assisted engineering (or even vibe-coding) shines in exactly this kind of context, when “good enough to demo” is the actual bar, not a compromise.
That’s the pattern worth noticing: when quality expectations drop from “production” to “communication,” the economics of custom development flip completely.
When This Makes Sense
Not every proposal should be a prototype. This approach works when:
- The client thinks visually. Designers, product people, founders with strong opinions about UX — they respond to interfaces, not bullet points.
- There’s no rigid format expected. RFPs with mandatory sections and scoring rubrics aren’t the place for creative delivery.
- You can move fast. The impact comes from speed. A prototype delivered a week later loses the “wow” factor.
- The product has a signature element. Something the client clearly cares about — a visualization, an interaction, a unique flow. If you can nail that one thing, the rest of the proposal writes itself.
If none of these apply, a well-structured document is still the right answer. The goal isn’t to be clever. It’s to communicate effectively.
The Deeper Point
This isn’t really about proposals. It’s about recognizing when AI-assisted engineering changes what’s possible, not just what’s faster.
Two years ago, building a custom interactive demo for a single sales opportunity would have been absurd. Too expensive. Too slow. Not worth the risk if you don’t win the deal.
Now it’s a two-hour experiment. If you work with clients — whether as a freelancer, a sales engineer, or someone building proposals at a software house — this is worth thinking about. Not as a process to adopt, but as a capability to have in your back pocket.
Sometimes, showing beats telling. And now, showing is cheap.