# Engagement process — the 6-week Build

> **Audience.** CTOs / COOs considering a Build engagement. The
> week-by-week operational detail of what happens from signature to
> handover.
> ⟵ [back to docs index](../README.md)

The Build engagement is our flagship service engagement: **6 weeks,
fixed price, ship-or-refund.** It produces either a Bilbs Box
configured for your environment (most common), a cloud-native
deployment in your VPC, or both.

## 01 · Timeline at a glance

| Week | Phase | Heavy lifting | Your involvement |
|-----:|-------|--------------|------------------|
| 1 | Scope & commit | Written SOW, acceptance criteria signed | 2 meetings + document review |
| 2–3 | Spike & validate | Thin vertical slice end-to-end, Friday demo | 30-min demo at end of each week |
| 4–5 | Harden & instrument | Eval harness, observability, fallbacks | Weekly review + production data access |
| 6 | Ship & handover | Docs, runbook, walkthroughs, UAT | 4-hour handover call |

## 02 · Week 1 — Scope & commit

**What happens:**
- Discovery call(s) with your team — 1 to 3 depending on complexity.
- We write the Statement of Work: scope, deliverables, acceptance
  criteria, success metrics, hardware config (if Box).
- You sign the SOW. 33% deposit wires to us.
- **The kill-switch is in effect.** If at any point in this week you
  decide the shape is wrong, you walk away whole.

