I Signed a Vendor After 2 Calls and Paid for It for 11 Months: My 7 Checks

The demo was excellent. The team on the call was senior, articulate and asked good questions, and the two references I rang said warm things. Eleven months later we had a codebase nobody on my team could change confidently, a production environment we could not deploy to without raising a ticket, and a change-request process that turned every small adjustment into a three-day estimate conversation. None of that was fraud. Every single warning sign was available to me before I signed, and I did not look, because looking felt like distrust and the quarter had a deadline in it. This is the process I use now, in the order I run it.

Why demos and references fail systematically

It is worth being precise about why the standard evaluation produces bad outcomes, because the failure is structural rather than moral. A demo shows you a finished artefact built under unknown conditions by unknown people on an unknown timeline. It is evidence of sales capability, which is real but is not the thing you are buying. References are worse, because they are selected: a vendor offers accounts that went well, typically staffed by their strongest engineers, often several years ago. A reference call is a genuine, honest account of an engagement that bears no particular relationship to yours.

Everything below replaces opinion with artefacts and behaviour. The ordering is deliberate: the cheap filters come first, so you only spend a paid trial on vendors who have already survived a document review.

Step 1: Write down what you are actually buying

Before meeting anyone, decide which of three things you want, because they imply different vendors and different contracts entirely:

• A capability you intend to keep. You want the system, and the knowledge, in house afterwards. Handover and documentation dominate the decision, and the cheapest builder is usually the wrong choice.
• Capacity on a capability you already have. You have the architecture and standards, you need more hands inside them. Integration with your process matters most, and your own review capacity becomes the constraint.
• An outcome you will never maintain. A marketing site, a one-off integration, a prototype with a known end date. Here speed and price legitimately win, and a heavyweight evaluation is waste.

Most disappointments I have seen come from buying the third while believing it was the first. If you write one sentence before the process starts, write this one: in two years, who maintains this? If the honest answer is your team, the vendor’s own engineering standards are now your inheritance, and steps two and five carry most of the weight.

Step 2: Ask for four artefacts before the first demo

Send this request before you accept a presentation. All four are things any competent vendor has to hand, and the response pattern is itself the first datapoint:

1. One real pull request from recent client work, redacted as needed, including the review comments. You are reading the conversation more than the code: does review catch substance, or is it a rubber stamp with an emoji?
2. One postmortem from a real incident. The strongest signal in this entire process is a vendor who can hand you a document describing their own mistake without defensiveness. It demonstrates that failures are examined rather than absorbed, and it is rare enough to be decisive.
3. Their onboarding document for a new engineer joining a client project. This tells you whether knowledge lives in writing or in one senior person’s head, which predicts exactly what happens when that person rolls off your account.
4. The named team list for your engagement, with roles and availability percentages.

Expect friction on the first two. Some refusals are legitimate, since client confidentiality is real, and a vendor offering a sanitised equivalent or an open-source contribution instead is answering in good faith. What should worry you is the vendor who cannot produce a postmortem because, as one told me cheerfully, they have never really had incidents. Everyone has incidents. Teams that do not write them up do not learn from them.

Step 3: Verify who will actually do the work

The gap between the people in the pitch and the people on the keyboard is the most common unpleasant surprise in this market, and it is entirely preventable with four questions asked in writing:

• Names and availability. Who specifically, at what percentage? A technical lead at 20 per cent is a reviewer, not a lead, and that is fine if you know it.
• Substitution policy. If someone leaves your account, what notice do you get and do you have any say in the replacement?
• Turnover on comparable accounts. How many engineers have rotated through a similar engagement in the past year? The number matters less than whether they can answer it at all.
• Overlap hours. How many hours per day overlap with your team, and who is on call during yours? For Singapore teams working with partners across the region this is usually workable, but it needs to be stated rather than assumed.

Put the answers in the agreement. A named-team commitment with a notice period on substitution costs a vendor nothing if they were being straight with you, and it is the clause that gets quietly resisted when they were not. If you are weighing this against hiring directly, our comparison of engaging an independent contractor in Singapore covers where each model makes sense.

Step 4: Run a paid trial instead of a reference call

This is the step that does the work, and if you only adopt one thing from this article, adopt this. Two weeks, paid at full rate, on a real slice of scope you genuinely need, inside your repository and through your review process. Not a take-home exercise and not a proof of concept in their sandbox, because both remove the conditions you are trying to observe.

What a trial reveals that nothing else does:

• How they behave when a requirement is ambiguous. Do they ask, assume, or build something defensible and wait to be told it is wrong? This single behaviour predicts more of your next year than any technical assessment.
• Whether tests arrive with the code, unprompted, when nobody has made it a contractual obligation.
• How they take rejection. Reject one piece of work for a legitimate reason and watch carefully. The response tells you what the next twelve months of disagreements will feel like.
• The real identity of the team, because the pitch team rarely survives contact with two weeks of actual delivery.
• Your own capacity. Most teams discover during a trial that their review throughput, not the vendor, is the binding constraint. Finding that out for two weeks of fees is cheap.

