A capture-management product for a vertical the horizontal tools never fit

The category gap

The buyer operates inside a procurement cycle that rewards precision and punishes improvisation. Opportunities are known months or quarters in advance. Each one moves through a fixed sequence of qualification, proposal, negotiation, and award — and each stage carries its own artifacts, approvers, and compliance checkpoints.

Horizontal CRMs treat this as a pipeline with custom fields. It is not. It is a workflow with hard dependencies between stages, specific documents required at specific gates, and partner organizations whose participation has to be tracked as carefully as the buyer’s own. The category gap is not a feature gap. It is a model gap.

Why vertical, why now

The economics decide the shape of the product. A seat priced at $25–60k per year, sold into a cycle measured in quarters, buys the right to model the workflow correctly rather than approximately. At $99 a month, you sell configuration and hope the customer finishes the job. At this tier, the product ships with the job already finished.

Our decision to build narrow was not a concession. It was the premise. One vertical, one workflow model, one integration surface. Everything that would be configurable in a horizontal tool is opinionated here — because the opinion is the value.

How the product is shaped

The workflow engine encodes the stages and the transitions between them as first-class objects, not as labels on a deal record. A stage knows what it requires to close, what it hands to the next stage, and which external parties participate. Compliance gates are checks the system performs, not reminders it shows.

Partner coordination runs through the same model. Subcontractors, teaming partners, and approvers appear on the opportunity with defined roles and defined artifacts. Microsoft Graph handles the calendar, mail, and document surface the buyer already lives in — the product meets the team inside the tools they already use, instead of asking them to leave.

CAPTURE PIPELINE · WEEK VIEW

IDENTIFIED ........ 12
QUALIFYING ........  7
PROPOSAL ..........  4
NEGOTIATION .......  2
WON ...............  1
PIPELINE VALUE .... $1.4M

The system, end to end

A Python backend holds the workflow engine and the integration layer. Postgres stores opportunities, stages, artifacts, and the audit trail — every transition is recorded, because in this vertical the audit trail is part of the product.

A React frontend presents the pipeline as operators think about it: opportunities by stage, artifacts by opportunity, partners by role. The interface is dense where the work is dense and quiet everywhere else. No dashboards for their own sake.

Microsoft Graph is the integration spine. Mail threads, calendar events, and documents attach to opportunities automatically, so the capture record stays current without anyone remembering to update it. The workflow engine sits above all of this and keeps the stages honest.

Building for one vertical at $25k a seat beats trying to be horizontal at $99 a month. The price buys the right to model the work correctly — and the customer stops rebuilding it inside a spreadsheet.

— On the economics of narrow products

What we are seeing in pilot

The product is in market in a structured first phase: a small number of pilot engagements, chosen for fit rather than volume. The first paid pilot is signed. Tracked stages of the procurement cycle — the ones the workflow engine governs directly — are compressing by roughly a third against the buyer’s prior baseline. Artifacts that used to live across inboxes and drives are resolving to a single record per opportunity.

These are directional indicators, not vanity metrics. The next phase widens the pilot, extends the workflow coverage into earlier-stage qualification, and hardens the partner-coordination surface. The pace is deliberate: a product priced in five figures per seat earns that price by being right, not by being early.

PythonPostgresReactMicrosoft GraphDomain workflow engine