The workflow before#
Betterworks sells OKR and performance management software, and it was moving upmarket. Its larger customers wanted real-time analytics inside the app: goal progress, team trends and dashboards that held up with thousands of people using them. The data stack underneath was custom-built on AWS. Every new source meant weeks of pipeline code, queries slowed as customer data grew, and engineers spent a large share of their time keeping pipelines alive instead of shipping features. Adding a data source took about 2 weeks. A new pipeline took about 3, and a new analytics feature about 8. The original plan was to keep building, which meant more months of the same work before enterprise customers saw anything new.
What we built#
We moved Betterworks from building data infrastructure to buying it. Instead of writing and maintaining custom pipelines, the team now runs on managed tools that do the plumbing, and its engineers spend their time on the analytics customers see. We kept the work that makes Betterworks different, the metrics and the in-app experience, and handed off the rest.
Managed loading instead of custom code
Fivetran now loads source data into Snowflake with managed connectors that handle schema changes on their own. A new source is a configuration, not a project. We chose to buy here because pipeline code was the part of the stack that gave Betterworks no advantage and cost it the most engineering time.
One definition for every metric
dbt builds the analytics models inside Snowflake, and Looker's semantic layer defines each metric once. The same definitions drive internal reporting and the dashboards customers see. We used one layer for both on purpose: when a customer's goal completion rate matches what Betterworks' own team sees, nobody has to explain the difference.
Analytics inside the Betterworks app
Looker's embedded analytics power the customer-facing dashboards in the app. Product managers can add a new view in weeks instead of months, and enterprise customers get analytics that keep up as their data grows.
A workspace ready for prediction
We stood up an Azure Machine Learning workspace connected to Snowflake, with a feature store and a deployment pipeline. It's ready for models that predict which goals are at risk and which customers need attention. Features come from the same modeled data as the dashboards, so a prediction and a chart never disagree about the facts.
How we delivered it
The engagement ran 24 weeks in three phases. We set up ingestion and moved about 5TB of historical data first, then built the Snowflake models and Looker semantic layer, then stood up the ML workspace and tested performance under simulated enterprise workloads. Knowledge transfer sessions ran throughout, so Betterworks' engineers could run and extend the stack on their own after launch.
Before and after#
| Measure | Before | After |
|---|---|---|
| Add a new data source | 2 weeks | 1 day |
| Build a new pipeline | 3 weeks | 5 days |
| Analytics feature delivery | 8 weeks | 3 weeks |
| Engineering time on data maintenance | Baseline | 50% less |
What's next#
Customer data is now modeled in one Snowflake warehouse with an ML workspace attached. The next step is putting predictions in front of customers inside the app, starting with which goals are at risk of slipping, so managers can step in while there's still time to change the outcome.
