How to Build a Product with 10 Customers and a Boring Tech Stack

In this interview, Saleh and Ted trace Gravity's origin to a phone call from a crowded hostel in Glasgow during COP26, and explain why they built the company's first version around a pilot program for just 10 customers rather than a broad launch. They discuss what they each learned from earlier ventures, Salesforce and Samsara for Saleh, ClearGraph's sale to Tableau for Ted, and why they believe a deliberately boring tech stack is what let a small engineering team ship code dozens of times a day.

Saleh (CEO of Gravity): Hi, my name is Saleh. I'm the CEO of Gravity, an industrial decarbonization platform. We help people manage their carbon and manage their energy.

Ted (Co-founder of Gravity): Gravity is tackling climate change in a scalable way, and then identify, plan and execute real world projects to reduce those things.

Saleh: Last year was our second year in existence, and we grew about four times. And this year we're on track to about three, three and a half x again, which is really exciting.

Saleh: In college, I started off by studying physics. I ended up graduating with a degree in computer science and mathematics. Computer science to me was the application of math in software, while physics was the application of math to the physical world, and I would say that was kind of the beginning of marrying atoms and bits for me.

So fresh out of college I went to a company called Salesforce. I landed as a software engineer there, on a team called the IoT Cloud. I fell in love with it, but my favorite times were when we were building prototypes and we actually had the physical products in our hands, and so I knew that I wanted to get closer to it.

 In leaving Salesforce, I looked to a company called Samsara, one of the most incredible sales machines and go-to-market machines, and I joined them to spearhead a product line they called Safety. Safety was expanding beyond fuel efficiency and GPS tracking and a number of other classic telematics offerings into dash cameras and safety monitoring.

In leaving Samsara, I joined an industrial venture capital firm called Eclipse, joined them as an entrepreneur in residence, incubating a number of different ideas. But the thesis that I really started to obsess over was one that centered around the groundswell in both actions and technologies that energy-intensive companies could take that were carbon-reducing but also incredibly aligned with competitive business metrics.

There was a lot of opportunity for them to take action that was aligned to climate. What really itched me, though, was that increasingly these entities were being pressured to disclose, or even lambasted for being carbon-intensive, by a lot of people who were eagerly pushing for the climate agenda. They had this incredible opportunity to participate and weren't doing so.

Ted: I had known Saleh socially for several years, he was always somebody that I had wanted to start a company with. And then in late 2021, he called me from a very crowded hostel in Glasgow, he was out there for COP26, the climate conference. He told me about how he had been an entrepreneur in residence at Eclipse Ventures, and at Eclipse he had been incubating a thesis about pragmatic decarbonization. He walked me through his thesis, and it was like getting struck with a bolt of lightning. I knew that if I didn't leave to pursue this opportunity with him, I would probably come to regret it.

I learned how to code when I was seven. Around my senior year of high school, I interned at a company called Ibotta, which is B2C, a consumer couponing application, and there were 20 people in the basement of a firehouse in Denver. That was the summer that Ibotta hit a million users, and it was just intoxicating seeing us build something, put it out there, and watch it grow in real time.

And then I went to college for a year, I actually dropped out of college after freshman year, I think because I had such a good experience at Ibotta. When my friend called me and said, hey, I want to drop out of Stanford and start an analytics company, I said, that sounds awesome. Both my parents are educators, and I remember talking to them and saying, hey, I have a once-in-a-lifetime opportunity to move to California and work on this company, and my mom said, you're 19, what do you know about once-in-a-lifetime opportunities, which I think is a very fair point.

The company that I joined after my freshman year of college was called ClearGraph. ClearGraph was an analytics company; we built a natural language search tool, kind of like Siri but for structured data. I worked at that company for several years and got an acquisition offer from Tableau, so we sold the company to Tableau in 2017, and then I stayed there for a couple of years. One thing I learned was that it's very important to niche down for a target customer.

At ClearGraph, I think one of the challenges we had was that the long term ambition was to make data accessible to all manner of business users who couldn't currently access it, but because of how broad that ambition was, we ended up building a product that was quite horizontal; it wasn't specialized in the ways that it needed to be specialized. Because it was trying to be everything to everybody, it ended up having a lot of trouble adding value whatsoever, and so if I could go back, I would have niched down earlier for ClearGraph.

We also learned a lot about the right way to build software at an early-stage company. We made some decisions that really slowed us down, like splitting the codebase into microservices and that sort of thing, and the learnings from ClearGraph definitely influenced the way that we operate engineering and product here at Gravity.

Saleh: Gravity was born out of a thesis that a lot of this growing pressure that energy or carbon-intensive companies were feeling to disclose or participate in a climate transition was rooted in software not being built to make that process easier, and business dots not being connected to make that more attractive. There's got to be some missing link. Rather than having an arm twist to pull these people into the climate transition, we could incentivize it, it could be attractive.

Ted: We help companies measure their carbon footprint and energy usage, and then identify, plan, and execute real-world projects to reduce those things. The actual math of carbon accounting is quite simple: you need to figure out all the things that a business does, and then you need to figure out how much carbon they emit, and then you multiply the quantities by the emission factors, and then you sum it up, and that's a carbon footprint.

But the art of building a good carbon accounting product actually has mostly to do with the inputs and the outputs: how do you get the right data in from the myriad sources throughout a business, throughout a business's supply chain, where it needs to come from, how do you output it and report it in the format that is useful, that lets a business accomplish its goals.

