Making deployments boring: How engineering toil was reduced at a pre-seed startup

The challenge: processes that scale worse than systems

Delivery practices that work for three people degrade in a characteristic way as a team grows. Knowledge that lived in individual heads becomes a bottleneck when those individuals are unavailable. Manual steps that were tolerable at one deploy per week become error-prone at ten. Releases accumulate changes, which raises their risk, which encourages less frequent releases, which accumulates more changes. Engineers begin to treat deployment as an event requiring preparation and attention, and the interval between writing a change and seeing it in production stretches from hours to weeks.

The company faced this trajectory under two additional pressures. Its customers were security-conscious enterprises, so change management would eventually be examined in audits and due diligence (the companion compliance study covers this). And headcount was growing quickly — from 3 toward 70+ — so any process depending on shared context that only early employees held would fail on contact with each new cohort.

The objective was set in operational terms: shorten the interval between a change being written and running safely in production, and make deployment sufficiently routine that the team performed it without ceremony.

The approach: remove variation, then measure the result

1. One path to production, with no exceptions

All changes — application code, infrastructure, configuration — reached production through a single pipeline. A commit triggered it: build, static checks (linting and type-checking), then automated unit and integration tests as gates a change had to clear before it could proceed. A passing change deployed automatically through the same infrastructure-as-code that defined the environment, so the deployment mechanics were identical on every run — on the order of ten minutes early on, twenty to thirty as the test surface grew toward Series A. Alternative routes — manual deployment, direct changes to production, one-off scripts — were closed. The single deliberate exception was a narrow emergency path, restricted to the Platform Engineering role, that could place a built-and-verified change in production in under five minutes when a critical issue demanded it: still through build and test, not around them, and fully auditable. A single path can be improved once for everyone; each additional path multiplies the surface on which failures occur and the knowledge required to operate the system.

Because infrastructure was code (see the companion study), the same discipline covered infrastructure change: production drift by manual modification was structurally excluded.

2. Small, frequent changes in place of large releases

Release risk scales with release size. The practice adopted was to ship the smallest independently safe unit of change, frequently, in place of accumulating changes into scheduled releases. Development was trunk-based: short-lived branches opened for a single change, reviewed, and merged back into a main line kept continuously deployable. Feature flags decoupled deployment from release, so incomplete or not-yet-enabled work could ship dark behind a flag rather than accumulate in a long-lived branch — which kept merges small and main always releasable. Each property reinforces the next: smaller changes fail less often, fail more legibly when they do, and are faster to roll back — which increases confidence, which sustains frequency.

3. Review conventions proportional to risk

Code review was standardised with conventions scaled to the risk of the change. A single approving reviewer was the default. CODEOWNERS routed changes touching security-sensitive or data-handling paths to the engineers who owned them, so the right eyes saw the changes that mattered without adding ceremony to routine ones. Automated checks — linting, type-checking, tests, and security scanning — carried the mechanical burden, leaving human review to concentrate on design and correctness. The intent was to keep review valuable and fast at the same time; review that is slow gets batched, and batched review recreates the large-release problem.

4. Environments that match, so results transfer

Divergence between environments converts testing into an approximation. Environment definitions were shared with production — the same code, differing in parameters — so that behaviour observed before production predicted behaviour in production. The structure was deliberately minimal: a staging environment that mirrored production, both instantiated from the same infrastructure-as-code and differing only in parameters. Non-production never held real customer data; staging ran on synthetic and seeded data, which kept an entire class of data-handling risk out of the lower environment. Drift, where it appeared, was treated as a defect in the definitions and fixed at the source.

5. Incident handling as procedure, learning as output

Incident response was written down as procedure. Severity was defined by customer impact across a small number of tiers, each with an expected response and an escalation path through on-call; higher-severity incidents carried a requirement to communicate with affected stakeholders while the response was still in progress. Post-incident reviews were conducted without attribution of blame and produced changes to the pipeline, the definitions, or the procedures — so that each incident narrowed the space of future incidents. Over time, as those changes accumulated, both the volume and the severity of incidents trended downward, each fix removing a class of recurrence rather than a single instance.

6. Documentation where automation was not yet possible

Consistent with the platform-wide principle, recurring work was automated and the remainder was documented as written procedure. For a team growing from 3 to 70+, this had a second function beyond operations: new engineers onboarded against documents and a standardised path, in place of apprenticeship to early employees. In practice a new engineer could ship a small change safely in their first week — against the documented path, rather than by shadowing whoever had built the system.

The execution: sequence of the work

Phase one — the pipeline. In the opening weeks of the build, the single path to production was established first, ahead of process refinement, on the reasoning that every subsequent improvement would be delivered through it. The starting point was bare: no environments and no pipeline, changes deployed by hand from engineers' laptops, and nothing structurally preventing a direct change to production. The principal change was to stand up one automated CI/CD path on AWS, with the environment defined as code in Terraform, and to close every manual and direct-to-production route behind it.

