Release assurance — for AI-built SaaS
Before you ship, prove the risky paths actually work.
A 10-business-day engineering pilot for AI-assisted SaaS teams. We define the exact release boundary, exercise up to three workflows that can lose customers or money, repair a bounded set of defects, and hand you an evidence-backed release decision.
One repository · one staging environment · up to three critical workflows · founding pilot $4,500
Why this exists
Green tests can still hide a broken release.
AI made the build faster. It did not make the handoff between systems easier to trust. The failure is often not inside one function; it sits between a browser session, an API, a policy, a webhook, a queue, and the data left behind.
Identity and access
Sign-up, sign-in, password reset, invitation, role changes, admin boundaries, and the tenant a user can actually reach.
Billing and entitlements
Checkout, webhook delivery, plan changes, cancellation, retries, and whether paid access matches the billing state.
Tenant isolation
High-risk reads, writes, exports, shared links, and support or admin paths across the roles included in the pilot.
Jobs and side effects
Queues, retries, scheduled work, emails, files, and external API calls that can duplicate, disappear, or finish out of order.
The method
Contract the release. Capture the evidence. State the unknowns.
01
Contract the release
Freeze the Git state, staging environment, roles, workflows, expected outcomes, evidence standard, and explicit exclusions.
02
Build the baseline
Run the local CodeTruss Boundary and, where approved, the hosted repository audit. Review scope drift, sensitive surfaces, deterministic findings, project checks, and codebase health.
03
Exercise the risky paths
An engineer manually verifies the agreed browser, API, data-store, and external-side-effect behavior. These checks are service work today, not a claimed automated CodeTruss feature.
04
Repair and rerun
Complete up to two bounded remediation pull requests, repeat affected checks, and record what changed and what remains unknown.
05
Make the release call
Deliver a go, conditional-go, or no-go recommendation with evidence, owners, deadlines, and every untested path stated plainly.
Independent worked example
See how a public snapshot became a release checklist.
We scanned a pinned open-source AI chatbot template, manually rejected unsupported analyzer output, and converted the remaining evidence into bounded release questions. This is public-source analysis—not a customer engagement, deployment test, or endorsement.
Read the walkthroughFixed pilot scope
Leave with a decision, not another dashboard.
- Release contract with the exact branch, environment, roles, workflows, checks, and exclusions
- Local CodeTruss receipt plus hosted architecture and health artifacts where repository access is approved
- Critical-path matrix showing expected behavior, executed check, result, evidence location, and owner
- Up to two bounded remediation pull requests with the affected checks rerun
- Release evidence pack with a go, conditional-go, or no-go recommendation and a prioritized risk register
- 45-minute handoff with the founder or engineering lead
Honest capability boundary
CodeTruss supplies repeatable repository proof. An engineer verifies the release paths.
Product · available now
Local change boundary
Scope rules, sensitive-surface flags, 13 deterministic registry analyzers, configured project checks, explicit verdict reasons, and integrity-signed Markdown and JSON receipts.
Service · engineer led
Cross-system verification
Browser, API, data-store, webhook, and job behavior is manually exercised for the workflows in the release contract. This is not presented as automated CodeTruss functionality.
Deliverable · bounded decision
Release evidence pack
Results, evidence locations, remediation, known unknowns, and the release recommendation are assembled into one reviewable handoff.
This is not a penetration test, compliance certification, legal opinion, uptime guarantee, or claim that software is safe. A signed receipt proves post-signing integrity of captured bytes, not trusted execution or the truth of every conclusion.
Frequently asked questions
What the pilot does — and does not — prove
Do you need repository access for the first call?
No. The first risk screen only needs the stack, target release date, critical workflows, and current testing state. Access and handling terms are agreed before technical work begins.
Is this a penetration test or compliance certification?
No. The pilot can include security-relevant release checks inside the agreed workflows, but it is not a penetration test, SOC 2 assessment, or other compliance certification.
Does a signed CodeTruss receipt prove the release is safe?
No. The signature proves that captured receipt bytes have not changed after signing. It does not prove trusted execution or make every analysis conclusion true. The release decision states its evidence and limits separately.
What if the work is larger than the pilot?
The evidence pack separates release blockers from later improvements. Work beyond two bounded remediation pull requests is estimated and approved separately before it begins.
Bring the three workflows that cannot fail.
The first conversation needs your stack, release date, current testing state, and the paths that would hurt most if they broke. Repository access is not required.
Request a release-risk screen