We built the first version of the product really fast, we were in the market within a month or two of getting going, we've been generating revenue from about that time as well, and I think that has done really well for us, because more important than the early revenue has been the feedback and the real world customer pain.

Saleh: Any product kind of goes through a few phases before it ends up becoming the actual costed and sold by many sales reps effort. The first one is selling on vision, and that is often to new hires; that's often to investors. The next one is really selling on a presentation, to an extent: you actually go to a buyer, and you share a slide deck of features, but you pitch them as existing, and you try to attach some sort of a cost to it. The pilot program was somewhere between those two.

We went to people and we said, for three months we will do X, in this case was help you submit a report to a requesting body, we'll come measure your emissions efficiently, we'll do it through the software powered experience, and we'll generate a report that you could share with either your shareholders, your largest customers, or if you're in a regulatory market, you could share it to a regulatory.

So the pilot program was minimally to find ten customers, which is what we wanted to do. We wanted them to be a mix of different organization sizes, and a mix of going directly to those industrials as well as some private equity firms, just to get a feel for the two-sided market that we were starting to see form.

During that time, to be honest, we had only a few lines of code and a lot of hypotheses, but in the spirit of if they come, we will build it. We wanted to be very reactive to the initial demands of these organizations. In real time, we were basically building software and answering the questions that they had around how to measure their scope one emissions or their scope two emissions, thinking about what integrations and what automations we wanted to actually build, completely informed by this first cohort.

Of course there's risk there: if you choose a cohort that's not representative of the rest of the market, you've built something tailored to them and no one else, but we tried to figure out the lowest common denominators that were highly useful. At the end of those three months, as was kind of communicated early on to those organizations, we said, you have the right to walk away, there's no commitment to purchase, or if you'd like to continue with us, here's a highly discounted early partner rate. We'd love to work with you.

And over 50% of that cohort converted. So the pilot program ended up being really impactful for us, we got revenue in the door within the first four months of our existence, which was astonishing, and we built a product rapidly in reaction to explicit customer feedback and had all these case studies that we could use to then evangelize not only to net new customers, but to sales reps who wanted to know that they were joining a company that was de-risked from a selling perspective. And so we started hiring and growing the team.

Ted: When hiring, I think it's really important to look for urgency, agency and customer obsession. The urgency and the agency are because you need people who can take a high level objective and relentlessly get after it and drive results double quick. The customer obsession is because you also need to pair that with a level of self-awareness or focus that lets you see when you're going down a rabbit hole and getting sucked into something that isn't actually going to be valuable to the user.

Asking people about the speed of execution is important; you want people to know where, when there's a problem, they act fast, and I think, to a degree, that can be learned; for some people, it's innate. Looking for times when people saw a problem on their own, or were very close to the customer and actually took a problem into their own hands, devised a solution, implemented it, and got it out the door, is important, and that is inherently a high-agency endeavor.

A good reason to start a company is if you fall in love with a problem or the people who have that problem. I think a big failure mode is getting attached to a specific solution too early. A lot of companies want to build something, but they don't want to solve something, and if you build something and it doesn't actually solve a problem, then your whole identity can crumble rather rapidly. So I think it's important to define your identity by a problem and not by a solution, especially when you're in the pre-traction days, hunting for the solution, especially the scalable solution, that you can bring to market.

I do think startups are a potent force for good. It is perpetually astounding how much can come from the work of a small, focused, motivated group of people. And as a founder, I think it's your job to create an environment where people know what their charter is, and then to drive a relentless tempo of execution so that you can capitalize on the vision.

Ted: As a startup you have to make so many decisions, you have to pick the right database, pick the right tech stack, build your software in a certain architecture, and the sheer number of choices presents a lot of surface area to get things wrong. But it's important to pick boring technology. Because as a startup you have so few resources, and you really can't afford to spend spare calories trying to pursue unknown return on investment.

Experimenting with powerful new databases, in my opinion, is a luxury for people who have more time and money to burn. It's important to pick well-established databases and keep it very simple so that you can spend your calories on the innovations that are actually meaningful.

At Gravity, for instance, we have a very boring tech stack. It's allowed a very small team of engineers to scale to a somewhat comical amount of data and to drive significant revenue. It does allow us to ship code dozens of times per day, and if problems come up, we can fix them in minutes, not hours. And if we want to build features, we can do it in a really predictable way, because we're never fighting tools; we're never breaking out of a prison of our own creation, which does sometimes happen.

I think of engineering as a skill set, but I think that engineering as a sense of identity can be limiting for individuals. As a startup, your job isn't to build software; your job is to build a product, and that product needs to be useful for people. The job is to make decisions that allow you to maximize the rate of change of your product, so that you can have the highest shot of building something useful.

So I would encourage software engineers to think of themselves as product people, where the way that they build product is by using software, and I think that's an important mindset shift, because a product person falls in love with the problem and the person who has the problem.

In that sense, almost every problem can be really interesting if you get in the weeds enough with it. Carbon accounting, somebody would reasonably call it dry and a little bit boring, but if you're really serious about solving the problem, and if you're really serious about building software to solve the problem, then of course you need to understand the problem and the way it's laid out, the terminology, the language, the people who have it, in order to begin to create solutions.

Saleh: I think, like many other companies in the climate space, our ultimate mission is accelerating decarbonization and the transition to a sustainable economy. But our particular contribution is to do so by succeeding in making action on climate extremely attractive to the most energy-intensive organizations: more attractive fiscally, more attractive from a labor perspective, and easier to comply with the growing needs from a regulatory perspective.