The Disassembly of the SaaS Stack

A fireside chat with Kashish Gupta at Hightouch

In the old world, every SaaS application would have to operate across the stack, from sophisticated data layer to sleek UI. But today, that stack is being disassembled. 

In this fireside chat, I spoke with Kashish Gupta, co-founder at Hightouch, which was profiled in Forbes today. We discussed how best-of-breed software is emerging in each layer of the stack. Hightouch has taken off in building one of those layers, offering a new way to pull data into applications -- often the biggest pain point in implementing software. In this way, Hightouch has removed a burden for data engineering teams in serving internal business teams, as well as for those teams' SaaS vendors, who currently invest considerably in enabling data intake. It's no exaggeration to say that this burden removal could lead to one of the biggest transformations in the SaaS ecosystem in a decade.


What is Hightouch?

Our goal is to get customer data in front of business users in a really easy way. Both of my co-founders Tejas and Josh worked at Segment early on, where they built products that got data from point A to point B. But people like to say that if Segment were built today, it would be built like Hightouch: on top of the data warehouse.

Right now we are laser-focused on enabling Data teams to use SQL to pull that data from the warehouse. But our company's mission is to get to the point where anyone in the company -- Sales, Marketing, and Customer Success people -- can access data regardless of their technical skill level and use it real-time in their workflows and decision-making.

We're building a category called Operational Analytics. 

I've also heard the term Reverse ETL. 

Reverse ETL describes what the product does right now. Usually people think of ETL as a way of getting all your data into your data warehouse. So naturally they started saying, the reverse of that is to get data out of the warehouse and back into your SaaS tools. But in naming our category, we wanted to describe how we fit into a company and what value we provide. 

You'd call Looker a BI tool. By contrast, we're analytics used for action. That's why we call it Operational Analytics.

What's the tailwind behind your business? 

The tailwind is definitely the rise of cloud-native warehouses such as Snowflake and BigQuery. Until recently you couldn't be sure that most companies would have the same way of centralizing data. There used to be all these SaaS vendors popping up saying, "We're the single source of truth." Salesforce wanted to be the single source of truth, as did a number of other applications.

Now that cloud data warehouses like Snowflake and BigQuery are becoming cost-effective and easy-to-access, it's really the right place to have a source of truth. That's why you see the majority of the Fortune 500 companies, as well as smaller companies, buying Snowflake and making it their source of truth. Everything else should be pulling data from that source.

Data warehouses greatly simplify and stabilize how the data can be accessed. You know what the data will look like. Previously you'd have to use your intuition to predict exactly what the event would be or when it's going to be triggered.

It used to be that every SaaS application would have three layers: (1) the data layer, (2) the operational analytics layer, and (3) the UI. But now, if I'm the CEO of a SaaS company, and I recognize that Snowflake should be layer #1 for my customers, should I think of you as lightening the load for me in terms of what I have to build in my product for layer #2?

Yes, all of these application providers are really interested in working with us as partners to solve for layer #2. One of the biggest problems they have is when the customer says, "How do I get data into the system?" Then the vendor usually responds, "We have an open API. You can get your developers to use our API and do all this manual work necessary in order to keep the data flow constant." That's usually a three- to six-month cycle for things like Salesforce. With our product, you can use SQL to easily pipe data into a SaaS app. So we decrease the implementation time and engineering load for buying a new SaaS tool. That's why SaaS companies really like us.

So if I'm the founder of a SaaS application, and I really believe in your vision of the way the world is going to evolve, I'd try to focus mostly on the UI layer. 

Right. Usually people say that workflows are where you can capture the most value, and charge the most, for your product.

What does this mean for companies like Zapier that have built their businesses integrating directly between different SaaS applications?

Those companies are actually here to stay. We're not replacing all their use cases. We're simply replacing the use cases where data is coming through the database. Zapier is great for "if-then" events between apps -- for example, if I want to trigger alerts in Slack based on meetings booked in Calendly, then I should use Zapier for that. In fact, we do internally. Zapier is really a visual layer for code.

In what ways do you need to educate your customers?

A lot of our customers are data engineers. They're used to a world where someone asks for data and the data engineer says, "I can build a python script for that." They get it done in-house. So we're often educating our customers about why they should use Hightouch rather than build in-house, and why long-term this should be a SQL-based interface rather than a one-time script that maps specific fields in their database to fields in their tool. 

The problem with the one-time script is that every time they want to add a new field, they have to update the script, and sometimes it breaks. Sometimes it's hard to know whether it's even working, and so you have to run logs on it. Then maybe the API changes. 

If you have a data engineer that writes the pipeline, they're bottlenecking anyone that wants to change that pipeline or add new pipelines. We're trying to focus teams on what's sustainable in the long-term.

We'd all like to say that we never have customer escalations, but obviously this is something that every founder has to handle. How do you respond when a customer escalates an issue? 

This is something we actually pride ourselves in. Every single one of our customers has a shared Slack channel. Slack has been great because we can basically live with our customers there. Our Engineers respond really quickly to customer messages. Even if a customer has a small question, they can ping us there. They also send us feature requests that are super helpful.

How are you thinking about the value that you're delivering to your customers and how you measure it? 

When we're selling to the data folks, it's usually a build vs. buy question. They're thinking, "How many engineering hours do I save by doing this?" and that's how they justify spending money on Hightouch. There's also the opportunity cost of data engineers spending time writing SQL queries -- they should instead be able to focus on their specialty, which is building sophisticated models in the data warehouse.

We also know that ultimately there's a ton of value to provide to the marketing, sales, and customer success people that are the end consumers of the data, because they're going to drive top-line growth by having better data. For example, marketers that have better data will run better campaign emails. Eventually, we'll be able to say, "Buy Hightouch and you'll make another $X a year." 


The Hightouch team is hiring! There are newly open roles across engineering, design, and growth. Reach out to the founders at if you're interested.

If you’d like to learn more about Hightouch's approach to enabling data teams, go to

If you'd like to hear from more founders like Kashish about once a week, sign up for my newsletter here: