The MVP special.

The MVP. It’s essential, it’s scary and I’ve seen it go wrong so many times !

What do you build? Who do you get to build it? What do you build it on? How long is too long to spend building? How much is too much to build?

All questions that don’t really have a definitive answer and differ from business to business, founder to founder. Classic.

We’ve been both building MVPs and investing in businesses with early MVPs for the past 9 years and while we’ve figured out a lot along the way, it’s still extremely complex.

Here are some of my thoughts on how to approach building an MVP and who should help you build it.

PRODUCT ADVICE
Think smart. Be scrappy !

I spoke to a founder recently whose MVP was:

  1. A website built on WordPress

  2. Airtable supporting behind the scenes

  3. They were manually inputting data every day, and serving customers manually behind the scenes

Everything was linked together with Zapier and essentially a bunch of digital sellotape. They did a load of manual processes and behind the scenes it looked a mess.

But they quietly generated a really solid revenue to put in front of investors, to prove traction.

They didn’t need to write a single line of code to do this either, they just needed a smart product manager or no-code builder to support them.

Of course, it isn’t scalable but they found traction by hacking all these things together, and were able to start serving customers. Then they were able to spend money and time building bigger and better.

I have found throughout the years that founders opt immediately for a code solution to the problem they want to solve, overlooking other scrappier options.

What this founder here did was so smart. They didn’t spend thousands on code before really validating their idea, they started building a loyal customer base, generated revenue and ultimately secured funding because of it.

As an investor, this shows the founder is smart, willing to be scrappy and isn’t jumping down the easy, expensive route of custom code.

DEVELOPMENT AGENCY ADVICE
How to build your MVP with a development agency:

1) First, decide whether you actually need code.

A big misconception is that you need code to start your tech business. This isn’t always true. Especially nowadays.

Before working with a development agency, decide whether you could actually build your MVP or validate your solution without code. This could look like using no-code tools or building a landing page/wireframes, or even simpler, a Typeform survey.

You don’t want to jump in head first and spend £200k on a product no one wants. You can validate your solution in simpler, less costly, ways. Always try this first.

2) Never expect an accurate timing or price estimate.

What often happens when working with a development agency is you discuss your product for an hour or so (sometimes less) and then you expect them to tell you: “that’ll be done by [insert date] for [insert price]”.

The fact is, no one in the world can accurately estimate how long a product will take to build, or how much it will cost.

But for non-tech founders, the natural instinct is to want to fix everything, to make sure you know what is being built and when, and to feel in control. However, you’ll realise some features aren’t needed, some problems take longer or less time to solve, and some new features will pop up. And if you’re talking to users consistently and in the right way, this will 100% happen without a doubt.

We typically say to embrace this uncertainty, this is where you are most flexible and you are most likely to build something your users actually want. Fixing something in place loses the ability to adapt to user needs– this is where startups are most powerful.

Instead, while the overall cost to build may be £200k+ over a long time, you need to agree on an initial smaller cost to build the smallest possible version of the product possible (I mean really small). If you build the full product and find out no one needs it, that is a huge amount of money down the drain. To ensure alignment, work with goals not fixed features. You need to be releasing the smallest version possible and getting feedback asap - then everything built from this point then needs to be built on this feedback, not in isolation.

Build less, but better.

3) Make sure you’re picking the right agency.

Now this point could be a whole newsletter in itself, but there are a few ways to know you are picking a good development agency to work with:

  1. They should challenge you throughout- if the agency you work with agrees to build absolutely everything you tell them, it’s a bad sign– they’re just trying to get your money. You need to be challenged on your ideas, it doesn’t mean they are bad, it means they need stronger validation or you need to pivot your idea. Most of the time you won’t release something you thought was the initial solution to your problem, so if you aren’t questioned, you’re likely building the wrong thing. Good agencies will also include past experience in this feedback. For example, their expert in User Experience will challenge the tech you want to build because they’ve seen it fail before, or someone will have built a similar product in a different domain and seen it work better than what you suggest. Those people are your extra source of information, they should challenge you.

  2. You should be in control- make sure they explain to you how the process of deployment and automation of quality works in their context. If they can’t explain it in the terms you understand you will always feel unsatisfied and not fully trust them. They all have to speak your language. Finally, see their project management tool like Trello/Jira, see how they will manage your project and how much detail they share with each other to deliver your business.

  3. They should show you their previous work- ask them for case studies and ensure they have worked with startups before. It’s a good idea to go and speak to founders they’ve worked with before and ask their opinion. A lot of founders will have had to completely rebuild their tech, or won’t have found the right fit, they will let you know.

  4. They should have a product team- if they are just an offshore developer who doesn’t have a product team, steer clear. The hardest part isn’t actually building something, it’s knowing what to build. That’s what product people do, they help you prioritise.

