The problem
Finance teams don't lack data. They lack a closed loop from raw transactions to a decision.
Runway lives in a spreadsheet someone updates on Sundays. Suspicious spend gets reviewed late, if at all. "What if we hire two people?" is a one-off model built under pressure, not something a team can check on demand. Enterprise finance tools cover pieces of this, at a price that stops most SMB CFOs from listening past the first call.
FinCrew's bet: CFO-grade intelligence without enterprise bloat.
The founder's brief was ambitious: six specialized agents, AR/AP, reconciliation, board decks, and a live feed showing agents work in real time. As a first build, most of that was distraction. The question that mattered for the MVP:
Can a team ingest transactions, see real risk, see runway, and ask a grounded question against their own numbers?
Everything else waited.
The core loop
ingest -> Fraud Agent -> forecast & scenarios -> ORACLE
Two agents, not six. Each produces something a person can act on directly.
- Fraud writes alerts a human reviews.
- Forecasting writes runway and what-ifs a team can plan against.
- ORACLE answers questions, but only from data FinCrew actually stores.
What shipped
Fraud Detection Agent: rules first, model second
Obvious fraud signals don't need a model: duplicate payments, weekend spending, new vendors, org-defined custom rules. Those run as deterministic checks in code.
Only the ambiguous remainder goes to Claude Haiku for structured scoring and a short explanation. If the model is unavailable, the rule-based checks keep working on their own. Lower token cost, lower latency, and a system that's debuggable when finance asks why a specific alert fired.
A review queue, vendor trust scoring, and admin digests sit on top of the pipeline.
ORACLE: a CFO assistant with a narrow tool surface
Streaming, tool-calling chat (Claude Sonnet) over live FinCrew data: KPIs, forecasts, scenarios, fraud alerts, transaction summaries.
ORACLE can only act through tools that hit FinCrew's own services. Every metric it returns carries a source and confidence label. Numbers it doesn't track stay unavailable rather than estimated. A finance assistant that invents a metric is worse than no assistant at all.
Forecast and scenario planning
13-week cash projections from transaction history, cached baselines, what-if scenarios with runway and burn impact. The brief treated this as one line among many; it's actually the surface a CFO opens first, so it got built as a first-class feature rather than a chart under the agent showcase.
The SaaS shell that makes the agents usable
Multi-tenant organizations, invites, Stripe entitlements, CSV import, background jobs for the heavier ingest and fraud-scan work, and an early-access marketing site. Bank connectivity was built end to end (auth, webhooks, raw-to-normalized pipeline, fraud handoff), then paused once the ongoing API cost didn't make sense for a product that hasn't launched yet. CSV import kept the loop moving. Bank sync is ready to switch back on if the unit economics work.
Scope killed on purpose
This is Scope You Kill on Purpose applied to a finance OS brief instead of a founder pitch.
| Ask | Why it waited | What shipped instead |
|---|---|---|
| Six agents + live activity feed | Assumed users would want to watch agents before there was evidence worth watching | Two agents with durable, actionable outputs |
| Invoicing, bills, reconciliation | Adjacent products | Clear "coming soon" placeholder in the IA |
| AI across most of the product | Ambient AI fails in production more than it helps | AI scoped to fraud triage and the CFO assistant |
| Payroll (asked for during a demo) | Different product entirely | A clear no |
| Bank connectivity as the default onboarding path | Vendor cost unproven against a product with no users yet | CSV-first; bank rails built, then paused |
The biggest cut was the multi-agent activity feed the founder's original brief treated as the centerpiece. Proving the loop had to come before giving people something to watch.
Engineering notes
Rules first, model second. The naive fraud design is one model call per transaction: expensive, hard to explain, and weaker than a predicate at catching what you already know how to catch. Splitting deterministic checks from model-scored edge cases fixed the cost and the explainability problem at once.
Ground the assistant in owned data. ORACLE's tool surface is deliberately narrow: it can only reach FinCrew's own services, and every KPI carries provenance. That constraint is what makes an AI CFO assistant usable instead of a liability.
Treat vendor cost as an architecture decision. Bank connectivity worked end to end. It also carried a real per-account cost that didn't make sense before FinCrew had any users to justify it. Pausing it and staying on CSV wasn't a retreat. It kept the loop alive without a cost the product couldn't carry yet.
Keep the request path thin. Import and fraud scans run as background jobs with retries, not inline in the request cycle, so the app stays responsive and a failed scan can recover without losing the import.
Keep the domain honest. Fraud, forecasting, KPIs, and ORACLE's tools share one domain package. Apps stay thin. No microservice cosplay for a product still proving whether the core loop is worth using.
Stack
| Layer | Choice | Why it earned its place |
|---|---|---|
| App | Next.js + TypeScript | UI, APIs, and streaming chat in one system |
| Domain | Monorepo core package | One place for financial logic |
| Data | Postgres + Drizzle | Tenants, transactions, alerts, forecasts, sessions |
| Jobs | Trigger.dev | Long-running ingest/fraud with retries |
| Auth / tenancy | Clerk + custom orgs | Managed identity; billing entitlements owned in-house |
| Billing | Stripe | Real plan structure without building payments from scratch |
| AI | Anthropic (Haiku / Sonnet) | Cheap structured scoring vs. deeper CFO reasoning, matched to the job |
Where it is now
FinCrew runs the full cash-intelligence loop (CSV ingest, fraud review, runway and scenarios, ORACLE) in founder-led demos with prospective finance teams. Bank sync is built and paused until the per-account cost makes sense at this stage. The six-agent vision is still the long-term bet; this build proved the smaller loop first.
Calendar time with the founder ran longer than three weeks — scoping, demos, and feedback between shipping days. The actual build was three weeks end to end.