Founder-led software architecture consulting and technical leadership for US and UK high-growth B2B SaaS and AI businesses.
Z
Zyvor
Software architecture and technical leadership for high-growth B2B SaaS and AI businesses
Founder-led by Waleed Ashraf

Computer Software selected work

Analytics Intelligence Dashboard

Product analytics platform designed for user tracking, session metrics, retention analysis, engagement reporting, and real-time KPI dashboards for data-driven product decisions.

Analytics Intelligence Dashboard project cover
PeopleIJul 1, 2021 – Oct 31, 2021

project context

The product team was flying blind. Every feature decision was a bet with no way to measure the outcome.

A SaaS product with 8,000+ active users had no analytics infrastructure. The product team made feature decisions based on customer complaints and gut feeling. Nobody could answer basic questions: Which features are actually used Where do users drop off What's the real retention rate The company was building features in the dark.

company

PeopleI

market

Computer Software

roles covered

Software ArchitectTechnical LeadData EngineerTechnical StrategyFull-Stack EngineerBackend EngineerAPI EngineerCloud Architecture

stack and architecture coverage

AWSNext.jsPostgreSQLTypeScriptReactNode.jsREST APIsAPI ArchitectureBackend ArchitectureCloud Architecture
Visit live projectView Case Study

measurable outcomes

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency
Discovered 8 features with less than 5% adoption (candidates for removal or redesign). Identified 3 features strongly correlated with 6-month retention. Product roadmap reprioritized based on actual usage data
Day-30 retention baseline established at 42%. Churn prediction model identifying at-risk users 3 weeks before cancellation with 78% accuracy. "Aha moment" identified: users who completed 3 specific actions in week 1 had 2.4x higher 90-day retention
Concrete result: Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

problem

What had to change.

No event tracking. The product had zero instrumentation. User behavior was invisible. The only signal was support tickets and NPS surveys, both lagging indicators that captured complaints, not patterns
Feature usage was unknown. The team had shipped 40+ features over 2 years with no data on which ones were adopted. Product roadmap prioritization was based on the loudest customer requests, not actual usage patterns
Retention was a guess. The finance team calculated churn from subscription cancellations, but nobody knew when users actually disengaged. A user could stop logging in for 3 months before cancelling, and the product team had no early warning
Session data didn't exist. Average session duration, pages per session, feature discovery paths, and error encounter rates were all unknown. UX improvements were based on designer intuition, not user behavior data
Reporting was ad-hoc SQL queries run by the CTO. When the product team needed a number, they filed a request and waited 2-3 days for the CTO to write a query. The CTO spent 8+ hours per week answering data requests instead of building product
A/B testing was impossible without baseline metrics. The team couldn't measure the impact of changes because they had no before-and-after comparison framework

approach

I built a product analytics platform that captures user behavior, tracks feature adoption, measures retention cohorts, and delivers real-time dashboards to the product team. Designed to make every product decision data-informed.

The product team was flying blind. Every feature decision was a bet with no way to measure the outcome.

Phase 1

Event Tracking Infrastructure

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency

Phase 2

Feature Adoption Analytics

Discovered 8 features with less than 5% adoption (candidates for removal or redesign). Identified 3 features strongly correlated with 6-month retention. Product roadmap reprioritized based on actual usage data

Phase 3

Retention Cohort Analysis

Day-30 retention baseline established at 42%. Churn prediction model identifying at-risk users 3 weeks before cancellation with 78% accuracy. "Aha moment" identified: users who completed 3 specific actions in week 1 had 2.4x higher 90-day retention

execution

The implementation lanes behind the project.

Capture everything. Query anything.

Event Tracking Infrastructure

  • Lightweight client-side SDK capturing page views, feature interactions, button clicks, form submissions, and error events with automatic context (user ID, session ID, device, timestamp)
  • Server-side event API for tracking backend events (API calls, background job completions, billing events) that don't have a UI component
  • Event schema registry ensuring consistent event naming and property definitions across the entire product surface
Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency

Know which features matter and which ones don't.

Feature Adoption Analytics

  • Feature usage dashboard showing daily/weekly/monthly active users per feature, adoption curves for new features, and power user identification
  • Feature discovery funnel tracking how users find and first engage with each feature, identifying UX barriers to adoption
  • Feature correlation analysis showing which features are used together and which feature combinations correlate with higher retention
Discovered 8 features with less than 5% adoption (candidates for removal or redesign). Identified 3 features strongly correlated with 6-month retention. Product roadmap reprioritized based on actual usage data

See exactly when and why users disengage.

