Last summer, I built an MVP called Unison for a friend of mine. The app is an online community for women to share health-related experiences and connect with others. I was honored to be asked to build it, and a bit daunted by the task. A blank slate with unknown unknowns waiting to derail me around every corner. My experience in product management helped me stay on track and I learned a lot along the way, so I figured I'd share some highlights. If you're a solo developer or founder, this post is for you.

1. Feedback is gold

It's a catch-22. You need user feedback to build your MVP, but it's tough for someone to conceptualize how your non-existent app could help them, so you need to create an MVP to show them. User feedback is the best roadmap for your app, so it's best to seek it out early and often. This fact will drive many of the other decisions we make when developing an MVP. It's a cycle to clarify an idea from a hunch, to a list of pain points, to a list of requirements, mockups, and finally the MVP features in code. The more accurate of a starting point you have the better, so reach out to prospective users early.

2. Don't skip mockups

Before writing a line of code, you should have a clear visual representation of the app. The fidelity of the mockups isn't super important in my opinion. The real power is that the mockups are relatively quick to make and adjust and can be shared easily to facilitate communication between stakeholders. Everyone has assumptions, and it's so much easier to address conflicts early when you can easily drag boxes around.

Molding fuzzy ideas into boxes and buttons will bring up critical, unforeseen questions. It's worth spending time on mockups to discover these, rather than when you're deep in the code. These issues can be fixed by moving a box around or changing a layout in a drawing, rather than refactoring a large section of the app which wastes time and could lower quality since this critical item is being shoehorned in. Requirement changes get more expensive at every stage of development. The more that has been built, the more that may need to change.

If you're building MVPs often or need a high-fidelity mockup, I'd recommend learning Figma. Being able to import components from your chosen UI library and modify layouts and spacing easily is pretty handy. Draw.io is also a great tool if you want something simpler to drag and drop boxes around.

3. Choose a framework that lets you ship quickly

When you're building a first version, speed matters. Getting to a point where you can show off the app to stakeholders and receive feedback is the primary goal. You don't want to spend months building something and realize it doesn't meet users' needs. Better to find that out as soon as possible if that's the case.

AI-assisted development has become the norm, so pick a framework that AI models write good code with. At the time I was building Unison, React was clearly the strongest choice. I use both React and Svelte, and while I prefer Svelte, I noticed AI models occasionally producing outdated or made-up Svelte syntax. Since leveraging AI is mandatory for fast development speed, I went with React, specifically Next.js hosted on Vercel. Test how models perform with your chosen framework, since they're improving and changing rapidly.

4. Use a backend-as-a-service

Building and maintaining a custom backend from scratch adds a lot of complexity and risk to your MVP timeline. Backend-as-a-service (BAAS) platforms bundle hosting, database, APIs, auth, and other services in one place, letting you focus on the custom business logic that actually delivers value to users.

I used Supabase for Unison. It provides a hosted PostgreSQL database with a user-friendly JavaScript client, and CRUD APIs are included out of the box. That means no time spent developing, testing, and debugging common read/write operations and no server setup. And if the app takes off, the underlying infrastructure scales without a full rebuild.

5. Skip frontend unit tests — for now

This is a deliberate tradeoff, not an oversight. In an early-stage product, the frontend changes too frequently to justify the cost of maintaining tests. Wait until it stabilizes.

Bugs that frontend unit tests would catch, like a component not rendering or props handled incorrectly, are easy to spot quickly through manual testing. Your time is better spent shipping.

That said, I'd still recommend unit tests for backend functionality, since that's where your core logic lives. Our initial users are doing us a favor by testing an early-stage app, and we don't want to waste their time with bugs in the most important features. BAAS platforms like Supabase help here too. Their APIs are already tested, so you only need to cover your custom backend behavior, like Supabase Edge Functions.

6. Don't rush estimating

My toxic development trait is that often I hear a feature request and think it'll be straightforward, even if I haven't done it before. It's easy to get caught in the excitement of building something new and then forget that it needs to play nice with all of the other, slightly less shiny features. A lot of the pitfalls don't come from the feature itself, but how it fits into the existing system. Scoping a feature in a vacuum is a recipe for regret.

I recently added Google authentication to Unison and underestimated the complexity. Connecting to Google was simple, but refactoring the existing login and signup logic blew up the scope. The signup page became too cramped on mobile and needed to be split into two steps, which then introduced the problem of half-completed profiles. This spurred some discussion about the step order and overall messaging for the best UX.

Before giving an estimate, think through edge cases and which other parts of the app will need to change. And as always, add a buffer for unforeseen issues bound to arise.

7. Beware of scope creep

More features sound good on paper, but it comes at a cost. It obviously takes more work to build new features, and there is a higher risk if features are added to the scope mid-project. There may not be sufficient time to properly plan the work before the deadline, leading to lower quality work or pushing the deadline out.

Creating a plan that locks down the major requirements early, and treating new major features as a separate decision with its own cost and timeline is the best way to handle this. Not all feedback is scope creep. The goal during an MVP build is to receive feedback and iterate on the app. That feedback could come from the users, the business owner, or other stakeholders. This is what we want.

Feedback about the major features already in development can typically be included, but additional features outside of the plan should prompt a discussion about how to handle the expanded scope. Maybe you push out the timeline, add it to the next phase of the project, or swap out a lower priority feature. Scope creep didn't become an issue in my project, mainly because we had a plan in place. It gave us a framework to communicate the constraints of the project when new ideas started to enter the picture.

Conclusion

There are many ways to build a software MVP, and hopefully some of these ideas resonated. The main idea across all of them to get feedback as fast as possible. If you disagree with any of my tips, leave a comment and I've love to discuss it.