How Courier Uses Propel To Build And Scale Their Customer-Facing Analytics
Courier is a SaaS startup that helps development teams manage all product-triggered communications (email, chat, in-app, SMS, push, etc.) in one place.
Seth Carney is CTO at Courier. He manages a growing engineering team and helps support the Courier platform. Seth is responsible for providing value to Courier’s customers and setting the vision for the engineering team, including any build versus buy decisions.
Courier CTO’s Top Goals
Hiring and Org Design: ensure that the engineering team is structured in a way that best serves the organization to get things done quickly.
Infrastructure Design: Stay ahead of the customer curve and continue to make the right infrastructure shifts so that we’re able to support even our largest customers.
Platform-related costs, system uptime and the ability to build faster were always top of mind for Courier’s engineering team. They knew that large infrastructure projects like building customer-facing analytics could dramatically improve Courier’s platform profitability and delight their customers, but there are usually high engineering costs associated with these types of products. Customer-facing analytics is operationally intense to build, support and scale.
“Our analytics footprint wasn’t as deep as we wanted. Other stuff to build was more important. Customer-facing analytics was on the roadmap, but it was always perpetually two quarters out,” Seth mentioned. “I’ve had to own [customer-facing analytics] in the past, and it’s not cheap. If you were to build what Propel gives you…you’d need a data team, an engineering team, you’d need to build and implement the UI, caching, performance optimizations, and maintenance of the data. It adds up.”
Besides the build piece, it’s also really expensive to continually query Snowflake for the concurrency needed for a customer-facing product. This time around Seth was looking for a better approach.
Courier decided to partner with Propel to build out their customer-facing analytics without hiring more people. They briefly explored embedded analytics tools but quickly realized those solutions weren’t compatible with what they were looking for - a fully native look and feel and performance at scale. More than just building pretty dashboards, Propel powers your entire customer-facing analytics infrastructure with a unified API platform.
And it was easy to get up and running. Courier created their initial analytics dashboard wireframe, connected their data source (Snowflake) to Propel, defined their metrics, iterated on the visualizations that they wanted, queried the GraphQL API and the dashboard updated in milliseconds.
“I was able to carve out a sprint or two and get something out the door with my existing folks. We did an afternoon POC and in a couple hours everything was up, with just one engineer and one data guy,” explained Seth.
Courier already had their data in Snowflake, and Propel unlocked the ability to use that data externally by providing caching, security, and an API layer on top of the data warehouse.
Courier realized it was better to buy versus build it themselves and finally stopped kicking the customer-facing analytics can down the road. Seth was able to effectively deploy his existing team members to build out the analytics in just a couple of sprints.
Build Without Hiring More People
Seth already had experience building out customer-facing analytics at a previous company and knew he needed a better approach this time. Even if they needed to bring on the minimum amount of people to build out the analytics (e.g. one data and one engineering team member) that’s still two employees to hire and manage but not sufficient to cover an on-call rotation in the long term. Instead, they were able to build analytics into their product with their existing front-end engineering team and without any backend dependencies or new infrastructure to manage.
Based on his experience, Seth knew that it was better to buy versus build because building in-house is operationally intense and hard to support and scale. In addition, he realized that an API-first approach would not only empower his product dev teams to build without data team dependencies, but also build a fully custom look and feel that is native to their product. They briefly explored buying embedded analytics tools but quickly realized that embedded dashboards (and BI tools) are just a band-aid and painfully inadequate. More than just building pretty dashboards, Courier was looking to power their entire customer-facing analytics infrastructure with a unified API and deploy fast experiences without data engineering.
Build For Scale
Now that their customer-facing dashboards and analytics foundation is up and running, Courier has more analytics use cases (e.g. in-product metrics, data sharing, and email reporting) on this year’s roadmap. Their data and insights will grow over time, but the team and infrastructure to support it doesn’t have to.