paint-brush
Building Vertical SaaS in an Old School Industry: What NOT to Doby@shangyan
849 reads
849 reads

Building Vertical SaaS in an Old School Industry: What NOT to Do

by ShangyanOctober 29th, 2024
Read on Terminal Reader
Read this story w/o Javascript

Too Long; Didn't Read

Exited Series A Vertical SaaS founder talks about the pitfalls of building in an old school industry.
featured image - Building Vertical SaaS in an Old School Industry: What NOT to Do
Shangyan HackerNoon profile picture


When Butter was acquired by GrubMarket, it marked the end of one chapter and the start of another. As a founder, the journey was incredible—full of hard-earned, sometimes painful lessons along the way. Now, I want to share some of those insights, so you can hopefully sidestep a few of the hurdles we hit in building your next startup.

Our Origin Story

When the pandemic hit in 2020, my cofounder and I launched Butter, recognizing an untapped opportunity in the food industry. Lockdowns were pushing businesses to adopt digital solutions – softwares like Toast, DoorDash, and Shopify were seeing explosive growth – and we believed the food supply chain tech stack was ripe for disruption with COVID’s digital tailwind.


Two major problems stood out:


  1. Chefs were still ordering ingredients the old-fashioned way—using a clipboard, paper order guides, and calling up or texting their suppliers. After all that, they often had no idea what would actually show up in their kitchens until the next morning. Imagine the daily stress of worrying about whether you can actually serve that ribeye or cioppino on your menu!


  2. Wholesalers, the chefs' vendors, were even worse off without modern tech. They were using tech straight out of the 1990s: manual order entry from texts or voicemails, outdated DOS ERP systems, and tracking inventory counts in Excel spreadsheets. Payments were still handled mostly through paper checks! Just entering customer orders into their systems could eat up six hours of their day — time that could be spent growing their businesses.

Orders are often hand-written with cryptic product names.


We spent a few months shadowing suppliers’ workflows at 3am, and thought we had the answer. Our plan essentially consisted of 3 components:

  1. Modernize their outdated systems with an all-in-one cloud ERP that could capture core workflows and serve as their “system of record” – giving us extremely high stickiness and engagement;


  2. Integrate financial services like payments, lending, payroll, etc. to drastically increase a customer’s ACV (a16z famously featured an article about the new wave of financial service-empowered vertical SaaS back in 2020, so we felt confident);


  3. Introduce a seamless communication process for both chefs and wholesalers, with a DoorDash-like app for ordering that would pull more vendors to join the platform, creating a flywheel network growth effect (I’d be lying to say we weren’t influenced by Choco, another ordering app’s meteoric rise to unicorn status);


Example ERP system (some info redacted) of one of our first customers – a fish purveyor selling to some of the top Michelin star restaurants. They were still using a bespoke 1980s DOS software that’s no longer maintained.


It seemed like a no-brainer. But we were wrong—really wrong.

Pitfall 1: Engineering Complexity & Customization

We figured building a modern ERP would be easy. The old systems were obviously out-of-date — how hard could it be to build something superior? We demoed the prototype to a few local customers and received trial interests, so decided to hit the gas on building. The next phase, however, turned out to be an immense struggle.


While we knocked out some of customers’ technical problems, like eliminating the risk of local server failures, the demands of the industry were much more varied than we'd realized. Every supplier prospect had specific requirements to actually go live: custom keyboard shortcuts for every action, exact column layouts on data entry screens, unique formats for invoices and warehouse printouts, and even the details to display for shellfish traceability tags.


Each customization turned into a black hole for engineering resources. What we thought would be a streamlined solution became a highly tailored product that needed constant tweaks and dev cycles to meet each client’s needs and secure that next incremental deal close. Our engineering budget ballooned as we tried to keep up. The wedge we had hoped for turned out to be a ginormous beast. It wasn't going to scale.


(Aside: I recently saw YC’s RFSfor new ERP softwares – please: really, really think it through if you want to jump down that rabbit hole.)

Pitfall 2: The Long Sales Cycle

Switching an ERP system isn't like upgrading your phone’s software — it’s more like open-heart surgery, where there's a living, breathing operation whose every facet you’ll impact, from warehouse, procurement, to accounting, and sales departments. Customer prospects hesitated because they knew how disruptive the process could be. Many put off the decision for as long as possible, even though their current systems were clearly costing them time & money. Even when owners (often the main economic buyer) wanted to switch, the complex workflow involved means that they needed every department’s comfort and buy-in, severely prolonging the process.


Perhaps also due to the old-school workflows, most of the food distributors / wholesalers we targeted could barely keep their heads above water, let alone actively shop for new softwares. This is especially bad during restaurants’ (their end customers’) busy seasons, essentially limiting our golden sales window to only early spring & the middle of fall.


This long sales and adoption cycle was a killer for us. Even though we offered a clear improvement, getting businesses to take the plunge was always an uphill battle — especially when it involved their core operations. Even towards the end, our deal close rate was 1/5-1/3 of our model target. Too many works-in-progress, too few done deals.

