Report first, hands second
Before touching a production server we write down what changes, what can break, where the latest backup is and how to roll back. We act only after your approval.
approach
How we work
We run our own systems in production, so we know what a mistake on a live server costs. Hence the order of work: calculate first, build second, and deploy nothing without your approval.
-
Stage 01
Understand the task
We look at what already runs, where the bottleneck is and what you would count as a result. Often AI is needed in one place out of five; the rest is fixed faster and cheaper without it.
- Outcome:
- A list of tasks with an estimated effect for each, and a clear first target.
- Needs:
- Access to what already runs, and one person who knows the process from the inside.
-
Stage 02
Design and cost it
We draw the solution and calculate the cost per request and per month of operation before the first line of code. If the numbers do not add up, you hear it at the start.
- Outcome:
- Architecture, a budget, and a straight answer on whether the project is worth doing.
- Needs:
- A decision on budget and priorities: what we build now and what waits.
-
Stage 03
Build and roll out
Code and architecture go through review. We roll out in parts, so one piece rolls back instead of the whole system. Monitoring ships with the release.
- Outcome:
- A running system with metrics and a rollback plan for every change.
- Needs:
- A staging environment and an agreed window for each rollout.
-
Stage 04
Operate and hand over
We watch the metrics, investigate incidents and fix what only shows up under real load. Documentation is written so the system does not depend on us personally.
- Outcome:
- A system another team can take over.
- Needs:
- Feedback from the people who use the system every day.
Rules we follow on production
These are not promises for a website. We run our own servers by these rules, and each one was written after a specific incident.
Production systems
Nothing deploys on its own
No deploy, service restart or config edit happens without an explicit instruction. Every change is agreed in advance, with its rollback path written down.
A backup is a restore
A backup file on disk proves nothing. The only test that counts is a successful restore from it, and that test happens before it is needed for real.
Roll out in parts
A change is split so that one piece can roll back on its own. A single large release cannot be rolled back; it can only be patched in a panic.
Failure tolerance
One failed node does not take the system down
Model providers are chained: on errors or rate limits the request moves to the next one in the list. A failing provider is excluded for a while so it does not drag the rest down.
Observability from day one
Metrics, logs and alerts ship with the release. A system whose outage you learn about from a customer counts as broken.
Versions are pinned
No dependency and no container image without an exact version. A build that worked yesterday and fails today because something updated itself costs more than any time saved.
Security and data
No fresh releases on production
We check the age of a version before installing it. A package published a few hours ago does not go on a production server: a poisoned fresh version of a popular library is a standard supply-chain attack.
Secrets do not live in code
Keys and tokens are passed as environment variables and never enter the repository. Access is minimal: a service gets exactly what it needs and nothing more.
Private data stays inside
Where confidentiality matters more than the last few percent of quality, models run on your hardware. Data does not go to external providers just because that was easier to set up.
Engineering discipline
Deterministic checks come before the model
Where a rule, a regular expression or a test solves the problem, a language model should not be there. It is more expensive, slower, and answers differently to the same input.
Prompts are code
Prompts, schemas and configs live under version control and change through review. An unrecorded prompt edit in production is a change in system behaviour that nobody knows about.
Documentation is written for the next team
We leave the system in a state another team can pick up: how it is built, how to deploy it, what breaks most often and what to do when it does.
What you get
Quality
Code and architecture go through review. Tests and monitoring from day one, before the first incident rather than after it.
Availability
The loss of one provider or node does not take the system down: reserve capacity and failover are part of the design.
Reliability
Every change has a rollback plan. Backups are made and verified by restoring them.
What we do not do
- We do not sell AI where a script, a procedure or plain automation is enough.
- We do not take on tasks without a measurable result. If nobody can say what success looks like, the project will not work.
- We do not leave behind a system that cannot be rolled back and that nobody watches.
If the task is not for us, we say so in the first conversation and, where we can, point you to someone who fits.
It all starts with the task breakdown
Describe what you have now and what is in the way. The first stage costs nothing.