Blog
Build, buy, or wait: assessing new technology without burning a budget
Something new arrives every few months that a vendor will tell you is urgent. Some of it is. Most of it is worth watching, and a small amount is worth acting on now. The businesses that handle this well are not the ones with the best predictions. They are the ones with a cheap way of deciding, so a wrong call costs a fortnight instead of a year. The default assumption is that waiting means falling
What 'embedded partner' means once you strip out the marketing
Every agency in the country says it is a partner rather than a supplier. The word has been used so freely that it no longer carries information, which is a shame, because the difference between the two is real and easy to describe. So here is ours, in specifics you can hold us to. You get a lead who owns the relationship and stays. Not a rotating account manager, not a different developer every qu
The rollout is the project, not the last two weeks of it
On most project plans, the rollout is a bar near the right-hand edge, about two weeks long, called training and handover. It is the first thing compressed when the build runs late, and it is where the return on the whole investment is decided. That is backwards, and it is worth understanding why it happens before looking at what to do differently. Not carelessness. Structure. The build has a defin
RAG, fine-tuning, or neither: how we actually decide
There is a standard conversation about AI architecture that goes straight to whether you should use retrieval or fine-tune a model. It is the wrong first question, and answering it early is how projects get expensive. The right first question is what kind of gap you are closing. There are only three, and each one has an obvious answer. If the model does not know facts about your business — your cu
Five things your data has to do before an AI agent can touch it
When an AI project fails, the post-mortem usually blames the model. In our experience it is almost always the data, and the failure was predictable before a line of code was written. My colleague Ryan has written about why readiness is the real work from the business side. This is the technical version: the five specific properties your data needs before automation on top of it is worth building.
Designing for the shop floor, not the boardroom
Software for operational work gets designed in the wrong room. It gets designed in an office, on a large monitor, by people sitting down, for people who are standing up. That gap explains most of what goes wrong. Not taste, not visual polish. The conditions the software was imagined in versus the conditions it has to survive. A person entering a job on a factory floor is standing, possibly wearing
Software isn't your constraint. The way you make decisions is.
Building software has never been easier or cheaper than it is right now. Which raises an obvious question: if the building was the hard part, why are so many businesses still stuck? Because it was not the hard part. The constraint was never how fast you could produce software. It is how fast your business can notice something, decide what to do, and act. Software only helps if it sits on that path
How we know an AI agent is still working six months later
Getting an AI feature to work in a demo is not hard any more. Knowing it still works in June, on data nobody anticipated in January, is the actual engineering problem, and it is where most implementations quietly fail. A traditional system either works or throws an error. An AI system has a third state: running normally and producing worse answers than it used to. Nothing alerts. The dashboard is