The expensive way to build software
The traditional path to custom software looks like this: someone writes a document describing what they think they want, hands it to a team of engineers, waits a few months, and gets back something that’s technically what they asked for but not what they meant. Then the expensive rework begins.
The problem isn’t the engineers. It’s that words on a page are a terrible way to describe a product. You don’t really know what you want until you can click on it.
What we’re doing instead
With this client, we’re prototyping in Cursor before a single production engineer touches it. He describes what he’s picturing, we build a rough working version he can actually use, and he reacts to something real instead of a paragraph. Then we adjust — fast — and do it again.
A prototype you can click through in an afternoon surfaces more real requirements than a month of meetings about a requirements document.
The point of the prototype isn’t to be the final product. It’s to make the thinking concrete so the expensive build is aimed at the right target.
The two things we hand the engineers
Once the prototype has taught us what the product actually needs to do, we turn that into two artifacts his engineering team can build against:
1. A product spec
Not a wish list — a clear description of what the software does, who uses each part, and what “done” looks like for every feature. Grounded in a working prototype, so it’s specific instead of hand-wavy.
2. A data model
What information the system stores, how the pieces relate, and the rules between them. Getting this right early is the difference between software that scales and software that has to be rebuilt in a year.
Handing an engineering team a validated prototype plus a clear spec and data model is a completely different starting line than “here’s my idea, go.” They spend their expensive hours building, not guessing.
Where I fit — and where I don’t
I’m not pretending to be his engineering department. His team will build and own the production system. What I bring is the product thinking up front: shaping the idea, pressure-testing it against something real, and translating “what the business needs” into “what the engineers can build.”
That gap — between a business owner’s vision and an engineer’s ticket — is where a lot of software money gets wasted. Filling it with a fast, cheap prototype is one of the highest-leverage things you can do before committing a real budget.
Why this matters even for small businesses
You might not be building custom software. But the principle scales down: make it real before you make it expensive. A rough working version — a landing page, a form, a simple tool — tells you more about whether an idea works than any amount of planning. Tools like Cursor make that first draft cheap enough that there’s no excuse to skip it.
If you’ve got an idea for a tool or product and you’re not sure it’s worth a full build yet, that’s exactly the kind of thing I like to prototype. Book a free conversation and we’ll turn the idea into something you can actually click on.