Buy by building
For software that has to be built, the most revealing procurement process is the one you can watch.
Most software is bought after a test. You shortlist suppliers, run a trial or a proof of concept, sit through a pilot, then sign. For established off-the-shelf software that’s exactly right, and a Fixathon would add nothing to it.
The difficulty starts when the thing you need doesn’t exist yet. If the deliverable has to be built around your specific operational problem, there’s nothing to pilot. You’re choosing on proposals, references and rehearsed demonstrations, and the riskiest decision of all — who builds the system your operation will come to depend on — gets made before you’ve seen any of it work on your problem.
A Fixathon is an accelerated procurement process for that case. Several teams build competing solutions to a single real problem, using your data, in your operational context, before anything is awarded.
What becomes visible
A proposal describes capability. A build event displays it. Over a compressed window, teams work against the same brief and the same data, and you see what a document conceals: how a team behaves under time pressure, how it negotiates trade-offs, how it talks to the people who own the process and the people who run IT, and how candidly it describes what its solution doesn’t yet do. Those qualities determine whether a supplier is good to work with over the next two years, and they’re precisely the ones a proposal struggles to reveal.
At the close you’re choosing between working prototypes, usually more than one of which works. That’s a different exercise from betting on the team that interviewed well, and it reorders the risk: the largest hazard in commissioning software is committing budget before fit is known. Set against a stalled rollout or a rebuild, a structured contest is cheap.
There’s a side effect worth having. A conventional process narrows to one supplier and closes. A contest introduces you to a field of teams working on your problem, and leaves you with a clearer map of who can actually do the work.
What it commits you to
For software and AI there’s a second question, quieter but increasingly decisive: not whether a system works, but what it ties you to. A solution can perform well in a demonstration while leaving its owner locked to one vendor’s platform, dependent on primitives that are awkward to move, or unable to run the system on its own infrastructure. Those constraints are easy to overlook in a proposal and expensive to discover after signing.
Examined as it’s built, a solution reveals them in advance. Its architecture, its dependencies and the cost of leaving can all be inspected while you still hold leverage — before the contract, not after. The question a prudent buyer can rarely put to a supplier gets put to the code instead: if you later changed a tool, brought the system in-house, or stopped paying a particular vendor, how trapped would you be? If digital sovereignty is a strategic matter for you rather than a slogan, that early sight is hard to come by any other way.
What the first edition showed
Blufab, the industrial arm of the Casais Group, needed to estimate production times for modular bathroom panels — work it had long done by hand, with predictable costs when the estimates drifted: quotes misaligned with reality, shaky planning, difficulty scaling. Rather than commission a single supplier and hope, it set the problem to competing teams with its own factory data. By the end of the weekend it wasn’t searching for a workable solution; it was comparing several, and went on to negotiate which team to take forward. IEM4.0, running a parallel challenge on make-or-buy and production decisions, finished in the same position.
One edition is a modest sample and we won’t pretend otherwise. But the pattern it produced is the one the method is designed for: at the moment of decision, each buyer was comparing solutions it had already watched run.
Where it fits
For commodities, hardware, standardised services and off-the-shelf software you could simply trial, conventional procurement and a pilot do the job. Where the deliverable has to be built around your problem, and the real risks sit in how it’s constructed, what it leans on and how it behaves under real conditions, watching competing teams build it is the better test.
There’s also a matter of timing. The company that runs the challenge sees the strongest answers to its problem first, and holds the first right to adopt the winning one, before the teams that built it take their work elsewhere.
New to the format? Start with What is a Fixathon?. For the operational view, read Fit before scale.