Context
A US fractional CFO and bookkeeping firm serving $2M–$25M construction contractors needed to identify the right beachhead among three vertical-software platforms (JobTread, JobNimbus, Buildertrend) before scaling outbound. The firm runs platform-specific landing pages, has ~100 clients and $80M+ in client ARR, and an internal automation engineer ready to operate the system after the architecture sprint closes.
The framing the client arrived with was single-platform: which one platform should we beachhead? The honest answer wasn’t one of three — “beachhead” contained three different questions a single platform can’t win simultaneously.
The framing refusal
The architectural move was naming that the question contained three sub-questions, each picking a different platform:
| Sub-question | Winner | Why |
|---|---|---|
| Best positioning wedge | JobTread | 56% owner-CEO roles, 100% named reviewers, landing page already live, finance gap implicit in platform choice |
| Best repeatable data source | Buildertrend | 1,725 Capterra rows, 18–25% identification rate after verification, ~165–260 qualified companies per scrape cycle |
| Best first MVP | Indeed primary + Buildertrend parallel | Indeed returns company name in every row, no cross-reference required; Capterra data already in client’s Apify org |
One question, three answers, each justified independently. Forcing a single answer would have miscalibrated the build.
The load-bearing insight — composite signal model
Contractors don’t Google “fractional CFO.” They declare a finance gap through behavior — using construction software AND actively hiring a bookkeeper at the same time. Either signal alone is moderate; the overlap is high-precision.
The scoring model:
- Section A (platform confirmation, 0–30) — does the company use one of the target platforms?
- Section B (buying signal — active finance hire, 0–40) — are they currently hiring for bookkeeper / controller / office-manager-finance?
- ICP modifiers (0–20, capped) — owner-led, $2M–$25M revenue band, no internal finance function.
Anchored on a 90/90 validation case: a custom home builder with JobTread confirmed in four simultaneous job postings, an active bookkeeper hire, owner-led, no internal finance function. The case proves the overlap pattern is detectable when it exists. The MVP is built to falsify pattern repeatability, not to validate any single platform.
Routing: 60+ outreach now, 35–59 nurture with 30-day recheck, 15–34 monitor at 90-day, 0–14 disqualify.
The 6-value disqualifier upgrade
The first-cut model used a binary finance_title_in_org disqualifier. The client correctly flagged it as too blunt — a contractor with an entry-level bookkeeper isn’t a closed door, it’s a different angle.
Revised to a typed finance_role_type field:
none(+6 ICP, standard offer)entry_bookkeeper(-10, Angle Shift to cleanup/advisory/overflow)office_manager_finance(-5, structured support layer)controller(-20, fractional CFO/advisory at client judgment)cfo_executive(disqualify)unknown(+0, manual review)
Angle Shift leads receive a distinct GHL tag and a different opener: “We often work alongside in-house bookkeepers at construction companies — handling the parts that take the most time, so your team can focus on the build.”
Rules with nuance live in the field schema, not in prompt prose. Same architectural commitment as the disqualifier-clamp pattern in my open-source agent work, applied to a Supabase field instead of a Python class.
Architecture handoff
The deliverable is the architecture itself — the build is the client’s internal automation engineer from Week 2 onward. Handoff package:
- Supabase schema — 3 tables (leads with 28 columns including verification outputs, nurture_holds tracking downgrade detection, signals as time-series log for Phase 2 delta scoring)
- 4 n8n workflows — weekly scrape trigger, enrichment → Supabase, Supabase → GHL, 30-day nurture recheck
- Claude Code verification CLI on client VPS — runs between Apify scrape output and enrichment, performs structured web lookups, filters to ICP-fit before any email-enrichment credit is consumed
- GHL pipeline + custom fields, Missive routing for the sales team
- Option A vs Option B build-cost decision framework — Clay Launch (
$216/mo, low effort, 10-provider waterfall) vs Apollo paid + n8n ($80/mo, medium effort, leverages existing relationship)
Build order is 8 steps; the internal engineer takes it from there. Steady-state cadence: Mon scrape → Mon-Tue verify overnight → Tue sequences trigger → Fri the founder reviews replies.
Why this engagement matters
Three things make this case different from a typical platform-comparison engagement:
-
Refused the single-platform framing. Operator-level answers “JobTread or Buildertrend?” with a winner. Architect-level names that the question contains three sub-questions picking three platforms — and ships the framework proving positioning fit, data-source volume, and MVP detectability are independent dimensions.
-
Validated the composite, not the platform. The 90/90 validation case anchors the overlap pattern (platform + active finance hire + owner-led + no finance function), not JobTread itself. The MVP falsifies pattern repeatability — the same eval-style commitment that runs through my agent work, ported into client advisory.
-
Sequenced the build by detectability, not ambition. A 6-tier signal priority map gates what gets built when. Tier 1 buildable now, Tier 2 needs Month-2 baseline, Tier 3 gated on tooling. Prevents the common SMB outbound failure of designing for signals that don’t yet exist in usable form.
The outcome is an architecture the client’s internal team operates from Week 2 — not an outbound agency on retainer.