What this is, and why
After enough builds, the process converges. Things you used to do because they seemed right turn out not to matter. Things you skipped because they seemed boring turn out to be load-bearing. The process at year three looks different from the process at year one, and dramatically different from the consulting playbook most teams start with.
What follows is the build process as it stands now. It’s the shape that ships AI in production reliably, in the timeframes we commit to, with the operational outcomes that hold up at quarter-end reviews. Some of it will sound obvious. Some of it will sound counterintuitive. All of it earned its place by surviving real builds.
Phase 1: Pre-engagement scoping (1–2 weeks)
Before formal engagement, a scoping conversation. Two or three calls. Pre-engagement asks four questions:
- What is the specific outcome? Not “we want AI.” A concrete output the system produces or action it takes.
- What is the operational context? Who runs it once it’s live, with what observability.
- What is the data shape? Where the data lives, what sensitivity, what residency requirements.
- What is the timeline pressure? What’s the cost-of-delay; when does this need to be live.
If any of these answers is fundamentally unclear, the engagement isn’t ready. We hold rather than start. This has saved more bad outcomes than any other single discipline.
Phase 2: Architecture sketch (week 1 of engagement)
The first week is architecture. Not “what we’ll build” — that’s design. Architecture is “where the system sits in the company’s stack.”
What gets decided in week 1:
- The provider matrix (which models for which tasks).
- The gateway / credential pattern (always: gateway-based, never raw credentials in code).
- The observability shape (decision traces, cost meter, eval harness, alerting).
- The data path (what flows where, with what sensitivity).
- The deployment shape (hosting, networking, secrets).
- The integration points (what calls in, what calls out).
The output is a 5-page architecture document. It’s reviewed with the client’s engineering leadership. Signed off in writing before any code starts. Changing architecture mid-build is expensive; we close the architecture before the build window opens.
Phase 3: Build (weeks 2–8)
The build window is six weeks for most initiatives. Smaller scopes ship in four; larger ones take ten. Eight is the median.
The discipline during the build:
- One pair, end-to-end. Following the two-person rule. The same two people own architecture decisions, code, deployment, and the eval suite.
- Eval suite built before features. The first week of build is the eval suite. The system is built against the eval suite. Features that can’t be evaluated don’t ship.
- Weekly demo to the client. Every Friday, the working system is shown to the client. Not a slide deck; the running system, with whatever it can do at that moment.
- Mid-build architecture check. At week 4, the architecture document is re-read and reconciled with what’s been built. Drift is corrected.
The build window is hard-bounded. If scope is in danger of slipping the deadline, scope is cut, not deadline extended. This is what allows commitment to delivery dates that hold.
Phase 4: Pre-launch hardening (1 week)
Between feature-complete and production launch, one week of hardening. The discipline that prevents week-two failures:
- The eval suite is expanded with at least 50 real (or realistic) production inputs.
- The full observability stack is verified end-to-end.
- The kill switch is tested.
- Cost ceilings are configured and verified.
- The runbook is written.
- The rollback path is tested.
- The on-call rotation is established.
This week feels slow. It’s also the week that separates systems that hold up from systems that don’t. We don’t skip it. We’ve stopped negotiating about whether to skip it.
Phase 5: Launch (1 day to 1 week)
The launch itself is small. The system is deployed, the eval suite is run against production, a small set of users get access, and the team watches.
What we don’t do at launch:
- Big-bang releases to all users. Cohort releases instead, expanding gradually.
- “Soft launches” without clear advancement criteria. Cohorts have specific criteria for expansion.
- Marketing-heavy announcements. The system has to prove itself to users before it gets externalized.
A launch week is mostly the team watching the eval suite, watching cost, watching user feedback, and being ready to roll back if anything looks wrong.
Phase 6: Operate (ongoing, with handoff at week 4)
The first month of operation is where most agent programs fail. We stay close for that month — bi-weekly check-ins with the client team, joint monitoring of the eval suite, paired post-mortems on anything that breaks.
The handoff happens at week 4 post-launch. The client team owns operation from that point. The handoff includes:
- A documented operational runbook.
- A capability transfer: the client team has run the eval suite, used the dashboard, flipped the kill switch (in test), and led at least one post-mortem.
- A 90-day support plan for any escalations.
By the end of month 4 (or whenever the engagement is complete), the system runs without us. That’s the goal: capability that compounds inside the client, not dependency on the consultancy.
What we stopped doing
A few things that were in earlier versions of the process and aren’t anymore:
Long discovery phases. Multi-week discovery before architecture turned out to be mostly performative. Pre-engagement scoping plus week-1 architecture covers it.
Strategy decks. Beautiful, expensive, and ignored. Replaced with 3-column roadmaps.
“Phase-gate” reviews. Replaced with weekly working demos. The working system is the gate.
Vendor-comparison matrices. Useful in 2023, mostly irrelevant now. We default to a specific provider stack, deviate when there’s a specific reason.
Detailed effort estimates. Replaced with fixed-scope, fixed-deadline windows. Scope is the variable when timeline gets tight.
“AI strategy” documents separate from the roadmap. The roadmap is the strategy in operating form. Separate strategy documents drift from execution.
Each of these felt valuable when we did them. Each turned out to add more friction than insight. Removing them shortened the calendar from 6 months to 3 for a typical build.
What we still do that looks dispensable
A few process pieces that look skippable but earn their place every time:
Written architecture document. Always 5 pages. Always signed off. Even when the client is in a hurry. Skipping this leads to mid-build drift that costs more than the document.
Eval suite of 50 real examples before feature build. Always. Even when the client wants to “see something working first.” Without the eval suite, the system has no baseline.
Pre-launch kill switch test. Always. Even when “we don’t need it because the system is read-only.” Read-only systems can still need to be stopped, and the time to discover the kill doesn’t work is not during the incident.
Joint post-mortem on the first incident. Always. Even when the incident is small. The post-mortem trains the client team in incident response and builds the muscle for the incidents that come later.
These pieces are the boring parts of the process. They are also the parts most predictive of whether the system holds up six months later.
What this looks like, calendar-wise
For a typical engagement:
- Week 0: Pre-engagement scoping.
- Week 1: Architecture sketch and signoff.
- Weeks 2–8: Build, with weekly demos.
- Week 9: Pre-launch hardening.
- Week 10: Launch and early operate.
- Weeks 11–14: Operate, with handoff at week 14.
Fourteen weeks, end to end. The client has a production system, an operational runbook, a trained internal team, and the foundation for the next build. That’s the deliverable.
The take
The Titanium Labs build process is the shape that survived. It’s not novel — most of it is straight engineering discipline applied to AI work — but the specific selection of what’s in and what’s out is earned from real outcomes. New engagements run on this process. Existing systems we audit usually missed two or three of the pieces above, and those are where the gaps in the system are. The process is boring on purpose. Boring scales. Clever doesn’t.
If you’re considering a build and want to walk through whether the process fits, schedule a call. The first conversation is always free.
