The learnings of a first failed MVP

And how to spot developers that don't do what they are supposed to do

Are you just starting out? Wanting to build the MVP of your product to be able to share it with your friends and family and get it going?

Well, then hear me out. Here is a list of things you should be aware of when working with external developers.

And a note on that too - If you can develop in-house, develop in-house. It makes your product much stronger, it allows you to talk about the decisions you made, and why you made them and a lot of growth in the early stages come from that.

Communicate Clearly

Most importantly, communicate clearly. Communicate exactly what you need and what is important to you.

That means, do not only communicate and speak about your high-level vision, but very specifically about how you want the product to look like, what kind of features you want to have and what functionality you want to very specifically have.

The more specific you can name and talk about what you want, the better the out put will be.

Here is an Example

Imagine you want to build an app to better sell your ice-cream via an E-commerce store.

Your vision might be clear in your head and you are sharing that information of your ice-cream shop with a developer or development team, then they may understand the bigger vision, but will they also know how specifically you envision your ice-cream shop? What makes this ice-cream shop unique? What color concepts are you looking for? How are your users guided through the store for maximum user experience?

All these questions are essential to communicate so that your ice-cream store looks and feels and functions like you envision it in your head.

For that reason, make sure to clearly communicate your vision and your specifics to the team.

You can create a specification or ideally technical specifications file, where you list all the relevant details of your store:

• Structure & Architecture How is it build up, which pages you want to have, how shall it be structured
• Features & Functionalities: What features shall it have, what shall it be able to do
• Look & Feel: How shall it feel, color concepts, typography, messaging, smoothness, buttons

Example

Not Good: Build me an app so that I can sell my ice-cream via an E-commerce store

Not Ideal: I want to have a start page and the user shall see all the ice-cream options there and then when the user clicks on an ice-cream, they see more options and then they can order their ice-cream directly to their homes, free of charge. The user can pay by Stripe for that and they can sign up for a newsletter.

Better:

• This is my vision for the shop:
• This is the structural outline of my ecommerce ice-cream shop:
• These are the functions and user flows:
• This is the design that I want to have:
• and so on..

The more specific you describe what you want, the better the developers are able to bring it to life.

Good developer teams proactively give you suggestions and make sure to program an application that does what you want it to do, but also gives you advice in how to make it better. Look out for those.

*** Spotting Lousy Developers

It’s not a good sign if you do not know where you stand in the project. What is true for you is also true for them: If they do not communicate well, the gap between your vision and their work likely increases considerably.

And the longer you wait the more problematic it gets. If they do not communicate effectively, they may be great in other fields and focus areas, but they may not build what you have in mind.

Hold Accountable

Make sure to hold the developer team accountable to the deadlines they were giving you. If they tell you that they are able to get it done in 3 weeks, trust them to get it done in 3 weeks.

There may always be obstacles, so add another 25%, but if they consistently stretch deadlines, do not take responsibility for their delays and you have no clear understanding about what they are doing or why it delays, be careful.

Unfortunately, you likely realize delays later in the project - thus make sure to spot them early and allow for early spotting - Let them build the first feature and pay them feature and progress-based instead of paying them upfront 100% of the bill.

This way you can opt out in case they are not as good as you anticipated and working with them feels like you are swimming in a wide ocean without land in sight.

*** Spotting Lousy Developers

If you cannot trust the milestones you set together with them and they consistently delay them, be careful. This is true for yourself too, but when you give them work and describe clearly what you expect them to do and they give you specific timelines for their work, its on them to deliver.

Check their language early on. Do they say they sent you a contract and do not do it at the right time? Do they promise overly optimistic timelines without any proper explanation why they are so much faster than everyone else on the market? Do they know what they talk about? Do you feel confident that they bring your product to the finish line? Do they have the right skills. Ask all these question to better understand how they work. Ask them what kind of tools they use to keep track of the progress. Do they share it with you? Do they give you daily updates of the progress made?

All these questions can help you determine if what they do will actually happen.

Make sure you have access to the key code

Even when you are not the main developer and have little ideas about tech and how to build tech products, make sure you have full access and transparency about what they are building.

When you are building your company and product, and they build it for you, never assume they will be there forever. You need to be able to take control of the product if needed. That means, you need to know how to keep it alive, how to potentially grow and expand it and how that works.

If developers give you a great product but you do not know how to handle it yourself, this is a problem. You need to be able to set it up yourself and it needs to be replicable. If anything happens, you invested your time and money and you need to make sure this Intellectual Property is yours and you know how to leverage it.

If you are not a technical person and never saw a line of code, ask a good friend to help you - yet, ideally you learn the basics of being able to control it yourself.

It will help you a long way. You do not need to be an expert, neither do you need to be able to build it, but you should be able to show others how to install it, work with it and take it from there.

With this also comes - Make sure you have a proper documentation and ask the developers to give and explain it to you.

*** Spotting Lousy Developers

While this is mainly about your understanding, make sure to write this down in your contract with them. Make sure for them to sign an NDA if your work is highly confidential, make sure that you have full rights over everything, discuss that with them further.

Discuss already in the beginning, how they hand over the product, setup and code. Discuss what tools they use, the pricing of keeping your product alive, the choices of tools to be used.

Make sure from early on that in regular milestones they share all the relevant details with you. And make sure even if there are issues along the way, that they share their partial work with you and document all that has been done so far so that others can take over.

If it feels like your developers moved into cave, documented nothing and are sloppy in their communication and what they achieve, make sure to keep them motivated or choose others.

Final Remarks & the biggest learning

Now, you have it. These are some of the key learnings I gained from building a first MVP with the help of developers.

And the biggest learning? Trust your gut! When you feel you are faster yourself and you do not trust them to do a good job, don’t do it - the price and costs and time you lose is not worth it and it may backfire - you think - ah they will be faster than I will be, they are ready now, but if they do a bad job, you may have to start all over again from the start and that is much more costly plus may risk your “right on time, right to start” momentum you build plus risks your own credibility as you trusted a team that did not bring to life what you promised and put out in the market.