We have three AI products in market. Not decks about products, not pilots waiting for a champion: shipped software that businesses run their operations on. Building them taught us a set of lessons that appear in no AI strategy presentation we have ever been shown, mostly because the people writing those presentations have not had to keep a product alive after the demo.
This is a build log, so it stays specific and slightly unglamorous. The lessons generalise; the scars are ours.
Why is the model the easy part? #
The model is the easy part because it is the only component you can buy. Capability arrives by API, improves without your effort, and costs less every year. Everything else that makes an AI product work, clean data, a home in someone's workflow, a clear escalation path, has to be built for the specific business, and that is where the time goes.
On every one of our three builds, the ratio surprised the client and, the first time, surprised us. The intelligence layer was a minority of the engineering. The majority was upstream and around it: connecting systems that had never spoken, deciding what the tool should do when it is unsure, and making the output land inside a routine someone already has.
The practical implication cuts against most AI roadmaps. Do not start with a model evaluation. Start with an honest audit of the three questions below, because they decide the fate of the build before a single prompt is written.
What are the real upstream problems? #
Three questions decide whether an AI build survives contact with a real business. Whose workflow does it live in? What data can it actually trust? And who signs off when the machine is unsure? Products with crisp answers to all three get used. Products without them get demonstrated, admired, and abandoned.
Workflow first. Software that requires a new habit is fighting human nature; software that appears inside an existing routine, the Monday report, the deal review, the compliance check, gets adopted by default. On each of our builds, the design conversation that mattered most was not about features. It was about which existing moment in the operator's week the product would occupy.
Data second. Every business believes its data is worse than everyone else's and most are right in ways they have not mapped. The build always includes a phase where the product's outputs are checked against reality and the discrepancies traced back to source systems. Budget for it. The model amplifies whatever it is fed, including the fictions.
Sign-off third. An AI product that cannot say "I am not sure, a human should look at this" is a liability, and one that says it too often is shelfware. Designing that threshold, and naming the human on the other end of it, is a governance decision dressed as a UX detail. It is the one executives most often wave away and most often regret.
What does deadline-driven adoption look like in practice? #
The strongest adoption forcing function we have worked with is a regulatory deadline. Indium OS, one of our three products, exists because Australia's AML/CTF obligations extend to real estate professionals from July 2026, bringing 80,000+ newly regulated entities into a compliance regime most of them have never operated under.
A deadline like that changes the texture of an AI build completely. Nobody asks for a vision workshop. The workflow question answers itself, because the obligations specify what must happen and when. The sign-off question answers itself, because the regulator has views. What remains is execution: can the product make an unavoidable process cheaper, faster, and safer than doing it manually?
The general lesson for any operator: look for the places in your own business where an external clock is already ticking. Regulation, contract renewals, platform deprecations, seasonal peaks. AI attached to a deadline gets adopted. AI attached to an aspiration gets discussed.
Why are most pilots designed to be abandoned? #
Most pilots die because they were scoped to demonstrate, never to operate. A pilot scoped for a demo optimises for the meeting: impressive output, curated data, no error handling, no owner. Everything that makes software survivable in production was descoped as "phase two", and phase two requires a business case the abandoned pilot can no longer make.
Scoping to keep inverts the priorities. It picks a narrow, boring, recurring job over a broad impressive one. It runs on live messy data from day one, because that is the only data the product will ever have. It names an owner, an escalation path, and a maintenance budget before build starts. It defines the number that will prove it worked, and the date that number gets checked.
The checklist below is the one we now run at the start of every build. It looks bureaucratic. It is the opposite: twenty minutes of scoping honesty that has killed our worst ideas early and made the survivors much harder to abandon.
Pilots are demonstrated. Products are kept. Choose at scoping, because you will not get to choose later.