Retention Cohort Analysis

  • Cohort retention curves showing Day 1, Day 7, Day 30, and Day 90 retention rates segmented by signup source, plan type, and onboarding completion
  • Churn prediction model identifying users showing disengagement patterns (declining session frequency, feature usage drop-off) 2-4 weeks before they cancel
  • Retention driver analysis correlating specific user actions in the first 7 days with long-term retention, identifying the "aha moment" actions
Day-30 retention baseline established at 42%. Churn prediction model identifying at-risk users 3 weeks before cancellation with 78% accuracy. "Aha moment" identified: users who completed 3 specific actions in week 1 had 2.4x higher 90-day retention

Every product metric. Live. No SQL required.

Real-Time Product Dashboard

  • Executive dashboard showing active users, session metrics, feature adoption, retention rates, and error rates updated in real time
  • Self-service query builder allowing product managers to create custom reports by selecting dimensions, metrics, filters, and date ranges without writing SQL
  • Scheduled report delivery: daily product health summary, weekly feature adoption report, and monthly retention analysis delivered to stakeholders automatically
CTO data request workload dropped from 8+ hours/week to near zero. Product managers self-serving 95% of their data needs. Decision-making cycle from "wait 3 days for a query" to "check the dashboard"

Measure the impact of every change.

Experimentation Framework

  • A/B testing infrastructure with user segmentation, traffic splitting, and statistical significance calculation
  • Experiment dashboard showing conversion rates, engagement metrics, and retention impact per variant with confidence intervals
  • Guardrail metrics: automatic alerts if an experiment negatively impacts core metrics (error rate, session duration, key feature usage) beyond acceptable thresholds
First 5 A/B tests run within 2 weeks of launch. 2 tests showed statistically significant improvements (12% and 8% conversion lifts). 1 test caught a regression that would have shipped to all users

Make the implementation usable after launch.

Architecture Handoff and Operating Model

  • Documented the key architecture decisions, tradeoffs, and ownership boundaries behind the work.
  • Connected delivery lanes to support, operations, and future product iteration instead of treating launch as the finish line.
  • Gave the team a clearer operating model for scaling the product without recreating the same bottlenecks.
Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

project depth

More context behind the Analytics Intelligence Dashboard work.

Each selected project is read through business pressure, architecture tradeoffs, delivery sequencing, team operating model, role coverage, and stack fit so the case study stays useful for founders, CTOs, and product leaders evaluating similar work.

business pressure

Why the work mattered

The product team was flying blind. Every feature decision was a bet with no way to measure the outcome. The project started from a real operational constraint, not a decorative rebuild, which made the architecture work accountable to business movement.

architecture pressure

PostgreSQL with TimescaleDB extension over dedicated analytics databases

Event data is time-series by nature. TimescaleDB provides automatic partitioning by time, compression for historical data, and continuous aggregates for dashboard queries. Keeps the stack simple (one database engine) while handling analytics-scale query patterns

implementation priority

Event Tracking Infrastructure

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency

operating change

What changed for the team

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency

role coverage

Leadership and engineering coverage

The work called for software architect, technical lead, data engineer, technical strategy, full-stack engineer coverage, connecting strategy, implementation, and delivery quality instead of treating them as separate tracks.

stack fit

Technology choices in context

AWS, Next.js, PostgreSQL, TypeScript, React, Node.js were part of the delivery context, but the value came from how the stack supported maintainability, scalability, and a stronger path from architecture to production.

architecture decisions

Technical choices that mattered.

PostgreSQL with TimescaleDB extension over dedicated analytics databases

Event data is time-series by nature. TimescaleDB provides automatic partitioning by time, compression for historical data, and continuous aggregates for dashboard queries. Keeps the stack simple (one database engine) while handling analytics-scale query patterns

Client-side SDK with batched event delivery

Individual event HTTP requests would add latency and bandwidth overhead. The SDK batches events locally and flushes every 5 seconds or on page unload. Reduces network requests 95% while maintaining sub-10-second event freshness

Materialized views for dashboard aggregations

Real-time dashboards querying raw event tables would be too slow at 2M+ events/day. Continuous aggregates pre-compute hourly and daily rollups. Dashboard queries hit pre-computed data, loading in under 500ms regardless of date range

TypeScript for the event schema registry

Event naming consistency is critical for reliable analytics. TypeScript interfaces define every event's name and required properties. The SDK enforces the schema at compile time, preventing malformed events from reaching the analytics pipeline

operating model

Architecture changes were tied directly to how the software business would operate after launch.

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency
Discovered 8 features with less than 5% adoption (candidates for removal or redesign). Identified 3 features strongly correlated with 6-month retention. Product roadmap reprioritized based on actual usage data
Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

