I recently had to write a proposal for a project that had unrealistic expectations regarding the scope of work, timeframe, and budget. I think most of this mismatch happened because the client said he wanted an MVP, but judging by the required features, it was actually the whole app.

An MVP, or a Minimum Viable Product, is the simplest version of a product that can be released with a minimal set of features that are enough to satisfy early adopters and provide valuable feedback for future product development.

I saw clients frequently misunderstand what an MVP actually is and how to go about building one. Solo developers working on their own products also make this mistake (myself included). So I figured it would be useful to share what I've learned about this topic over the years.

The Proposal

The project in question was a "micro SaaS / MVP" that would cater as a CRM for a certain niche of construction companies. The client wasn't settled on a specific technology, which was great because that meant I could suggest we build it quickly using Ruby on Rails. I was also interested because I'm working on a CRM for a specific niche (dental clinics), and I thought there would be some overlap there.

But as I was reading the job description, some red flags started appearing. The client wanted the whole application built on a Minimum Viable Budget, in 1-3 months.

Adjusting Scope to Align with Reality

Instead of turning down the project, I responded with a proposal to adjust the scope. This way, we could stay within the client's budget while also reducing the time needed to build the initial version.

I explained in my response that what was described was more complex than just an MVP and that it would be better to start with a simple product and give it to early customers and iterate on it, depending on the feedback. That way, he would avoid wasting time and money building something that nobody cared about.

Breaking Down the MVP Strategy

I suggested we focus on just three of the total of nine core features the client initially requested: lead management, project management, and estimation. My reasoning was that these would allow a user to start getting value out of the app right away. He wouldn't need analytics and reporting right away if there's not that much data in his account, for example.

Here are two more examples of features that might seem foundational but in fact can be dropped safely from the initial version of your product:

• Account creation and linking users to accounts for multi-tenant SaaS applications can be set aside initially. I've spent a lot of time figuring out the logic for this and decided not to implement it right away, opting to handle it manually in the backend until there's enough demand and it becomes unmanageable. This approach is perfectly fine in the beginning.

• Billing systems — the same as above, you can do it manually at first and when you can't keep up with generating invoices, then you hook up some payment provider. Good problems to have!

Starting small and iterating later is always wise. This approach allows you to gather feedback to ensure you're on the right track and begin generating revenue faster.

Why go with Ruby on Rails for an MVP?

I think Rails is a great framework for building products quickly and validating ideas. Its "convention over configuration" philosophy allows developers to jump right into building the core that provides business value without getting bogged down by setting up and configuring things.

To speed up the development process even more, I regularly use certain tools that work well with Rails. One such tool is Avo, an admin panel I often use. It provides customizable dashboards, form builders, and other important user interface components for MVPs. This approach not only makes development faster but also adds a level of polish and functionality to the MVP that could otherwise take extra weeks to develop.

Rails is especially a good choice for MVP development as it supports quick, agile changes and iterative updates. This is important when reacting to the first feedback from users.

Conclusion: The Path Forward

Remember, the purpose of an MVP is to learn fast and make improvements based on actual use — not to release a flawless product from the start. By carefully narrowing down the scope and using the appropriate tools, you can develop a product that truly meets your users' needs and sets a strong base for future upgrades.

What are your experiences of building MVPs? What strategies have worked to test an initial version of a product or how have you reduced scope to just what's essential?

---

Starting a SaaS project and feeling a bit swamped? Or just looking to polish up your MVP? I’m all ears and ready to help! If you need some guidance, a quick chat about your ideas, or even some hands-on help with the nitty-gritty of SaaS development, just reach out!