A construction company posted a job on Upwork: convert a complex Google Sheets system into a full web application — materials database, BOM generation, quoting, supplier management, and job cost tracking across a full project lifecycle. Invite only. Serious build.
Most developers reading that post spent time writing a detailed proposal — tech stack recommendations, timeline estimates, architecture thoughts, questions about the current Sheet. Reasonable approach.
I spent 25 minutes building a live working demo and sent that instead.
Text proposals on Upwork are mostly identical. Everyone says they've done similar work, everyone lists their stack, everyone asks to see the Sheet. The client reads 15 of these and they all blur together.
A live link is different. The client clicks it before they've read your words. They're already inside something you built — something that looks like their problem — before they've evaluated you at all. The psychological dynamic shifts immediately.
The key is what you build. Not the whole thing — that would take days. Just the one feature the client called out as most important.
Reading the job post carefully, one section stood out. Under "Quoted vs Actual Job Tracking," the client wrote: "This is a key requirement." Then they described exactly what they wanted — quoted vs actual cost comparison, variance breakdown by materials, labour, and subcontractors, with reporting to identify underpriced jobs and overruns.
That's the POC. Not the materials database, not the BOM generator, not the supplier management — those are all important, but they're also expected. The variance tracking was the specific pain. Build that.
I described the feature to Claude: a job cost tracker with a dashboard showing quoted vs actual costs, variance calculations by category (materials, labour, subcontractor), summary metrics, and a chart. Real seeded data from a construction context. Clean UI.
Claude generated the HTML, CSS, and JavaScript. I reviewed it, adjusted the data to fit the construction/retrofit context from the job post, and pushed it to GitHub Pages.
25 minutes. Live at a public URL.
Step 1 — Read the job post properly. Not to extract requirements for a proposal. To find the one thing the client cares about most. It's almost always stated explicitly — either as "this is critical" or as the feature they describe in the most detail.
Step 2 — Decide: static or dynamic. Static demos (HTML/JS, no backend) deploy to GitHub Pages in seconds. Dynamic demos (database, server logic) go on Railway. For most POCs, static is enough — you're demonstrating the UI and logic, not a production system. If the job is specifically about backend architecture, Railway.
Step 3 — Describe it to Claude. Not "build me this app." Specific: what the data model looks like, what the UI should show, what interactions matter, what domain the data comes from. The more specific the prompt, the less back-and-forth. For this job: I told Claude it was a construction job costing system, described the variance dashboard, gave it the cost categories from the job post, and asked for seeded data that looked real.
Step 4 — Review and adjust. Claude gets the structure right. I adjust the seeded data to match the client's context, fix anything that looks off, and make sure it actually demonstrates the point. This is the 10-minute part, not the 2-minute part.
Step 5 — Deploy and link. GitHub Pages: push the file, enable Pages, get the URL. Takes under a minute. The demo goes live. The proposal goes out with the link in the first paragraph — not buried at the end.
Step 6 — Turn it off after a few days. The demo isn't a permanent portfolio piece. It exists for this proposal. Keeping it live indefinitely isn't necessary — and taking it down after the engagement decision keeps things clean.
The honest version: Claude writes the code. I direct it, review it, and make the judgment calls about what to build and how to frame it. That division of labour is the point.
Without Claude, building a working variance dashboard with a chart, seeded data, and a clean UI takes 2-3 hours minimum if you're doing it properly. That's not economical for a proposal — you'd only do it for jobs you're certain about. With Claude, 25 minutes is repeatable for any job where a POC makes sense.
The skill that matters isn't prompting — it's knowing what to build. Anyone can describe "a dashboard." Knowing to build the variance tracker specifically, because the client flagged it as a key requirement, because that's the thing that differentiates a construction estimating system from any other project management tool — that judgment is what Claude can't replace.
POCs work when the job has a concrete deliverable — something you can demo a slice of. Web apps, Google Sheets tools, dashboards, data pipelines, automations — all demoable.
POCs don't help when the job is discovery-first. "Help me figure out what to build" or "review our current system and recommend an approach" — these clients want to talk first, not see a demo. Sending a POC for these comes across as missing the point.
The other limit: don't build the wrong thing fast. A generic dashboard with placeholder data doesn't help. What helps is something that looks specifically like the client's problem — their domain, their terminology, their key metric. That requires actually reading the post.
Working on something similar? If you have a Google Sheets system that's outgrown itself — or a workflow that needs a proper application — we're happy to look at it.
Get in touch