What we take on
Systems that have to stay up
Some software is a project. Some software is a dependency — the thing a business runs on, where an outage is not an inconvenience but a phone call. The second kind is what we take on.
That distinction shows up in the build long before it shows up in the operations. When the people writing the code are also the people who get woken up, arguments resolve differently: plainer data models beat clever ones, fewer moving parts beat more capable ones, and anything that cannot be diagnosed from a log at three in the morning tends not to survive review.
In practice that means web and mobile applications built on a stack we can still reason about in a year, and a handover that includes what usually gets left out — how it deploys, what gives way first under load, what to check before escalating, and which decisions were deliberate rather than accidental.
Coverage after launch is agreed per engagement rather than promised in the abstract. What we will not do is build something and then disappear from its consequences.
Getting AI into a product that already has users
Putting a model into a greenfield demo is straightforward. Putting one into software that already has customers, a schema, an authorisation model and a support queue is a different job, and most of that job has nothing to do with the model.
The questions that decide whether it works are structural. What is this feature allowed to see, given the permissions those users were already promised? Where does an answer come from when the model does not know — and does the product admit that, or bluff? What happens when the provider changes a model underneath you? Who reads the failures?
The work is usually retrieval over data you already hold, integration through MCP so a tool is described once instead of reimplemented per client, and the unglamorous parts: evaluation you can run before shipping, logging that shows what was actually retrieved rather than only what was returned, and a way to switch a feature off without a deploy.
Sometimes the honest answer is that a feature does not need a model at all. We would rather reach that conclusion early than bill for the alternative.
Whether we are a fit
Tell us what is in front of you and what you have already tried. If we are not the right people for it, we will say so and tell you what we would look for instead.