Build Blueprint — Sample (Data Connector)
Blue Mesa Moving & Storage LLC — Jobs → Invoicing → Payroll-Hours Connector
SAMPLE — FICTIONAL CLIENT. Blue Mesa Moving & Storage does not exist. Every name, number, and quote in this document is invented so prospects in the data-connector wedge shape can see exactly what a paid Build Blueprint contains before buying one. A real Blueprint is built from the client's own intake answers, a workflow interview, and their actual tool/data access — the structure, depth, and fixed-price format below are the real thing.
| Prepared for | "Blue Mesa Moving & Storage LLC" — local + regional moving and storage, 28 field staff + 4 office, ~95 jobs/mo (fictional) |
| Prepared by | AI Build Concierge |
| Blueprint price | $995 flat — credited in full toward the Managed Build below if the client proceeds within 60 days |
| Delivery | 7 calendar days from paid intake |
| Verdict | BUILD — a small connector, deliberately not a platform. Three systems the client already uses each hold a third of every job's truth, and office staff re-type it twice. One narrow sync — completed job → invoice draft → payroll-hours summary, with an exception queue for everything that does not match — removes the re-typing without touching how crews work. Details §2–§4. |
1. Problem map
The client came in asking for "one app to run the whole operation." The interview found the operating system they have works on the road — it is the office hand-offs between systems that bleed, in cost order:
| # | Problem | What it costs them (client's own estimates, fictional) |
|---|---|---|
| P1 | Every completed job is re-typed twice. Crew hours and job charges are keyed from paper / a jobs spreadsheet into the invoicing system, then crew hours are keyed again into the payroll spreadsheet. The office lead estimates 12–15 staff-hours a week on re-typing alone. | Highest cost; pure waste, no judgement in it |
| P2 | Invoices go out 5–10 days late, and some never go out. A job closed on a busy Friday can vanish between the jobs board and invoicing. The owner estimates 1–2 jobs a month are invoiced very late or found unbilled at month-end — at a fictional ~$1,400 average job, $17k–$34k/yr at risk. | Cash-flow pain the owner feels monthly |
| P3 | Payroll-hour disputes are unanswerable. When a crew member questions hours, the office reconstructs them from texts and the paper sheet; the argument takes longer than the fix. | Trust cost; fixed by one audit trail |
| P4 | No single job view. "What did job #4821 actually cost and bill" lives in three places and a memory. | Solved as a by-product of P1+P2 |
What we are NOT solving in v1: dispatch / route optimisation, a customer booking portal, claims or damage handling, replacing any of the three existing systems, and the "one app" itself. Each is named in §4 as explicitly out of scope — that list is part of what the Blueprint fee buys.
2. Workflow audit — before / after
| Workflow step | Before (today) | After (with v1) |
|---|---|---|
| Job completed on site | Crew lead texts hours + extras to the office; office re-types into the jobs spreadsheet | Crew lead closes the job in the jobs system as today (same taps); the connector reads the closed job — no new field workflow |
| Invoice creation | Office re-types job charges into the invoicing system, 5–10 days later, from the spreadsheet | Invoice draft appears in the invoicing system within an hour of job close, built from the job record; a human reviews and sends — nothing auto-sends to a customer |
| Extras / overages (extra hours, packing, storage days) | Handwritten note, sometimes lost before invoicing | Extras entered on the job record at close are line items on the draft; extras with no price attached land in the exception queue, never silently at $0 |
| Payroll hours | Office re-types crew hours a second time into the payroll spreadsheet | Weekly payroll-hours summary generated from the same job records the invoices came from; every hour traceable to a job and a crew lead's close-out |
| Mismatches (hours edited after close, job reopened, duplicate close) | Found at month-end, or never | Exception queue, reviewed in one 15-minute daily pass: the connector never guesses — a mismatch is a flagged job with both values shown, not a silent overwrite |
| Month-end close | Two days reconciling three sources | The three sources already agree, because there was only ever one entry; close is a review of the exception log |
3. Context-engineering assets included
This is the part a generic builder skips, and the reason a connector survives contact with a real business instead of its demo data. The Managed Build includes building and handing over:
- Business context file — job types (local / regional / storage-in / storage-out), how extras are priced, which charges are taxable in the client's state treatment as configured in their invoicing system, crew roles, pay-period boundaries.
- Field-mapping sheet — every field in the jobs system, what it becomes in the invoicing system and the payroll summary, in plain language the office lead can audit. This sheet is the contract for what the connector does; if a field is not on it, the connector does not move it.
- Exception playbook — the ~12 mismatch cases this business actually produces (reopened job, split crew, storage day spanning two periods…) and the agreed handling for each: flag, hold, or pass — decided by the office lead in advance, not by the software mid-incident.
- Naming + ID convention — one job ID carried unchanged across all three systems, so any number can be traced in under a minute by any human, with or without the connector running.
- Escalation rules — what the connector must never do alone: send an invoice, change a price, edit a closed job's hours, or resolve an exception. All four stay human acts; the connector drafts, moves, and flags only.
All context assets are the client's property, delivered as plain documents they can hand to any future builder.
4. Build spec (v1 — pinned)
In scope:
- Connector service (client-owned account) that watches for jobs reaching Closed status in the jobs system and builds the matching invoice draft in the invoicing system from the §3 field-mapping sheet.
- Extras handling: priced extras become draft line items; unpriced extras block the draft into the exception queue with the missing price named.
- Weekly payroll-hours summary generated from closed job records, by crew member and pay period, exported in the format the client's existing payroll process already consumes.
- Exception queue: a single review screen / sheet listing every mismatch with both source values, its playbook case, and a human resolution that is written back and logged — the connector never overwrites a human-entered value.
- Run log + daily health note: every sync, draft created, and exception raised, in one readable log; a missed run alerts the office lead the same morning, never discovered at month-end.
- Training: two recorded walkthroughs (office lead, owner) + a one-page runbook including how to pause the connector safely.
Out of scope (explicit): replacing or migrating any of the three existing systems, dispatch/routing, customer-facing anything (portal, automated emails, review requests), auto-sending invoices, computing pay rates, overtime, or deductions (the connector moves hours; pay math stays in the existing payroll process), claims handling, and a general-purpose integration platform for future systems. Quoting any of these later is a separate Blueprint or a change order — never a mid-build addition.
Acceptance test: v1 is accepted when (a) 20 test jobs — including at least 5 with extras, 2 reopened, and 1 duplicate close — produce 20 correct invoice drafts or correctly-flagged exceptions, with zero silent overwrites, (b) the test week's payroll-hours summary matches a hand total from the same job records to the minute, (c) pausing and resuming the connector using only the runbook loses no job and duplicates no draft. The QA bot runs this checklist against this spec before handoff; it fails loudly, it does not pass silently.
5. Recommended stack
| Layer | Choice | Why |
|---|---|---|
| Jobs system | The client's existing jobs system — unchanged | Crews already work in it; the connector adapts to the business, not the reverse |
| Invoicing | The client's existing invoicing system — unchanged; drafts only | Invoices must live where the accountant already looks; human review before send is a hard rule (§3) |
| Connector | A small hosted automation + one narrow custom sync service (Make for the scheduling/trigger layer; a single-purpose coded connector where the jobs system's API needs it), running in the client's own accounts | This is the one wedge shape where some custom code is the product — kept to one service, one job, documented against the field-mapping sheet |
| Exception queue + run log | A structured sheet + log view the office lead already knows how to open | The queue is a daily 15-minute human habit; exotic tooling would kill the habit |
| Payroll summary | Generated export in the existing payroll process's current format | Hours move; pay math does not — no payroll migration in a connector project |
Custom code in v1: one narrow sync service — deliberate, and bounded by the §3 field-mapping sheet. Anything a second system or a new field would need is a change order, which is what keeps this from becoming the "one app" project in disguise.
6. Timeline
| Phase | Duration | Owner |
|---|---|---|
| Blueprint (this document) | 7 days from paid intake | AI Build Concierge |
| Client decision window | Up to 60 days — the $995 credit holds | Client |
| Field-mapping sign-off + API access in client's own accounts | Week 1 | Both (office lead ~1 hr) |
| Connector build + 20-job test set | Weeks 2–3 | Concierge + builder bench |
| Exception playbook live run (parallel with manual process) | Week 4 | Office lead (daily 15-min pass) |
| Acceptance test + training + handover | Week 5 | Both |
| Total, decision → live | ~5 weeks (incl. one full parallel-run week — a connector earns trust by comparison, not by launch day) |
7. Fixed price
| Item | Price | Terms |
|---|---|---|
| Build Blueprint (this document) | $995 | Paid at intake. Credited in full toward the Managed Build |
| Managed Build v1 (spec §4, complete) | $12,800 fixed | 50% ($6,400) to start, 50% on acceptance test passed. 2 revision rounds included. Kill fee: if the client stops the build mid-flight, work-to-date is invoiced at the milestone reached and everything built is handed over — no hostage code |
| Care Retainer (optional, from go-live) | $1,100/mo | Connector monitoring, exception-pattern review, field-mapping updates when a source system changes its fields, monthly unbilled-jobs sweep. Tool/hosting costs pass through at cost — estimated $40–$90/mo at this volume |
| Client's real first-year picture | $12,800 + ~$13,200 retainer + ~$780 tools ≈ $26,780 | Against 12–15 re-typing hours a week (~$15k–$20k/yr of office time at the client's own loaded rate) plus the owner's $17k–$34k/yr late/unbilled estimate — the hours alone nearly carry it; both figures are client estimates, not measured data — see §8 |
All prices inside the Concierge's published pricing (Blueprint $995 flat · Managed Build $3,500–$15,000 · Retainer $500–$1,500/mo). Fixed means fixed: if the build takes longer than §6, that is our cost, not the client's — scope changes go through a written change order priced before work starts. Proceeding costs $5,405 net new money at signing (first milestone $6,400 − $995 Blueprint credit).
8. Risks — stated, not buried
| Risk | Honest read | Mitigation in this plan |
|---|---|---|
| A source system changes its API or field names and the sync silently degrades | The standing risk of every connector; "silently" is the dangerous word | Run log + same-morning missed-run alert (§4.5); the connector flags schema changes as exceptions instead of mapping them by guess; Retainer includes field-mapping updates |
| Job data at close is sloppier than the test week suggests | Crews closing jobs in a hurry is the input-quality ceiling | The parallel-run week (§6) measures real exception rates before go-live; if exceptions exceed ~15% of jobs, the honest recommendation is a close-out checklist fix first — said in advance, here |
| The payoff estimates are optimistic | Possible — P1's hours and P2's at-risk revenue are client estimates, not measured data | The parallel run measures both: re-typing hours actually removed and drafts actually created; if the measured saving is near zero, the honest recommendation is to cut the retainer, and this Blueprint says so in advance |
| Office lead becomes the single point of failure for the exception queue | Real — the queue is a habit, and habits live in people | Playbook (§3) written for a stand-in to run; queue sized to 15 minutes; a second staff member is trained at handover |
| Scope creep toward "connect everything / run the operation" | The original ask, and how connector projects die | §4's out-of-scope list is contractual; each new system is its own Blueprint |
9. Next-step offer
- Proceed to Managed Build at the fixed $12,800 — the $995 Blueprint fee is credited, so starting costs $5,405 net new money (first milestone $6,400 − $995 credit). Signature on the MSA + SOW starts the clock.
- Or take this Blueprint anywhere. It is the client's property — spec, stack, field-mapping approach, and context assets are complete enough for any competent builder to execute. We'd rather earn the build than trap it.
- Or don't build. If the interview numbers were optimistic, the correct move may be a $0 version: one office staffer runs the §2 exception discipline manually for a month — invoice drafts within a day, from a daily closed-jobs list — to measure P1 and P2 before spending anything. This Blueprint's audit tables are structured so the client can do exactly that.
Contracts (mutual NDA, MSA, SOW with IP assignment to the client) are provided before any payment beyond the Blueprint. The client owns the code, the data, and every context asset from day one.