Change your dev team like a pro
Not fully satisfied? Learn to safely start looking for new, better developers.
Facing programmers’ limits is normal
Imagine Mark. He’s a 34-years old entrepreneur from North Carolina with ambitious plans. He’s spent the last 5 years bootstrapping his small startup — a SaaS application in the niche of email marketing. Josh has managed to get a few freelancers who fit into his moderate budget to develop the application. And it worked — the more time he invested in the project and marketed it online, the more people came. Recently, he started charging for premium plans. His revenue started to increase.
But not everything is so perfect. The site has a major bug in checkout. Furthermore the site’s gained quite some traffic recently, but it gets really slow when peaks hit. It seems like the programmers he hired were good for starting the app when he didn’t have much to invest, but can’t keep up with the technical challenges and increasing traffic they’re facing now.
“Hiring new developers is so risky, I don’t know how to start. Is it really worth my time?”
Josh considers hiring new developers. “But that’s so risky. And I don’t know how to start”, he thinks. Does it really have to continue this way, though?
Three steps to safely change developers
Whether your current developers seem too inexperienced, demand has outgrown them, they’re missing deadlines, delivering a faulty product or just aren’t a personal fit for you any more, it’s time to move on to more experienced developers who are reliable and fun to work with. Following these 3 steps, you’ll be on the safest side possible and you’ll know how to prepare yourself. So, let’s start!
1. Draw a line with the old developers
Get comfortable with the idea of changing developers. If you experience any of the symtpoms mentioned above, that’s a clear sign you should be looking for a different team. Let’s explore when it is the best moment to change and what to finish with your current developers.
Finish almost completed features
Should you have any features that are almost done and require only little attention, finish them with your current developers. Most prospect developers will tell you they’ll be more than happy to finish them for you, but the truth is that it takes a new developer much more paid time to finish up little tasks than it will take your current developers to do that for you.
Should you worry about the quality of your current developers’ code, you can always decide to completely rewrite the feature later on, but you should at least finish it now.
Let them write a handing over document
This one will save you a lot of money and nerves with your new developers. It’s not their fault — they have to wrap their mind around the system, and that takes time. As your new developers will probably have a higher rate than your current ones, it’s much cheaper to let your current developers prepare a little introductory document, than pay for countless hours of research that your new developers will bill you.
Your current developers know your system best — it should be easy for them to write a few paragraphs about:
- the greater concept behind their architecture
- showcase any critical infrastructure
- explain major decisions behind certain larger parts of the system and
- point out any points of failure or unstable parts which require special care
Also instruct them to revisit their code comments, and improve them if necessary.
What if they won’t do it
It happens that freelancers disappear, lack time or you’re in a dispute with them. In this case, your new developers will simply have to figure it out on their own. That shouldn’t be a problem for them, but be prepared to spend a little more money. An important thing to do in that situation is to make a backup of the code and database of your application and safely keep it in a place you control. If you don’t know how to do that — ask your hoster, they’ll probably be able to help you.
2. Prepare useful information
Make life easy for your new prospect developers. You want to make sure they understand what your app is about and what exactly it is that you need done. Otherwise you’re risking wrong estimations and disputes afterwards.
Describe your business
In short paragraphs or bullet points, describe
- the market and position of your business
- what problem and pain point you’re solving and
- how exactly your app does that
You can use the lean canvas, that one’s perfect for such a high-level business model description. Be sure to point out the problem-solution fit — this is valuable information for any developer!
Describe all major features
There’s no need to go into much detail — but roughly describe all major features that your application has, e.g. a paywall, a blog, a registration page and a newsletter subscription.
List all ToDos
Now make a list of all the work that still has to be done. Divide that list into three sections:
- bugs: what’s not working as expected
- features not finished: include information about what’s left
- upcoming features: features that haven’t been started yet
Copy your current site
You may hesitate to give away the essentials of your app, but it’s important for your developers and will give you much better estimations. Trust me — you’ll save everybody a lot of headache.
If you don’t know how to export and zip a copy of your site’s code and database, your hosting provider may be able to help you again. In worst case you’ll have to give your prospect developers direct access to your servers, but you should be careful with that. You should always only hand out copies of your site if possible until you have a contract.
Should you have any sensitive content that you don’t want prospect developers to have access to, you can delete specific content from the copy of your database. This is quite a technical task and you may need your current developers to do it. Pay attention not to delete any configuration.
You may want to sign an NDA with any prospect developer who’s receiving a copy of the code and database.
Give project-related info
Point out your expected timeline:
- by when do you need a proposal?
- when is your earliest start date?
- when is your latest due date?
Also, try including your budget with the RFP. Many people are hesitant to tell it upfront, but it will immediately show if what you demand is realistic, and a developer is much more likely to propose cheaper alternatives when being aware of your budget upfront than he is after you reject his proposal which he spent a lot of time preparing.
Furthermore, it’s important to clarify what quality of work you expect:
- do you need a prototype?
- should it be ready to work on your live site with many users visiting?
- do you require an enterprise solution which is super safe and robust?
Next, describe your existing hosting infrastructure:
- what kind of environment is it?
- is it a server, or a virtual machine, a cloud-based provider?
- what are its specs?
- is it managed by your hosting provider, or will your prospect developer have the freedom to customize it but also have to keep it secure?
Lastly, describe any existing development procedures that you already have in place and you don’t want to give up. If you don’t have any yet or don’t require to keep them, that’s fine. Your new developers should have a proven routine anyway.
3. Choosing the right developers
This one is a huge topic on its own — that’s why we won’t go into it here. Whenever we publish a post on assessing prospect developers, we’ll link it up here.
What happened to Mark?
Mark has followed these steps about two years ago. He’s found new developers, and he’s very happy with them. He’s happy that he finally made the decision to switch, and if you’re struggling with your product development, so should you.