This is what a Blueprint looks like.

A representative deliverable so you can inspect the thing before you buy it. The subject below is a composite (real engagement patterns, every identifying detail removed or changed), but the structure, depth, and bluntness are exactly what you receive.

Get yours arrow_forward About the Blueprint
Page 1 · Engagement Summary

The situation, in one honest page

Subject: a regional field-service company, about a dozen staff, whose scheduling-and-invoicing app was built to roughly 70% by a contractor who left. The business runs on the working parts daily; the unfinished parts are bridged by spreadsheets and memory.

Verdict: the system is worth finishing. The data model at its core is sound and the scheduling flow your dispatchers use every day is the strongest part of the build. It’s also one bad week away from real damage: there are no working backups, two critical credentials are shared in plain text, and invoicing math lives in three places that already disagree. Nothing here requires a rewrite. Everything here requires order.

The number that matters: the path from today to a dependable system is three bounded phases. Phase 1 is measured in days and removes the existential risks. You shouldn’t sign anything for phases 2–3, with us or anyone, until phase 1 is done and the ground has stopped moving.

Page 2 · System Inventory

What actually exists

Not what the proposal said. Not what anyone remembers. What is running:

  • check_circleApplication: web app (React front end, Node API), deployed on a single cloud VM by hand. Last known-good deploy: unclear — the previous developer deployed from their laptop.
  • check_circleData: one production PostgreSQL database on the same VM. Schema is genuinely good. Backups configured but writing to a disk that filled eight months ago — zero restorable backups exist.
  • check_circleIntegrations: payment processor (live keys in the repo), accounting export (manual CSV, weekly, by one person who knows the steps), SMS notifications (working, undocumented).
  • check_circleAccess: the business owns the domain. The cloud account, code repository, and error-tracking account are all under the departed contractor’s personal logins.
  • check_circleThe 30% that was never built: technician mobile view, automated invoicing, customer notifications. The spreadsheet bridging invoicing is where the money is leaking.
Page 3 · Risk Register

Ordered by what can hurt you, not by what is interesting

  1. CRITICAL — No restorable backups

    A disk failure today loses every job, customer, and invoice since the system went live. Fix is hours of work. This is item one for a reason.

  2. CRITICAL — Infrastructure under a personal account

    The person who left can still take the system down (accidentally or otherwise), and a lapsed personal credit card does the same thing slower. Transfer, then rotate every credential they ever touched.

  3. HIGH — Live payment keys committed to the repository

    Anyone with repo access can charge your customers. Rotate the keys, purge the history, move secrets out of code permanently.

  4. HIGH — Invoicing math disagrees with itself

    The app, the bridging spreadsheet, and the accounting export each compute totals independently and diverge on edge cases. You are almost certainly under-billing somewhere; a customer will eventually catch the reverse.

  5. MEDIUM — Single-human deploy and export processes

    Two workflows exist only in two people’s heads (one of whom already left). Documented, repeatable versions are cheap insurance.

  6. MEDIUM — No tests on money paths

    Nothing prevents a future change from silently breaking invoicing again. Tests go in around the money first; full coverage is not the goal, sleep is.

Page 4 · The Plan

Three phases, each independently valuable

  1. Phase 1 · Stabilize (days)

    Backups that restore (proven, not assumed) · infrastructure and repo transferred to accounts you own · every credential rotated · payment keys out of the code. Stop here if you stop anywhere — this phase alone converts “one bad week from disaster” into a normal business system with problems.

  2. Phase 2 · Make the money honest (weeks)

    One source of truth for invoicing math, tested; the bridging spreadsheet retired; the accounting export automated and boring. This phase typically pays for the entire engagement by itself.

  3. Phase 3 · Finish what was promised (weeks, scoped tightly)

    Of the unbuilt 30%, build the technician mobile view and automated customer notifications; consciously cut the rest until the business asks for it again. Finish on a foundation that can carry it.

Estimate structure (illustrative): each phase gets its own fixed quote before it starts, sized from this inventory — no open-ended retainer, no “we’ll see.” The real document states numbers; a sample stating fake ones wouldn’t tell you anything about how we estimate.

What happened next (in the engagements this composite is drawn from): phase 1 completed before any larger commitment was signed. That order is the point of the Blueprint — and the plan you receive is written so any competent team can execute it, which is what keeps us honest when we quote phases 2 and 3.

Want this document about your system?

Starting at $2,500, fixed scope, delivered with a plain-language walkthrough. The plan is yours whoever builds it.

Start a Project arrow_forward