Feeling a bit stuck on your MVP development?

A really common scenario: you’ve had some code developed, but now you’re feeling a bit stuck. Typically:

• your developer doesn’t get what you’re trying to do
• they are unavailable to do further work
• you need to move faster
• concerns about the work being good enough to commercialise or scale

Don’t stress - lots of people are in exactly the same situation. There are a few key decisions you need to work out.

The first is whether you want to keep working with your existing developer or not. There might be reasons you’d like to keep working with them - such as they’ve already been paid, you think they understand everything and you don’t want to lose that etc.

Or not. There might not be any reason to persist. But be clear in your own mind as to why. This helps repeating mistakes going forward.

Now if you want to keep working with your existing team, it would be a Bad Idea™️ to keep your existing developer pushing changes while you also engage a dev team like Red Ant to do the work. I realise this might seem to make sense, but it rarely works out.

What can work is if there is a natural segmentation in your project like APIs or delivery formats (eg: native phone app that consumes an API) - so each team can work pretty much independently. And most importantly take responsibility and ownership for delivery.

Another option is to pad your team with freelancers, but this is not without it’s challenges. The first is surprise at how hard it is to find developers. The second is joy when you finally find someone available. And the third is despair when you realise they are way more junior than you need and you’re now a bit further behind.

The other option is to engage an experienced development team like Red Ant. This is probably the fastest and most reliable way to get to a commercial MVP. If you’re anything like other people we’ve worked with, you simply don’t have the time to get developers up to speed (we find it takes 3-6 months for a new developer). We’ve already got all the process, systems and experience to push straight into your MVP build.

Hang on - you’re probably wondering how impartial this advice is. Of course we’re going to argue that. Right?To explain - we get to see a lot of train wrecks. Companies at various stages of progress, that have made various decisions. Then at some point they ask us for an estimate, a code review or analysis of options. We have no incentive to work with train wrecks. We’d like to work with solid companies that will become super successful. We think we can help improve your odds, and keep working with you for many years. A bad fit is bad both ways - so whatever insight or advice we can provide that helps you make a decision benefits both parties.

To address delivery timeframe and quality, you typically need to increase team size. It is not unusual (in our experience) to run into MVP projects that have been built by a single developer that are almost there, but not quite. You’ve probably heard that saying about the last 5 or 10% being the hardest - well that applies here.

To compound the problem, the type of developer personality that will tell you they can build everything is probably exactly the type of developer you don’t want. They’ll typically make the early decisions and chose shiny technology that is interesting to them but will mire you in technical debt for many years.

You also need a well rounded team. You’ve probably heard from people that you just need these mythical “Full Stack” developers. They only exist in the parallel universe that recruiters live. Which I can totally understand and relate to. It must be really easy to place someone that can do anything. How cool would that be? When we recruit people, if they use the term “full stack” they probably won’t get an interview. It implies a lack of experience to know what you don’t know.

What you do need is a functional MVP that is commercial. To get to that point you’re going to need quite a few things:

• good project management,
• to make the right technical + product decisions,
• choose the right technology,
• and create a user experience that works.

You need a well rounded team that can work together to deliver each of those aspects.

The next decision is around existing code. Of course it would be sensible to build on top of what you already have. Sometimes this makes sense, sometimes it can actually slow you down. It isn’t black and white, and there are probably some compromises you need to understand and then decide on. We’d need to do a code review first, and then discuss options around what to keep, fix and redo.

Getting a team like Red Ant to deliver your MVP has arguably the lowest risk / best return. You’re getting a more stable product and more predictable outcome. However, this all costs money, and might be more money than you have/want to spend. My advice would be to keep in mind that

more effort = more code = more/better features.

Just like any other constraints in an Agile project - you’ve got quality, specific features, budget and delivery date that can all move up and down. If you make one fixed, you’ll probably need to compromise on another. Also consider things like R\&D and Government Innovation grants that can offset costs, and eventual sale. Working with reputable team like Red Ant does make this a lot easier - it is hard to justify good valuation if your underlying tech is wonky.