**Artefacts:**
- Signed SOW + MSA + DPA.
- Architecture diagram (Miro or PDF).
- Eval-suite plan (what we'll test against).
- Data-access plan (what you give us, how, for how long).

**Your time:**
- One 90-min discovery meeting.
- One 60-min architecture review.
- One 60-min commercial close.
- Document review: ~2 hours of reading on your side.

## 03 · Weeks 2–3 — Spike & validate

**What happens:**
- We build a **thin vertical slice** of the system: one real user
  prompt travels end-to-end from the UI through the model and back.
  The slice is crap on purpose — no polish, no hardening. Its job is
  to prove the architecture.
- In parallel, we start the fine-tune on your data (if a fine-tune is
  in scope).
- Friday-end-of-week-2 demo: you click a button, you get a response.
  Latency and cost measured on real hardware.
- Week 3 deepens the slice — realistic prompt distributions, real
  corpus for RAG, actual tool integration if the scope includes
  agents.
- Friday-end-of-week-3 demo: the slice handles 10 realistic prompts in
  a row without crashing.

**Artefacts:**
- A deployable artefact (Docker image + Helm chart or raw binary for
  the Box).
- Latency + cost numbers from real inference runs.
- A running eval harness with your acceptance tests in it.

**Your time:**
- 30-min demo each Friday.
- Data access provisioning (varies).
- One follow-up thread to clarify edge cases.

## 04 · Weeks 4–5 — Harden & instrument

**What happens:**
- Everything that was crap in the spike gets productionised.
- Observability added: metrics, structured logs, distributed traces.
- Failure modes exercised: what happens when the model OOMs, when a
  tool API is slow, when an eval fails.
- Security hardening: SBOM, signed artefacts, dependency pinning,
  least-privilege on every API token.
- Load testing: we replay a synthetic version of your production
  traffic at 2× expected concurrency.
- If Box: hardware is procured in parallel and arrives at our
  staging lab for pre-flashing.
- If cloud: Terraform / Helm charts written against your target
  account, permissions verified.

**Artefacts:**
- Production-shaped code.
- Eval-harness results meeting the acceptance criteria.
- Load-test report.
- Runbook draft (printed + PDF).

**Your time:**
- Two 45-min review meetings (one per week).
- One security review (if your org requires).
- A production-data access window (~3 days) for final fine-tune
  validation.

## 05 · Week 6 — Ship & handover

**What happens:**
- If Box: the chassis is burned with the final weights and runtime,
  packed in its flight case, and freighted to your dock.
- If cloud: final Terraform apply in your VPC.
- UAT (user acceptance testing) runs: your admin and a handful of
  users beat on the system for 48 hours, raising any issues.
- Remaining issues get fixed in 24–48 hours.
- Handover call: a 4-hour session where we walk through every
  subsystem with your admin team, recording the whole thing. This
  recording becomes your onboarding asset for new hires.
- Handover package delivered: runbook, video walkthroughs, CLI access,
  admin credentials, eval harness repo, a printed wallet card with
  your support PIN.

**Artefacts:** see [deliverables.md](./deliverables.md).

**Your time:**
- 4-hour handover call (one session or split over two days).
- UAT coordination with your users.
- Final 34% payment.

## 06 · Kill-switch clause

At the end of **week 1**, you can walk away with:
- A full refund of the 33% deposit.
- The written scope doc and architecture diagram (yours to keep).
- The eval-suite plan.
- No residual obligation.

No meetings, no lawyers. Email `admin@groupebilbs.com` before Monday
of week 2 and the refund wires within 48 hours.

The clause is rarely exercised — in 40+ engagements since 2024 it's
been invoked once, by a client whose internal priorities shifted
between signature and week 1.

## 07 · Change-orders during the engagement

Scope changes happen. Our rule:

- **Small changes** (< 5% of the scope) — absorbed at no cost. We do
  what's right.
- **Material changes** (≥ 5%) — require a written amendment. Priced
  at a pre-agreed blended rate. Turnaround: 48 hours.

We do not surprise-bill. Every material scope change gets a written
revision both sides sign before work begins on it.

## 08 · Weekly demo discipline

Every Friday of the engagement ends with a **30-minute demo** of
working software. Not slides. Not "we would have shown this but…"
Working software running on intended hardware, in front of you.

The demo is recorded. Past demos accumulate into a de-facto
project journal you can reference in 6 months.

If a demo is going to miss, we tell you by Wednesday. Missing a demo
without warning triggers the ship-or-refund clause on our side: we
owe you a credit.

## 09 · Data handling during the engagement

- **Data access window** is typically a 3-day slot in weeks 2–3 and a
  3-day slot in weeks 4–5.
- We sign a DPA before you share anything live. See
  [msa-dpa.md](./msa-dpa.md).
- We access data exclusively through your controls — VPN, bastion,
  SSO, your choice. We do not copy data to local disk.
- After the engagement, we delete any engagement artefacts containing
  your data within 30 days unless the SOW specifies otherwise.
- If a subcontractor is involved (rare — ~15% of engagements use one
  named subcontractor under NDA), they receive the same controls.

## 10 · What makes a Build succeed or fail

### Things that correlate with success

- **Tight executive sponsor.** One accountable person on your side who
  can make decisions inside a week.
- **Realistic data available fast.** If we can't see real prompts by
  week 2, the scope is probably wrong.
- **Acceptance criteria written in numbers.** "Passes 95% of eval
  suite X at p95 latency ≤ 300 ms" beats "is good."
- **A staging environment** that mirrors prod reasonably.

### Things that correlate with failure

- **Committee decision-making** — 4+ stakeholders who must all approve
  every decision. Slows the weekly cadence until nothing moves.
- **Changing goals mid-engagement** beyond the change-order mechanism.
- **Gate-keeping data access** — if we can't get to real data by week
  3, re-scope or kill-switch.
- **Rebuilding the wheel.** If you want a general-purpose AI platform
  rather than one specific workflow, Build isn't the right engagement;
  that's closer to an Embedded retainer + Cluster.

## 11 · After handover — what changes

- Engagement engineer rolls off after 30 days.
- Your Slack channel transitions:
  - **With Support plan:** stays live, named `#bilbs-<yourco>`,
    staffed by the assigned Support engineer.
  - **Without Support plan:** archived after 30 days.
- Invoices for monthly plans (if any) start billing the calendar month
  after handover.
- Updates + Support plans can be added or removed at any time.

---

Next: [deliverables.md](./deliverables.md) · [msa-dpa.md](./msa-dpa.md).