Phase two — release practice and review conventions. Over the following months, as the first engineers joined, change-size and frequency norms were established and review conventions agreed with the team and encoded where possible as automated checks. The small-change and feature-flag discipline was not adopted without friction: it was initially seen as overhead, and gained traction only once the team could see rollbacks becoming cheaper in practice. The conventions were tuned collaboratively with the engineers operating them rather than imposed — practices imposed without a team's agreement tend to be routed around.

Phase three — environments and incident procedure. As the first enterprise customers and the first audit cycle approached, environment definitions were consolidated, drift eliminated, and incident severity, escalation, and review procedures written and exercised. One incident was representative: an out-of-band hotfix, applied under time pressure, caused a follow-on problem. The response was not to forbid urgency but to formalise it — the emergency path became a controlled, Platform-Engineering-only workflow that still built and verified the change and put it live in under five minutes, so that acting quickly no longer meant acting around the safeguards.

Phase four — steady state and handoff. The delivery system operated as routine, with its measures — lead time, deployment frequency, change failure rate, and time to restore service — reviewed on a regular cadence. Operational ownership was later handed off to a one-person platform team, alongside the platform itself, as described in the companion studies.

What did not go smoothly

A test suite that made small changes expensive. One service carried a slow, occasionally flaky test suite, which made the small-and-frequent discipline costly — every trivial change paid a long, uncertain CI tax. It was resolved by repairing and speeding up the suite, after which the discipline paid for itself rather than against it.

On-call that outgrew a single timezone. Sustaining incident coverage strained a lean team as usage spread across regions. It was resolved by convincing management to adopt a follow-the-sun model, which eased the operational load during off-hours in any one region.

An environment that resisted consolidation. One environment had accumulated hand-tuned configuration that would not fold cleanly into the shared definitions. Rather than reconcile it piecemeal, it was re-defined from scratch to match production at the source, removing the divergence for good.

The results

• The practices held through 20x headcount growth, from 3 people at pre-seed to 70+ at Series A, with new engineers onboarding against a standardised path in place of person-to-person knowledge transfer
• Change management satisfied audit and due diligence examination under ISO 27001 and SOC 2 Type 2 with the pipeline itself serving as the evidence source (see the companion compliance study)
• The delivery system was handed off with the platform to a one-person platform team and continued operating
• Delivery improved on its own measures — lead time fell from days to under an hour, deployment moved to multiple times a day, and incident volume and severity trended down as post-incident changes accumulated

What this means if you're running a startup or SME

Teams do not become slower because they grow; they become slower because variation accumulates faster than it is removed.

Every manual step, undocumented exception, and person-dependent piece of knowledge is variation, and each one levies a small recurring tax that compounds with headcount. The remedy demonstrated here consists of unglamorous work — one path to production, small changes, matching environments, written procedure — applied consistently and measured by lead time. None of it requires additional headcount; most of it releases capacity that existing headcount is currently spending on toil.

This is the work we do at Aijutsu with operators and SME engineering teams: identifying where delivery capacity is being consumed by process friction, and implementing the practices that return it. It is also available as coaching, working with your senior engineers to build the capability internally.

If deployment in your team is an event with a checklist and a designated person, capacity is being lost. Book a diagnostic conversation: [email protected]

Frequently Asked Questions

How do you reduce deployment risk?

Reduce the size of each change and remove manual variation from the path to production. Small changes fail less often and more legibly; a single automated pipeline behaves the same way every time. In this case, the combination shortened lead time from days to under an hour and made deployment a routine activity.

What is lead time in software delivery and why measure it?

Lead time is the interval between a change being written and running safely in production. It is a useful primary measure because most delivery dysfunctions — large releases, slow review, environment drift, manual steps — surface as lead time, so improving the measure requires fixing the causes.

How often should a startup deploy to production?

As frequently as the smallest safe unit of change allows — for most teams with an automated pipeline, at least daily. Deployment frequency and deployment risk are inversely related: infrequent releases accumulate changes and concentrate risk, while frequent small releases distribute it.

How do engineering processes survive team growth?

By encoding them in systems and documents in place of individual knowledge. In this case, a standardised path to production, matching environments, and written procedure carried the team from 3 to more than 70 engineers; new joiners onboarded against the system itself.

When should a startup formalise its engineering process?

When the cost of informality becomes visible: deployments requiring a specific person, releases delayed to accumulate changes, environments behaving differently, or onboarding depending on apprenticeship. The formalisation demonstrated here is deliberately minimal — a single path, small changes, written procedure — and is designed to reduce ceremony, with heavyweight process avoided.