We bring your vision to life — to a signed scope, a fixed price and a date.

The brief, as it usually arrives

“We're a recruitment agency. Everything is in spreadsheets and the recruiters lose track of candidates. We need a proper system.”

The five questions we ask before quoting anything

1. Where does a candidate actually get lost? Between first call and client submission, or after submission while waiting on the client? These are two different tools. (Assume: the second — it is the usual answer, and it is the one that costs the agency money.)
2. Who else must see this? Recruiters only, or do client-side hiring managers log in? A client-facing portal roughly doubles the surface: permissions, invitations, an audit trail.
3. What is the single number the owner checks on Monday morning? That number defines the dashboard. Everything else is a nice-to-have.
4. Where do CVs live today, and must they stay there? Google Drive is an integration. Uploading into our own storage is not. The answer changes a week of work.
5. How many open roles at once, and how many candidates per role? 40 roles × 30 candidates is a list view. 400 × 300 is a search problem, and a different quote.

What we would build — the scope that fits 4 weeks

One workflow: candidate moves from sourced to placed, and the agency always knows who is waiting on whom.

Eight screens: role list · role detail with its pipeline · candidate list · candidate detail · submission drawer (stage, owner, next action) · my-week view (everything due, by owner) · owner dashboard (time-in-stage, placements this month, CSV export) · admin (users, clients, stage names).

Two integrations: Google sign-in, so nobody manages another password. Google Drive, so CVs stay where recruiters already put them — we store a link and a permission check, not a copy.

What we would deliberately cut, and say so on day one

• WhatsApp integration. Everyone asks. The Business API needs a Meta business verification and message templates approved by Meta — a dependency we do not control, inside a four-week fixed date. We ship a copy-to-WhatsApp button instead: same minute saved, none of the risk.
• CV parsing / AI ranking. Accuracy here is unbounded work and the acceptance test would be a matter of taste. Out of scope by name, in writing.
• Email sync. Reading recruiters' inboxes is a second project with its own privacy conversation.
• Bulk import of three years of old spreadsheets. Excluded. We import open roles only; history stays in Sheets, read-only.

Named risks, and who carries them

The acceptance test we would sign

On the production URL, by the end-of-week-4 date: a recruiter signs in with Google, creates a role, attaches two candidates, advances one through every stage to placed, and the owner dashboard shows that placement plus a correct average time-in-stage, exported to CSV. Any item in the signed scope that does not do this is a defect and is fixed free inside the 14-day window.

Effort estimate [illustrative]: ~170 hours of equivalent senior engineering. That is a Launchpad, at the 8-screen and 2-integration ceiling — not below it. If questions 2 or 5 above come back the other way (a client portal, or 400 live roles), this is a Buildout and we say so before quoting, not in week 3.

The brief, as it usually arrives

“We quote loads over the phone, write them on a sheet, and then call drivers to assign them. We lose money on quotes we price wrong and we can never tell a customer where their shipment is.”

Why this is a Buildout and not a Launchpad — decided before the quote, not during

There are three workflows here, not one, and they cannot be separated without the tool being useless: quote → dispatch → status to customer. A Launchpad that shipped only quoting would leave dispatch on the spreadsheet, which means double entry, which means the tool gets abandoned. We would rather name the bigger package up front than deliver a working quarter of a system and watch it go unused.

The three workflows, and the acceptance test for each

The data-model decision that matters most

Quote and Load are separate records, and a Load stores a frozen copy of the quote's cost lines rather than a reference to them. Every ops tool we have seen get this wrong gets it wrong the same way: someone re-prices a quote after the load is running, and last month's margin reports silently change. A frozen copy makes history immutable and the owner's margin number trustworthy — which is the entire reason they are buying this.

What we refuse, and why it protects the date

• Live GPS tracking. That is a telematics integration per carrier, and carriers are not our vendors. We ship manual checkpoints plus a driver-facing status link. If GPS is non-negotiable, it is a separate project after an integration review — priced then.
• Automatic rate-engine pricing from market data. Rate APIs are paid, per-lane and licence-restricted. We build the margin calculator the brokers already reason with, and leave the rate source as a field they type into.
• Invoicing and accounting posting. Ends at CSV export. Writing into their accounting system crosses into financial reconciliation, which we do not take on.
• Anything load-board-integrated. No documented public API we can rely on → outside our integration rule.

The eight weeks, as we would commit them

Effort estimate [illustrative]: ~330 hours, 4 integrations at the ceiling (Google sign-in, email/SMS send, Sheets import, Slack alerts). Signing off one workflow at a time is the point: if week 4 reveals the margin formula is more complicated than described, we re-plan weeks 5–8 together while two-thirds of the value is already accepted and in use.

Why this example exists

Most briefs arrive as a comparison to an app the client admires. A comparison is not a specification, and quoting one is how fixed-price projects lose money — for us, which then becomes a problem for the client. This is the teardown we do instead, and it is exactly what the Blueprint buys.

Step 1 — Separate the one job from the admiration

“Like Uber” usually names four products at once: a consumer marketplace, a supply-side app, real-time dispatch, and a payments ledger. We ask one question: if only one of these worked on launch day, which one earns or saves money this quarter?

Four of the five sentences shrank. That is the normal outcome, and it is worth more than any discount we could offer.

Step 2 — Find the hard part early

In rental, the hard part is never the booking form. It is the availability calculation: an item is unavailable for its rental window plus transport and service buffers, across overlapping bookings, with blackout dates. This is where a cheap quote quietly dies, so we build it on day one of the Blueprint — a bare screen that answers "what can I rent on Tuesday", with the client's real inventory and their real buffers. If that is wrong, everything built on top of it is wrong, and we would rather know in week one of a cheap engagement than in week three of an expensive one.

Step 3 — What the client holds at the end of the week

1. A clickable prototype: catalogue → date picker with real availability → booking → confirmation → staff view of tomorrow's dispatches.
2. A written spec: the data model (Asset, AssetUnit, Booking, RateCard, BlackoutDate), the availability rule in plain English next to its pseudocode, and the integration list.
3. A fixed-price, fixed-date quote for the build, with the acceptance test written out.
4. The named risks: payment-gateway onboarding time, who owns a damage dispute, and what happens when a renter keeps an item two days longer.
5. A handover note good enough to take to a different developer. The Blueprint is useful even if you never hire us — that is deliberate.

Step 4 — What the teardown is allowed to conclude

Sometimes the honest answer is don't build this, or this is bigger than eight weeks and we are not the right firm. The Blueprint fee covers us saying that out loud, with the artifacts to back it up and the reasoning written down — which is a cheaper week than finding out during a build.

Illustrative throughout. No client said these words; the brief is a composite written to show the method. The availability rule, the shrink table and the risk list are the parts we would actually produce.