Stop bidding on tenders. Start showing up with the solution already built.

Most enterprise software gets bought the same way it did twenty years ago. A customer has a problem, writes it up, and issues a tender. Vendors respond with a proposal and a price, someone scores the submissions against a checklist, and a winner gets picked. Only then does the vendor actually sit down and build the thing, a process that can easily run for months before anyone finds out whether it works, or whether it was even what the customer meant in the first place.

That is an extraordinarily long time to wait to discover a misunderstanding, and it's part of why we've started doing things differently.

01What the traditional RFP actually asks of everyone

Procurement researchers have been writing about the same handful of RFP problems for years, and reading through that literature feels less like discovering something new and more like watching an old injury get diagnosed correctly for the first time. One recurring theme is that RFPs are often built around the past rather than the need, requirements get written to describe how things are done today, or how the incumbent supplier already does them, rather than what the organisation is actually trying to achieve. That limits how creative a vendor is even allowed to be in their response, and it means the customer rarely learns anything they didn't already know going in.

A second, related problem is what happens to price in that process. Evaluation frameworks often carry a long list of weighted criteria that look rigorous on paper, but a large share of the actual decision usually comes down to a much smaller set of factors, delivery risk, confidence in the team, and long-term flexibility, none of which a spreadsheet full of scores captures well. When price becomes the tie-breaker across superficially similar bids, it quietly crowds out the harder, more useful question of whether a solution will actually hold up two years after it ships.

And then there's the timeline itself. Even when a vendor is selected fairly and the contract looks sound, the customer is still buying a promise rather than a proven solution. The actual build happens afterward, often taking months, and it's only once that build is finally delivered that anyone discovers whether it does what was needed, or whether the brief was interpreted differently than intended somewhere along the way. By the time that becomes clear, unwinding a bad decision is expensive for everyone involved.

None of this is really about procurement teams doing their jobs badly, it's a structural problem with the format itself. A process built to be defensible and comparable on paper will always struggle to capture the parts of a good solution that only show up once you've actually seen it running, and it pushes that discovery to the point in the relationship where it's most expensive to act on.

02What we do differently now

Here is the part that changed for us. Trusted ActionVerse lets us build both AI workflows and agentic workflows without writing software from scratch, and it's worth understanding the difference, because they solve different kinds of problems. An AI workflow applies a model to a specific, well-defined step inside an otherwise fixed process, extracting data from a document, classifying a request, drafting a summary. An agentic workflow hands a system a goal and lets it plan, decide, and adapt its own path to get there, calling tools, making judgement calls, and adjusting when something doesn't go as expected. Some customer problems call for the first, some for the second, and most need a mix of both working together. TAV lets us build whichever the problem actually needs, without starting from zero each time.

That speed changes what we can bring to a customer before a contract even exists. Rather than waiting for a tender to appear and writing a proposal describing what we would build if selected, we increasingly build it first, on our own initiative, and bring the customer something that already runs on a version of their actual problem. Most of the time this means showing up with something close to the finished solution rather than a sketch of one. If the idea is genuinely new or unproven, the kind of concept nobody has built before, we'll walk the customer through it in a few staged demonstrations as it comes together, but that tends to be the exception. Far more often, because of how much groundwork TAV already handles, we can simply show them the real thing.

"A written proposal tells a customer what we think we could build. Showing up with something that already works tells them what we actually have."

The difference is easy to underestimate until you've sat through both. Reading a proposal means imagining a solution and trusting the vendor's account of their own ability to deliver it. Watching something that already works means you can see it, prod at it, ask what happens if a variable changes, and get an answer on the spot rather than a follow-up email three weeks later.

03Why this fixes more than one problem at once

Building the real thing first addresses the incumbency problem directly. Requirements in a traditional tender tend to reflect how the customer already does things, simply because that's the only reference point they have to write against. When we build first, independently, and bring the customer a solution shaped by a fresh perspective rather than one derived directly from their own outline, something useful tends to happen. Seeing their problem tackled from an angle they hadn't considered themselves often shows the customer that there was more than one way to think about it in the first place, and that realisation tends to open the conversation up into something closer to genuine collaboration, both sides bouncing ideas off a solution that's actually sitting in front of them instead of a document describing one.

It also rebalances the overemphasis on price that a checklist-driven RFP tends to produce. Once a customer has already seen a solution work, they naturally start evaluating it on whether it actually solves their problem and holds up over time, rather than comparing a column of numbers across proposals that all sound similar on paper. Price still matters, of course, but it stops being the only variable a rushed evaluator can meaningfully compare.

It also changes who gets a fair hearing, though maybe not in the way people assume. When several companies compete for the same piece of work, it's tempting to think the biggest team wins by default, simply because they have more people and more hours to throw at the problem. In practice, we've found headcount matters far less than the tools behind it. A small company working with strong abstractions and modern AI capability can move faster, and often build something better, than a much larger competitor still relying on traditional development methods. The advantage was never really about size. It was about the tooling. A rigid RFP format tends to reward whoever already has the relationship, the brand recognition, or the boilerplate response sitting ready to go, which is usually the largest player in a category. Turning up with something that already works is a much harder thing to overlook, whatever size the company behind it happens to be.

04Where this is heading

We don't think every procurement decision should skip a tender process altogether. There are good reasons regulated organisations need documented, auditable comparisons, and that isn't going away. But we do think the balance has swung too far toward the paperwork and away from actually seeing something work, and TAV is what makes it realistic to correct that. None of this comes from a change in ambition on our part, it comes from the fact that Trusted Hub's technology has genuinely shortened and streamlined the entire development process. Work that once needed weeks of engineering time to stand up now takes days, and building fast enough to show up with a working solution used to be something only much larger vendors, with much larger engineering budgets, could pull off. It isn't anymore.

Open communication tends to start earlier when there's something real to talk about rather than a document to interpret. Customers understand exactly what they're buying because they've already used it, and vendors get judged on what they can actually build, not just on how convincingly they can describe it. That's the trade we'd rather make, and increasingly, it's the one we're offering.