How Projects Get Scoped, Shown Honestly
This is not a portfolio page with logos on it. It is four worked examples of how we cut a project down to a first version — what goes in, what gets deferred on purpose, and roughly how long each part takes.
There are no client names on this page, and that is deliberate
Our client work is covered by non-disclosure agreements. We have not published case studies, logos, testimonials, store links or download figures, because we do not have permission to and we are not going to invent them. Plenty of agency sites show work they did not do; we would rather show you nothing than that.
What follows are representative build scenarios: composite examples of the kinds of projects we are asked for, written to show how a build gets structured, scoped and sequenced. They are illustrations of method, not results from named clients. Every figure below — weeks, sprints, screen counts, any number at all — is illustrative and labelled as such.
If you want references, ask on the estimate call. Where a client has agreed to speak to a prospect, we will arrange it directly rather than paraphrase them here.
A Two-Sided Marketplace MVP
The most common shape of first-time startup enquiry: buyers on one side, providers on the other, and a founder who has been told it will cost $200,000.
The situation
- A founder with domain experience wants to connect local service providers with customers who currently find them through word of mouth.
- No software exists yet, and no technical co-founder.
- The pitch deck describes provider profiles, instant booking, in-app chat, reviews, subscriptions, referrals and an analytics dashboard.
The constraint
- A budget that will not survive building all of that, and a need to show traction before raising more.
- The real unknown is not technical. It is whether providers will list at all.
- So the build has to answer that question as cheaply as possible, not be a finished company.
Scoped into version one
- Provider sign-up, profile and availability, entered on the web.
- Customer search, provider detail and a booking request flow.
- Payment taken at booking through a hosted checkout, with payouts handled manually at first.
- Email and push notifications on the three moments that matter: request, acceptance, reminder.
- An admin view for the founder to approve providers and fix bookings by hand.
Deliberately deferred
- In-app chat — a phone number in the confirmation email answers the same need for now.
- Ratings and reviews, which mean nothing until there is volume to average.
- Automated payouts and the provider subscription tier.
- A native app for providers; the mobile web page covers them at this stage.
- The analytics dashboard, replaced by exporting the data and reading it.
The shape of the build
Weeks 1–3 · Discovery and design
Both user journeys mapped, screens designed, clickable prototype tested with real providers before code starts.
Weeks 4–11 · Four build sprints
Sprint 1 foundations and accounts, sprint 2 provider side, sprint 3 search and booking, sprint 4 payments and notifications.
Weeks 12–13 · Hardening and store review
Real-device QA, live payment test, store listing and submission, fixes against review feedback.
Weeks 14+ · First providers onboarded
Support window open while the founder recruits the first side of the marketplace by hand.
Illustrative scenario and timeline, written to show how scope decisions are made. It is not an account of a specific client project, and the weeks shown are indicative.
An Internal Tool Replacing a Spreadsheet Nobody Trusts
An established business, not a startup. The software already exists — it is just made of tabs, formulas and one person who understands it.
The situation
- A services company schedules field jobs in a shared spreadsheet that has grown for six years.
- Two people edit it at once and overwrite each other; nobody can tell which version is current.
- Crews work from photographs of the sheet taken on their phones.
The constraint
- The business cannot stop for a migration; whatever gets built has to run alongside the sheet for a while.
- Staff who have used the spreadsheet for years will reject anything slower than it.
- Six years of historical data has to come across without being quietly mangled.
Scoped into version one
- Jobs, customers and crews as real records with an audit trail on every change.
- A scheduling view for the office, built to be faster to operate than the spreadsheet it replaces.
- A stripped-back mobile view for crews: today's jobs, status, notes and photos.
- Role-based permissions so field staff cannot see pricing.
- A one-off data migration with a reconciliation report the owner can check line by line.
Deliberately deferred
- Automated invoicing — the accounting package keeps doing that until the core is trusted.
- Route optimisation, which sounds valuable and is worth nothing until the data is clean.
- Customer-facing booking and notifications.
- Reporting beyond three exports the office actually asked for.
The shape of the build
One shared spreadsheet
- Source of truth
- Disputed
- Change history
- None
- Access control
- All or nothing
- Field access
- Photos
A scheduling application
- Source of truth
- One database
- Change history
- Per record
- Access control
- By role
- Field access
- Mobile view
Illustrative comparison describing the shape of the change, not measured results from a client engagement.
Weeks 1–2 · Watching the work happen
Sitting with the office and a crew, mapping the real process rather than the documented one.
Weeks 3–10 · Four build sprints
Data model and migration script first, then the scheduling view, then the crew view, then permissions and the audit trail.
Weeks 11–12 · Parallel run
Both systems live at once, differences reconciled daily until the office trusts the new one.
Week 13 · Spreadsheet retired
Archived read-only, with a documented way back if something was missed.
Illustrative scenario and timeline. Figures are indicative and do not describe a specific client project.
An AI Feature Added to a SaaS Product That Already Works
An existing product with paying customers. The risk here is not building the feature — it is breaking the thing that already earns money.
The situation
- A document-heavy SaaS product where customers upload contracts and staff read them manually.
- Customers are asking for summaries and search that understands meaning rather than keywords.
- The product has one in-house developer who is fully occupied keeping it running.
The constraint
- Per-request model costs have to be predictable, or the feature quietly destroys the margin.
- Customer documents are confidential, so data handling has to be defensible in a sales conversation.
- A confident wrong answer is worse than no answer, so every output must cite its source.
Scoped into version one
- Document ingestion, text extraction and chunking behind the existing upload flow.
- Semantic search across a customer's own documents, isolated per tenant.
- Summaries that quote and link back to the exact passage they came from.
- A usage meter and a hard per-account cap, visible to the customer and to support.
- A feature flag so it can be switched off per tenant without a deployment.
Deliberately deferred
- A conversational assistant over the whole account, until search proves useful on its own.
- Fine-tuning or a self-hosted model, which is premature before usage data exists.
- Automated actions taken on the customer's behalf.
- Multi-language support beyond the one language most customers upload.
The shape of the build
Weeks 1–2 · Spike and cost model
A throwaway prototype on real documents to prove quality, plus a spreadsheet of cost per document at three usage levels.
Weeks 3–8 · Three build sprints
Pipeline and tenant isolation, then search, then summaries with citations and the usage meter.
Weeks 9–10 · Private beta
Enabled by flag for a handful of accounts, with outputs reviewed before it goes any wider.
Week 11 · General release
Rolled out tenant by tenant, with the off switch kept close to hand.
Illustrative scenario and timeline showing how we phase AI work. Not a description of a named client, and the weeks shown are indicative.
Rescuing a Mobile App the Previous Developer Abandoned
The enquiry we get most often, and the one where the first job is to tell the truth rather than to start coding.
The situation
- A founder has paid for nine months of work and has a build that crashes on launch for some devices.
- The developer has stopped replying. There is no documentation and no written architecture.
- The App Store listing and the cloud account are in the developer's name, not the founder's.
The constraint
- Nobody can say whether the existing code is 70 per cent done or 30 per cent done, and both parties have an incentive to guess.
- Remaining budget is a fraction of what has already been spent.
- Sunk cost makes rewriting feel unthinkable even when it is the cheaper option.
Scoped into the first engagement
- A fixed-price audit before any promises: build the app from source, read it, test it on real devices.
- A written verdict with evidence — what works, what is unsafe, what is missing entirely.
- Two costed routes: finish this codebase, or rewrite the client and keep the parts worth keeping.
- Account recovery: getting store listings, repositories and cloud accounts into the founder's name.
- One visible stabilisation release so users see something improve while the bigger decision is made.
Deliberately deferred
- Every new feature on the original roadmap until the app stops crashing.
- Redesigning the interface, however tempting it is to start there.
- The second platform, until the first one is stable.
- Any argument with the previous developer, which costs money and changes nothing.
The shape of the engagement
Week 1 · Audit
Source obtained, built from scratch, dependency and security review, crash reproduction on a device matrix.
Week 2 · Written verdict and two prices
Findings with evidence, a finish-it plan and a rewrite plan, each costed. The founder keeps the document either way.
Weeks 3–5 · Stabilise and take ownership
Crash fixes shipped, accounts and repositories moved into the founder's name, credentials rotated.
Week 6 onward · Chosen route
Either sprints to finish the existing build, or a staged rewrite that keeps the app live throughout.
Illustrative scenario and timeline describing how a takeover is structured. It is not a report of a specific client engagement, and all durations are indicative.
The Only Scenario That Matters Is Yours
The four above are teaching examples. The useful version of this exercise is the one where the situation, the constraint and the deferred list are about your product.
Send a paragraph
Describe what you want built the way you would describe it to a friend. You do not need a specification, and a half-formed idea is a perfectly normal starting point.
Get the same treatment in writing
A scoped version one, an explicit deferred list with reasons, a budget range with its assumptions, and an indicative timeline. Yours to keep whatever you decide.
No pressure to proceed
If we think the idea needs a prototype rather than an app, or that you should not build it yet, we will say so. An NDA can be in place before any of it, on request.
Get a Real Estimate for Your Own Build
Tell us the situation and the constraint — we will come back with the version one we would scope, and what we would leave out.