What if the MVP proves the idea doesn't work?

Then it did its job for a fraction of what finding out later would have cost. That's the entire point of spending six weeks instead of a year, and it's a better outcome than a beautifully built product nobody wants.

Is the code throwaway?

No. Small scope, full standards - typed, reviewed, deployed on CI. If the idea works you keep building on it; the MVP boundary is what we left out, not the quality of what went in.

Can you build on the MVP afterwards?

Usually we do, either as a phased SaaS build or a monthly retainer. You're not obliged to - you own everything, and plenty of teams take it in-house at that point.

How is a fixed price possible on something this uncertain?

Because the scope workshop comes first and produces a written, bounded scope. We price that. If you change it mid-build we re-quote the delta openly rather than absorbing it quietly and cutting corners elsewhere.

Do you take equity instead of fees?

Occasionally, as part of a mix, and only where we'd have taken the project anyway. It's a conversation, not a standard offer.

Service 03

Ship the smallest thing that proves you're right.

An MVP isn't a worse product, it's a smaller one. We cut scope until only the core loop is left, then build that part properly - because a rough prototype tells you people dislike the execution, not whether they want the thing.

Start a project How pricing works

MVP Development

Typical timeline: 3 to 8 weeks
Engagement: Fixed scope, fixed price
Who you work with: Product designer, full-stack engineer

Get a scope and a number

3-8

Weeks from first call to live

Core loop, built well, nothing else

100%

Production standards, not throwaway code

48h

Typical turnaround on a scope and quote

Before we start

What usually brings people here

The scope keeps growing

The feature list started at six and is now at thirty. Every one feels essential, launch keeps moving, and nothing has been in front of a real user yet.

Six months in, nothing shipped

A freelancer, then another, then a rebuild. Burn is real, learning is zero, and the market has had half a year to move without you.

The demo undersells the idea

A no-code prototype held together with duct tape gets tested and people bounce. You learn the mock is bad, which is not the question you were asking.

What's included

What you get

A live product, the evidence to read it, and a codebase that's a starting point rather than a liability.

A scope you can defend

A workshop that ends with a written core loop and an explicit not-now list. Everything that survives ships; everything that doesn't is recorded, not forgotten.

A clickable prototype first

The real flows, designed and linked, in week one. Put it in front of five people before a line of production code exists.

Production-standard build

Typed, reviewed, tested where it matters, deployed on CI. Small by design, but not the kind of small you have to throw away in March.

Accounts and payments if the loop needs them

Sign-up, sessions and Stripe checkout wired properly, because 'would you pay' is answered with a card form, not a survey.

Instrumentation from day one

Analytics on the events that define activation, plus a funnel view, so week two produces a number rather than a feeling.

A roadmap out of the MVP

A written view of what to build next depending on what the data says, including the parts we deliberately deferred and what they'd cost.

The process

How the build runs

Four weeks is the common case. The shape is the same whether it's three or eight.

Talk it through with us

01
Scope workshop
Half a day. The user, the problem, the single loop that proves the idea, and the hypothesis we're testing. Ends with a fixed scope and a fixed price.
02
Design sprint
Week one. Flows and screens to production fidelity, assembled into a clickable prototype you can test on real people immediately.
03
Build
Weeks two to three or four. Staging updated continuously, a short check-in twice a week, no disappearing acts.
04
Launch
Domain, analytics, error tracking and a soft launch to your first cohort, with us watching the logs for the first few days.
05
Read the results
Two weeks after launch we go through the funnel together and decide, on evidence, what happens next.

Under the hood

What it's built on

Mainstream, well-supported tools your next developer will already know. We pick per project - this is the shortlist we choose from.

Application

Next.js
TypeScript
Tailwind CSS
shadcn/ui

Data and auth

Supabase
PostgreSQL
Prisma
Auth.js

Payments and mail

Stripe
Resend
Twilio
Cloudinary

Measurement

PostHog
GA4
Sentry
Vercel Analytics

Straight answer

Is this the right thing to buy?

We'd rather point you elsewhere on the first call than take on work that was never going to land well.

A good fit if

You can name the one assumption the build has to test
You're prepared to launch something smaller than the vision in your head
You have a route to the first fifty users, even a manual one
You'd rather have real data in six weeks than a full product in nine months

Probably not a fit if

The scope genuinely can't be cut - that's a product build, and we do those too
You need enterprise compliance in place before launch
There's no plan for getting anyone to use it once it's live

Questions

The ones we get asked most

Anything not covered here, message us - you'll get a real answer from someone who'd be working on it.

Also part of the offer

Tell us what you're building.We'll tell you what it takes.

A short call is usually enough to size the work. You get a fixed scope, a timeline and a real number - normally inside 48 hours.

Book a call See the work