Skip to content
Code Serve Tech logo

ENGINEERING AT CODE SERVE TECH

How we build the systems we ship.

Engineering at Code Serve Tech is a delivery contract, not a brand promise. The same six principles apply on a 12-week MVP and a three-year platform program. The named architect is on the call, the tests are in the repo, and the runbook is part of the system.

§01 / PRINCIPLES

Six principles that apply on every engagement.

  1. PRINCIPLE / 01

    A named architect on every engagement.

    One senior engineer owns the architecture decisions and the delivery contract from sprint zero to handover. Not a rotating role, not a committee.

  2. PRINCIPLE / 02

    Tests precede merges.

    Every change ships with tests at the right level. Integration and end-to-end where behaviour matters; unit where logic is dense. No feature merges to the main branch without them.

  3. PRINCIPLE / 03

    Observability ships with the feature.

    Logs, metrics, and traces are part of the feature, not bolted on after. If you cannot answer 'is this working in production?' with the dashboard you shipped, the feature is incomplete.

  4. PRINCIPLE / 04

    Reviews are technical, not theatrical.

    Pull requests get read by another senior engineer for design, correctness, and risk. Style is automated. We do not ship LGTMs on architecture changes.

  5. PRINCIPLE / 05

    Backwards-compatibility is a real cost.

    We track API and schema compatibility deliberately, with deprecation windows and migration tooling, not as an afterthought when something breaks.

  6. PRINCIPLE / 06

    The runbook is part of the system.

    Every service ships with a runbook for on-call, in the same repo as the code, kept current as part of the work. If it is out of date, the service is unfinished.

§02 / HOW WE SHIP

The day-to-day rituals.

The cadence and the gates that make the principles enforceable instead of aspirational.

CADENCE
Two-week sprints with a demo at the end of each. One shared backlog visible to everyone, including the customer. No status meetings that exist only to summarize the backlog.
REVIEWS
Required senior review on architectural changes, schema migrations, and security-sensitive code. Optional but encouraged review on everything else. Style + lint + types enforced in CI, not in review.
DEPLOYMENT
Trunk-based development. Every merge to main is deployable. We deploy multiple times a day on most services, gated by an automated smoke check and a feature flag where the change is risky.
ON-CALL
Senior engineers on the engagement carry the on-call rotation for what they shipped. The team that ships owns the runbook and answers the page.
HANDOVER
Documentation for the maintaining team and runbooks for ops are part of the engagement, not a final-week scramble. Support windows are written into the proposal, not assumed.

§03 / STACK

The named tools.

What we actually use. Not a list of everything we have ever touched; the working set on most engagements.

LANGUAGES

  • TYPESCRIPT
  • PYTHON
  • GO
  • SQL

FRONTEND

  • NEXT.JS
  • REACT
  • TAILWIND
  • TANSTACK QUERY

BACKEND

  • NODE
  • POSTGRES
  • REDIS
  • TEMPORAL

INFRA

  • TERRAFORM
  • AWS
  • GCP
  • KUBERNETES

OBSERVABILITY

  • OPENTELEMETRY
  • GRAFANA
  • SENTRY

CI

  • GITHUB ACTIONS
  • TRUNK-BASED

§04 / OPEN WORK

What you can read and use.

GITHUB

Open-source utilities and reference implementations that come out of engagements when the customer agrees.

GO

ENGINEERING WRITING

Long-form posts on the engineering practice, written by the engineers doing the work.

GO

HIRING

We are usually hiring senior engineers. The role descriptions are concrete, not aspirational.

GO

Want this engineering practice on your project?

Bring us a brief