A working product in four to six weeks.
Builds run $6,000–12,000 depending on scope and complexity, fixed before anything starts. Architect-led, using AI tooling deliberately — not a team of juniors learning on your budget.
You have a validated idea and no one to build it.
- Non-technical founders with a real idea and no technical co-founder
- Funded startups who need something in market before the next milestone
- Established businesses testing a new product line without committing internal resources
- Anyone quoted six figures by an agency who suspected there had to be another way
Why not just build it yourself with Claude or Cursor?
You should ask this. A $200 subscription against a several-thousand-dollar build is a real comparison, and anyone who tells you the tools can't do it is either behind or selling something.
They can do it. People ship real products this way every week, and some of them are good. So here is the honest version of when you shouldn't hire anyone.
You're technical, or willing to become technical. You're still testing whether anyone wants this. It's mostly forms, lists and a database. You have more time than money, and no fixed deadline. In all four cases, go build it — genuinely. Come back when it starts mattering.
What you're actually paying for is not the typing. The tools write code faster than any human. What they don't do is decide — and the decisions are where products get expensive.
- The data model. Get this wrong and you don't find out for three months, at which point every feature you've built sits on top of it. This is the single most common reason a working product becomes unworkable.
- Authentication and permissions. Not "does login work" but "can user A reach user B's data through an endpoint nobody thought about." AI writes the login screen correctly and the authorization check inconsistently.
- Money. Payment retries that charge twice, webhooks nobody verifies, no audit trail when a customer disputes a charge. Fixable in an afternoon if you know to look, expensive if you don't.
- Knowing what to leave out. Most self-built MVPs are three times bigger than they need to be, because every conversation with an AI ends in more features. Scope discipline is a judgment call, and it's the one that decides whether you launch in six weeks or six months.
- What happens on change three hundred. Code generated without tests works until you modify it. Then every fix breaks something else, and nobody — including the AI — holds enough context to tell you why.
And the cost that isn't on the invoice. A non-technical founder building their own product spends three to six months on it. That's not a criticism — it's a genuine education and plenty of people conclude it was worth it. But if your idea has a window, or you have customers waiting, or your own time has a market rate, do that arithmetic before comparing a subscription to a build.
We build with the same tools. The difference is fifteen years of knowing which of their outputs to keep.
What "MVP" means here.
Not a prototype. Not a clickable mock. A deployed product real users can sign up for and use — with authentication, a database, payments if you need them, an admin view, hosting, monitoring and a deployment pipeline. Small in scope, complete in function.
The scope discipline is the point. Most MVPs fail because they try to be version three. Discovery exists to cut the feature list down to what actually tests your idea, and then to hold that line.
Discovery, and what you walk away with.
Priced low deliberately, so the decision to start is an easy one. It exists because fixed pricing is impossible without it — and because you deserve to see how we think before committing to a build.
Everything below is yours to keep, whether or not you continue. Take it to another developer if you'd rather. It's a specification, not a sales document.
- A written product specification. What's being built, in plain language: every screen, every user action, every rule. The document both sides point at when there's a disagreement later.
- User flows. Step by step, from sign-up to the thing your product actually does. This is where most surprises surface — usually a step nobody had thought about.
- A data model. What gets stored and how it relates. The decision that's cheapest to change now and most expensive to change in month four.
- Architecture and stack choice. What gets used, where it's hosted, and why — explained so you can evaluate it, not just accept it.
- An explicit scope line. What's in version one and what's deliberately deferred. The deferred list is often the most valuable page in the document.
- Risks and unknowns. The parts that could go wrong, what they'd cost, and what we'd do about them.
- A fixed quote for the build. A real number and a real date, not a range. Valid for 30 days.
- A walkthrough call. We go through all of it together and you ask whatever you want.
Sometimes discovery concludes that you shouldn't build it — the scope is wrong, the idea needs testing first, or an off-the-shelf tool already does it. You'll be told that plainly. It's a cheaper outcome than finding out in week five.
How a build runs.
Discovery — $500
A few days. Produces everything listed above, including a fixed quote for the build. Credited against the build if you continue.
Build — four to six weeks
Working software in a staging environment from the first week. Weekly demos and written updates. You see progress continuously rather than at the end.
Launch
Production deployment, monitoring, documentation and handover. Everything in your repository and your cloud accounts.
After
Most clients move onto a retainer. Some take it in-house. Some do nothing for six months and come back. All fine — there is no lock-in of any kind.
What you get
- Product specification and architecture
- Full-stack build in Node, Rails or Python
- Authentication and user management
- Payments integration where needed
- Admin interface
- Clean, professional interface built on an established design system
- AWS deployment with CI/CD
- Monitoring and error tracking
- Automated tests on critical paths
- Documentation and handover
What's out of scope
- Native mobile applications
- Custom visual design. Builds use an established component system, which looks clean and professional but is not bespoke. If you want custom design, we'll introduce a designer and their fee is separate — budget $3,000 upward.
- Content, copywriting and brand work
- Anything outside the agreed specification, which becomes a change order priced and agreed before any work starts
Fixed, and agreed before anything starts.
| Stage | Price |
|---|---|
| Discovery Full specification, data model, scope line and a fixed build quote. Yours to keep either way. Credited against the build. | $500 |
| Focused build One kind of user, one core workflow, sign-in and a simple admin view. No payments, no third-party integrations. | from $6,000 |
| Standard build Two or three user types, payments, a couple of integrations, a real admin dashboard. The most common shape. | from $9,000 |
| Complex build Roles and permissions, multi-tenancy, several integrations, background processing or anything with regulatory weight. | from $12,000 |
Price follows scope and complexity, not a clock. The bands above describe what's being built, not how long it takes — two products of the same size can differ by a factor of two depending on integrations, permissions and how much of it is genuinely novel. Discovery establishes which band yours sits in and produces the number.
50% deposit to begin, balance net 14.
Before you book.
Why can't I just build it myself with Claude or Cursor?
Often you can, and sometimes you should — there's a full answer to this further up the page, including the cases where hiring anyone would be a waste of your money. The short version: the tools write code faster than any human, but they don't decide. The data model, the permission boundaries, the payment edge cases and the scope discipline are what you're paying for, and they're the things that decide whether the product still works in month six.
Why is discovery only $500?
Because the decision to start should be easy. It's priced to remove friction, not to make money — and you keep everything it produces regardless of what you decide next, including the specification and the quote.
Why is the build a range rather than a price?
Because an honest fixed price requires knowing the scope, and nobody knows the scope before discovery — including you. The bands tell you the neighbourhood; discovery produces the number.
Do you bill by the hour?
No. Every engagement is a fixed price agreed in advance, based on what's being built rather than how long it takes. You should not have to audit a timesheet to know whether you got value, and we shouldn't be penalised for being fast. If the scope changes, that's a change order with its own price, agreed before any work starts.
What if I need changes mid-build?
Small things get absorbed. Anything that moves the scope becomes a change order with a price and a revised date, agreed before any work happens. That protects you as much as it protects us.
Who owns the code?
You do, entirely, from the first commit. It lives in your repository and deploys to your cloud account.
What stack will you use?
Node, Rails or Python depending on the problem, deployed on AWS. The choice gets explained during discovery. All boring, well-supported technology any competent developer can pick up later.
What about design?
Builds use an established component system — clean and professional, but not bespoke. Most MVPs don't need more than that, because you're validating an idea rather than winning a design award. If you do want custom design, we'll bring in a designer and their fee is separate.
What if the build runs over?
The price is fixed. If the scope was estimated wrong, that's our problem, not an invoice. If you change the scope, that's a change order agreed in advance.
Tell us what you're trying to build.
Twenty minutes. You describe the product, we'll tell you what it realistically takes and what it costs — including whether it's smaller than you think, or whether you'd be better off building it yourself.