Engagement process

A process built around production.

Every engagement follows the same spine: understand the system before we build it, ship a thin path to production early, then harden it until it holds under load. You always know what we are working on, why, and what it will cost.

How we run the work

Five phases, no surprises at the end.

Most projects fail late, when integration and load reveal what the design missed. We front-load that risk. Discovery produces an architecture you can staff and afford, then we prove it in production one slice at a time. The same senior engineers stay with you from the first whiteboard to the on-call rotation.

What the process holds to

6 wk
Median time from kickoff to first release
2 wk
Fixed-fee discovery and architecture
60+
Production deploys per day on managed platforms
99.98%
Median uptime once we operate a system

The engagement, step by step

From a first conversation to a system you can rely on.

The phases run in order, but they are not a waterfall. Each one produces something concrete: a decision record, a working environment, a slice in production, a runbook. You can stop after any phase and walk away with usable artifacts.

01

Discovery and architecture

Two weeks, fixed fee. We sit with your team and map the constraints that actually govern the design: throughput and latency targets, data ownership, failure modes, compliance boundaries, and the operational reality you live in today. The output is an architecture with named trade-offs, a delivery plan you can staff, and a cost you can put in front of a board. If the honest answer is that you do not need us, we say so.

Architecture decision records Named trade-offs Fixed fee
02

Foundations

Before feature code, we stand up the things that make the rest of the project safe to move fast on. Reproducible environments defined as code, a CI/CD pipeline that goes from commit to a deployed environment without a human in the loop, and an observability skeleton (metrics, structured logs, and traces) wired in from the first service. When the first real feature lands, the runway to production is already paved.

Environments as code CI/CD pipeline Observability skeleton
03

Build in vertical slices

We ship a thin path all the way to production first, then widen it. One real transaction that flows from the edge through the service, into storage, and back out, deployed and observable, beats a stack of half-finished components. That first slice validates the architecture under real traffic and turns integration risk into something you can watch on a dashboard from week one. Each slice after it adds capability against a working baseline, never a big-bang merge at the end.

Thin path to prod Real traffic early Incremental widening
04

Harden

A system that passes a demo is not a system that survives a bad Tuesday. We run load tests that push past your expected peak and read the results against your latency budget, write runbooks for the failures we can predict, set up alerting and an on-call rotation that pages the right person, and put the code and infrastructure through a security review. By the end, the way the system behaves under stress is documented, not discovered live at 3am.

Load tests Runbooks On-call Security review
05

Operate or hand over

You choose the ending. We can run the system as a managed service with defined SLOs, an error budget, and 24/7 on-call, so the team that built it is the team that keeps it healthy. Or we hand it to your engineers with the documentation, dashboards, and runbooks needed to own it confidently, plus a handover period where we shadow your on-call until you are comfortable. Either path leaves you with a system you understand, not a black box.

Managed run with SLOs Clean handover 24/7 on-call

A typical schedule

What the first months usually look like.

Timelines vary with scope, but the shape is consistent: a fixed discovery window, a short foundations phase, then slices reaching production while the ground is still fresh. The median engagement reaches its first production release in six weeks.

Phase Typical window What lands You can see
Discovery and architecture Weeks 1 to 2 Architecture, delivery plan, cost Decision records, diagrams
Foundations Weeks 3 to 4 Environments, CI/CD, observability A green pipeline, live dashboards
First vertical slice Weeks 5 to 6 A real path in production Traffic and latency, live
Widen and harden Ongoing Features, load tests, runbooks Error budget, on-call readiness
Operate or hand over At agreed milestone Managed run or clean handover SLO reports or handover pack

Engagement models

Three ways to work with us.

The process is the same. What changes is how deep we go and who carries the system afterward. Most engagements start with Build and move to Operate or a handover once the system is live.

Model 01

Build

We design and build the system end to end, from the discovery architecture through the vertical slices to a hardened release. A small senior team owns delivery and is accountable for what ships. This is the right fit when you need the system built well and built once.

  • Fixed-fee discovery, then milestone delivery
  • Two to five engineers, direct access, no account layer
  • Ends in a working, documented production system
