Problem.
Most Customer Success dashboards stop at insight. They show CSMs which accounts are at risk and leave the action to the human. Churn happens when a CSM sees the risk but takes no action.
Force24 needed an Account Intelligence platform for their CSMs, accounts, and stakeholders that closed that gap. The platform had to ingest data from across the estate, transform it into analytics-ready customer views, surface actionable insights, prompt the action and capture the outcome. We built it as a greenfield project in 16 weeks and shipped it with the engineering team into a live production environment.
My contribution.
Data layer (owned end to end).
Force24 specified PostgreSQL as the warehouse. Every other tool decision on the data layer was mine.
- Chose Dagster for orchestration, dbt for transformation, the layered warehouse pattern (raw, staging, intermediate, marts) on top of PostgreSQL.
- Wrote every Python extractor against the source systems, scheduled and orchestrated through Dagster.
- Built every dbt model from scratch: staging views, intermediate business-logic tables, curated marts. Tests, documentation, lineage included.
- Wrote every Dagster job, materialising assets across the warehouse and scheduling the recurring runs.
- Set up Dagster on a VM with Caddy fronting it for admin authentication on manual runs alongside the automated schedule.
Service layer integration.
Plugged the data layer into the FastAPI service:
- Materialised the endpoints that surface marts tables to the frontend.
- Introduced Redis for caching where the API was hitting the warehouse too often.
- Wrote the scheduled jobs the service uses for batch operations.
Frontend (Angular).
Force24 specified Angular. My frontend contributions:
- Action Tracker (lead feature, owned end to end). CSMs create actions manually for any account, or accept smart-suggested actions surfaced by the system based on churn risk and account health score. Admins assign actions to specific CSMs. For each assigned action the CSM follows up with the account, captures notes on what was done, and records the outcome.
- Materialised the smart-suggestion logic that powers the recommended-action surface.
- Shipped additional features and enhancements across the dashboard surface where the data layer needed changes upstream.
Cross-layer integration.
The rest of the platform used data from the data layer. Wherever a layer needed something from it, the integration work was mine. Endpoint shapes, materialisation strategies, scheduling, caching, auth.
Why the Action Tracker matters.
A dashboard that only displays data does not help users act on it. The Action Tracker prompts CSMs to act on the risks they see, records the outcome, and stores each step as structured data.
Operationally it stops missed follow-ups by making ownership explicit and tracked. Each risk becomes a task with an owner, who works on it and closes it.
Architecturally it produces action-context-outcome triples that, with volume, become the labelled training set for a causal model that prescribes interventions instead of just flagging risk. The current platform flags risk. A future version trained on this data can recommend the intervention most likely to retain a given account.
Architecture.
Three layers. Stack constraint from Force24 (PostgreSQL warehouse, Angular frontend), free choice elsewhere.
- Data layer. Dagster orchestration on a VM with Caddy auth, custom Python extractors against multiple source systems, layered PostgreSQL warehouse using dbt across raw, staging, intermediate, and marts.
- Service layer. FastAPI backend with my contributions on data-layer endpoints, Redis caching, and scheduled jobs.
- Frontend. Angular dashboard with Action Tracker plus additional features and enhancements I shipped.
I used Docker to run all three layers together. The Dagster-on-VM automation framework was mine.
Outcomes.
- Over 40 dbt models on a deduplicated account spine.
- Five daily Dagster schedules.
- About 95 percent lower nightly running cost, after I rebuilt the high-volume revenue models as incremental on an append-only raw layer.
- 123 dbt tests and 82 pytest tests gate every build in GitHub Actions CI. They kept 22 data-quality defects out of the first production release.
- The platform runs 24/7 at zero infrastructure cost on Oracle Cloud.
Lessons.
Users notice the data layer only when it produces wrong numbers. I designed this one with the lineage that proves the marts are correct, the orchestration that lets you re-run anything from any failure point, and the auth controls that let you run things manually without compromising the automated schedule. The rest of the platform depends on this routine work.
A dashboard that only displays data does not help users act on it. The Action Tracker taught me to design analytics views around the action the user should take, with the displayed data supporting that action. The first-order win is operational: CSMs work their accounts, admins distribute load, follow-ups stop slipping. The second-order win is analytical: every captured action and outcome becomes a labelled data point for the next generation of the platform. Designing for both at once changed how I shaped the data model.
Cross-functional collaboration is its own discipline. The integration points, where my data layer fed the API and the frontend, were where most of the real coordination happened. Owning a layer cleanly is what makes those handoffs work.
Stack.
Dagster · dbt · PostgreSQL · Python · FastAPI · Redis · Angular · Docker · Caddy · Oracle Cloud · GitHub Actions · Git