Backend Engineering
Services with clear contracts and predictable behavior under load and under failure.
- Versioned, documented APIs
- Validation at every boundary
- Idempotent operations
- Integration tests where it matters
Loading…
Technology
A list of frameworks says little about how a company builds software. We'd rather explain the principles behind our decisions — because tools change, and principles stay.
Principles
Response time is part of the experience. We measure at the percentile that hurts (p95/p99), not the average.
Failures will happen. We design so they are detected early, contained and recoverable without data loss.
Least privilege, secrets kept out of the code, audited dependencies and inputs always validated.
Minimization, time-limited retention and clarity about where each piece of data is processed — including by AI models.
Structured logs, metrics and tracing from the first deploy. Without visibility, there is no operation.
Growing without rewriting: stateless components, queues for heavy work and explicit limits.
Builds, tests, deploys and checks run on their own. A manual process is a process that will fail one day.
Want to see these principles applied? Our engineering posts explain real decisions.
Engineering notesDisciplines
Services with clear contracts and predictable behavior under load and under failure.
When one system becomes many, the network becomes part of the business logic.
Models treated as software components: with a contract, evaluation and monitoring.
Reading, understanding and transforming documents of very different formats and quality.
Infrastructure described as code, reproducible and with costs tracked.
Correct data before abundant data.
Security as a property of the system, not a final step.
Knowing what is happening in production without having to guess.
Build vs Buy
We use existing technology when it makes sense, and build our own components when doing so gives us a technical or product advantage.
Building everything from scratch is vanity; buying everything off the shelf is dependency. Every decision is recorded with its context, alternatives and rationale — and revisited when the context changes.
| Question | We use what exists | We build |
|---|---|---|
| Is the component what sets the product apart? | No — it's common infrastructure. | Yes — it's the reason someone chooses the product. |
| Does it involve sensitive data? | No, or the vendor can be audited. | Yes, and the alternative means sending data somewhere we can't audit. |
| Is there a mature solution? | Yes, proven in production by many people. | Not at the quality the real use case demands. |
| Cost of maintaining it | Maintaining it would cost more than paying for it. | The cost pays for itself in control, quality or margin. |
| Can we switch later? | Yes, without rewriting the product. | No — the dependency would be structural. |
A concrete example
The site itself follows the principles above — the most direct way to show how we work.
See what we're building with these principles.