Quote recovery
Stale quotes are chased on a schedule and the chase stops automatically on reply, out-of-office, bounce, unsubscribe or complaint.
QUOTE
Proprietary software asset · Pre-revenue · Available for acquisition
Complete B2B SaaS foundation for automated revenue recovery.
An acquisition-ready software foundation designed to identify, orchestrate and measure recovery workflows across quotes, leads, invoices, payments, disputes and customer reactivation.
- 647 automated assertions
- 13 connectors
- 40 database models
- 14 migrations
- 0 customers
01 — The product
One governed pipeline, from at-risk revenue to evidence-backed attribution.
Revenue Recovery AI is built around six stages. Each stage is a real module in the codebase, and the sensitive ones are deliberately slowed down by policy, risk and human approval.
-
01
Detection
Scheduled sweeps and inbound provider events surface stale quotes, overdue invoices, dormant customers, broken payment promises and disputes.
-
02
Decision
An AI proposes the next action inside a strict output schema. Tenant policy, the risk engine and human approval can all override it.
-
03
Execution
Approved actions run through the connector layer with an idempotency key, a claim/lease protocol, a hard timeout and an audit entry.
-
04
Follow-up
Contact safety decides when the next touch is allowed: suppression list, per-customer cooldown, per-case budget, business hours and out-of-office pauses.
-
05
Recovery
A case is only closed as recovered when verified evidence supports it. A customer reply on its own never counts as recovered revenue.
-
06
Measurement
Dashboard and reporting derive every figure from attribution records and tenant-scoped metrics — not from estimates or projections.
Recovery areas present in the codebase
Lead recovery
Unanswered leads are followed up before they go cold, inside the tenant's follow-up limits.
LEAD
Customer reactivation
Dormant customers are identified and re-approached under the same policy and contact-safety controls.
REACTIVATION
Invoice recovery
Overdue invoices are chased with payment reminders whose frequency and tone are governed by tenant policy.
INVOICE
Payment promises
Promised payment dates are tracked, and a broken promise escalates instead of silently aging.
PAYMENT_PROMISE
Invoice disputes
Disputes open as cases and are handled under the tenant's dispute rules, with human approval for anything commercial.
DISPUTE
02 — What is already built
Six subsystems, implemented and covered by the test suite.
Status labels follow the acquisition documentation's own vocabulary. The legend below defines each one: Implemented · Tested Implemented · Stand-in verified Not implemented
- Tested
- Covered by automated tests running against real PostgreSQL and Redis.
- Stand-in verified
- Exercised end-to-end against a local stand-in that implements the provider's real authentication, pagination and webhook signature scheme — with no real credentials.
- Live verified
- Exercised against a real third-party service with real credentials. No capability in this asset is live verified.
Recovery Engine
Implemented · Tested- Six recovery case types with a lifecycle, detection sweeps and per-type playbooks
- Read-only simulator for dry runs — always shadow, never sends anything
- Reply, auto-reply, bounce, unsubscribe and complaint handling that cancels pending work
- Contact guard: suppression, per-customer cooldown, per-case budget, business hours, out-of-office pause
AI Orchestration
Implemented · Tested- Strict structured output, validated server-side before anything else happens
- The decision contract cannot carry prices, discounts or payment terms — they are not fields
- Deterministic guards for hallucination, price, discount, recipient and prompt injection
- Escalation strips subject, body and recipient; every decision is persisted for audit
- Mock model by default; an OpenAI-compatible live adapter exists but has never been exercised against a real model
Multi-Tenant Architecture
Implemented · Tested- Organisation scoping enforced on every request; isolation is asserted by automated tests
- JWT authentication with server-side session revocation
- RBAC with five roles on a code-defined permission matrix
- Audit log, tenant-scoped metrics and structured logs with request correlation
- Redis-backed scoped rate limits for read, write, AI, ingest and authentication traffic
Integration Layer
Implemented · Stand-in verified- 13 connectors behind a registry that fails closed on an unknown provider
- Universal Connection API — connect, verify, rotate and remove, with real health checks
- Nine provider webhook signature schemes verified against the raw request body, with replay deduplication
- External identity mapping to internal customers, leads and invoices, with lazy backfill
- Customer import: CSV with a dry-run preview, and connector-driven pull
- No connector has been authenticated against a real provider account
Policy, Risk & Approval Controls
Implemented · Tested- Tenant policy caps discounts, follow-ups, follow-up intervals and automatically handled value, and defines reminder and dispute behaviour
- Tenant policy always overrides the AI recommendation
- Human approval is required for discounts, price and contract changes, credits, refunds, cancellations and legal actions
- Approval centre shows the original versus the recommended payload, and supports edit-and-revalidate, approve, reject and escalate
- An approved action can be revoked before dispatch; an edited approval is re-fingerprinted and blocked if the payload changed
Revenue Attribution
Implemented · Tested- Evidence-based states: RECOVERED, INFLUENCED, ORGANIC, UNRECOVERED and UNKNOWN
- RECOVERED requires a conversion plus payment or order evidence inside the attribution window, above a confidence threshold
- Append-only attribution history, with human confirmation of evidence
- Every dashboard figure is derived from these records
03 — Product screenshots
Captured from the synthetic demo tenant.
Every image below is a real capture of the running product, taken against the deterministic synthetic tenant “ACME Industrial”. There is no customer data anywhere in this asset, because no customer data exists. Images are shown unmodified apart from resizing and framing.
Captured from the acquisition package and cropped to remove the empty margin that surrounded the application column in the original files — presentation framing only, no pixel inside the application interface is altered or removed. Intrinsic sizes: 777×800 (dashboard and integration center), 777×798 (recovery case), 1200×670 (AI decision). Served as responsive WebP with a smaller variant for narrow screens. The captions describe what is on screen; they are not performance claims.
04 — Architecture
Thirteen layers from inbound event to attributed revenue.
A buyer can follow a single event through the whole system without talking to the author: the pipeline below is what the code does today.
- 01Event ingestion — provider webhooks and connector reads enter through signed, deduplicated endpoints.
- 02Event normalization — provider payloads become one internal vocabulary of 32 event types, classified as case-opening, lifecycle or recorded-only.
- 03Identity resolution — external identifiers are mapped to internal customers, leads and invoices, with lazy backfill for legacy rows.
- 04Recovery case engine — normalized events and scheduled sweeps open and advance cases across the six recovery types.
- 05Rule engine — per-type playbooks and tenant rules decide what should happen next.
- 06AI orchestration — the decision layer proposes the next action inside a strict, validated schema.
- 07Policy engine — tenant policy is applied and can override or block the recommendation outright.
- 08Risk engine — the proposed action is assessed before anything can be executed.
- 09Approvals — sensitive commercial actions stop for a human decision, which can be edited and is then re-validated.
- 10Action execution — validation, policy, risk, approval, idempotency, claim and lease, provider call, outcome.
- 11Outcome tracking — results, failures and stale claims are recorded and reconciled; an authorized retry re-runs every gate.
- 12Revenue attribution — evidence is verified against the tenant's own rows, and only then counted.
- 13Measurement — dashboard and reporting derive from attribution records and tenant-scoped metrics.
Stack
- NestJS 11
- TypeScript (strict)
- Zod validation
- PostgreSQL 16
- Prisma 6
- Redis 7
- BullMQ
- Next.js 15
- React 19
- Docker
- Jest + Supertest
05 — Integrations
13 connectors — implemented, and honest about their verification level.
These are the integration capabilities that exist today. Nothing below is a roadmap item, and two levels of verification are kept strictly apart.
Level 1 Implemented and exercised against local stand-ins
All 13 connectors are implemented and were driven end-to-end against a local HTTP stand-in that reproduces the provider's real authentication header, pagination style, record shape and webhook signature scheme. The code, the registry and the capability declarations are covered by the automated test suite.
Stand-in verified — no third-party credentials exist anywhere in this asset.
Level 2 Requires buyer-side live credential validation
Every external provider sits here. Validating a connector against a real account requires real credentials, which are deliberately not part of this transfer. The buyer supplies their own accounts and performs live validation.
Requires buyer action — no connector has been verified against a real provider account.
| Provider | Category | Capabilities | Webhook signature | Verification |
|---|---|---|---|---|
| Resend | EMAIL_SEND, EMAIL_WEBHOOKS |
svix |
Stand-in | |
| Gmail | EMAIL_SEND |
— | Stand-in | |
| Outlook | EMAIL_SEND |
— | Stand-in | |
| HubSpot | CRM | CRM_READ_CUSTOMERS, CRM_READ_LEADS, CRM_WRITE_ACTIVITY |
hubspot_signature |
Stand-in |
| Stripe | Billing | BILLING_READ_INVOICES, BILLING_READ_PAYMENTS |
stripe_signature |
Stand-in |
| Shopify | E-commerce | ECOMMERCE_READ_ORDERS |
shopify_hmac |
Stand-in |
| WooCommerce | E-commerce | ECOMMERCE_READ_ORDERS, ECOMMERCE_WEBHOOKS |
woocommerce_hmac |
Stand-in |
| Tiendanube / Nuvemshop | E-commerce | ECOMMERCE_READ_ORDERS, ECOMMERCE_WEBHOOKS |
linkedstore_hmac |
Stand-in |
| Mercado Pago | Payments | PAYMENTS_READ, PAYMENTS_WEBHOOKS |
mp_signature |
Stand-in |
| WhatsApp Business (Cloud API) | Messaging | MESSAGING_WEBHOOKS (inbound only) |
meta_sha256 |
Stand-in |
| Generic REST | Generic | GENERIC_API_READ |
— | Stand-in |
| Generic webhook | Generic | GENERIC_WEBHOOKS |
internal_hmac / svix |
Stand-in |
| Mock email | Email (test) | EMAIL_SEND |
— | Local by design |
How inbound data is protected
- Nine provider signature schemes, verified against the raw request body rather than a re-serialised payload
- Replay deduplication per provider and event type; a replayed delivery is acknowledged but not reprocessed
- An unknown or unsatisfiable signature scheme is refused rather than accepted
- Provider batches are expanded per item instead of being collapsed into one event
- Credentials are encrypted at rest with AES-256-GCM and refreshed before use; secrets are never logged
What is explicitly not implemented
- Scheduled connector synchronisation — reads are on demand or triggered by a manual import
- Connector drift monitoring — no background re-verification of connected accounts
- Anything not listed above — this page lists no roadmap items, only what exists in the code
06 — Technical evidence
647 automated assertions, on the frozen tree.
Verification evidence, not commercial traction. These numbers describe how thoroughly the codebase is tested; they say nothing about demand, customers or revenue.
- 133 Unit tests
- 353 Integration tests
- 39 End-to-end tests
- 122 Synthetic ACME scenarios
647 assertions passing in total, reproduced on a clean clone.
Other checks that pass
- TypeScript typecheck — 0 errors
- Lint — 0 errors
- Production build — exit 0, 18 of 18 routes generated
- Prisma schema validates and the client generates
- All 14 migrations apply cleanly to an empty database
- All three Docker Compose configurations validate
- Secret scan of the working tree, the archive and the Git history — clean
- Deterministic demo environment reproduces an identical fingerprint across runs
Example invariants the suite enforces
- A customer reply is never counted as recovered revenue
- The emergency stop is authoritative and always wins the race
- Cross-tenant access is rejected
- An edited approval is re-validated and blocked if the payload changed after approval
- An action is never executed twice for the same idempotency key
- A stale claim is reconciled instead of being silently retried
These figures come from the frozen tree and were re-run after all documentation and cleanup changes were complete. Test coverage was not measured, so no coverage percentage is claimed. Docker image builds were not executed, only the Compose configurations were validated. No live provider call and no live model call has ever been made from this asset.
07 — What the buyer gets
A complete, self-contained transfer package.
The transfer is the frozen working tree plus the acquisition documentation set — not a partial repository, and not a subset of the source.
- Complete source code
- Frontend (Next.js operator UI, 17 routes)
- Backend (NestJS API + in-process worker)
- Database schema (40 models, 9 enums)
- Database migrations (14, verified on an empty database)
- Deterministic seed
- Integration foundation (13 connectors, fail-closed connector registry, webhook signature verification)
- AI orchestration and decision guards
- Recovery engine (six case types)
- Tests (unit, integration, end-to-end and scenario suites)
- Docker configuration (dev, prod and verify compose files, multi-stage non-root images)
- Technical documentation (architecture, takeover guide, reproducible setup, due diligence)
- Acquisition documentation (42 documents)
- Synthetic demo environment
- Screenshots (21)
- Sales deck and written listing copy
- Video materials (script, shot list, voice-over, title and end cards, captions)
- Buyer handoff documentation and FAQ
- Acceptance checklist the buyer can execute
- Proprietary IP transfer, subject to a separate written agreement
Not included
- Third-party credentials, API keys, OAuth secrets or provider accounts
- Domains, hosting or TLS certificates
- Customer data — none exists
- Live provider validation — never performed
- Any guarantee of revenue, customers or market demand
Third-party software
The asset depends on third-party open-source packages (predominantly MIT and Apache-2.0), which remain under their own licences. No rights in third-party software are transferred, sold or implied by this acquisition. A full dependency and licence inventory is part of the handoff documentation.
08 — Current status
Current status: pre-revenue
This is stated plainly on purpose, at the top of the section rather than in a footnote.
| External customers | None |
|---|---|
| Revenue | None — the asset is pre-revenue |
| MRR / ARR | None |
| Public traffic base | None |
| Customer data included | None — no customer data exists |
| Production credentials included | None |
| Integrations validated against a real account | None |
| AI calls against a real model | None |
| Commercial layer (billing, subscriptions, usage metering) | Not implemented |
| Password-reset email transport | Not implemented |
| Scheduled connector synchronisation | Not implemented |
| CI/CD pipeline | None |
| Test coverage measurement | Not measured — no percentage claimed |
| Load or performance testing | Not performed — no benchmarks exist |
| Independent security review | Not performed |
| Production deployment performed | No |
| Trademark registration | None claimed — status unknown |
About the demo environment
“ACME Industrial” and its control tenant are synthetic. They are deterministic, reproducible and entirely fictional, and they exist so the whole pipeline can be demonstrated and re-verified without any external account. Shadow mode is on by default, so nothing leaves the system during a demo.
If a screenshot on this page shows a dollar amount, that amount is synthetic demo data produced by the scenario fixtures — not recovered customer revenue.
Known limitations taken from the engineering record
- No live provider verification — no credentials are included
- The AI is a deterministic mock by default; the live model path is unexercised
- Shadow mode is on by default and must be turned off deliberately
- Session token is held in browser
localStorage, not a cookie session - Metrics and error counters are in-memory only
- Single-process worker; no multi-region or high-availability design
- No multi-currency, no internationalisation (English UI only)
- The product UI is client-rendered, so the application itself has no server-side SEO
09 — Who could take it further
Built to be continued, verticalised or embedded.
The most likely buyers are teams who already have distribution and need a governed automation and integration foundation, rather than another prototype.
- SaaS founder
- Vertical SaaS company
- ERP / CRM provider
- Software agency
- B2B automation company
- Existing business-software vendor
- Founder seeking an existing technical foundation
Ways a buyer could use it
Continue it as a standalone SaaS
Finish the commercial layer, add the provider credentials, validate integrations live and go to market with the existing pipeline.
Verticalise it
Bind it to one industry or country — where the recovery rules, the connectors and the policy defaults are specific enough to be defensible.
Integrate it into an existing product
Use the recovery engine and operator UI as a feature inside a platform that already has customers, rather than as a separate product.
Reuse the foundation inside another product
The connector registry, webhook verification, governed execution pipeline, approval centre and evidence-based attribution are reusable well beyond revenue recovery.
No financial projection, valuation, return, market size or buyer-interest claim is stated or implied anywhere on this page. What a buyer does with the asset is the buyer's decision.
10 — Acquisition
Built. Tested. Ready for a new owner.
The project is being offered as a proprietary software/IP asset rather than as an operating business with existing revenue.
Source code
The complete frozen working tree: frontend, backend, shared contracts and tests.
Documentation
Technical documentation plus a 42-document acquisition and handoff package.
Tests
647 automated assertions and an acceptance checklist the buyer can run directly.
Demo
A deterministic synthetic tenant that runs with no external accounts.
Open the interactive demo — static, read-only, synthetic data.
Technical foundation
Integration layer, governed execution, approval centre and attribution.
Acquisition materials
Screenshots, sales deck, listing copy, demo script and video materials.
View acquisition listing
Placeholder
The marketplace listing has been prepared but not yet published, so no public
listing URL exists at the time of writing. Nothing has been published, submitted or priced.
Replace SIDEPROJECTORS_LISTING_URL with the real URL (see
site/README.md) and this button will link straight to it.
How contact works
Contact happens through the marketplace listing. Until that listing is published there is no public contact channel on this page — deliberately, and no personal email address is exposed here. The acquisition documentation records the transfer model and the questions a buyer usually asks.
Nothing on this page is an offer, a solicitation or a commitment to sell. Transfer of the proprietary IP happens only through a separate written agreement, and the sale price is the owner's decision.