results

What changed after the work.

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency
Discovered 8 features with less than 5% adoption (candidates for removal or redesign). Identified 3 features strongly correlated with 6-month retention. Product roadmap reprioritized based on actual usage data
Day-30 retention baseline established at 42%. Churn prediction model identifying at-risk users 3 weeks before cancellation with 78% accuracy. "Aha moment" identified: users who completed 3 specific actions in week 1 had 2.4x higher 90-day retention

Week 1

Event tracking SDK deployed. 150+ events instrumented across all product surfaces. 2M+ events/day flowing into the analytics pipeline

Week 3

Feature adoption dashboard live. 8 low-adoption features identified. 3 high-retention features discovered. Product roadmap reprioritization started

Month 1

Retention cohort analysis revealing Day-30 baseline at 42%. Churn prediction model identifying at-risk users 3 weeks early. Self-service query builder eliminating CTO data requests

Month 2

A/B testing framework live. First experiments showing 12% and 8% conversion improvements. Guardrail metrics catching 1 regression before it shipped

Month 4

Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

Final outcome

Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

buyer relevance

Why this project belongs in Zyvor software architecture work.

Software architecture signal

Analytics Intelligence Dashboard shows how architecture decisions can move from implementation detail into business leverage for computer software teams.

Technical leadership signal

The work connects software architect, technical lead, data engineer responsibilities with delivery clarity, execution confidence, and a cleaner operating model.

Scale-readiness signal

Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

What kind of business is Analytics Intelligence Dashboard most relevant for?

This project is most relevant for computer software and computer software teams that need stronger software architecture, clearer technical direction, and more reliable execution as product or operational complexity increases.

What did Zyvor focus on in this selected work?

I built a product analytics platform that captures user behavior, tracks feature adoption, measures retention cohorts, and delivers real-time dashboards to the product team. Designed to make every product decision data-informed. The work was framed around practical architecture decisions, delivery ownership, and measurable business outcomes rather than advisory language alone.

How does this support Zyvor's software architecture consulting focus?

Analytics Intelligence Dashboard supports Zyvor's focus on B2B SaaS and AI software architecture consulting by connecting system design, technical leadership, scalability, and execution quality to a concrete project outcome: Product team fully data-driven. Day-30 retention improving from 42% toward 55% through data-informed feature changes. CTO reclaimed 8+ hours/week. 15 experiments completed with measurable outcomes

What kind of technical leadership problem does this represent?

It represents the point where delivery pressure, architecture ownership, and business expectations start converging. In work like Analytics Intelligence Dashboard, technical leadership is not only about writing code; it is about choosing the right sequence, reducing ambiguity, and giving the team a clearer execution model.

What should a founder or CTO notice in this project?

A founder or CTO should notice the link between the business problem and the technical system underneath it. The most important signal is not a tool choice by itself; it is how the architecture, implementation lanes, and operating model support a measurable business result.

Does this kind of work require a full rebuild?

Not always. The right engagement depends on where the risk sits. Some projects need a focused architecture reset, some need modernization, and some need new product development. Zyvor frames the work around the smallest practical path to stronger scalability, reliability, and delivery confidence.

engagement depth

More than a project screenshot: what the work proves.

The value of selected work is strongest when it shows the connection between architecture choices, business pressure, implementation quality, and leadership confidence.

Architecture decisions connected to commercial or operational pressure
Technical leadership that clarifies ownership and sequencing
Implementation work shaped around measurable delivery outcomes
Scalable execution patterns that remain useful after launch

Decision context

The product team was flying blind. Every feature decision was a bet with no way to measure the outcome. That business pressure shaped the architecture choices, implementation order, and operating model behind the work.

Delivery leverage

Full product instrumentation deployed in 2 weeks. 150+ distinct events tracked across all product surfaces. Event ingestion handling 2M+ events/day with sub-100ms capture latency This is the kind of delivery leverage Zyvor looks for: fewer bottlenecks, clearer ownership, and better execution rhythm.

Architecture handoff

The project covered AWS, Next.js, PostgreSQL, TypeScript, React while keeping the handoff focused on maintainability, future change, and leadership clarity instead of isolated implementation tasks.

Best-fit conversation

A similar engagement usually starts with the current bottleneck, the architecture decision that feels stuck, and the business risk that is becoming harder to ignore.

related services

Service paths connected to this project.

Performance OptimizationArchitecture Audit and Scaling RoadmapArchitecture and Technical Leadership
Contact ZyvorOur Services