RevPilot AI.
Revenue intelligence, from question to evidence
Pipeline, billing, collections and retention tell different parts of the revenue story. I built RevPilot to connect them through consistent metrics, evaluated models and investigations whose numerical claims can be traced to the database.
Start with the commercial decision
A revenue total rarely explains the decision in front of a team. A sales manager needs to distinguish pipeline value from likely conversion. Finance needs to separate invoices from cash receipts. Customer teams need account context before prioritising retention or collections.
RevPilot brings these views into one workspace. A user can start with a performance measure, examine an opportunity or account, investigate a question and inspect the supporting records. The product connects analytical depth with the practical work of a revenue operations team.
A connected view of commercial performance
Commercial history with a reproducible foundation
I created Northstar Cloud as a deterministic B2B demonstration company, with linked accounts, opportunities, activities, subscriptions, invoices and payments. A fixed seed and reporting anchor make the results reproducible. The dataset supports realistic analytical relationships without exposing customer or employer records.
| Entity | Records | Analytical role |
|---|---|---|
| Accounts | 2,500 | Segment, geography and customer context |
| Contacts | 6,000 | Relationships within each account |
| Opportunities | 8,000 | Pipeline value, progression and outcomes |
| Activities | 45,000 | Engagement and opportunity history |
| Subscriptions | 1,800 | Recurring revenue and retention analysis |
| Invoices | 15,000 | Billing, ageing and payment exposure |
| Payments | 12,574 | Cash collection against issued invoices |
PostgreSQL holds the canonical facts and operational records. Database sessions set an organisation context for row-level security; application and migration roles have separate responsibilities. SQL and dbt views establish the analytical foundation consumed by the API.
One definition from database to decision
- 01Commercial recordsReproducible history · validated account imports
- 02PostgreSQL 18Canonical facts · organisation scope · operational audit
- 03Analytical layerSQL / dbt views · fitted Python models
- 04FastAPIGoverned metrics · typed filters · authorised operations
- 05Next.js workspaceNine connected analytical screens
The browser presents analytical results rather than maintaining a competing set of calculations. Invoiced revenue, cash collected, recurring revenue and pipeline each have their own definition. This keeps a change in chart, filter or interface from silently changing the meaning of a commercial measure.
Move from performance to the underlying record
The pipeline behind the headline
- Overview connects invoicing, collections, recurring revenue and open pipeline.
- Pipeline analysis combines stage distribution, ageing, opportunity search and detail history.
- Customer intelligence connects account records to subscription, activity and billing context.
- Recovery analysis prioritises outstanding exposure using documented value and ageing rules.
- Reports preserve analytical snapshots, while CSV exports make the underlying results available for further analysis.
Shared reporting filters provide a consistent route through the product. The operations view exposes ingestion, quality and model records alongside the business-facing screens, giving the analytical output an inspectable operational foundation.
Evaluate on later observations
Forecasts with an evaluation history
For deal and churn classification, I separated training, validation and test periods in time. Logistic regression and LightGBM compete on validation Brier score, which assesses the quality of predicted probabilities. The selected family is refitted on the development period before evaluation on later observations.
Held-out reporting includes average precision, ROC AUC, Brier score and calibration bins. Model records preserve the features, time boundaries, selection criterion and evaluation results so that a probability can be interpreted in the context of its benchmark.
Invoiced revenue forecasting compares a seasonal baseline, exponential smoothing and gradient boosting through rolling-origin backtests. Mean absolute error determines selection. The displayed uncertainty band summarises the observed one-step backtest errors.
The generated commercial environment makes model selection, calibration and error analysis reproducible. Each result remains attached to its data period and evaluation record.
An analyst that has to show its working
DeepSeek interprets the question; authorised analytical tools establish the numerical evidence. The model does not receive unrestricted SQL execution. Tools validate their arguments, query the organisation-scoped data and return evidence references that are persisted with the investigation.
Each investigation has a defined execution budget: four provider rounds, ten tool executions and an overall deadline. The final round produces an answer from the retrieved evidence. Provider failures remain explicit, and saved results can be reopened without making another model call.
From a question to a verifiable answer
Recruiters can investigate without signing in. A signed HTTP-only visitor cookie separates saved histories, while durable visitor, network and global quotas bound use of the paid provider. API credentials stay on the server. The same boundary keeps public exploration separate from changes to shared commercial records.
An action needs more than a recommendation
The workflow design separates a recommendation, a proposal, approval and execution. Approval is attached to the exact payload and version of an action. A changed payload cannot inherit an earlier approval, and a replayed execution is rejected.
Rule simulation shows the records that meet a condition before an action is proposed. Temporal provides durable internal task execution in the full local runtime. The public product preserves the exploration experience while protecting shared rules and records from anonymous changes.
This separation makes the application useful beyond a conversational interface: a user can inspect the evidence for a proposed intervention, understand its scope and control the point at which it becomes an action.
Delivered as a working analytical product
The deployed product uses Vercel for Next.js, Render for FastAPI and Neon for PostgreSQL 18. The API runs with an application database role; migration credentials are kept outside its hosted runtime. Provider configuration is server-side and excluded from the repository and frontend bundle.
Verification covers analytical calculations, tenant boundaries, signed sessions, cross-visitor history isolation, usage admission and provider failure handling. Browser checks cover desktop, tablet and mobile layouts. A public DeepSeek investigation was reconciled with the analytical data, saved and reopened through the deployed interface.