AI in productionRAG that doesn't hallucinate
Grounding an assistant in your own documents — with citations, and an honest “not found” instead of a confident guess.
9 min read
← Resources
Blog · engineering & product writing
Field notes from shipping software.
Practical writing from the engineers who build our client work — AI in production, SaaS architecture, integrations, and security. The decisions and trade-offs, not press releases. Written to be useful to the people who actually have to build the thing.
AI in production/SaaS architecture/integrations/security
Scroll
01Why we write
Most engineering writing is marketing. Ours is the stuff we wish we'd read.
The internet is full of tutorials that stop at the happy path and launch posts that skip the part where it broke. We write the other thing: what we learned shipping real systems for real clients — the decision behind a piece of architecture, the trade-off nobody mentions until it bites, the boring detail that turned out to matter most. Every post is grounded in something we actually built or debugged, written for the person who has to make the same call next week. No press releases, no thought-leadership filler — just the notes we'd have wanted before we started.
02Featured
AI in production12 min read
Shipping AI to production: what actually breaks.
The demo always works. Then real users arrive with messy inputs, the latency budget tightens, costs creep, and the model confidently invents an answer no one can trace. This is the field guide we give ourselves before turning a clever prototype into a feature people can actually rely on — grounding, evaluation, guardrails, fallbacks, and the unglamorous plumbing that decides whether it survives contact with production.
Read the post03What we write about
Six things we ship — and write about.
- 01
AI in production
Assistants, RAG over private docs, evaluation and guardrails — getting models from demo to dependable.
- 02
SaaS architecture
Multi-tenancy, billing, and the foundations a product can grow on without accumulating security debt.
- 03
Integrations & APIs
Reliable syncs, webhooks, retries and idempotency — integrations that hold up when the other system misbehaves.
- 04
Security & compliance
Auth, roles, audit trails, and least privilege — the things that are cheap up front and painful to retrofit.
- 05
Data & dashboards
Pipelines, metrics, and the difference between a chart that looks busy and one a team actually trusts.
- 06
Performance & cost
Latency, query plans, and cloud bills — the unglamorous work that keeps a product fast and affordable.
The decisions, not the press release.
Every post is grounded in something we actually shipped — including the parts that broke.
04From the blog
Recent writing worth your time.
AI in production
IntegrationsIntegrations that survive the real world
Retries, idempotency, and replay — why the happy-path webhook demo is the easy 20% and the rest is where projects die.
11 min read
SecurityMulti-tenant security from day one
Tenancy, roles, and isolation done right at the start — because retrofitting it after the first customer is the expensive way.
8 min read
05How we write
Useful, honest, and grounded in real work.
Grounded in real builds
Every post comes from something we shipped or debugged — not a topic picked to chase search traffic.
Honest about trade-offs
We name what we'd do differently and where the obvious answer is wrong. The caveats are the useful part.
Written for builders
Focused on the decision you actually face, with the background linked rather than padded into the post.
One practical dispatch a month.
The posts worth reading, collected — no spam, unsubscribe in a click.
Subscribe06Questions
The things readers ask first.
The engineering we do for a living: shipping AI into production, SaaS architecture, integrations and APIs, security and compliance, data and dashboards, and the unglamorous performance and cost work that decides whether a product survives. We write about the decisions and trade-offs — not press releases — so the posts are useful to the people who have to build the thing, not just read about it.
Got a problem worth writing about?
The best posts start as a real question someone asked us. Tell us what you're wrestling with — even if it doesn't become a post, we'll point you at the most relevant thing we've written or built.