Brutal prioritisation
We cut the 80% of features that do not matter yet, so you can launch the 20% that do.
Startup MVP Development
Startup MVP Development
The honest way to build a first version. Core utility and speed to market, so your MVP actually survives its first users.
Typical scope
Scoped first release
Delivery style
Founder-ready
Launch focus
Launch learning
What you get
A first version shaped around one real question
The work is scoped around the few decisions that matter most for a first release: the core workflow, the technical shape, and the path to launch.
Clean tech foundation
Code that can scale, not throwaway hacks you have to rewrite the moment the product works.
Direct feedback loop
You work directly with the builder. No project managers, no lag — just real progress, weekly.
A release, not a demo
Deployed on your own domain with accounts, analytics, and error reporting wired up. Real people can sign up on launch day.
A written not-yet list
Everything we deliberately left out, and why. It is what stops the second release turning into an argument about what was promised.
The repository, from day one
Code in your own account from the first commit, on a stack a New Zealand developer can pick up. No handover ceremony, because it was never mine to hand over.
The offer
Scope it properly, then build it
The scoping sprint is paid on purpose. It is the only honest way to put a fixed price on an idea that is still too wide — and it is credited in full against the build, so nobody pays for it twice.
one week
NZD 1,500
Credited in full against the build if you go ahead within three months.
A scoping sprint
One week, ending in a written scope you could hand to any developer.
Most MVPs fail on scope, not code. A week spent cutting the idea down to one question real usage can answer — and pricing what is left honestly.
Best for
Founders whose idea is still too wide to quote, or who have been given wildly different numbers by three different developers.
- The one decision your first release has to inform
- The core workflow, screen by screen
- An explicit not-yet list — the part that saves the money
- A technical shape and a fixed price for the build
- Yours to keep, even if you build it with someone else
fixed price
NZD 8,000 – 15,000
Quoted exactly after the scoping sprint. The range covers most first releases.
An MVP build
Four to eight weeks to a release real users can sign up for.
The first version, built and launched. Narrow enough to ship this quarter, solid enough that you are not rewriting it the moment it works.
Best for
Early-stage products that need a working release in front of real users, not another round of clickable mock-ups.
- The core workflow built properly, end to end
- Accounts, payments, and email if the product needs them
- Launched: domain, hosting, analytics, error reporting
- Weekly working builds — you see it move, not a status report
- Code you own on a stack you can hire for, handed over on day one
Proof and fit
Good fit when you need
- You have a product idea but the first version is still too wide.
- You need help choosing what to build now and what to postpone.
- You want a working product, not just a clickable mockup.
- You need technical judgment before committing more time or budget.
Why this approach works
Shan Studio keeps strategy, UX, and implementation close together. That reduces handoff loss and helps founders move from idea to real product faster.
If the first question is still whether the core idea works at all — especially if that question sits inside an AI workflow — start with AI prototyping instead. If you already have a written scope, send it through and I will quote the build.
How the work moves
Scope, shape, build, launch
You get weekly working builds rather than status reports. The point of showing it early is that changing direction is cheap in week two and expensive in week seven.
01
Scope
Clarify the goal, audience, constraints, and the smallest useful version.
02
Shape
Turn the scope into screens, flows, technical decisions, and a build plan.
03
Build
Implement the core product directly, review progress, and adjust without heavy handoffs.
04
Launch
Prepare the release, fix the rough edges, and define the next iteration from real feedback.
Most focused projects move from scope to first release in weeks, not months.
FAQs
Questions founders ask
If something else is on your mind, just email me — a real reply, not a sales sequence.
What technology do you use for MVPs?
Modern, lightweight, widely used stacks — usually TypeScript on the web with a managed database. Boring on purpose, so another New Zealand developer could pick it up without a tutorial.
What is the typical MVP budget?
Most MVPs fall in the NZD 8,000 to 15,000 range for a launch-ready version. The exact number comes out of the NZD 1,500 scoping sprint, which is credited in full against the build.
How long does it take?
Four to eight weeks of build after the scoping week — narrow enough to ship this quarter, solid enough that you are not rewriting it the moment it works.
Do you help with the launch?
Yes. Domain, hosting, analytics, and error reporting are part of the build — real people can sign up on the day it goes live.
Can we add features later?
Yes. The build is modular so the MVP can evolve into the full product, and you get a written list of what was deliberately left out and why.
Do you work for equity?
No. Fixed price on a written scope, so both sides know exactly what is being delivered and when it is finished.
Build a launch-ready MVP
Ready to move from “thinking” to “shipping”? Tell me about your core feature and I will send back a suggested scope — or an honest reason to start smaller.
NZD 1,500scoping sprint, credited against the build
The build itself is NZD 8,000–15,000, quoted exactly once the scope is written. Prefer email? Write to me directly.
You'll hear back directly from me within one business day.