Don’t throw money at the wrong software product: build a prototype first

“That’s going to cost between $500,000 and $250,000,“ I told them. They looked at me with a huge surprise and finally said, “we thought it would be around $10,000.“

Now that’s what I call wishful thinking, but I was happy to talk to them if I could help them avoid making the mistakes I did in the past even if we wouldn’t end up working together.

Background Story

A few months ago, a founder duo reached out to me about a startup they wanted to build, probably looking to get additional opinions on the cost required to get their product live.

They must have been hoping to get a lower price than the money they’ve raised for the startup to avoid spending more out of pocket since they told me they had some conversations with a few agencies.

That’s the approach we as founders want to take and it totally makes sense: I don’t know if the business is going to work, so I’m taking a bunch of risk, but I don’t want to lose my hard-earned money when I can avoid it. This is totally understandable.

Each person’s tolerance for risk is different, so it has to be a sum you’re comfortable with letting go. It’s the same when trading stocks or crypto, or any other asset for that matter that you don’t intend on holding for the long haul.

No matter how many startup validation techniques we use and fairytales we tell ourselves, we can never reduce the risk to zero and we have to plan for that, or… you know how the saying goes — you plan to fail.

Unrealistic Expectations

Only there was a problem here: what this founder duo thought they needed for the first iteration of the product was actually several magnitudes bigger than necessary to test out their hypotheses — and, frankly, a set of hypotheses are all we have in the beginning of a new venture.

We have hypotheses about the problems, the market, and the solution. These are “educated guesses“ but still guesses nonetheless.

The more concerning part was that some agency they found on Upwork was promising them the full set of features for web, iOS, and Android at the total price of $11,000. Yeah, that’s totally realistic…

Though I can’t share the exact feature set, the product is an all-in-one type of marketplace that would require a startup investment of at least $250,000 if not closer to $500,000.

When projects are this big, it becomes very difficult to have any accuracy, so it’s pretty much pulling a price out of nowhere. $11,000 for such an undertaking is a drop in the bucket no matter where the team lives.

I happen to understand the range this project would fall into because at a bird’s eye-view, it’s similar in needed features as the initial version of the freelance marketplace I wanted to create a few years ago though there were other challenges that made me pivot into a different direction (writing an article about this, so follow this publication if you don’t want to miss it).

Even if you did have half a million bucks laying around somewhere, waiting to be spent, it’s better to take it step by step, so you could either pivot or stop building altogether to avoid additional burn of funds. Otherwise, you can just set it on fire right in front of you and at least you’ll enjoy the heat.

Coupling with various experiments along the way, you will either exit or pivot fast, raising the probability of building the product customers need and satisfied customers are the fuel to your revenue generator!

Grounding Into Reality

Once I’ve explained this to the founder duo, they accepted to trim the feature set down by what they thought was a good amount, but it was clear they believed the success of their project depended on all the remaining bells and whistles.

The price was still hovering between $50,000 and $35,000, focused on the web platform this time as that’s where we agreed their startup would have the most impact rather than focusing on native devices.

Choosing the web platform is not always the best choice, but it makes sense for this particular project especially when it’s possible to take it closer to a native experience (turning it into a Progressive Web App) while reaching a bigger audience that is more inclined to use the web version.

Later in the company’s lifetime, they could release native mobile apps if they choose to though by that time, the company should have consistent revenue and it only makes sense to prioritize the native app experience when there are no other tasks with higher priority, avoiding a bigger opportunity cost than what you choose to focus on.

Going back to the cleaned up feature set, I still thought we could dive even further, but that’s only possible by taking a step back to look at the bigger picture for the startup in terms of what they’re trying to accomplish and how to go about it.

Instead of talking about the product, per se, we can now look at what it takes to build the full company and what it takes to get to revenue fast.

In other words, we can now have a business conversation and solve business problems that will take them to the next level on the path to revenue rather than simply building a product just for the sake of building it.

I’ve got a process I use (derived from a combination of theoretical knowledge and refinement through trials and error from real projects) for launching a startup: The Customer-Loop Framework.

Before I get into the framework, you should always know that it’s never possible to reach 100% validation through any process you may use and if anyone claims this, they’re lying.

Instead, our goal is to increase our level of confidence in finding Product/Market Fit by surmounting every hurdle we place in front of the startup.

After all, as Steve Blank wrote in his book, “a startup is an organization in search of a repeatable and scalable business model.” You know you’ve found it when you’ve hit Product/Market Fit.

In other words, don’t bank on a specific product that you think you need to build now, but rather take into account that you may need to move fast and it’s definitely harder to turn around a full 18-wheeler compared to a bicycle, isn’t it?

But even if you go through several validations on the way to Product/Market Fit, you still won’t be certain your business model will work out in the end. Just like you don’t see past the headlights projection on the road at night.

So what we really want is simply permission to try the next step in the framework rather than 100% assurance that our product will definitely work with every subsequent step getting us closer to Product/Market Fit.

Instead of simply enumerating the steps from The Customer-Loop Framework, I will walk you through the plan I came up with for the founders, but without going into too many specifics as the general lessons can apply to any software startup.

The Customer-Loop Framework

At the heart, its goal is to avoid spending too much time and money in the wrong direction. The sooner you realize you need to make changes, the more experiments you’re be able to run, and the faster you’ll find something that works.

1. Problem Validation

We start with a problem to fix or desire to fulfill. That’s our first hypothesis that we want to test and the data set has to be statistically significant (i.e. you having this problem or desire doesn’t count without getting feedback from more people).

From the conversation with the founder duo and from the stats they showed me, it was pretty clear they did confirm a specific problem, but instead of zoning in on solving it, they wanted to go all in right away. That’s like asking your love partner to marry you after the first date. It’s possible, but will that relationship last?

