The platform worked. It had been specified properly and delivered close to budget. By the time we were called in, nobody left in the business could safely change a line of it.
Everyone involved had done their job. The brief was answered, the build was sound, and the people who understood why it was put together that way had long since moved on. What the business owned by then could be replaced but not repaired.
That is the most common way technology money disappears, and it almost never gets recorded as a failure. What went wrong happened years earlier, in the gap between the person who worked out what the business needed and the person who wrote the code, because the only thing that travelled between them was a document.
A specification is a lossy format. It carries the requirement. What it drops is the reasoning, and the remark the finance director made in passing that turns out to govern the whole design.
The two halves, and who holds them
Both halves of this work are hard, and they are hard in ways that have almost nothing in common.
The first is commercial. A chief executive with a problem rarely has a specification. They have a symptom. Margin is thinner than it should be and nobody can say exactly where it goes. Work gets won, then something happens between agreement and delivery. Turning that into something worth building means understanding how the business makes money, which parts of the process carry the risk, who has to be persuaded before anything changes, and what the organisation will actually adopt rather than what it says it wants. Most of that is diagnosis and internal selling, because change has to be sold inside a business before anyone can deliver it.
The second is engineering held to a production standard. Systems that take real money and keep running while the person who wrote them is asleep. There is no partial credit for that.
The market treats these as two professions because for almost everybody they are. The conventional options each solve one of them.
A consultancy does the diagnosis and hands over a document. The recommendation is often correct and nothing gets built, because the people who wrote it were never going to be the people who built it.
A development agency does the build and needs the diagnosis handed to them. They will deliver what the brief says. Whether the brief was right was somebody else’s job, and by the time that surfaces the engagement has ended.
An internal hire covers both, eventually, at a cost most businesses below a certain size cannot carry, and with a long wait before anything ships.
The firms doing this at the largest scale have noticed. Alongside forward deployed engineers, they are now hiring forward deployed product managers, and Ode has said so directly. That is a well-resourced organisation solving the seam by putting two people either side of it and absorbing the cost of the join.
There is another way to close it, which is for both halves to sit with the same hands. Nothing then has to survive translation, because there is no point at which one person’s understanding becomes another person’s instructions.
That is how Flux Dynamics is arranged. Diagnosis and engineering are treated as one job, scoped and priced as one job, and delivered by the person who did the diagnosis.
What the commercial half looks like
Every operating business has a commercial function. What most of them do not have is that function written down anywhere. Lead to proposal to job to paid invoice runs on people rather than systems, and it holds until the volume changes or somebody leaves. Almost no software gets built for that layer, because the businesses depending on it most look too small to be worth the trouble.
Strategic land shows the same problem with the stakes raised. A promoter that buys a site outright instead of optioning somebody else’s has changed its capital structure, and the risk position and the financing move with it. Carrying a contested greenfield scheme of more than 1,500 homes to outline permission then means holding a planning authority, a bench of consultants, a board and an investor group inside one programme for years, alongside the grid connection reserve and the utility tender.
The operating systems for that get built in-house, because nothing on the market is shaped for a business structured that way.
Software is rarely the first answer to any of this. It becomes the right answer once the operational problem is understood well enough to be worth automating, and working out which side of that line a business sits on is the first thing we do.
What we hold ourselves to
Commercial judgement without engineering discipline is opinion, so it is worth being exact about the standard.
Our planning-policy research engine is the clearest example. Hybrid retrieval across dense vectors, full-text search and exact code lookup, with reranking. Chunking that understands document structure, so a retrieved passage never splits a policy clause in half. Every claim it makes is bound to a verbatim quote from a real source, and the embedding and reranking run locally, so client documents never leave the machine.
It is also measured. Scored against an audited question set on citation accuracy, faithfulness, context recall and abstention, each with a threshold published before the run. Refusal is treated as a correct outcome and scored as one, so the system is judged on when it declines to answer as well as when it answers. Thresholds are fixed before the run, and a run that misses one does not ship.
Anyone can demonstrate a chatbot. Very few will show you the runs where it failed.
Planiit, where both halves were the same job
Planiit is our own events and payments platform, live in production with paying customers. A Rails application on Postgres, taking real money through Stripe. Hosts send digital invitations, guests respond and contribute, and the contributions pool into one gift instead of ten forgettable ones.
Writing it was the straightforward part. Moving other people’s money in the UK means satisfying e-money regulation, and the structure the product needed did not fit the standard patterns. We were rejected repeatedly. Each rejection meant going back and reworking how funds were held, who held them and on what basis, until we arrived at something both lawful and commercially viable. That took longer than building the software.
The binding constraint was regulatory from beginning to end. No amount of engineering removes it, and no specification would have contained it, because it was only discoverable by walking into it. That is the shape of most serious projects. The constraint sits in regulation, in a stakeholder, in an existing contract, or in how the business operates rather than how it is described.
Planiit also shows the part businesses underestimate about launching. Users ask for things nobody predicted, and some of those requests reveal that an assumption in the original design was wrong. The product improves only if somebody can change the code this week.
Why we stay after launch
A business that owns a finished artefact nobody can alter owns a photograph of a solution.
The platform this article opened with was a strategic land developer’s, and the fix was a security-first rebuild. An end-of-life system carrying real exposure, replaced because repair was no longer an option anyone could take on.
So we take on discovery and a costed roadmap through to build, deployment, hosting and ongoing maintenance on infrastructure we run. Web applications, internal tools, integrations and data platforms, alongside production AI covering retrieval systems, agents and content pipelines.
Current work includes a land promotion business running on a geospatial site-assessment tool and a planning data pipeline, a market monitoring agent of our own that runs continuously, e-commerce and membership platforms, and data systems that turn unstructured public information into something a business can act on.
Otto is the next of our own products. Evidence-grade planning AI for the industry: consultants, developers, land promoters, agents and councils. It answers from planning law, national policy and the development plan, and quotes the exact passage behind every point.
Who this suits
Businesses where the technology decision is commercial at root, and the constraint is regulatory or political, wearing a software costume. If you have been burned by a specification that was answered accurately and solved nothing, that is the failure this is built to avoid. It suits anyone who needs the person setting the direction to be the person who builds it.
The industry is currently rediscovering that delivery is where projects fail. That much is right. What is still being missed is where inside delivery the failure happens, and it is at the join, every time, at the point where one person’s understanding has to survive becoming another person’s instructions.
The most reliable way to protect a project from that is to remove the join.
Frequently asked questions
What does a fractional CTO actually do?
Sets technical direction and owns delivery, which mostly means deciding what is worth building and what is not. In our case that includes writing the software and running the infrastructure afterwards, so the person making the architectural decisions is the one who lives with them.
Why does commercial experience matter for a technical partner?
Because the hard part of most projects is identifying the real constraint, which is regulatory or political more often than it is technical. A brief that answers the wrong question gets delivered accurately and changes nothing.
How is this different from hiring an agency?
An agency delivers against a brief somebody else wrote. We do the diagnosis, set the direction, build it, then host and maintain it. Nothing is handed between parties, so nothing is lost in the handover.
What happens to the software after it launches?
It keeps changing, or it decays. Users surface requirements nobody predicted and some of them invalidate the original design. We stay on the code and the infrastructure, so the system can still be altered in the week somebody needs it altered.
What size of business is this for?
Businesses too small to carry a full internal engineering function but with problems too specific for off-the-shelf software. That usually means established firms modernising, and founders who need a technical partner rather than a supplier.
Jamie Francis is the founder of Flux Dynamics, a fractional CTO who builds. Tell us what you are weighing up.