We have hired seven development partners over nine years. Two of them we went back to. The other five did competent work that finished, invoiced, and ended.

The difference was not skill. It was what happened around the code, and I can now spot it within about three weeks.

What most partners optimise for is finishing on time and on budget. That is table stakes. It gets you paid and it does not get you asked back.

The two we returned to did something else. They made us better at running the next project, whether or not they were on it.

One told us in week two that a module we had scoped would cost more than we thought and probably was not worth building. They were right, we cut it, and the contract got smaller. That is why they got the next one.

A software development company willing to shrink a contract in week two is showing you something no reference call reveals.

Weekly demos of working software, on real infrastructure, with our data.

Not slides. Not a recorded walkthrough. Something we could click.

The reason this matters commercially is that it makes problems small. A misunderstanding found in week three costs an afternoon. The same misunderstanding found at handover costs a phase.

Every partner we did not rehire had reported progress in documents. Every one of those projects had a surprise near the end.

I did not understand this early on and it cost us.

Our third partner delivered good software with a deployment process only they could run. When they left, our team could not release safely, and we paid a second firm to rebuild that path.

Now the delivery mechanics are in scope from day one. Automated build and test, environments defined in code, and a release our own engineers can perform.

Our current partner works in Azure DevOps Services because our estate already sits there. They built the pipelines in our tenancy rather than theirs. Any firm that resists using your own Azure DevOps Services instance is worth questioning. That detail sounds administrative and it is the difference between owning your delivery path and renting it.

We now require our own people in design reviews and pairing sessions. It slows the first month and it is the reason month twelve works.

The failure mode is easy to describe. A partner builds something well, documents it properly, and hands it over. Six months later nobody internally understands why a decision was made, and every change becomes a small archaeology project.

Knowledge does not transfer through documents. It transfers through people who were present.

Every proposal lists capabilities. Almost none lists limits.

We now ask directly. What kind of work do you turn down? Where are you weaker than a specialist? What would you refer elsewhere?

Two firms said they took anything. One named three areas plainly and recommended someone else for one of them.

That third firm got the contract. A software development company confident enough to describe its own edges is easier to plan around.

Every proposal mentions AI, so the question has become how rather than whether.

Our current partner uses assistants heavily for tests and routine code, and told us plainly that their review load went up as a result. I found that credible in a way the confident productivity claims were not.

We also asked about our Salesforce estate, where the automation story keeps changing. Agentforce features have replaced what used to be Einstein Copilot, renamed in early 2025, and the current generation is Agentforce 360. Two of our shortlisted partners were still describing the old product by its old name, which told us how recently they had worked in that platform.

●      Did they disagree with something in our brief, specifically?

●      Is there working software we can use, on our data?

●      Have they told us anything we did not want to hear?

●      Are our engineers in the sessions or receiving updates?

●      Can we deploy what exists today without them?

Five questions, asked at week three, predict the outcome better than anything in a proposal.

Fixed price or time and materials?

Fixed price for a tightly defined first phase, then time and materials once you both understand the system. A long fixed price contract encourages a partner to resist the scope changes you will want.

How large should a first engagement be?

Small enough that being wrong is affordable. Ours is one meaningful outcome in about ten weeks.

Should they use our tools or theirs?

Yours, in your accounts. A software development company working entirely in its own environment is building an exit cost into the arrangement.

Should the same firm run it afterwards?

Not necessarily. Ask any software development company what your team will be able to maintain alone, and judge the answer.

How do we compare proposals fairly?

Give all of them the same three real problems, including your ugliest one. Generic briefs produce generic proposals and every firm looks similar.

By the time we award a second project, we know something no reference call would have told us.

We know how they behave when an estimate is wrong. We know whether our own team learned anything. We know whether the code can be changed by someone who was not there when it was written.

That is what a software development company should be trying to demonstrate in a first engagement. Delivering the scope is the minimum. Leaving a client more capable, with their own pipeline and their own understanding, is what gets the phone call the following year.

The five partners who did not come back all did the work we asked for. That turned out not to be the same as doing the job.