A checklist before looking for a new development partner

6 min read
Article by Tudor Cutus
Product Consultant

I speak with quite a few founders every week at Tapptitude. A significant portion of them are not at their first attempt at building a product or they are looking to replace their current development partner for various reasons. When they are looking into replacing partners, founders often complain about the difficulty of communication, the speed of delivery or the work quality (i.e. large number of bugs that take forever to fix). But beyond exploring new avenues, what’s a founder in an unproductive collaboration to do?

Is the relationship truly dead and buried? 

If you’re considering switching your development partner, it helps to remember that you’re the one paying the bills. Your partner might have the technical know-how to build your product (and even keep it working), but you also have a lot of power in shaping the relationship. 

On the other hand, your budget will run out (especially if you are bootstrapping); that means you are on a clock when it comes to defining what kind of relationship you want with your current development partner, and even switching your agency involves costs. Sometimes, having an open conversation within a troubled partnership, where you offer transparency and ask for the same, allows the two sides to find a new middle ground. You can start by informing your partner where your expectations were not met and hopefully they will share what went wrong on their side – or what was flawed in the initial set-up of the partnership. From there, things may start looking better for you. But if they don’t, know that you’ve still got options to explore before you hit a dead end. 

The red flags of a bad partnership with an agency

Although I typically only hear the founders’ side of the story, I can usually spot mistakes they’ve made in picking their partner. Here are some examples:

  • No proper due diligence about the team’s competencies and delivery track record;
  • Rushing into a partnership for the sake of starting to build right away (reputable agencies don’t usually have teams or developers on the bench available to start within a couple of weeks); 
  • Going with a cross-platform framework (most common React Native or Flutter) without taking into account its limitations for the type of product you’re looking to build or the level of expertise the agency has on that framework;
  • Asking for a fixed price quotation before the product is fully defined (not trusting the time & material model or the steps needed in order to get to a fixed budget agreement)
  • Not clarifying how the team that will work on your product looks like and how much of their working time they will spend to work on your product;
  • Not clarifying the IP implications (you’d be surprised how creative some agencies can get with reusing code they don’t own the IP for or even buying templates from Codecanyon);
  • Having unrealistic expectations about the development velocity.  
  • Trying to build bootstrapped, thinking that will get you in a better position to raise your first round
  • Going with a partner that won’t challenge you and only tells you what you want to hear

To conclude, take a hard look at what went well and what went wrong. Rinse and repeat what has helped you. Learn from your mistakes. Are you in a better position to work with a more reputable (and often not as cheap) development agency or product studio or do you need to go back to the drawing board (and maybe to investors to raise a round)?

Can the new partners continue from where the previous developers left off? 

In an ideal scenario, your old development partner will hand over your codebase and upload it onto a repository you manage. From there, your new partners can take over and continue the work. But that is not always a smart idea… or the most productive path. Sometimes understanding another developer’s approach can be slower than rewriting it from scratch, especially if there is no documentation and they are no longer available to assist in this process.  

Another piece of advice here – try to get more than just one assessment of the code quality and avoid agencies that will only tell you what you want to hear to get your business. It’s better to prioritize transparency than too good to be true news. 

Where do we stand?

At Tapptitude, we ask many of the tough questions investors might ask you on a daily basis. This is to make sure the foundation is there for a better partnership and we don’t embark on one that’s doomed to fail at some point. We are also more than just executioners, it’s in our DNA to get involved in defining the value proposition, the validation plan for the MVP and so on – so expect us to cover those things with you again, and ask some tough questions as well, even though you might think you’ve cleared all those hurdles and just want to see your MVP built – or to iterate on the existing one. 

We’re also aware that the start-up journey is more about survival in the first one or two years than anything else, so you need a product team in place, not just an MVP built and then fingers crossed that the development team will have time for tweaks while the team is assigned on the next project. You need an experienced Product Manager, not just a Project Manager, to help you pivot or iterate as much as it takes until you get meaningful data and good traction on your product.

When taking on a client who already has a first version of a product built by another agency, we have a clear methodology:

  • We do an initial assessment of the code quality – if it’s too low, we will let you know this is a no-go for us. 
  • If necessary, a more in-depth code audit will be proposed  – to identify any areas that might need refactoring. 
  • An alignment phase to get on the same page about what you are building, for whom and what is the validation plan for the MVP. 

I hope this helps – if you’re ever stuck in your product journey, or looking for a partner to start your own, feel free to get in touch for a quick call to get to know each other.

Tudor Cutus Product Consultant