Building a Minimum Viable SaaS Product in 3 Months

With two people, no budget, and zero technical debt. Here’s our roadmap for getting to a marketable, SaaS product with a future-proof, scalable foundation.

If we followed the traditional startup approach to building an MVP, we would’ve:

  1. Thrown up a landing page.

I understand why that’s appealing.

It’s less risky, less expensive, and less work. But it doesn’t answer the question, “Is it viable?”

We wanted to a working product. Something we could use. Something that typically takes a 5–7 person team and millions in funding. But with two people and no budget.

If you’re looking for an MVP-in-a-weekend post, this isn’t it.

If you want to see our secret process for building a production-ready MVP while bypassing the black hole of technical debt, keep reading.


Minimum Viable Product Roadmap

We asked:

“What is the fastest route to a useful, valuable, and delightful product that we can build in three months with zero technical debt?”

Here’s our MVP roadmap roughly broken into three months:

  1. Pre-work — Before we started on the MVP, we built a mock marketing site with sales copy for the features I thought we wanted. This took a week or two before we officially started.

Let’s start with the work before the work…


Mock Marketing Site and Sales Copy

There’s an approach at Amazon called, “working backwards” where new products start with a press release.

They layout the problem, solution, customer experience, etc. prior to building anything. If there’s no excitement, they don’t build it.

To give us a starting point and better define what we’re creating, I built a mock marketing site with a homepage, product tour, pricing page, comparison tables, FAQ, and 2,790 words of sales copy.

Here’s a sneak peek:

The problem is that most freelancers struggle to get and keep clients… partly because they don’t have a homebase for displaying their work, handling their clients, and professionally invoicing on projects.

The solution is to build a system that allows freelancers to showcase their portfolio, manage their clients, and get paid… all on their domain. An easy-to-set-up, low-cost, no-maintenance way for your clients to have a 100% branded journey from first message to final invoice.

Once we were both on board with the vision, it was time to define what we call, “The Minimum Happy Product”.


The Minimum Happy Product

If an MVP tests viability, then an MHP tests happiness.

The goal of an MHP is to solve the customer’s problem in a way that makes them happy.

As freelancers, we both saw the value in having everything bundled up on our domains. But we didn’t agree on where to start.

I wanted a website builder, portfolio, client CRM, invoices, escrow payments, and marketing tools. Mike — our technical co-founder — wanted contracts, invoices, and Stripe-powered payments.

To help us decide and begin the MVP/MHP process, we built out live mockups for the two main parts of the product:

  1. Mission Control — Where freelancers manage their account, add clients, and send invoices.

I started the next day.


Designing Live Mockups for Mission Control

It took four days to design and build out the pages, tables, forms, and panels for the freelancer’s mission control.

Here’s the basic dashboard with recent activity, current plan, and a few base components.

How I imagined the data tables for clients, projects, contracts, invoices, etc.

The create invoice page and with base form, label, input, and button stylings.

Each item — client, project, invoice, etc. — needed a view panel. This was the layout for an invoice with the status in the upper right.

We could’ve mocked up the site in Photoshop, but we’d rather have static screens that we could click through as though they were live. Plus, something we can reference and re-design on the fly.


Designing Live Mockups for Client Control

Once we had the base styling and components for the mission control, it was easier to build the client pages and views.

This is the client dashboard. Same style as mission control, but clients are limited to paying invoices and viewing their account.

When a client receives an email and views the invoice, they get taken to this invoice page.

They fill out their credit card details and pay the invoice with a click.

Whether they’re on a desktop or mobile device, clients need to be able to pay invoices as easily and quickly as possible… all while knowing that they can access their accounts at any time.

Keep in mind, these were the initial mockups. The final web app will look slightly different.


Defining the Fastest Route to a Happy Product

Now that we had clickable prototypes for both the mission control and client control, we negotiated the minimum happy product.

What’s the core problem? What needs to be built to solve that problem? What is less necessary for now?

The core problem is that freelancers often fail to get repeat or recurring business partly because they have unprofessional freelance processes — with invoicing being the client’s most important touchpoint.

We asked around. You’d be surprised by how many freelancers still send Word document invoices. I’d have a hard time recommending that person.

