The Origin Story of an $800 Million Fuel Card Business

Vignan Velivela grew up in a small town in India, and now he's the CEO of a company on Forbes' Next Billion-Dollar Startups list.

I love his story:

He grows up in an area with poor schools, so he spends all of his time in libraries teaching himself about science and technology.

Right out of college, he builds a lending platform in India that enforces digital contracts and payments.

It doesn't work out, but he learns a lot, so he tries again.

This time, he builds a marketplace for buses. Gets accepted into Y Combinator, starts talking to customers, and then boom, COVID hits.

So he's back to the drawing board.

He goes to several truck stops to talk to drivers, and learns about their biggest problem: payments were broken. Fuel prices were volatile, and truckers were using fuel card networks from the 1960s. Drivers had no spending controls, no pricing insight, and no way to manage their number one cost.

Vignan thinks, "we can build a better network and do it on a more modern infrastructure."

So that's what he does. His team crushes go-to-market and early customer sales. They take the transportation payments industry by storm.

And people notice:

A managing partner at General Catalyst said AtoB is “one of the fastest-growing businesses we are involved in. Their go-to-market model and the way they have scaled is stunning. It’s hard to acquire that many customers that fast.”

I had a great conversation with Vignan, and I'm excited to share it with you. We talk about:

• How Vignan's early years shaped his later years, which ultimately led to the founding of AtoB.

• Why Vignan had a customer support rep join every engineering meeting in the early days.

• Why you don't need five different value propositions to become a billion dollar company (two is plenty).

• Why you should constantly talk to your customers and use their insights to inform your next pivot.

• How AtoB's culture of memos over meetings forces people to think clearly and actually articulate problems.

If you're an early-stage founder, or you're thinking about starting a company yourself, you don't want to miss our conversation.

You can watch it on our YouTube channel, or you can read it below.

Enjoy.

Tell me about your early life.

I grew up in a small town in the southern part of India called Hyderabad. I spent a lot of time in public libraries because my town didn't have a good school. I learned a lot from encyclopedias, which really opened me up to the world of science and technology. I was really fascinated by engineering, which is ultimately why I ended up pursuing a formal education and career in the field.

After I graduated from college, I wanted to work on something that would be useful and important to a lot of people. My friends and I looked for problems to solve, and we ended up starting a payments company. India has this interesting problem where a lot of people have smartphones, but they might not have a bank account. And this is especially true in the case of rural, poor areas and in urban areas below the poverty line.

So we built a payment product that was smartphone-first, had a digital identity element to it, and effectively bridged some of the gaps that traditional banks could not solve. During this time, we learned a lot about how to build a company and how not to build a company. We made a few, classic, first-time founder mistakes like: obsessing over the product and not focusing enough on distribution. But we self-corrected over time as we realized that both go hand in hand. Ultimately, this first venture of mine didn't end up being much of a success.

What sparked your interest in the transportation industry?

After my first venture fizzled out, I chose to start again. One of the areas that I was interested in was transportation. And this was way back in mid-2010 when Tesla wasn't very popular; especially in a country like India where the average cost of a car was probably a few thousand dollars, most people did not believe in electric cars, and autonomy was a far sighted idea.

I ended up going to graduate school at Carnegie Mellon to study computer science and robotics. The particular lab I worked in during graduate school was known for producing several of the self-driving startups that you see in San Francisco today like: Aurora, Waymo, Argo, and Cruise. I learned quite a bit about self driving cars during that experience. And I actually worked for Cruise briefly, during which I learned some of the basics of the transportation business.

Tell me about the origin story of AtoB.

When we first started out, we wanted to make transportation and commuting more efficient and convenient. I grew up in Asia, and one of the inefficiencies I saw was how much time people were spending on their daily commutes. Some people were traveling two to three hours to work every day and commuting anywhere from fifty to one hundred miles. And that inefficiency wasn't just unique to Asia (or the Bay Area)–roughly one third of people in the U.S. were considered long distance commuters.

So we asked ourselves, what can we build to solve this? We saw a gap in the market: Uber and Lyft weren't focused on the long distance commuters because most of their rides were conducted in under thirty minutes or within a ten mile radius. That was the zone in which most of their rides were profitable. Nobody was booking 50 mile trips because they were prohibitively expensive. So we thought this was an interesting problem to address.

