A lot of first calls start the same way. Before anyone describes the project, they describe the last developer.
The details vary. The project stalled halfway. The freelancer stopped answering. The agency delivered something that technically worked and that nobody on staff could change. The bill kept growing and the finish line kept moving.
The feeling underneath is always the same, and one software manager put it plainly:
Which is where we're stuck because we've already spent way too much money to start over.
That is a reasonable place to be. It is also the moment organizations are most likely to make the same mistake again, either by hiring the most confident-sounding replacement or by not hiring anyone and living with a system they no longer trust.
There is a better way to pick the next one.
What Usually Went Wrong
Before evaluating anyone new, it helps to be honest about what failed. In our experience it is rarely raw technical skill. It is one of these:
- The scope was never written down. Both sides thought they agreed. They didn't. A marketing partner describing a founder's history with developers said it in one line: "they just didn't scope well."
- The first commitment was the whole project. Months of work were bought on the strength of a sales call, with no small job to test the relationship first.
- Nobody owned the result. The code lived in the developer's account, on the developer's hosting, under the developer's licenses. When they left, so did your access.
- The technology was chosen for the developer, not for you. Something new and interesting, which the next person had to learn from scratch or throw away.
- Nobody answered the phone. Problems sat for days because there was no clear path to a person.
Write down which of these happened to you. It becomes your checklist for the next hire.
Before You Call Anyone: Find Out What You Own
The first job is an inventory, and you can do most of it without a developer.
- Where does the code live, and do you have admin access to that account?
- Who controls the hosting, the domain and the DNS?
- Which paid plugins, APIs or services is the system using, and whose name are the licenses in?
- Where are the credentials, and who else still has them?
- Is there any documentation, even an old email thread explaining how it works?
If you cannot answer these, the next developer's first task is to find out, and you'll pay for it. Better to know going in, and much better to recover access while the previous developer is still reachable.
The Questions That Separate the Next Hire
A new developer will demo well. So did the last one. These questions get past the demo.
1. "What would you change about what we've asked for?"
A good developer pushes back on scope. If every requirement comes back approved and priced, nobody has examined it. The answer you want sounds like "this part is more expensive than it's worth" or "you don't need this yet."
2. "What's the smallest first job we could do together?"
This is the most important question on the list. It tells you whether they are willing to earn trust instead of asking for it. More on this below.
3. "How do you estimate, and what happens when something unplanned turns up?"
Listen for specifics. You want an estimate for a defined piece of work that you approve before it starts, and a clear rule for what happens when the work uncovers something new. The rule should be that you hear about it and approve it before it gets built, not that it shows up on an invoice.
4. "Who actually does the work, and who's the backup?"
A fair question from any organization that has been left stranded. You should know whether the person on the call is the person writing the code, where the team is, and who picks up if that person is unavailable.
5. "Where will the code live, and what do we own at the end?"
The answer should be simple: in your account, and everything. The code, the repository, the data and the licenses.
6. "What would you tell us not to build?"
A developer who has never talked a client out of a project is a developer who sells projects. The ones worth hiring have a few stories about work they recommended against.
7. "What will you build it with, and why?"
The right answer is usually boring. As we put it to one prospect: we definitely don't want to stick something too new in front of something that's going to be used by people. Proven tools are easier to hire for, easier to maintain and easier to hand over. That last part matters more to you now than it did the first time.
Make the First Job Small, Real and Paid
The single best protection against a second bad experience is a small first engagement.
Not a free trial and not a discovery exercise that produces a slide deck. A real piece of work, with a real estimate, that delivers something you'll actually use. Fix one broken integration. Automate one report. Stabilize the part of the existing system that fails most often.
A small first job tells you things no sales call can:
- Whether the estimate matched the work.
- Whether they communicate when something goes sideways.
- Whether the code ends up where they said it would.
- Whether your staff can work with them.
It also tells them things about you, which is fair. When a prospect named their own distrust on a call, the answer we gave was the same one we'd give anyone: understood, and let's start with something small. Once we prove it, we'll be okay on the other side.
A director of software development at a large nonprofit asked for exactly this before the larger engagement:
I do think it'd be helpful if we started, like, with a really small slice of it, just to kind of like as a way of getting to know each other.
That was the right instinct, and it cost nothing to ask. The relationship that followed grew into a custom platform they still run on today. Trust on a project that size gets built in small pieces first.
Don't Assume You Have to Start Over
Burned clients often arrive convinced everything must be thrown away. Sometimes it should. Often it shouldn't.
Before any new developer quotes a rebuild, ask for an assessment of what exists: what is sound, what is fragile, and what can be kept while the worst parts are replaced. A rebuild is the most expensive answer, and "we've already spent way too much money" is a good reason to rule it out until someone has actually looked.
Red Flags the Second Time Around
- They want the whole project committed up front.
- They can't say who the backup is.
- The code will live in their account "for now."
- Their estimate has no assumptions written into it.
- They agree with every requirement.
- They say the last developer was an idiot before reading a line of the code.
That last one deserves a word. Inherited code is often messy for understandable reasons. A developer who blames everything on the previous one is setting up the same excuse for later.
Final Thoughts
Being burned once is expensive. It is also useful, because you now know exactly which questions matter.
Hire the next developer on the strength of a small, real piece of work, with the scope written down, the estimate approved before it starts, and the code in your account from day one. If that goes well, give them the next piece.
If you're recovering from a project that went sideways and want an honest read on what's worth keeping, we're happy to take a look. See how we approach custom software, or book a short consult.