Problem.
Most Customer Success dashboards stop at insight. They show CSMs which accounts are at risk and leave the action to the human. The gap between "I see the risk" and "I did something about it" is where churn lives.
Force24 needed an Account Intelligence platform for their CSMs, accounts, and stakeholders that closed that gap. A system that ingests data from across the estate, transforms it into analytics-ready customer views, surfaces actionable insights, drives the action, and captures the outcome. Greenfield, 16 weeks, shipped 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 data layer was the spine the rest of the platform consumed. Wherever a layer needed something from it, the integration work was mine. Endpoint shapes, materialisation strategies, scheduling, caching, auth.
Why the Action Tracker matters.
Dashboards that only inform are half-built products. The Action Tracker pushes CSMs from awareness to action, captures the outcome, and turns the loop into structured data.
Operationally it stops missed follow-ups by making ownership explicit and tracked. Risk turns into work that is owned, worked, and resolved.
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. The next generation of it, fed by this data, can recommend the specific 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.
Docker tied it all together. The Dagster-on-VM automation framework was mine.
Lessons.
The data layer is invisible until it is wrong. 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. None of it is glamorous. All of it is what the rest of the platform depends on.
Dashboards that only inform are half-built products. The Action Tracker taught me to design analytics surfaces around the action they should provoke, not the data they should display. 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 · Git