Model 02

Operate

We run the system in production as a managed service, with defined SLOs, an error budget, and 24/7 on-call. The team that built it keeps it healthy, releases against a change budget, and reports on reliability every month. This suits teams that want the system without staffing a platform group for it.

  • SLOs, error budgets, monthly reliability reports
  • 24/7 on-call held by the engineers who know the code
  • Continuous hardening, not a frozen deliverable
Model 03

Advise

Your team owns the build; we bring senior judgment where it counts. Architecture review, a second opinion on a hard design, load-test interpretation, or an audit of a system that is drifting. Shorter and lighter than Build, and useful when the gap is expertise, not hands.

  • Architecture and design reviews with written findings
  • Load-test and incident postmortem analysis
  • Focused, time-boxed, no long-term lock-in

What you keep

Every engagement leaves artifacts, not just working code.

Code that no one understands is a liability. We treat documentation, dashboards, and runbooks as part of the deliverable, not a favor at the end. If you take the system in-house, this is the pack that lets your team own it without a call to us.

ArchitectureDecision records and diagrams
OperationsRunbooks per failure mode
VisibilityDashboards and alerts
EvidenceLoad-test results
OwnershipHandover pack

Standard deliverables

  • Architecture docsDecision records, system diagrams, and the trade-offs behind each choice, kept current as the system evolves.
  • RunbooksStep-by-step procedures for the failures we can predict, so an on-call engineer is reading, not guessing, at 3am.
  • DashboardsThe metrics, logs, and traces that tell you the system is healthy, wired in from the first service, not bolted on later.
  • Load-test resultsEvidence of how the system behaves past its expected peak, read against the latency and error budgets you agreed to.
  • Clean handoverA documented, walkthrough-backed transfer so your team can operate the system with confidence and no hidden knowledge.

Working in the open

Progress you can watch, not just hear about.

engagement.log
# week 2, discovery complete
> architecture signed off, delivery plan approved
# week 4, foundations live
> pipeline commit to prod in 7m40s, traces flowing
# week 6, first slice in production
> slice-01 serving real traffic, p99 41 ms
> error budget healthy, on-call rotation staffed
They shipped a real slice to production in the sixth week and we watched it under load from that point on. There was no scary integration at the end, because there was no end where everything landed at once.
SR
Sofia Reinhardt
CTO, Helio Energy

Common questions

Before you start a project.

It depends on scope, but the shape is predictable. Discovery is a fixed two weeks. The median engagement reaches a first production release in six weeks from kickoff. From there, widening and hardening run as long as the system needs, and many clients then move into a managed run. We give you a milestone plan at the end of discovery, so you are committing against dates you can see, not an open-ended retainer.

Discovery is always fixed fee, because we can scope two weeks accurately. For the build, we prefer milestone-based pricing tied to the delivery plan discovery produces, so the number is known before you commit. Where scope is genuinely open, for example an ongoing platform effort, we work time and materials with a clear rate and a monthly cap. We tell you which model fits and why, rather than defaulting to whichever bills more.

Yes, and often that is the point. We pair with your engineers, review each other's code, and share the on-call rotation during hardening so knowledge transfers as the system is built, not in a rushed handover afterward. If your team is strong and just needs senior weight on the hard parts, the Advise model is lighter still: reviews, second opinions, and audits without us holding the keyboard.

That is a first-class outcome, not a failure mode. Everything we build ships with architecture docs, runbooks, and dashboards from the start, precisely so a handover is clean. When you are ready, we run a transfer period where your engineers take the pager while we shadow, then step back once they are comfortable. You are never locked in by missing documentation or knowledge that only lives in our heads.

Start

Ready to scope the first two weeks?

Tell us what you are building and the constraints you are under. Discovery is fixed fee, and you walk away with an architecture you own, whether or not you build it with us.