Four Scopes, Taken Apart in Public
There are no logos on this page. What there is instead: four representative UK builds worked through in the open — the situation, the constraint that shaped it, what went into version one, what was left out on purpose, and roughly how the weeks fell.
Before You Read Any Further
Our client work sits under non-disclosure agreements. We have published no case studies, no company names, no logos, no testimonials, no App Store or Google Play links and no download figures — because we do not have permission to, and inventing them is not a thing we are willing to do. A good deal of what appears on agency portfolios in this country was not built by the agency showing it.
What follows are representative build scenarios. They are composites drawn from the kinds of enquiry we actually receive, written to show how a scope gets structured and sequenced. They are illustrations of method, not outcomes from named clients. Every number below — weeks, sprints, screen counts, any figure at all — is illustrative and labelled as such where it appears.
If you want references, ask on the estimate call. Where a client has agreed to speak to a prospective one, we put you in touch directly rather than paraphrasing them here.
Paper Job Sheets, Four Depots and a Van Fleet
A multi-site service business — the shape fits a commercial cleaning firm, a plant hire company or a regional maintenance contractor equally well.
Everything depends on a piece of paper getting back to the office
- Engineers collect job sheets in the morning and hand them back at the end of the week, or the week after.
- Invoicing waits on that paper, so cash collection runs a fortnight behind the work.
- Photographs of completed work arrive by text message to one manager’s personal phone.
- When a customer disputes a visit, proving it happened takes somebody an afternoon.
The people using it are not sitting at desks
- Plant rooms, basements and rural sites mean no signal for part of every day, so offline capture is not optional.
- Handsets are inexpensive Android devices with cracked screens and cold, gloved hands on them.
- Some of the workforce will be openly hostile to being tracked, so the app must earn its place rather than police them.
- Location data about employees is personal data under UK GDPR and has to be justified, minimised and explained to staff.
One day in the life of one engineer, done properly
- An Android app showing today’s jobs, working fully offline and syncing when signal returns.
- Arrive, complete a short checklist, attach photographs, capture a customer signature, close the job.
- A web back office for the depot schedulers: assign work, watch it close, chase what has not.
- A completed-jobs export the accounts team can load into the existing invoicing package.
- A PDF job record with photographs and signature, produced on demand when a visit is questioned.
Left out of release one, and why
- Automatic route optimisation — schedulers know the patch better than an algorithm will for the first year.
- Direct write-back into the accounting system; a reviewed export is safer until the data is trusted.
- A customer-facing portal, which is a second product and belongs in its own phase.
- Continuous location tracking, dropped in favour of a location stamp at job start and job close.
- An iOS build, added once the Android rollout has settled across all four depots.
An illustrative timeline
Weeks 1–2 · Discovery in a van
A day shadowing engineers on site, because the paper form and the actual job are never quite the same thing. Roles, offline behaviour and the checklist fields are settled here, along with what location data is genuinely needed and what staff will be told about it.
Weeks 3–4 · Screens and a prototype on a real handset
The prototype is put in the hands of two engineers, one enthusiastic and one sceptical. The sceptical one is the more useful session. Sign-off fixes the screen set, the roles and the scheduler workflow.
Weeks 5–12 · Four build sprints
Sprint one is foundations, accounts and the offline sync model, which is the hardest thing in this build and therefore goes first. Sprints two and three are the engineer app and the depot back office. Sprint four covers the PDF record, the export and hardening on low-end devices.
Weeks 13–15 · One depot, then the rest
Release to a single depot first, with paper running alongside for a fortnight as a safety net. Rollout to the remaining sites once the first depot stops printing anything, followed by the support window.
Illustrative scenario and timeline, written to show how scope decisions get made on a field-service build. It is not an account of any specific client project, and every duration shown is indicative.
A Membership Body Whose Renewals Live in Excel
The shape fits a professional institute, a trade association or a sizeable charity with a membership base and an events programme.
Three workbooks, one mail-merge and a very patient administrator
- Membership records, renewal dates and event bookings sit in three separate spreadsheets that disagree.
- Renewal reminders go out as a mail-merge, and lapsed members are discovered months later.
- Event places are held by email and reconciled by hand against bank statements.
- One person understands the whole arrangement, and they are retiring in eighteen months.
Volunteers, trustees and a membership that is not young
- Accessibility is a genuine requirement, not a tick-box: members use screen readers and large text, so WCAG 2.2 AA is the baseline.
- Budget is approved annually by a board that will want a fixed figure, in advance, with VAT shown.
- Some members will never pay online, so cheques and bank transfers must remain first-class options.
- Years of member history must migrate intact, including the records with three spellings of one employer.
Renewals and events, and nothing else yet
- One member record that is the single source of truth, migrated and de-duplicated with the administrator sitting alongside.
- Self-service renewal by card or Direct Debit through GoCardless, with an offline route the office can mark as paid.
- Automatic renewal reminders on a schedule the office controls, and a lapsed-member view that is finally accurate.
- Event listings with booking, member and non-member pricing, a waiting list and a delegate list to print.
- A member-facing account area built and tested to WCAG 2.2 AA, with an accessibility statement drafted.
Phase two, agreed and written down
- A members-only content library, which is a publishing project wearing a membership costume.
- Continuing professional development logging, deferred until the renewal data is trusted.
- A member directory, which raises consent questions that deserve their own conversation.
- A mobile app, for which there is no evidence of demand and a perfectly good responsive site.
- Gift Aid claim automation, sensible later but dependent on clean historical data first.
An illustrative timeline
Weeks 1–3 · Discovery and a hard look at the data
The membership rules turn out to be more interesting than the screens: concessionary rates, honorary members, organisations with several named contacts. A sample export is profiled early so the migration is a known quantity rather than a late shock.
Weeks 4–5 · Design, prototype and an accessibility pass
The prototype is walked through with a member who uses a screen reader, before sign-off rather than after launch. Sign-off fixes the screen set, the roles and the payment routes for version one.
Weeks 6–15 · Five build sprints
Foundations and the member record first, then renewals and payments, then events and booking, then the office views, then reminders and reporting. The migration is rehearsed twice against real data before anyone relies on it.
Weeks 16–18 · Cutover around the renewal calendar
Go-live is timed deliberately away from the annual renewal peak, with the old spreadsheets kept read-only for a quarter. Training for the office, and written material they keep when the administrator retires.
Illustrative scenario and timeline. The weeks, sprint counts and sequencing are indicative and describe a typical shape rather than a specific membership organisation we have worked with.
A Manufacturer Whose Customers Ring Up to Ask Where Their Order Is
The shape fits an engineering or components manufacturer selling to trade customers, with an established ERP system and a very busy internal sales desk.
The internal sales desk is a human search interface
- A large share of inbound calls are customers asking for an order status that already exists in the ERP.
- Order acknowledgements and delivery notes are emailed as attachments and routinely lost by the recipient.
- Larger trade customers have started asking for a portal, and one has made it a condition of renewal.
- Nobody internally wants to touch the ERP, and the supplier quotes a large figure for a bespoke module.
The system of record must stay exactly where it is
- The ERP cannot be replaced, slowed down or written to by anything new in version one.
- Trade pricing is confidential and account-specific; showing one customer another customer’s rate would be serious.
- Integration is by nightly export and a read-only view, because the ERP has no usable modern API.
- Customer users will be procurement staff on old browsers, not early adopters on new laptops.
Answer the question the phone call was asking
- A customer login scoped strictly to one trading account, with several named users under it.
- Open orders with line-level status, promised dates and any revision to them, refreshed on a schedule.
- Documents in one place: order acknowledgements, delivery notes and certificates, downloadable at any time.
- An internal view so the sales desk sees precisely what the customer sees when they ring anyway.
- An integration layer built so that a real ERP API, if one ever arrives, replaces the export without a rewrite.
Not in the first release, on purpose
- Online ordering, which needs stock, lead times and pricing rules to be right before it can be trusted.
- Live stock levels, deferred until the nightly view has proved itself accurate for a quarter.
- Invoice payment inside the portal, which is a finance project with its own approvals.
- A mobile app, when the users are at a desk with two monitors for most of the day.
- Writing anything at all back into the ERP, which stays a later and carefully separate decision.
An illustrative timeline
Weeks 1–2 · Listening to the sales desk
The fastest route to scope is a morning with the people answering the phone and a tally of what callers actually ask. The data available in the ERP export is profiled at the same time, because the portal can only show what the export contains.
Weeks 3–4 · Design, prototype and the permission model
Account scoping is the decision that matters most here, so it is drawn out explicitly and reviewed before code: which user sees which orders, and what happens when a customer has three sites and two buying entities.
Weeks 5–12 · Four build sprints
Sprint one builds the integration layer and the nightly import, deliberately first, because everything else depends on it being boring and reliable. Then accounts and permissions, then orders and documents, then the internal view and hardening on older browsers.
Weeks 13–15 · A pilot with three accounts
Released first to a handful of trade customers who complained loudest, which is both good feedback and good diplomacy. Wider rollout, then the support window, with call volume watched as the one number worth measuring.
Illustrative scenario and timeline describing how a read-only customer portal is usually sequenced. Not a specific client engagement, and all durations and phasing shown are indicative.
A Fintech That Cannot Answer “Who Changed This, and When?”
The shape fits an FCA-regulated firm with a working product, a funding round ahead of it and a data model that was never built to be questioned.
The product works. The record of what it did does not exist
- Records are updated in place, so the current state is visible but the history behind it is gone.
- Support staff can amend customer data directly, with no durable record of who did what.
- A due diligence questionnaire has arrived asking questions the current system cannot answer.
- A complaint has been escalated, and reconstructing what the customer was actually shown took three days.
Live money, live customers and a date that will not move
- Nothing may go offline, and no migration may put a customer balance at risk for a moment.
- The retrofit has to be finished before diligence begins, which fixes the date at the outset.
- The audit log itself becomes personal data under UK GDPR, so retention and access need deciding, not assuming.
- We are engineers, not compliance consultants: we build what the firm’s own advisers say is required.
An answer to every “who, what, when” from this point forward
- An append-only event log for the handful of actions that genuinely matter, rather than for everything.
- Every staff amendment recorded with actor, timestamp, before and after values, and a reason where one is required.
- Internal roles narrowed, so that reading, amending and approving stop being the same permission.
- A case view that reconstructs one customer’s timeline in minutes for a complaint or an enquiry.
- A written note of retention periods, storage region and access rules, so diligence gets a document rather than a meeting.
Tempting, and left for later
- Reconstructing history from before the retrofit, which cannot honestly be done and should not be implied.
- Rewriting the whole platform on event sourcing, which is the right answer to a different question.
- A full analytics layer over the new event log, useful but not what the deadline is about.
- Customer-facing statements of their own activity history, sensible in a later phase.
- Formal certification work, which belongs with the firm’s own advisers rather than with a development supplier.
An illustrative timeline
Weeks 1–2 · A paid audit before anything is promised
A fixed-price read of the codebase and the data model, producing a written list of where state is overwritten, where permissions are too broad and what a retrofit would actually involve. That document is what the scope is built from, and the firm keeps it regardless.
Weeks 3–4 · Deciding what must be recorded
Worked through with the firm’s compliance adviser, because the list of auditable events is their call and not ours. Recording everything is as unhelpful as recording nothing; the aim is a short list nobody argues about later.
Weeks 5–12 · Four sprints, shipped behind flags
The event log and write path first, running alongside existing behaviour so nothing changes for customers. Then staff permissions, then the case view, then the data protection decisions written up. Each sprint releases to production behind a flag rather than accumulating into one large risky deployment.
Weeks 13–14 · Rehearsing the diligence questions
The firm asks its own hardest questions of the new system while there is still time to fix an answer. Handover documentation is written for whoever reads it during the round, not for us.
Illustrative scenario and timeline. It describes a common shape of retrofit engagement rather than a specific regulated client, all durations shown are indicative, and nothing here should be read as regulatory advice.
None of These Is Your Project
They are shapes, and yours will differ in the details that matter most. The useful thing is not the scenario — it is getting the same treatment applied to your own situation, in writing, before you spend anything.
Send a paragraph, not a specification
Describe what is going wrong or what you want to launch, in your own words. A half-page email is plenty. If you already have a requirements document, send that instead and we will read it properly.
Get the same breakdown back
Within two working days: what we would put in version one, what we would defer and why, an indicative sterling range excluding VAT, and the questions that still need answering before any of it firms up.
Take it wherever you like
The scope document is yours whether or not you hire us, including to another firm for comparison. If we think you should not build it yet, or should buy something off the shelf instead, that is in the document too.
Swap the Scenario for Your Own
Half an hour on what you are trying to achieve, then a written scope and a sterling range excluding VAT. No charge, and no obligation to go any further.