25 Sept 2026 · 5 min read
MVP development for startups: what to build first, and what to leave out
How we scope an MVP for a startup: the one flow that has to work, the features that wait, real prices and timelines, and the parts of MeltsWell's first version we'd cut if we did it again.
An MVP is the smallest version of your product that a real person can use from start to finish without you in the room. That's the whole definition. Nothing about it has to be ugly, and nothing about it has to be minimal in quality. It has to be minimal in scope.
Most founders we talk to agree with that sentence and then send a feature list with 30 items on it. So here's how we actually cut one down, with our own marketplace as the example.
What MVP development means in practice
MVP development is picking one path through your product and building it properly. Sign up, do the one thing, get the result. Everything that isn't on that path waits.
For MeltsWell, a marketplace for home bakers, the path was:
- A baker signs up and builds a page with their best creations.
- A buyer finds that page.
- The buyer taps a button and orders on WhatsApp.
Three steps. The first working version had those and an admin screen so I could approve new pages. It took seven weeks, from the first commit on March 25 to public profiles and a creator dashboard on May 3.
Everything else came later: Stripe billing (June), a free tier and new prices (July), coupons, featured spots, three languages, a mobile app (August). Some of it was right. Most of it was built before anyone asked for it.
The four questions we ask on a scoping call
1. Who has to show up first? Every product has one person without whom nothing happens. In a marketplace it's usually the seller. In a B2B tool it's the person who feels the pain, not the person who signs the contract. Build for that person first.
2. What do they do in the first ten minutes? Write it as a sentence. "A coach adds a client and sends them a plan." If you can't write it, you're not ready to build, and no amount of development fixes that.
3. What can a human do by hand for now? New MeltsWell pages went through an admin review panel, and I approved them one by one. That's fine at 50 users and it saves weeks of building automated checks.
4. What's the one number that tells you it works? For a marketplace like ours, a good one is how many seller pages get an order tap in their first week. Pick yours before you build, and make sure the MVP can measure it on day one.
What goes in a startup MVP
| Always in | Usually waits |
|---|---|
| Sign-up and sign-in | Teams, roles, permissions |
| The one core flow, end to end | A second or third flow |
| A simple dashboard to see your stuff | Custom analytics and charts |
| Analytics events on the core flow | A/B testing |
| An admin view for you | Self-serve settings for everything |
| One language | Translations |
| Transactional email (welcome, reset) | Newsletters, drip sequences |
| Error tracking | Performance tuning beyond "fast enough" |
Payments is the hard call. If people pay on day one because paying is the product (a booking tool, a paid course), it goes in. If you're charging for a subscription on top of a free product, it can wait. We built MeltsWell's billing before we had anyone to bill, then rewrote it a month later when real users showed us what they'd pay for. That's roughly four weeks we'd take back.
What we'd cut from our own MVP
Being honest about MeltsWell's first version:
- Three languages before launch. English, French and Arabic, and Arabic is right-to-left. It roughly doubled every UI task from April on. One language first.
- A seven-step onboarding. It worked, but three steps would have gotten the first bakers in just as well.
- Billing before users. Covered above.
- A photo upload flow with QR codes to move pictures from phone to desktop. Clever, and it ate most of a week in April. A plain file picker was enough.
What we'd keep exactly as it was: the leaderboard, the public page, the WhatsApp button, and the admin panel. Those four things were the product.
How much MVP development costs
Our prices, the same ones in the cost calculator:
| MVP type | Weeks | Price |
|---|---|---|
| Landing page + waitlist (test demand first) | 1 | $1,500 to $3,000 |
| Small tool: sign-in, one core flow, dashboard | 2 to 3 | $4,000 to $7,000 |
| Full product, first version | 5 to 7 | $10,000 to $20,000 |
| Two-sided marketplace | 6 to 9 | $15,000 to $25,000 |
| Mobile app (iOS + Android) with backend | 7 to 10 | $15,000 to $30,000 |
The full breakdown is in how much it costs to build an app, and the week-by-week story of MeltsWell is in how long it takes to build an app.
If a quote for a startup MVP comes back at six months and six figures, the scope is wrong, not the price. Ask what the first four weeks would ship.
App development for startups: web or mobile first?
Web first, almost always. You can ship a web app today and change it tonight. An App Store release takes a review, and your users have to update.
Go mobile first only if the product needs the phone itself: the camera, location in the background, push notifications as the core loop. MeltsWell started on the web in March and got its Expo mobile app in August. The mobile app had real screens on its first day because the API and the design already existed.
Signs your MVP is too big
- You can't demo the core flow in under two minutes.
- The feature list has a "phase 1" with more than eight items.
- Anything on the list starts with "users should be able to customize".
- You're building settings for a user you haven't met.
- The launch date moved twice and nobody outside the team has used it.
Signs it's too small
This happens less, but it happens. If the one flow doesn't produce the result someone signed up for, it's a demo and people will treat it like one. A buyer on MeltsWell who couldn't reach the baker would have closed the tab. The WhatsApp button was small, but without it the product didn't work.
How we run an MVP build
One call to scope the path. A fixed price for that scope. A demo every week, so you see it before we polish it. You own the repo from the first commit. Then launch, watch ten people use it, and decide what's next with real data instead of a guess. The longer version of what to demand from anyone who builds for you is in should you outsource your app.
If you have the path written down and want to know what it costs, tell us what you're building.
Written by Badr El Adraoui, founder of Node & Scale. Building something? Build with us.