AI Development Services
Most AI projects die somewhere between the demo and the first real user. We build the unglamorous parts that decide whether yours survives.
A notebook that answers ten questions correctly is not a product. We learned that the slow way, on systems where being wrong has consequences: a police report that goes to a prosecutor, a revenue decision across a hotel portfolio, a voice assistant people talk to every morning.
We came to AI work sideways. We were already running production Laravel and Python for clients with uptime commitments and regulators to answer to. When those clients started asking for AI features, the interesting question was never whether a model could do the task. It was what happens when the model is confidently wrong at two in the morning on a Sunday, and who finds out first, you or your customer.
What we build
We work on four shapes of problem. Most projects are a mix of two or three of them.
- /LLM pipelines that take messy input (field notes, transcripts, documents, form data) and produce structured output a downstream system can trust.
- /Retrieval augmented generation over your own content, with retrieval treated as a search problem first and a prompt problem second.
- /Agents that take actions in real systems: booking, routing, updating records, escalating to a human when confidence drops.
- /Evaluation harnesses, because the only way to change a prompt safely is to know what broke.
The part most teams skip
Evaluation. Almost nobody builds it up front, and it is the reason AI projects stall at eighty percent good enough.
Without an eval suite every prompt change is a guess. Someone tweaks a system prompt to fix one customer complaint, ships it, and quietly regresses four behaviours nobody was watching. Six weeks later the team has stopped touching the prompt at all, because they cannot predict what will happen.
We build a graded corpus early, usually a few hundred real cases with known good answers, and wire it into CI. After that, changing the prompt becomes an ordinary engineering task with a pass rate attached. It is dull work and it is the difference between an AI feature you can improve and one you are afraid of.
Cost and latency are product decisions
Model choice gets framed as a quality question. In production it is mostly a cost and latency question, and those are product decisions rather than engineering ones.
A two stage pipeline where a small fast model handles the easy ninety percent and a larger one handles the rest will often beat a single expensive model on every axis that matters. Cheaper, faster, and easier to debug because you can see which stage failed. We default to that shape and only reach for the big model where it earns its place.
Where it runs
Not every client can send data to a third party API, and for some that is a legal position rather than a preference.
We have shipped into a CJIS compliant environment for US law enforcement, onto Swiss hosting with a self hosted text to speech stack for a client who wanted nothing leaving the country, and onto ordinary EU infrastructure for everyone else. If your constraint is regulatory, say so early, because it changes the architecture rather than the deployment script.
Work we have actually shipped
Four of these are live right now. You can go and look at them.
A patent pending pipeline that turns an officer's field notes into a complete, regulator compliant report. Officers get back roughly two and a half hours per shift. Running in departments across six US states, hosted in a CJIS compliant environment.
Harold OS, the AI layer running aparthotel portfolios: revenue, demand, guest journey and ground team coordination. Agents plus RAG over a vector database, with LangFuse for tracing. A dedicated Brigada team ships weekly alongside the founding operator.
Oxodin, a voice first agentic assistant for a Swiss AI company, live on the App Store and Google Play. Self hosted text to speech, Swiss hosting, and an agent layer that has to feel instant because people speak to it.
A US IT asset disposal business where the AI work is quieter: an assisted content pipeline feeding a Statamic CMS, aimed at lead generation rather than headlines.
Questions we get asked
Do you fine tune models or use APIs?
Usually APIs, with strong retrieval and evaluation around them. Fine tuning earns its place when you have a large volume of consistent labelled examples and a narrow task. Most clients who ask for fine tuning actually need better retrieval, and we will tell you that before taking the work.
How do you stop the model hallucinating?
You constrain what it can say and you check what it said. In practice that means structured output rather than free text wherever possible, retrieval that grounds answers in your own documents, and a validation layer that rejects or escalates responses failing a rule. Then an eval suite tells you the actual rate rather than your impression of it.
Can you run models on our own infrastructure?
Yes. We have shipped into CJIS compliant hosting for US law enforcement and onto Swiss infrastructure with a self hosted speech stack. Self hosting costs more in engineering time and usually more in compute, so it is worth doing when you have a regulatory or contractual reason rather than a general preference.
How long until something is in production?
Our typical gap between kickoff and first deploy is under two weeks, though that first deploy is deliberately small. A useful AI feature in front of real users is more often six to twelve weeks, and most of that goes into evaluation, edge cases and the fallback path rather than the model call itself.
What does an AI project cost to run?
It depends far more on your traffic shape than on the model price list. We model token cost per request early, because the difference between a naive single model design and a staged one is often five to ten times on the monthly bill at the same output quality.
Tell us what you are building
We will tell you honestly whether we are the right team for it, including when the answer is no. First reply usually comes the same working day.