The exit story

The standing answer to the one question every platform-shop pitch earns: “and what happens if we part ways?” Every claim below is a shipped capability with a named mechanism, not an intention — evaluators are invited to verify each one against a generated product.


The claim

A client who leaves keeps a complete, ordinary software project — and the tools that built it. What they walk away with is indistinguishable from what a strong in-house team would have produced by hand, because that is literally what the factory emits.

What a departing client holds, item by item

1. A standard codebase with no proprietary runtime. .NET (Wolverine + Marten on PostgreSQL) and Angular — mainstream, MIT/Apache-class open source, hireable skills. There is no interpreter, no licensed engine, no design-time artifact the code depends on. Delete every trace of us and the product builds, tests, and deploys exactly as before. Contrast the platform alternative: leaving Appian means leaving the runtime the application is, which means a total rewrite. Leaving us means changing a git remote.

2. The generators, not just their output. Every scaffolding tool ships inside the product (scripts/): full-stack feature slices (generate.cs), event-sourced case workflows (generate-workflow.cs), accessible multi-step forms from a reviewable spec file (generate-form.mjs), honest data tables (generate-table.mjs), background jobs, admin views, integrations, demo scenario packs (generate-scenario.cs). A successor team — or the client’s own — keeps generating 508-conformant features at the same speed, without us. This is a deliberate business position (docs/DECISIONS.md, 2026-07-22): in federal competition the strongest argument against a platform shop is lock-in, and the rebuttal has to be structural, not contractual.

3. The compliance record as a living artifact, not a binder. CONTROLS.md maps NIST 800-53 controls to the tests that prove them; CI regenerates the evidence pack (EVIDENCE.md, machine-readable JSON, an OSCAL 1.1.2 component definition) on every green run, stamped with that run’s URL. The 508 posture is enforced, not asserted: every route is axe-scanned in CI by construction, forms inherit the error-summary pattern from one audited component, and plain-language and translation-completeness gates run on every commit. An assessor’s package regenerates from the repo at any commit — including after we’re gone.

4. The verification machinery. The same CI that gated our work gates theirs: generated products carry their own pipeline (build, unit/functional/architecture tests, accessibility crawl, dependency and SBOM gates, evidence regeneration). Cross-checked client/server validation harnesses go red when either side drifts. None of it phones home; all of it runs on commodity runners.

5. The demo and capture apparatus. Named seed scenarios, the demonstration banner, and one-command capture demos (Seed__Scenario=<pack>) transfer with the product — the client can demo their own system to their own stakeholders without us in the room.

What stays ours — said plainly

The upstream template’s evolution: new patterns, security fixes, compliance updates, delivered through the fleet-advisory machinery (docs/ADVISORIES.md, Fleet-Advisory: commit trailers, /sync-from-template). A client could replicate any single fix by hand; what they’d be re-deriving is the stream. Retention is earned by work quality plus upstream maintenance they would otherwise fund themselves — never by a runtime they can’t leave.

Why this is credible rather than aspirational

One email starts it.

  1. Tell us your agency and what you would like to see: a form, a legacy screen — or just say you want to learn for now.
  2. We reply and work out a time that fits your schedule.
  3. You watch a working system built from your own materials.
Start the email

SheaRogers@thinkforge.io — plain text, if the button is blocked.

Not a chatbot. This goes to a person.