Pay for it, for two reasons. A vendor who declines a paid trial has told you something useful and inexpensive, and free work carries no accountability on either side. If you are running trials with more than one vendor, keep the scope identical and the reviewer the same person, or you are comparing reviewers rather than vendors. Our statement of work clause guide covers how to scope a trial so that the output is usable whichever way you decide.

Step 5: Inspect the handover surface

Ask one question and insist on a concrete answer: if this relationship ended next month, what exactly would we have? Then check each item rather than accepting the summary:

• Code. In your version control, under your organisation, from day one. Not delivered at milestones.
• Infrastructure. Defined as code, in your cloud account. This is the expensive one to get wrong: discovering that production lives in the vendor’s account with a deployment path only they can execute converts a contract dispute into a hostage situation.
• Credentials and secrets. In a store you control, with your own break-glass access.
• Documentation. Written continuously in your systems, not promised as a deliverable at the end. Documentation scheduled for the final sprint is documentation that will be negotiated away when the final sprint runs late.
• Knowledge. Can a competent engineer who has never seen the system get it running locally from the written instructions? That is testable during the trial, and I now test it.

If your intention is to bring the work in house later, plan the transfer at the start rather than at the end: our knowledge transfer method works the same way for vendor exits as it does for team changes.

Step 6: Price the change path, not the build

The quote you are comparing is for the thing as currently described, and the thing as currently described is wrong, because it always is. So the number that determines your actual spend is not the build price but the cost of changing your mind. Establish, with a worked example from a past client rather than a description of the mechanism:

That last row is the one I now care about most. A small-change allowance, even a modest monthly pool of hours, removes the friction that otherwise makes everyone avoid improving things. Without it you get a codebase nobody fixes, because fixing anything requires a conversation about money.

Step 7: Score the evidence against a bar you set first

Write your pass criteria before the process begins, and record findings per check as you go. The reason to fix the bar early is not rigour for its own sake: it is that by the time you have invested three weeks and a trial fee, you will be strongly motivated to conclude that the vendor is adequate. A written bar from week zero is the only defence against your own sunk cost.

My own standing rules, which you are welcome to borrow or disagree with:

• No postmortem and no credible substitute: stop. Not a deduction, a stop. This has saved me twice.
• Infrastructure in the vendor’s account with no path for us to deploy: stop, unless the engagement is genuinely disposable per step one.
• A refused paid trial: stop, with the one exception of a vendor you have already delivered with.
• Everything else is a trade to be priced and written into the contract rather than hoped away.

And be willing to run the process again. Running it twice costs six weeks. My compressed version cost eleven months, a rebuild, and a quarter of my credibility with a team who had asked, reasonably, whether anyone had looked at the vendor’s code before we signed. Nobody had. If the vendor you choose will be managing a dedicated team for you, our method for building a dedicated QA capability is the natural next read, and hiring a solutions architect covers the in-house counterpart who should own the review side of the relationship.

Frequently asked questions

How long should technical due diligence on a software vendor take?

About three weeks end to end, of which the paid trial is two. The artefact review and team verification take a few days of calendar time and only a handful of working hours. Teams compress this because a deadline is pressing, and the compression almost always removes the trial, which is the one irreplaceable step. If three weeks genuinely does not exist, scope the first engagement small and reversible instead of skipping the evaluation: a one-month pilot with an explicit break point costs far less than eleven months of a bad fit.

Is a paid trial really better than checking references?

Yes, and the reason is selection rather than dishonesty. References come from accounts that went well, often staffed by the vendor’s strongest people years ago, and they honestly describe an engagement unlike yours. A two-week paid trial on real scope in your repository shows how they handle ambiguity, whether tests arrive unprompted, how they respond to rejected work, and who is actually on the keyboard. Pay for it: a declined paid trial is informative, and free work carries no accountability.

What are the two contract clauses that matter most?

Handover and change requests. Handover should state that code, infrastructure definitions, credentials and documentation are yours, where they live during the engagement, and that transfer to you or a third party needs no cooperation beyond a defined notice period. Change requests should state how a change is estimated, who approves it, the approval turnaround and how it is billed, ideally with a small-change allowance. A fixed quote with an unconstrained change path is not a fixed quote.

Does this process work for a small engagement or just large ones?

It scales down if you keep the order and reduce the depth. Under about three months, steps one, two and four carry most of the value: know what you are buying, read one real pull request and one postmortem, run a short paid trial. Steps five and six can be a single conversation with written answers. What never scales down is the handover question, because small engagements are exactly where it gets skipped and where a critical service ends up deployed by a process only the vendor knows.