SaaS Pulse

The problem

Early stage founders read their numbers from three different tabs and a spreadsheet that is always a week behind. The questions they actually ask are immediate. Is revenue growing this week? Who cancelled? Who just signed up?

SaaS Pulse puts those answers on one screen and keeps them current.

What I built

• A metrics dashboard tracking MRR, churn and user signups, designed so the trend is legible at a glance rather than buried in a table.
• A live activity feed that keeps up with events, so signups and cancellations appear as they happen.
• Custom JWT authentication with role-based access control, giving founders and team members appropriately scoped views of the same data.

Architecture decisions

Auth built rather than bought, deliberately

SaaS Pulse uses a custom JWT implementation because I wanted the full mechanism in my hands: issuing, verifying, scoping and expiring tokens, with roles carried through to every protected route.

Read paths shaped by the questions being asked

A dashboard is a read-heavy product. The data model is organised around the handful of questions the page asks constantly, rather than being a generic schema that needs expensive aggregation on every load.

Feed first, charts second

The activity feed is the part a founder would keep open, so it gets the shortest path through the stack, with the aggregate metrics computed around it.

Hard parts

• Defining churn honestly. The metric is easy to compute and easy to compute wrongly, and the definition has to match how a founder thinks about their business.
• Keeping the feed cheap. Live is a user expectation, not an excuse to hammer the database on a timer.
• Role scoping without duplicating the UI. One dashboard, several audiences, one code path.

Outcome

SaaS Pulse is the project where I went deepest on authentication and on shaping data for the way a screen is actually read. It is live, open source, and the auth patterns from it carried straight into Task-Flow.