Most prospective clients arrive at the first conversation with a vague sense of what hiring an AI consultancy is going to feel like, but no clear picture of the actual mechanics. “They’ll do a discovery, then build something” covers it at a high level, but it tells you nothing about week 3 or week 6, where the questions and the decisions actually live.
This article is the opposite of that. It’s a week-by-week walkthrough of a typical eight-week Launchpad engagement — the kind of project that ends with a workflow automation pilot live, a fixed price quoted on day one, and a documented payback figure. The shape of the work doesn’t vary much from project to project; the content of each week obviously does. Treat this as the template, not the script.
Before week one: how the engagement gets agreed
The decision to engage gets made in a 30-minute conversation. We use the time to:
- Understand the business at the level of what does the team actually do all day, rather than the strapline.
- Identify the workflow that’s costing the most hours, not necessarily the one the founder wanted to talk about.
- Quantify the hours-per-week and rough hourly cost, leading to an annual saving figure.
- Sketch what an engagement might cost — fixed price, range, ballpark.
- Decide whether there’s an obvious fit. If there isn’t, we say so.
Roughly one in three of these conversations leads to a proposal. The rest go either not now (timing wrong, budget wrong, team not ready) or not us (off-the-shelf tool is the right answer; another agency is closer to the brief). We don’t try to talk anyone into anything.
If the conversation lands at yes, send a proposal, the proposal arrives within 48 hours. Fixed price, fixed scope, fixed timeline. A handshake or a signed quote starts the clock.
Week 1 — Discovery
What happens this week determines whether weeks 4 through 8 work. Get discovery wrong and you build something polished that solves the wrong problem.
What we do:
- A two-hour kick-off meeting at your premises (or video for remote teams). Attended by whoever does the work, not just whoever pays the invoice.
- Watch the actual workflow being done. Show me the email you got at 8:42 this morning. Walk me through what you did with it.
- Document every input, every step, every decision, every output. Sticky notes, then a written process map.
- Identify the trigger event that starts the workflow and the terminal event that ends it. Anything outside those bookends is out of scope.
- Confirm the success metrics — usually hours-per-week saved and error-rate reduction.
- Identify the adversarial cases — what does the workflow look like when things go wrong? Late, missing, malformed, conflicting?
What you do:
- Free up the people who actually do the work for the kick-off meeting. Not their managers.
- Share the input data we need to inspect — usually a few weeks of real examples, anonymised.
- Decide who internally owns the engagement. One name, one phone number.
Deliverable at end of week:
- A two-page process-map document showing the workflow as it exists today, with hours quantified per step.
- A confirmation that the planned automation removes the right hours from the right step.
If discovery surfaces something fundamental — “actually, the workflow is fine; what we need is a different supplier” — we say so this week. Better to lose the build fee than build the wrong thing.
Week 2 — Design
Discovery told us what. Design decides how.
What we do:
- Design the data model. What entities does the new system need to know about — customers, jobs, invoices, documents, whatever.
- Decide the integrations. Which tools does this need to talk to (Sage, Stripe, Outlook, your CRM, your booking system) and what does each integration look like.
- Decide the AI architecture, where AI is involved. UK-hosted SaaS, UK-resident inference, or air-gapped on-premise — driven by the data sensitivity, not by a default.
- Sketch the screens. Wireframes, low fidelity. This is where the operator types the postcode; this is what they see when the lookup completes.
- Decide the failure modes. What happens when the integration is down? When the AI returns nonsense? When the user enters garbage?
What you do:
- Provide credentials for any third-party systems we need to integrate with — Sage API key, Stripe test-mode key, your email provider details. Most clients underestimate how much access matters; we usually need read/write to 2–4 systems.
- Review the wireframes with the team. Push back on anything that doesn’t match how the work actually happens.
- Sign off the design before week three starts. Changes after this point still happen but cost time.
Deliverable at end of week:
- Wireframes you can click through.
- An integration map listing every external system, what data flows where, and what the credentials look like.
- A signed-off design document.
Weeks 3 and 4 — First build phase
The visible-progress weeks. Most clients enjoy these.
What we do:
- Set up the development environment, the staging deployment, and the production hosting (typically Cloudflare Pages, Cloudflare Workers, or Firebase App Hosting depending on architecture).
- Build the core data model and CRUD operations.
- Wire up the first integration — usually whichever one you’d miss most if it broke.
- Build the operator UI. Real screens, real data, no Lorem ipsum.
- Daily commits to a private repository you have access to.
What you do:
- Be available for 30-minute check-ins twice a week to look at progress.
- Answer questions when they come up — “what does the team do when the postcode lookup returns multiple matches?” — within a working day.
- Start thinking about training. Who needs to know how to use the new system? When will they get an hour with us?
Deliverable at end of week 4:
- A staging URL you can log into and exercise the workflow against test data.
- A short Loom-style video walking through what’s built so far.
Weeks 5 and 6 — Second build phase
The unsexy-but-essential weeks. The integrations that turned out to be hard. The error-handling. The edge cases. The accessibility pass. The performance pass.
What we do:
- Build the remaining integrations. Edge cases that came out of week 4.
- Wire the AI components, where applicable. Prompt-engineering the AI behaviour to match the team’s actual standards. Audit logging.
- Build the admin and reporting screens. Not glamorous; necessary.
- Performance pass. Most internal apps don’t need to be fast; the ones that do, we tune.
- Accessibility pass. Keyboard navigation, screen-reader support, contrast, focus indicators. Mandatory regardless of whether the client is in scope for the Equality Act.
- Security pass. Authentication, session handling, secrets management, dependency audit. Mandatory.
What you do:
- Use the staging build for at least an hour. Fill in real-world data. Try to break it.
- Identify any team members who need additional training or accommodations (e.g. screen-reader users) so the deploy plan covers them.
- Schedule the go-live training session.
Deliverable at end of week 6:
- A feature-complete staging deployment, exercised against real data, with all integrations live in test mode.
- An issue list — small bugs, polish items — to clear in week 7.
Week 7 — Pre-launch
The week most agencies skip. We don’t.
What we do:
- Clear every issue from week 6 that affects launch. Defer anything that doesn’t.
- Move from test-mode integrations (Stripe Test, Sage sandbox) to live-mode credentials.
- End-to-end testing with real data. A Stripe charge that actually charges. A Sage invoice that actually appears in your accounts.
- Write the runbook. What does on-call look like? Who do you call when this is broken at 11pm on a Saturday? What does recovery look like?
- Train the team. Usually a 90-minute live session with the people who’ll use the system, plus a 5-minute video as a refresher.
- Run a war-gaming session with you. What happens if Stripe goes down during a service? What if Sage’s API is rate-limiting us? What if a customer enters a postcode that doesn’t exist?
What you do:
- Make sure the team training time is in everyone’s diaries.
- Sign the data-processing addendum if there’s a UK GDPR component.
- Run through the proposed launch sequence one more time.
Deliverable at end of week 7:
- A go/no-go decision for week 8 launch.
- A runbook the team can use without us.
- All credentials transferred to production with the test-mode disabled.
Week 8 — Launch
The hardest day to plan and the easiest day to fluff if planning was light.
What we do:
- Launch first thing Monday morning, not Friday afternoon. Mondays let us catch problems with five working days of support runway.
- Be on-site or on-video for the first three hours. The team is doing the workflow live; we’re watching, ready to fix anything that surfaces in production.
- Monitor for the rest of the week. Most launches surface 3–8 small issues in week one. We fix them within hours.
- Sign-off meeting at end of week 8. The system is live, the runbook is yours, the support agreement starts on Monday of week 9.
What you do:
- Do the work. Use the system. Tell us what’s wrong.
- Decide which support tier you want for ongoing — Silver, Gold, or Platinum. Most clients land on Gold.
Deliverable at end of week 8:
- A live system, doing the work, with the metrics from week 1 ready to be measured against in 60 days.
After launch — months 2 to 6
Two follow-up touchpoints matter.
At day 30: a brief written report comparing the actual hours saved and error-rate change against the projection from week 1’s ROI calculation. Clients are sometimes surprised by the result — usually because the actual time saving is higher than projected (the projected number was conservative). Occasionally lower; if so, we identify why and adjust.
At day 90: a half-hour review meeting. What’s working, what isn’t, what should the next thing be? At this point, most clients are starting to think about their second project — once you’ve seen one workflow get automated cleanly, the next two or three become obvious.
What this engagement does not look like
A few things that aren’t part of the standard shape, despite the marketing of other agencies suggesting otherwise:
- No 12-month discovery phase. Eight weeks total. If the project is genuinely so complex that it needs more than that, we’d break it into two eight-week phases with a defined deliverable at the end of phase one.
- No team of six junior consultants. Two senior people, dedicated. The phone you ring is the phone of the person who built the system.
- No design-by-committee. The wireframes happen in week 2 with whoever does the work. The design isn’t reviewed by an internal communications team that wants to add a “digital transformation journey” page.
- No surprise charges. The proposal said £18,400 fixed. The invoice says £18,400. Out-of-scope work — and there usually is some — is quoted separately and only proceeds if you say yes.
- No “strategy deliverable” at the end. You get a working system. Strategy is woven into discovery; it isn’t a separate slide deck.
When this template doesn’t apply
The eight-week shape is right for a workflow automation pilot or a self-contained custom application. It’s not right for:
- Pure consultancy without a build — typically 2–4 weeks, no week 3 onwards.
- Long-running platform builds — a multi-tenant SaaS product, a public-sector procurement-driven engagement, anything where the regulatory overhead is heavy. These typically run 16–24 weeks across two or three milestones.
- Pure assurance work — independent review of someone else’s system. Typically 1–3 weeks, paper-only deliverable.
If your engagement falls into one of those, the underlying logic is the same — discovery, design, build, launch, support — but the calendar stretches accordingly.
What to take away
The most reassuring thing about a Launchpad engagement is that there are no surprises after week one. The price is fixed, the timeline is fixed, the deliverables are fixed, and the questions you’ll be asked each week are predictable. That’s deliberate — most prospects have been burned at least once by a vendor who was great in the sales meeting and absent from week three onwards. We try to be the antidote to that.
If the shape of this engagement makes sense for a workflow you have in mind, the next step is the 30-minute conversation that opens it. We’ll know inside that half-hour whether the maths works.