4) Make sure your next CTO would want to inherit your code.

After building your MVP/first version and finding traction, you will eventually need a CTO. This CTO won’t want to inherit code that is messy and needs a complete rebuild, they want to build on top of strong existing code.

So, it’s best for you to make sure your development agency builds to your unique context choosing the best tools, processes and technologies for the actual opportunity, but also using the best modern practices that are battle-tested and define great technology products. This could look like a checklist of specifics that you should expect e.g. definition of a process of managing technical debt, focus on quality in all stages of the build, automation and performance testing being as part of daily work, frequent code reviews done by the whole team, automation of deployment, security consideration, bug policies (prioritising fixing them), and flexibility to build the architecture that can adjust as your business changes. The tech team needs to understand that they must enable the business to thrive not become a bottleneck to its progress.

Make sure you also ask how hard it would be to hire reasonable developers for your internal team after the relationship is over. Ask what the process of "inheritance" of the whole code and infrastructure looks like (everything should be yours and you should always be in control of all your assets (code, infrastructure, designs, accounts).

The type of language or the framework the tech is built within isn’t that important (make sure it’s a common language so you’ll have future developers who can inherit it !), but you should try to use the latest version. It’s about having your technology built to the right standard with the right considerations so that your first CTO can pick it up and start working immediately.

That’s the difference between a good development agency and a bad one. Make sure you know how they are going to build your product and that it isn’t going to be binned the second you get a CTO on board.

LEARN FROM MY MISTAKE
A word of warning !

Take timelines on your MVP software with a pinch of salt. Whether you’re using an agency, contractors or have an in-house team.

Definitely don’t hinge everything on it !

When I was 19, I took over my family’s musical instrument retailer and digitised it.

I made a load of mistakes, but also learnt a lot very quickly.

I spent too much money on custom code when there were off-the-shelf platforms I could have more readily used. I also trusted the timelines the development agency gave me for the launch of our platform, which was meant to be ready well in time for Christmas.

In true fashion, the platform wasn’t ready in time, and we’d bought a load of stock in preparation. We had it all sitting there, and had to resort to platforms like eBay (which the suppliers didnt like us using !). Christmas is the biggest time of the year for most retailers, so it was a big blow.

The business was almost gone before I could even give it a good crack. Instead, I had to do a sale in January and sold most of the stock just to survive.

Two key bits of learnings here:

  • Don’t build custom code when there’s off the shelf available (at least not at the very start, and this was 15 years ago - that's even more the case today).

  • Don’t hinge everything on development timelines. It’s really hard for development teams to estimate delivery, so it's vital to have back ups in place. Don’t plan major activations around exact delivery dates, instead ensure there is some slack.

Be very careful !

YOU MIGHT BE INTERESTED IN
Our upcoming webinar:

1) Intellectual property 101! With Mo Abbas and Dan Christey.

Hear from Mo about:

🛡️ Brand Protection: Essential trade mark registration guidance.

🎯 IP Strategy: Strategies to secure your innovations.

🌱 IP Portfolio Growth: Expand your IP assets alongside your business.

📚 IP Rights: Insight into your full range of intellectual property rights.

Trademark Brothers specialises in turning complex intellectual property issues into straightforward solutions.

Register here to join here: https://lu.ma/nmnuun9j

Again, thank you for signing up to my newsletter ! I’ll be sending it out every month.

Always open to feedback, content suggestions or collaborations. Tell me your thoughts.

All the best,

Matt Jonns