On this page
A client posts a job: they want virtual try-on for their jewelry store — point your camera at your hand, see the ring on your finger. Dozens of freelancers will reply with some version of the same proposal: relevant experience, similar projects, happy to discuss.
I replied with a URL. Behind it was a working camera-based try-on demo — rings on hands, necklaces, watches, running against real product photos — that I had built and deployed to a live domain in about two hours, between reading the job post and sending the proposal. The proposal itself was two sentences long, and the honest one mattered most: I put up this quick prototype for you in just two hours using AI tools.
Why a demo beats any proposal
A proposal is a claim about the future. A demo is evidence about the present. The client’s actual anxiety when hiring a freelancer isn’t “does this person have six years of experience” — it’s “will anything real ever appear, and how long will it take.” A live URL answers both questions before the first conversation.
It also reframes the entire negotiation. Every other bidder is asking the client to imagine the product. You’re asking them to critique it — “the ring placement drifts on small hands” is a conversation between a client and their developer, and it’s happening before the contract exists. You’ve skipped the audition and started the job.
And there’s a filtering effect I didn’t expect: a demo makes bad clients disqualify themselves. Someone who sees a working prototype in their inbox and still wants to haggle over rate was going to be painful anyway.
The honest part: say how it was made
I told the client it took two hours and that AI tooling did the heavy lifting. Some freelancers would hide that, on the theory that effort is the product. Effort is not the product. Shipped software is the product, and “this person can go from your job post to a deployed demo in two hours” is a far stronger claim than “this person worked very hard.” The speed is the pitch — it’s a preview of what the whole engagement will feel like.
What two hours actually buys
The scope discipline matters more than the tooling. A two-hour prototype must be:
- The one thing the job post is about, and nothing else. The job was try-on. So: camera, overlay, a handful of real products. No accounts, no cart, no admin, no mobile app. Every minute spent on anything the client didn’t ask about is a minute stolen from the thing they did.
- Demoable, not correct. The ring doesn’t need jeweler-grade tracking; it needs to make the client involuntarily point their camera at their own hand. A prototype’s job is to create belief. Production comes later, and is billed accordingly.
- On a real URL. A screen recording is a claim; a link is an experience. The difference in impact is not small.
The AI tooling is what compresses the build itself — scaffolding the camera pipeline, the overlay math, the UI — into the time window. Two hours was not possible for this kind of demo a few years ago. It is now, if you don’t waste any of them.
The deploy has to already be solved
Here’s the part that actually makes two hours real: the deployment took minutes, because the rails already existed. The demo went out through the same infrastructure everything else I run goes through — a Coolify instance on my own hardware, fronted by Cloudflare, with DNS a single API call away. I’ve written up that whole stack in my $0 infrastructure post; the short version is that “put this container on a subdomain with TLS” is a five-minute operation for me, every time, because it’s the same operation every time.
One convention from that setup that earns its keep here: origins stay plain HTTP and Cloudflare terminates TLS at the edge. Set it up any other way in a hurry and you’ll burn twenty of your hundred and twenty minutes staring at a redirect loop between two layers that each think the other should handle HTTPS.
If deploying something new takes you an afternoon of fiddling, the two-hour prototype strategy is closed to you — not because you can’t build fast, but because your last mile is slow. Fix the last mile once, and every future proposal inherits it.
When not to do this
Scope honesty cuts both ways, so: I don’t do this for every job.
- Vague briefs — if the post doesn’t name a concrete thing, there’s nothing to prototype, and guessing wastes the advantage.
- Jobs where the hard part is invisible — a migration, an audit, a rescue. A flashy demo of the easy 5% would misrepresent the work. For those, the equivalent move is a sharp diagnostic: read what they’ve shared, name the actual problem, propose the first step.
- Prospects who’d mistake the demo for the deliverable — the two-hour version is a sales artifact. If the conversation starts drifting toward “can we just launch this,” that needs correcting early and in writing.
The general principle
The cost of demonstrating competence has collapsed. Most of the market is still bidding as if it hasn’t — competing on adjectives in a text box. For any job where the deliverable is visible software, the strongest possible proposal is a small, real, deployed piece of the deliverable itself, plus an honest sentence about how fast it happened.
Two hours of building beats two hours of writing about building. It isn’t close.