The core solution is an easy-to-set-up, low-cost, no-maintenance way for your clients to have a 100% branded journey from first message to final invoice. Making it fun for clients to work with you and easy to recommend you to their friends.

With the core solution in mind, here are the features we kept:

  • Dashboard — Overview of account and activity.

Here are the features we’ve cut (for now):

  • Time Tracking — Add time entries to generate invoices.

After negotiating the MVP, we built something to help us bypass the black hole of technical debt.


Technical Debt Busting Style and Component Guide

Avoiding technical debt — short-term coding decisions that lead to extra work long-term — was one of our top priorities.

The best way to sidestep technical debt is to start with a style guide.

So that’s what we built.

A style guide is a living document that defines the styling for your typogpraphy, buttons, colors, forms, panels, pages, etc… Also known as a component guide or pattern library.

Here’s what we get out of it:

  1. Consistency in design — Every word, button, color, input, panel, page layout, etc. is styled exactly the same in every instance, whether you’re on the marketing site or the web app.

The reason we were able to develop and build features so quickly is because we didn’t have to think about front-end. Even if we were to redesign everything from scratch, now it’s only a matter of redesigning the components.

This will be a big advantage moving forward. And it only took a week or so to create.

You can find our complete Bundlify Style Guide here.


Marketing Site and Web App Foundation

Now that we had live mockups, a well-defined MVP, and an established style guide — all in just over a month — it was time to start building.

Every SaaS company has two main sites:

  1. Marketing site — Sales copy with marketing funnels. You’re on our marketing site now 😀.

In the second month, Mike set me up on Middleman for the marking site and he started building the web app with Ruby on Rails.


Marketing with Middleman

It took about a month — off-and-on — to build the initial marketing site, with the bulk of the work upfront.

Here’s our initial blog page layout:

We were going to use WordPress but decided go with Middleman for a few reasons:

  1. Performance — Middleman is a static website generator which means there’s no database. Since there’s no database, our marketing site will always be lightning fast. According to Pingdom, it’s faster than 100% of the sites they’ve tested.

To be fair, there are a few drawbacks as well:

  1. Familiarity — Everyone knows WordPress. Even a first-time user can work within their CMS. Not as many people are comfortable working in a file editor and terminal. Might be a challenge to hire.

Overall, worth it.


Building the Web App with Ruby on Rails

As I was building the marketing site, Mike started on the web app.

In the first month Mike built out:

  1. User accounts — People can sign up, log in, and manage their accounts.

In a little less than a month, Mike had a live version of the app connected to his subdomain. Here’s a sneak peek:

Why Ruby on Rails?

We chose Rails for two reasons:

  1. We’re familiar with it — Mike and I have been working on a Rails project together for the last three years.


Wrapping up Marketing Site and Dog-Fooding a Functional Web App

Mike and I both finished the laying-of-the-foundation for the marketing site and web app at the end of month two.

We spent month three building out the core functionalities for each.


Marketing Site Functionality and Pages

Once the layout was there, it was time to write and create the pages we needed to have a functional marketing site.

Here’s the list of pages we created:

  • Homepage — Briefly introduce Bundlify and explain how it works.

I know this seems like a lot, but to us, these were the minimum pages we wanted for a proper marketing site.


Wrapping up the MVP Web App

This was an exciting month for us because everything came together so quickly:

  1. Clients — You can quickly create accounts within your account for your clients to access and pay invoices.

As our MVP-is-complete test, Mike sent me a real invoice. I paid with a click and the funds went to his Stripe account. All on his domain.

Right on schedule!


MVP is Complete, But Not Ready

Mike and I are both dog-fooding the MVP by using it to invoice our clients. The response has been amazing.

By using it ourselves, we know you’re going to love it. It’s also helped us fix the UX in a few important places:

  1. Deleting invoices — Should be able to delete unpaid invoices.

We expect this list to get longer as we continue to use it.


Finishing the Onboarding, Free Trial, Subscription, and Importing Systems

We’re still building the tools you’ll need to have an amazing experience.

  1. Onboarding — The first-run experience from the signup form to sending the first invoice.

Keep in mind, as a bootstrapped SaaS app, everything we’ve done here has been part-time work. We both have other projects and clients.

Update: Unfortunately we had to close, but the lessons in this experiment still hold true.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store