Similar to how Google and Facebook offered commuter shuttles to their Bay Area employees, we wanted to see if we could build a better version of that for small businesses. We spent a lot of time talking to riders at various Caltrain and Bart stations (two public transit systems in the Bay Area). And the one thing we realized was that most people were not happy with the options they had. They wanted a better alternative.

But it wasn't going to happen unless someone built a marketplace. Because unless you're the size of Google or Facebook and have a critical mass of 10,000 plus people, you can't run a shuttle network profitably or efficiently. So we built one. And that was what we started out as–a simple marketplace for buses. But unfortunately, that chapter of our life was cut short due to COVID.

What was the thinking behind your pivot from a marketplace for buses to more of a Stripe for transportation?

I think the most important factor in the decision to pivot came from learning about the pain points of our customers. While we operated the bus network, we spent half of our time talking to commuters and getting them onto our buses, and the other half of our time on operational things, like paying for the bus operators and making sure the buses were being tracked correctly.

One of the things that was surprising to us was how cumbersome and manual the orchestration process was for the bus operators. Most of them had a few million dollars to tens of million dollars in revenue, but they primarily ran on paper. So whether it was the payments or the day-to-day operations, there was no real vertical software that existed in that industry.

And once COVID hit, nobody was taking our buses. So we had to go back to the drawing board. One of the key problems we sought to understand was why the payment infrastructure was so fundamentally broken in the transportation industry. So we went to several truck stops all over California and talked to truck drivers and small business owners who operated the trucks.

And the big problem we discovered was how broken payments were. Business to business payments were broken. Payroll was broken. How truck drivers were paid was broken (paper checks). All of these recurring themes helped us realize that there were multiple use cases for a payments' solution in the trucking space.

Why did the transportation space need its own payment solution?

So originally, we thought American Express or modern payment companies like Stripe could solve these problems, because they aren't unique to the trucking space. But what we realized about transportation–particularly trucking–was that the level of data required for each of transaction was significantly higher and more granular than the average business transaction.

So, for example, truck drivers are often paid on a mileage basis. They're not paid an hourly rate or a fixed salary. So you can't really pay them with generic payroll software. We found that most trucking companies just used an Excel sheet to log all the miles driven each week or month. And then they would write a check after a couple of weeks.

We only understood this problem once we realized that most truck drivers were making between $60,000 to $150,000 per year, but they would often run out of money–especially on long haul trips. So we asked ourselves, how is this still acceptable? Because truck driving is one of the most popular professions in the US, especially if you look at the major states like Texas or California.

So we decided this was a solvable problem, and we set out to build a vertical focused solution to fix it. Then we set out to explore what data we should gather and what systems we should integrate with. Ultimately, it was a problem of plumbing– figuring out the right pipes to connect to make sure that money was flowing correctly.

What was unique about the payment solution you decided to build?

Trucking is a huge industry. It's close to a trillion dollar market in the US and Canada, and the industry as a whole has several problems, particularly when it comes to payments and access to capital. And that's actually where we saw an opportunity–we started with a narrow use case and offered a fuel card.

Every time we spoke to a small business owner, they would constantly complain about two problems. The first had to do with the variability in the price of fuel. These businesses would have rather fixed revenues–they'd quote fixed loads–but then their number one cost, fuel, was too hard to predict. And it varied based on how their drivers performed. The second problem had to do with driver-hiring and retention.

We learned that the first problem could be solved with modern payment sales, because trucking is the only industry that runs on a dedicated, closed loop network. Outside of Visa and Mastercard, the trucking industry ran on antiquated payment systems called "fuel card networks." And some of these networks were built in the 1960s, which was way before the internet or the Visa card network.

So truck drivers were spending thousands of dollars on fuel without any real spending controls (like you have in a traditional Visa card network). And these custom built "fuel card networks" offered more control and more insight. We figured we could build a much better network than anybody else and do it on a modern infrastructure. So that's what we did.

How did you bring your product to market and get your first customers?

It was a fairly iterative process. We talked to a lot of truckers on the phone. We sought to understand all of the different things that they did on a daily basis–like what radio channels they used and what places they stopped at for breaks. We realized that most of them were receptive to our calls and welcomed the chance to learn about a new product over the phone. And that made sense because the trucking industry still ran on phone calls–that was how they booked loads or coordinated delivery.

So once we started talking to them, they wouldn't waste time asking about what a fuel card was–they were all familiar with the product–they would ask us instead about how we're different or better than the incumbents.

