Hiring Custom Software Developers Again? Check What You Already Paid For

If your software is late, keeps breaking or never shipped, hiring more custom software developers is the costliest next step until someone has looked at what you already have. New developers inherit the existing code. If the code is weak, they will work slowly, build on top of it and bill you for the time they spend learning it.

Why a new hire often repeats the old problem

Most hiring guides tell you to write down your requirements, check portfolios and start with a small trial project.^[1] That is sound advice for a new build. It leaves out a case that matters to a founder with a product that is already half built: the problem may sit in the foundation, not in the people.

Weak architecture shows up as the same symptoms every time. Small changes take weeks. Fixing one bug causes another. Only one developer understands how a part works, and nobody wants to touch it. A stronger developer can still be slow in that setting. So when a project stalls, swapping developers rarely fixes it, and the spending continues.

What to find out before you hire

Four questions take a day or two to answer and change what you should do next.

• Do you own everything? You should keep full ownership of the code and the custom features built for you.^[2] Check that the code repository, the hosting account and the domain name are in your company's name, not a contractor's.
• Can a stranger run it? Ask a developer who has never seen the project to set it up on a clean computer from the repository. If that takes days, or can't be done without the original developer, the project depends on one person.
• Is there a safety net? Look for automated tests and a written record of changes. Without them, every release risks breaking something that worked.
• What does it cost to run? Look at the monthly hosting bill and ask what it pays for. Software that needs a large bill to stay up is often hiding poor design.

You don't need to read code to ask these. You do need an answer you can trust, which is why a short independent review is worth having before any new contract.

What the answers change

If the base is sound, the problem is usually direction or skill on the current team, and the right hire is someone who fills that gap. If the base is weak in a few places, those places should be stabilized first, so that any developer you hire afterward can move quickly. If one part can't carry the product, rebuild that part and leave the rest.

In each case you spend money on the specific problem. Hiring first means paying people to work around it.

How to hire once you know the gap

Describe the gap, not a job title. "We need someone who can untangle the billing module and write tests around it" gives you something to test in an interview. Ask candidates to read a piece of your existing code and explain what they would change. Developers who have done this work will have specific answers. Developers who haven't will talk in general terms.

Start with a small, paid piece of work before a long contract, so you see how they communicate and what they deliver.^[1] Keep the repository and accounts in your name from the first day.

What I do at Moosara

I rescue software that has stalled or keeps failing. I review the code and the architecture first, then tell you what is wrong and what fixing it will involve. I interview and hire the developers the work needs, so you don't have to judge them yourself. I also train your team and leave you with a system that cheaper developers can maintain and that costs little to host. The aim is a product that launches, or a smaller team that can keep it running.

The cost and time depend on what the review finds, and I won't guess before I have seen the code. If you want to talk it through, contact me directly and tell me where the project stands.