If you are looking to hire a custom software developer for the second time, the job is different from the first. You are no longer choosing someone to build. You are choosing someone to judge what the last developer left behind, and then to finish it.
Most founders skip that step. The software is late and unstable, the money is half spent, and the pull is to find another developer and keep going. That is how a second contract ends up paying for the same problem as the first.
Find out what you own
Before you hire anyone, learn what state the software is in. You need answers to a few plain questions:
- Does it run from a clean copy of the code, or only on one developer's machine?
- Do you hold the logins to the code repository, the hosting account and the domain, or does a contractor?
- Are there automated tests, so a change in one place doesn't quietly break another?
- Does the structure of the code fit what the product needs to do next?
A founder can't answer these alone. An outside developer with no stake in the old work can, usually after a short review of the code. The review decides whether the software can be repaired or has to be rebuilt in part. Repair is often cheaper, but only someone who has read the code can say.
Why the first hire went wrong
Founders who can't read code tend to hire on what they can see: a good pitch, a low rate, a polished website. None of these says whether the developer can design software that holds together as it grows.
The usual result is software that works in a demo and fails under real use. Features pile on top of a weak structure, each change takes longer than the last, and the bills grow while the product stands still. The developers may be honest and hardworking. They may simply lack the skill or the architecture to go further.
So the second hire needs a different test. Judge the developer on evidence of past work, not on promises about future work.
What to check before you sign
- Ask to see software they built that is still running. Ask for a client you can call, and ask that client whether the software stayed stable a year later.
- Ask about a project that went badly. A developer who has never had one is either new or not candid. What you want is a clear account of what they changed afterward.
- Start with a small paid task. Two or three weeks on a real piece of your product shows more than any interview. You see their code, their questions and how they report progress.
- Put ownership in writing. The code, the accounts and the documentation belong to you from the first day.
- Require working software every two weeks. Demos on slides don't count. You should be able to use what was built.
- Ask what it will cost to run and who can maintain it. If only the developer who wrote it can change it, you have hired a dependency. Software that a cheaper developer can maintain, on modest hosting, protects you for years after the contract ends.
Pause the spending while you check
Keeping the old contract running while you search feels safe, but it isn't. Each month adds cost to software you may need to repair or partly replace. A short pause for an outside review costs little beside another quarter of the same work.
How Moosara works on a second hire
Moosara is a software rescue practice run by Robert Lara III. It starts with the review described above: what runs, what breaks, and why. From that comes a plan to launch the product or to cut the size of the team that maintains it.
Where the team lacks skill, Moosara interviews and hires developers who have it, and trains the people already on the project. It sets a sound architecture so the system stays stable and runs on low hosting costs, and so cheaper developers can keep it going.
Founders ask two questions first: what will it cost, and how long will it take? Neither can be answered honestly before someone reads the code. A direct conversation with Robert is the quickest way to start. Contact Moosara to book one.