Just because a problem does exist, it does not mean we already have Product/Market Fit. We’re still far from that point.

This step can be done in a very low tech way. You can personally reach out to people who you think have the problem you’re trying to solve and actually talk to them. You can run polls on social media channels. You can send out surveys through email or paid ads. You can even call business owners on the phone if the problem you want to solve is both urgent and expensive.

You don’t need a website or landing page at this point as there is nothing to present: you’re only collecting data from the market. This is what Market Research is all about and that’s how you should frame this whole step.

So what you do is you come up with a specific experiment and parameters to test against the hypothesis and understand if it has passed or failed. You can even try multiple experiments for confirmation or for honing in on the right problem or desire to work on.

No matter what medium you use to collect data for the experiment, it should give you a hint of whether it makes sense to dig further or not. Bonus points if you are able to collect contact information from those who confirmed they had the problem!

Together with the founder duo, we agreed what problem they should try to solve was, backed by statistics that showed 89% of respondents agreed it was an actual problem and since a few hundred people participated, the results were statistically significant and worthy to move to the next step.

2. Solution Validation

The best outcome from the previous step is a list of people that signaled they had the problem we want to solve, so we could reach out to them during this phase. No worries if your medium didn’t allow you to do this as it’s possible to get them for the first time here, but it may cost extra in time and money.

So, what is our goal here? We want to end up with a positive response to a prototype that showcases how we could solve the problem. Bonus points if you’re building it together with the people who signaled they had the problem in the first place.

Just get in touch with them and talk about how you want to solve it. What are they telling you? What are they pointing out? Take note of every conversation as that will allow you to come up with a very good solution.

Do you go and build a full product based on those findings? Absolutely not! There are a few ways to continue with this:

1. A design prototype that shows how the Unique Selling Point (USP) is implemented

2. A no-code prototype that implements the USP

3. A manual solution behind a web page that would implement the USP

Which one of these steps is next really depends on both budget and company. I would start with a design prototype if money is available or a no-code prototype. If the budget is really small, I would go with #3, then once you either raise more funds or earn some money, you can invest in a more of an automated solution.

What’s important is that you focus on a single core feature along with the most important supporting functionality that allows your potential customers to use that core feature. This is what your USP is.

Once you’ve chosen the way to go, you go back to the people you talked earlier, but this time to confirm they also think your solution solves their problem. At this stage, you could even ask for a pre-order! That’s the best validation you could have.

However, don’t stop here just yet. Set up a landing page that showcases your solution and start building a waiting list. You will make use of it in the later phase, but don’t shy away from getting in touch with them about reviewing your prototype, too!

This is the phase where the founder duo was when they reached out to me. Although it was clear what problem they had to solve, they didn’t confirm a Solution Fit just yet, but instead they began to come up with various features that would make the product cool, but this doesn’t make you money. In other words, it was not the right time to build or even think about an MVP just yet.

The goal of this phase is to get more than 50% of your list to agree that your solution will definitely solve the problem you talked about and you know you nailed it when you get asked things like, “When can I get my hands on the product?! Take my money!“ Obviously it won’t make sense to presell everything, but that’s the gist of it.

If we focused on the problem the founder duo wanted to solve, instead of spending $50,000 on an MVP, we could have a prototype ready in 10 days for $5,500 and it would be responsive for the web platform.

In other words, we’d have the bandwidth to build 9 of these prototypes for the price of a single MVP! Heck, they could even build it themselves with all the great no-code tools out there if they had enough time on their hands!

What do you think has a higher chance of nailing the right solution? A single MVP or 9 prototypes? Leave a comment with your thoughts, would love to read your opinion!

A rule of thumb is to build prototypes in less than 2 weeks. Anything more than that is too long and is too slow to react to change.

As soon as we get above the 50% positive reaction from both the initial list and the waiting list after they’ve interacted with the prototype, it’s time to charge them money for using it.

Obviously you won’t be able to do it with just a design prototype, but no-code tools or even a custom coded product based on the lean design should be enough to make your users pay unless you’re following a freemium model. Either way, it’s time to move on to the next phase.

3. Go-to-Market

This is when we’re going to build the MVP based on all the feedback found with the prototype from the initial paying customers. We automate manual tasks and add features that will turn the app into a more of a complete product, but the beauty of it is you’re already going to have a revenue stream.

In fact, you may be able to raise Seed capital for this phase if you’re not going the bootstrapped route. However, make sure you budget at least $50,000 for design & development as well as another $30,000 or so for marketing. Ideally, you should raise between $150,000 and $250,000 to ensure you have enough runway until the next round. The actual sum will depend on your product, but that’s pretty much what it takes to launch a startup.

At this point, the goal is to clearly establish Product-Market Fit. Once you achieve this, we can move on to the next phase.

4. Scale

Armed with Product-Market Fit, you can raise a Series A round of about $1–2 million. With this, you’re mostly going to invest in growth, but also in developing all the features requested by users as well as optimizing the platform to allow scalability.

However, not all products need a high throughput, so you may be able to focus more on requested features rather than building a scalable architecture, but don’t ignore the bottlenecks or incurred technical debt as it will come back to bite you later.

When left undealt with, technical debt can cost your business a fortune and new features will exponentially take more time to build while strange bugs will start to pop up. While it didn’t make sense to focus on this until the current stage, now it’s the time to invest resources in the codebase to make the product better.

I’ve seen how technical debt ruins startups time and again — just like bad marketing strategies. This stage is the first time when the quality of written code actually matters.

But from here on out, the sky is the limit.

This is how you build a startup step by step without investing more than needed at every phase.

It doesn’t make sense to spend $500,000 on the features that are simply your guesses when you can take it gradually and focus your resources on things that actually work.

Need help with your product? DM me on X/Twitter or LinkedIn.