//architecture

The architecture practice

What we optimise for, what we refuse to do, and the stack we reach for. Published because a prospective client should be able to disagree with our approach before they pay for it, not after.

principle_01

Measure before you optimise

Every performance engagement starts with a reproducible load test against the current system. A profile beats an opinion, and it turns "it feels slow" into a number we can hold ourselves to.

principle_02

Boring technology by default

PostgreSQL until it genuinely will not do. A queue before a service mesh. New technology has to earn its place in a written trade-off, because you inherit the operational cost of every clever decision we make.

principle_03

Failure is a design mode, not an exception

Timeouts, retries with backoff, idempotency keys, circuit breakers and dead-letter handling are designed in at the start. Retrofitting them into a system that assumed the network always works is most of what a rescue project costs.

principle_04

You own the code and the reasoning

Repositories, pipelines and infrastructure state live in your accounts from day one. Architecture decision records explain why each structural choice was made, so the next engineer does not have to guess.

//stack

Stack

Chosen per project against the constraints, not by preference. Anything on this list we have run in production and been on call for.

0xprogramming --get-stack --verbose
0xprogramming --get-stack --verbose
Languages & runtimes
PHP 8.3Go 1.22Node.js 20 / TypeScriptPython 3.12SQL
Data & messaging
PostgreSQL 16MySQL 8RedisClickHouseRabbitMQKafka
Interfaces
REST / OpenAPI 3.1gRPC + ProtobufGraphQLWebhooksServer-Sent Events
Platform & delivery
KubernetesDockerTerraformAnsibleGitHub ActionsGitLab CI
Observability
OpenTelemetryPrometheusGrafanaLokiSentry
Security
OWASP ASVSOAuth 2.1 / OIDCmTLSHashiCorp VaultSAST / dependency scanning
exit 0

//delivery

Delivery process

  1. 01

    3–5 days

    Technical discovery

    We read the code, the schema and the incident history, then interview the people who operate the system. Output is a written constraint map: current load, real bottlenecks, coupling, and the changes the business actually needs.

  2. 02

    1–2 weeks

    Architecture & plan

    Target architecture with decision records, a migration path that keeps production running, capacity model with headroom, and a delivery plan sequenced by risk rather than by convenience.

  3. 03

    Project-dependent

    Implementation

    Two-week increments, trunk-based, every change behind CI with tests and review. You get a working environment from week one and a demo at the end of each increment — no six-week silences.

  4. 04

    1–3 weeks

    Load, hardening & handover

    Load tests to the agreed target, failure drills including a restore from backup, security review against OWASP ASVS, then runbooks and a working session with your team. We leave when they can run it without us.

//constraints

What we will not do

Stated plainly, because discovering it three weeks in wastes your money as well as our time.

  • Ship without a way to observe it

    If we cannot instrument it, we cannot support the claim that it works. Metrics, logs and traces are part of the deliverable, not a phase two.

  • Rewrite a working system on principle

    Rewrites are the most expensive way to be right about architecture. We will propose one only when incremental migration has been costed and is genuinely worse.

  • Hand over a system only we can run

    No proprietary wrappers, no undocumented deployment folklore, no hostage architecture. Handover includes a working session with your team.

  • Quote a number we cannot justify

    Every estimate breaks down into named work at a published day rate. If the scope is too vague to cost, we say so and propose a discovery phase instead.