AI guides
Less about models, more about judgement. The expensive mistakes we see are projects that should never have been AI projects — so these guides are mostly about telling the difference.
The guides
Where we stand
We build AI systems, and we turn down AI projects. Those are not in tension — the second is what makes the first work.
The pattern behind nearly every disappointing AI deployment is the same: something automatable by rules got a model instead, or something with a data problem got a layer on top of the bad data, or a system was built whose errors nobody can see. None of those are model failures. They are scoping failures, and they are decided before any code is written.
So the useful thing we can publish is not prompt technique. It is the test we actually apply.
What we are writing next
| Guide | The thing that catches people |
|---|---|
| What an AI feature costs to run | Per-request economics, and why the pilot that cost nothing becomes a real line item at volume. |
| Designing for visible failure | Making a system say "I do not know" is worth more than making it more accurate. |
| Public API, private model, or neither | The decision that determines your cost floor, your latency and where your data goes. |
| Evaluating before you ship | How to know it works without shipping it at customers first. |
Bring us the workflow, not the buzzword
Describe what a person on your team does over and over. We will tell you on a 30-minute call whether AI genuinely helps — including when the honest answer is a script and an afternoon.
Book a call →