Refract Group2026
MVP development
A working first version, designed and built by one team.
MVP development is the design and build of a product’s first usable version. It is usually eight to twelve weeks of work. We agree the scope and the price before we start, and the code is yours when we finish.
A small product that does one job in full
An MVP, or minimum viable product, is the first version of a product that lets its users finish one whole task. We design it and write the code, so the screens you approve are the screens that ship. Prism is our own product, and we designed and built it end to end. Our studio is in Sydney, Australia, and we work between Sydney and New York with founders and product teams.
Who the product is for, the one task it must let them finish and what waits for a later version. Settled with you before we design anything.
Every screen and state that task needs, including what a user sees when a step fails. The components become a design system in code.
Custom code, usually TypeScript, with Vue or React for the interface and Node or Python on the server. If you already have a stack, we work in it.
The code, the design files and the documentation, held in your accounts and written so another engineer can pick them up.
In short
What you get
A first version of your product that lets its users finish one whole task, live and in your accounts. With it come the design files, a design system in code and the documentation another engineer would need.
What it costs
We scope the build with you, agree its price before it starts and bill it in stages. An embedded team costs between $10,000 and $30,000 a month. A product sprint beforehand is $2,500 for the week.
How long it takes
Usually eight to twelve weeks from a settled scope to a product people can use. A product sprint before that is one week. Work can usually start within a couple of weeks.
When it’s not a fit
You don’t yet know who has the problem, a prototype would answer your question, the first version has to hold the whole roadmap, or you want it assembled in a no-code app builder. We build products in code.
From the scope to the first users
Read when to build a prototype and when an MVPAgree the first version
We settle who it is for, the task it must complete and what is left out. The price and the timeline are fixed here.
Design the whole task
We draw the flow from first screen to last, with its error and empty states. You see drafts as they are made.
Build from components
The components are written in code first and the product is put together from them. A working screen reaches your browser early.
Launch small
The product goes live for the people it was scoped for. A limited pilot is fine, provided those users know what it covers.
Hand over or carry on
By launch the code, files and documentation are in your accounts. Your team takes it from there, or we stay on and keep improving it.
Before and after an MVP
- EngineeringThe wider service, for a product that already exists: front end, back end and integrations.
- A product sprintOne week ahead of the build: a single problem taken to a working prototype and a build plan.
- Product designOnce people are using it, for the journeys that turn out harder than they should be.
Questions about an MVP
It depends on what the first version has to do, and we agree the price before the build starts. A project is scoped with you and billed in stages. A team by the month costs between $10,000 and $30,000. You can also begin with a single week of work for $2,500, credited in full if the build starts within 60 days.
Usually eight to twelve weeks. What moves it is how many kinds of user the product serves and how many other systems it connects to. We settle the scope and the timeline before any work starts. If the date matters more than the scope, tell us and we’ll cut the scope to fit.
A working product that the people it was scoped for can use to finish a task. You also get the code, the design files, a design system in code and the documentation. All of it sits in your accounts and belongs to you.
One person who can make decisions, and whatever you already know about the people the product is for. Send any designs, research or prototype you have. During the build we need you to look at drafts and use the working version. If you have engineers, we work in their repository and the code goes through their review.
Only when the open question is whether people understand the product. A prototype answers that, and parts of it can be mocked up. An MVP answers whether people keep using the product once it works. If you can’t tell which you need, a product sprint takes one week, costs $2,500 and ends with a working prototype and a build plan.
In code. We usually write TypeScript, with Vue or React for the interface and Node or Python on the server, and where you have a stack we work in that. We do build websites in visual builders such as Webflow. For a product we write code, and we do not build in no-code app builders. If one of those would get you an answer sooner, use it. We are the team for the version you expect to keep and extend.
You do. The code, the designs and the documentation are yours and sit in your company’s accounts. You are not tied to us once the product is live. It is documented so that an engineer you hire later, or another supplier, can read it and keep building.
That is your call. We can stay on and keep improving the product as people use it, or hand it to your engineers with what they need to run it. Staying on is an embedded team, from $10,000 to $30,000 a month. Either way, what the first users do with it should decide what gets built next.
Yes. You don’t need to read code. You need to know the people the product is for and be willing to decide what it does. You work with the designers and developers directly and use the product while it is being built. The code sits in your accounts, so any engineer you trust can check it.
Yes. Our studio is in Sydney, and the people who design a product here also build it. Prism is our own product, and we designed and built it end to end. Our usual client has raised a seed or Series A round, and we take on an earlier company when we can see a long partnership.
A closer look at the work
- Prototype vs MVP: what should you build first?A prototype tests a question. An MVP is a usable first product. Choose the next build by the uncertainty you need to resolve and what real use requires.
- What is a product sprint, and when should you run one?A product sprint takes one product problem and a fixed length, tests a working prototype with the people it’s for, and ends with evidence and a build plan.
- Design studio, in-house designer or design subscription?Choose a studio, in-house designer or subscription by the decisions, continuity and capacity you need. Compare the work each model can own, then the cost.
Know what your first version has to do?
Tell us who it is for and the one task it must do. We’ll tell you what we’d build first and what we’d leave out.
Most teams start with a call, then a sprint or an audit.
The people you’d work with, from the first call to launch