Startups should custom-build only the core workflow that customers will pay for, the one thing that makes the product different, and rent or buy everything else: logins, payments, email, analytics and support. Skip native apps on both platforms, elaborate admin panels, microservices and "nice to have" features until paying users ask for them.
Early money is the most expensive money a founder spends. Every week of building the wrong thing is a week not spent learning from customers.
What should a startup build first?
Build your core loop: the shortest path from a user arriving to that user getting the result they came for. For a booking platform, that might be "find a slot, book it, get a confirmation." For a B2B reporting tool, "connect data, see the report, share it with the boss."
Write it as a single sentence: one type of user, doing one job, getting one outcome. If you cannot, the product is not focused enough to build yet.
Everything in your first version should either be part of that loop or be the minimum needed to make it safe and usable. Our guide to building an MVP without wasting money goes deeper into scoping a minimum viable product, meaning the smallest version that real users will actually use.
What should you build, buy or skip at the start?
Most of what a modern app needs already exists as a reliable, affordable service. Building it yourself adds cost and maintenance without making you any more different from competitors.
| Capability | At first version | Why |
|---|---|---|
| Your core workflow | Build | This is your product and your advantage |
| Login and sign-up | Buy (authentication service or framework standard) | Security-sensitive and solved; don't reinvent it |
| Payments and subscriptions | Buy (Stripe, Razorpay or similar) | Compliance, tax and card handling are specialist work |
| Transactional email and SMS | Buy | Deliverability is hard to get right yourself |
| Product analytics | Buy | You need data from day one, not a custom dashboard |
| Customer support chat | Buy, or just use email and WhatsApp | Volume is low early on |
| Admin panel | Build a basic one, or use an admin framework | Enough to fix data and help users, nothing fancy |
| Native iOS and Android apps | Skip, start with a responsive web app | One codebase while you learn |
| Multi-language, multi-currency | Skip, unless your first market needs it | Doubles testing for little early value |
| Complex roles and permissions | Skip beyond two or three roles | Add as real teams demand it |
| Microservices architecture | Skip | A well-structured single app is faster to change |
| AI features | Build only if AI is the core value | Otherwise it is cost and complexity, not differentiation |
What should you deliberately leave out of version one?
Founders rarely regret what they cut; they regret what they spent months building that nobody used. Common candidates for the "later" list:
- Settings pages for every preference. Pick sensible defaults.
- Detailed reporting. Export to CSV covers early needs.
- Integrations nobody has asked for yet. Wait for the first customer who will pay for one.
- Pixel-perfect polish on secondary screens. Polish the core loop; keep the rest clean and functional.
- Automations for tasks you do ten times a month. Do them by hand until volume justifies the build.
A useful filter: a feature makes version one only if a paying user cannot get value without it. Everything else goes on a written backlog, so ideas are captured rather than lost, and nobody feels ignored.
How do you test demand before writing code?
Before committing a large budget, check that people want the outcome. Options include a landing page that explains the offer and collects sign-ups, a clickable prototype shown to target customers, or delivering the service manually for a handful of customers behind the scenes.
Paid ads can speed up that test, but costs vary enormously by market and offer. Across the ad accounts we manage, an immigration and study-abroad consultancy's best lead form brought in 245 leads at $0.34 each, while a removals company paid roughly $13–27 per lead. Neither number predicts yours; the point is that a small, time-boxed test gives you real data on what attention costs in your niche before you build.
How much should a startup spend on its first build?
Typical ranges we see for an MVP web app or SaaS are US$15k–50k globally, ₹4–12 lakh in India and A$25k–80k in Australia, with timelines of roughly 8–16 weeks. These are estimates; scope moves the number more than anything else. Our breakdown of how much an MVP costs to build in 2026 explains what pushes a project to either end.
Budget for what comes after launch as well. Maintenance typically runs 15–25% of the build cost each year, and you will want money left for the changes users ask for in the first few months. A startup that spends its entire budget reaching launch has nothing left to respond to what launch teaches it. Many founders hold back a meaningful share of the budget for post-launch iteration.
Should a startup start with no-code instead?
Sometimes, yes. No-code tools are excellent for validating demand, building internal processes and testing a workflow with early users. They become a constraint when you need custom logic, performance at scale, complex data or full ownership of your platform.
A sensible path for many founders is: no-code or manual delivery to prove demand, then a custom build of the core loop once you know what works. Our comparison of low-code, no-code and custom development sets out the trade-offs honestly.
Which foundations should never be skipped?
Cutting features is smart. Cutting foundations is expensive later. Even the leanest first version should have:
- Basic security: properly hashed passwords, HTTPS everywhere, admin accounts protected with multi-factor authentication, and secrets kept out of the code.
- Backups that run automatically and have been restored at least once.
- A sensible data model. Fixing the database structure after you have thousands of records is painful.
- Analytics events on the core loop, so you can see where users drop off.
- Code and accounts you own. The repository, hosting and domain in your company's name.
- A few automated tests on the parts that handle money or permissions.
- Privacy basics if you collect personal data: a clear notice, consent where needed, and the ability to delete a user's data.
What comes after the first version?
Let usage decide. A typical sequence:
- Launch to a small group and watch how they use the core loop.
- Fix friction first. Where people get stuck matters more than new features.
- Add the most-requested capability that paying customers would miss.
- Automate the manual work that has started to hurt as volume grows.
- Revisit the "skip" list quarterly and promote items only when evidence supports them.
Once version one is live, our guide to custom software development for growing businesses is a useful map of what growing software needs next.
Frequently asked questions
Should my MVP be a web app or a mobile app?
For most startups, a responsive web app comes first. It works on every device, needs one codebase, and avoids app-store review cycles while you are still changing things weekly. Build a native app when your core loop depends on phone features or daily habit.
How many features should an MVP have?
As few as it takes to complete the core loop well. There is no magic number, but if your list of must-haves runs to dozens of items, it probably contains several products. Cut until each remaining feature is essential to one user getting one outcome.
Is it a mistake to build an admin panel?
No, but keep it basic. You need a way to view and correct data and help users. A full-featured back office with charts and bulk tools can wait until your operations team needs it.
When should a startup hire in-house developers?
Usually once the product has traction and a continuous stream of work. Before that, an agency or a small contracted team can be more economical. Whichever route you take, make sure you own the code and documentation.
Should I add AI because investors expect it?
Only if AI genuinely improves your core loop. Bolted-on AI features add usage costs, testing effort and privacy questions. A clear, working product that solves a real problem is a stronger story.
What if my competitor already has more features?
Feature count rarely decides an early market. Doing one important job noticeably better, faster or more simply is a stronger position than matching a long checklist half-well.
Start with the part that matters
The best first build is small, sharp and owned by you. For help separating your core loop from the "later" list, plus a fixed-price quote for version one, tell us what you're building. You can see products we've helped launch on our work page.