Pitfall 3: Low Willingness to Pay / Long Revenue Activation Period

The biggest shock came with pricing. Many of these businesses had razor-thin margins — often as low as 5%, if that. For the vast majority of them, only revenue comes top of mind – offering them anything but usually is a tough pitch. They were used to paying $80 a month for QuickBooks, and getting them to pay for a full-scale ERP upgrade at a rate that justified our development costs was a huge challenge.


We expected the fintech & ordering app components to greatly expand each customer’s ACV beyond traditional SaaS subscription, and they did…only on paper.


In reality, activating the payment / app usage revenue also took exceedingly long – on top of the already long ERP sales cycle detailed above. On both the payment and e-commerce app fronts, adoption ended up hinging more on end restaurant / retailer customers’ preference, which is also old-school. Vendors didn’t want to force customers onto credit card payment, and many customers still stubbornly preferred calling/texting to order because of the (arguably false) sense of security they’d be better taken care of that way.

End result: it usually took 2-3 months’ of hard push to get to 20%-30% of target adoption & added revenue. That’s simply too much effort for too little revenue.


Pitfall 4: Too Many Bets at Once

Finally, we as an organization also suffered from having too many simultaneous bets at once.


I will skip some details here as this article is meant to highlight the key problems encountered and lessons learned, not to recount step-by-step all the experiments we’ve tried throughout the journey. Suffice it to say that we didn’t succeed in finding a true wedge before also attempting to unlock additional revenue streams and flywheel network effects. We were fighting a large-scale campaign on 3 fronts, when we should have stayed in guerrilla warfare mode to secure a single major win.


This execution problem meant that we couldn’t rapidly test out hypotheses iteratively, and the team started to burn out. There were still several what-ifs to test by the time the acquisition offer came along, like moving up the food supply chain where better business margins may yield higher ACVs, or scaling the go-to-market motion for our new lightweight AI-powered wedge products, but after almost 4 years of building, we decided to take our products & tech to someone with an already established distribution channel.


Lessons We Learned the Hard Way

Don’t get me wrong – the team and I did many things I was proud of: getting up at 2am and literally sleeping in warehouses for weeks on end to ensure successful onboarding, building a highly complex while also intuitive software loved by customers, developing a rigorous implementation playbook, and the list goes on. In the grand scheme of things, however, we fell short of building a venture business that actually scaled.


Our experience taught us one big lesson: Don’t jump into an idea based on high-level theses alone. Listen to what the people on the ground, in the warehouse, and the back-of-house have to say – talk to people for the sake of truth-seeking, not reaffirming preconceived ideas.


To build a successful product, especially in old-school industries, you need these things:


  1. **People who care deeply about the problem.**If the pain of staying the same doesn’t outweigh the friction of change, no one will bother switching systems, no matter how great your product or how grand your vision is. Inertia is powerful, but change only needs a few catalysts.

  2. **Deep enough pockets.**If your customers can’t afford the solution, all the value you bring won’t make up for your bottom line.

  3. A 10x better product experience than what they already have. The more traditional your customers are, the more drastic the improvement needs to be. Tackle the hardest problems in their world because there's a reason they've stuck around for so long.


  4. Simplicity is king. Your initial wedge product should be extremely simple to adopt and cover a single foundational customer unit. Are you selling a fancy Japanese bidet, or replacing their entire plumbing?


Some more nuanced notes: I’m not saying your startup will fail without all of the above criteria, but their presence together usually means a clear winning path.


To elaborate, in order to be a successful SaaS startup, the size of deals must be commensurate with the time required to close them. In his article “The Difficulty Ratio,” David Sacks introduced the deal size/cycle time quadrant to help clearly visualize the relationship. I highly encourage you to read it in its entirety, but the TL;DR is either high ACV / low deal velocity or vice versa may be okay, but both being low spells the death of your company.

Source: Substack


Back to the 4 criteria above – if your target customers don’t have deep enough pockets but you have a crisp wedge product with a short sales + onboarding cycle, then you may win in the SMB category with fast deal velocity. If, on the flip side, your product is complex yet delivers distinct value propositions that customers are willing to pay a premium for, you may secure substantial deals in the enterprise quadrant.


In the case of Butter, however, we unfortunately fell into the slow deal velocity + low ACV death quadrant (to be precise, the ACV wasn’t terribly low given the additional revenue streams, but the deal velocity with the full revenue activation timeline wasn’t just slow – it was snail-paced).


Final Thought

In hindsight, we underestimated the complexity of building a vertical SaaS in a space that relies on deeply ingrained practices and outdated tech. We thought that offering a digital solution would be enough to spark adoption. Instead, we learned you need to prove your product can deliver major improvements on what they already have, in the ways that they understand, to meet their needs — because if it doesn’t immediately stand out as a good fit, they’ll stick to what they know.


Stay tuned for Part 2, where I’ll dive into how AI is opening up new opportunities which do work in these old school spaces, and how we’re using it to solve dead ends.