So over time, as we've differentiated our offering, we've built a fairly fast and efficient payment processing system. We help our customers do everything from paying a truck driver to paying for fuel, and we help them do it in an instant (24x7). And our offering is unparalleled in the trucking industry, because other solutions take an average of three to four business days to transfer money or make payments.

So we really bet on two axes: speed and cost. We realized that you don't need five different value propositions. You just have to be the fastest payment provider and save your customers money. It was similar to how Amazon built its business: at any given time, they really excelled in at least two out of the three axes (between speed, cost, and choice).

So we spent most of our product and engineering cycles optimizing for those two axes, speed and cost.

What's unique about how your team works internally?

It all comes down to how we think about problems. We try to talk to users as often as possible–before we write a line of code or build a new product. We listen to pain points that our users describe without asking them to prescribe any solutions. We've been doing this since our early days when we were trying to figure out what to build.

And here's why: unless there's a recurring set of persistent problems across your user base, it's easy to just fool yourself into thinking that your product is actually relevant. We want to make sure that we're staying close to user feedback, especially as we scale the business.

In our early days, we always had a customer support rep present in every engineering meeting, so the rep could share customer complaints and feedback with the entire engineering team. And even today, we still share customer feedback across the team: every other week, we have joint customer check ins where the entire company listens to customer support calls. Because a lot of times, information gets siloed and the people building the product get disconnected from the people using the product.

Payments are really a supply chain between multiple parties–banks, processors, networks, merchants, and points of sale–and any one of them could go wrong at any point. So at the end of the day, we want to build enough redundancy in every step to make sure that our users have the best product experience and that we're able to have the highest customer satisfaction ratings in the industry.

Right now, we're just two years out from our original launch and we're the fastest growing payments product in the industry. Our success is just the end result of the process we followed, which is just to be close to the customer.

What's been the biggest challenge with hybrid work?

How much time we spend on open ended problems. A good middle ground for us is to force ourselves to have a written culture, which means that we make sure most communication is happening in memos rather than in meetings or Slack. I firmly believe that writing forces you to think clearly and actually articulate the problem. So by building a written culture, we've been much more effective.

One quick example of this: we were working with a large bank and for whatever reason, they liked to have long meetings with twelve people present in every conversation. But in those meetings, nobody was really giving much input and things never seemed to progress. After a month or two of this, we stopped all meetings and just forced ourselves to write down the specs of everything we needed.

This helped us cut down on a lot of the unnecessary back and forth and move things along in an asynchronous fashion. We ended up completing the technical project in under a quarter, which would have taken us over two quarters to do if we had kept with the meeting-first approach.

What advice do you have for other founders?

There is no perfect process. The best thing you can do is to get customer insights as quickly as possible. You have to talk to customers often.

Paul Graham wrote this great essay called, Do Things That Don't Scale. For us, going to truck stops and talking to truckers was doing things that didn't scale. These conversations helped us learn what happened on the front lines of the industry. There's no real replacement for talking to customers.

And after talking to customers in the field, we became much more empathetic towards what they were going through on a daily basis and how they interacted with our product. I strongly encourage other founders to also try and do that.

Also, in the early stages, there's definitely a lot of setbacks and shortcomings, so you just have to pick yourself up and continue to iterate. It is doable.

And at the end of the day, pre-Product Market Fit and post-Product Market Fit are equally hard. Pre-Product Market Fit, it feels like you're basically pushing a boulder uphill. Post-Product Market Fit, it feels like you're running away from a boulder going downhill. It's not easy going either way. So the key there is to just enjoy the process and continue to jam.

Next Week on The Big Bet: Hari Raghavan, CEO of AbstractOps

Hari Raghavan is the CEO and founding team member of AbstractOps, an automated, back-office operating system for startups.

Prior to founding AbstractOps, Hari was employee #1 and COO at Forge, formerly known as Equidate. During his time at Equidate, Hari helped the business 100x and enter a period of hyper growth that lasted for over three years.

Hari is also an active angel investor. He's invested in over 100 early stage startups, with notable investments in Notion, Mercury, Rippling, and On Deck.

Armed with a wealth of early stage operating experience, a track record for growing companies, and a penchant for early stage investing, Hari is THE domain expert when it comes to early stage startups.

You’ll get my full conversation with Hari next Thursday.