"..if you’re raising in 2024” ⏩
181 investor meetings, scaling with the user-buyer-developer persona, and deciding on experience over potential.
Welcome to the 88th edition of The SaaS Baton.
A fortnightly newsletter that brings you hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay (curated with 💛 at Chargebee for Startups) and the interwebz. So, stay tuned!
And thanks so much for reading across 2023! 🌼
In this edition, you’ll find the following instructive and inspiring pickings:
#1: Vimcal’s co-founder and CEO, John Li, lists “crucial things” that helped them raise a round (while getting rejected, ghosted, and bad-actored) in a market that has seen seven straight quarters of trouble.
#2: Twilio’s co-founder and CEO, Jeff Lawson, having been steeped in solving for the (then overlooked) developer segment for 15 years, describes the three foundational sources of solutions (both common and rare) that have historically worked for this category.
#3: Recast’s co-founder and CEO, Michael Kaminsky, talks about how the aims of accomplishing a highly autonomous, remote-first culture led them towards incredibly experienced hires and how they’ve approached bringing them in as a startup.
Finding these discerning founder takes valuable? Please consider sharing this edition with an ever-curious teammate or a much-cherished SaaS friend. 🙂 New readers can sign up here.
🗞 Recently on Relay:
➡️ Heuristics and Hunches (December 8th) — “One of Our First Engineers Had Been Working in Tech for 30 Years” and Other Notes on Deliberately Hiring Senior People Early with Recast’s Co-Founder, Michael Kaminsky
— Why Recast has hired senior people from day one
— How it’s easier to evaluate experience over potential
— How this hiring choice was tough yet (always) viable
➡️ Heuristics and Hunches (December 15th) — Solving a Truly Universal Problem, Competing with Software Built in The 80s, SMB Notes from Xero, and Other Observations with Tallyfor’s Co-Founders, Peter and Ben Wen
— Situating a product’s universal premise
— Building against (and with) decades-old competitors
— Selling cloud infra and tax software
— Finding an elegant price and why churn isn’t a problem (yet)
— Hiring and onboarding as experts and beginners
#1: “…if you’re raising in 2024” ⏩
(From: Vimcal’s John Li) (Source: LinkedIn)
It took 11 months and 181 investor meetings to raise Vimcal’s last round.
Fundraising at the bottom of the market... really sucked.
Here are 5 crucial things to know if you're raising in 2024:
First off, some stats:
- Round: Series Seed
- Duration: 11 months (Dec-June angels only, June-Oct funds only)
- Total convos: 181 (108 VCs, 73 angels)
- Total Rejections: 146
- Ghosted: 14x
- Bad actors: 2
- VC offers: 7
1) PROOF of traction >>> everything else
Your best bet to getting funding is to have explosive growth for the last 3 months.
Regardless what VC Twitter tells you about prioritizing profitability, the ugly truth is that most don't care about it until you're inside their portfolio.
I highlighted our high retention, frugality, & $0 CAC.
They respected all these aspects but their eyes rarely lit up.
What made the biggest impact was launching a frenzy of features and campaigns in the months leading up to and during the fundraise, which gave us 3 of our best months of revenue growth and enterprise logo acquisition.
Boost your growth #'s — all else is secondary.
2) Articulate a clear path to $10B
VCs have become more diligent about only investing in venture-sized outcomes.
That means even if they love you, they'll pass if they think you can only get to $100M.
By far the #1 reason we got passed on at the beginning was that investors didn't see a calendar company becoming a unicorn.
Calendly is the only exception and the biggest prior exit was Sunrise at $100M.
Certain products just ‘seem’ to have a natural upper limit.
This made me realize I had to be very explicit that @vimcal isn't and never was, a calendar company.
We're a ‘meetings’ company — calendar being just a beachhead.
What other unicorns have a team scheduling product? Salesforce, HubSpot, Zoom.
Convos were noticeably different after.
3) Have a firm stance on AI
You'll get asked in every meeting how AI will affect your industry and how you're using it.
Say something unique — this is your chance to show off your expertise by teaching them something new.
4) Raising from angels will take much longer
When I last raised in 2021, the avg angel check size was $25K-$50K.
This meant you could put together a decent early round with just a handful of ppl.
This time around, most were only investing $1K-$10K due to illiquidity.
If you keep collecting $5K checks, you'll be fundraising until 2030.
This shouldn't stop you from trying as having awesome angels onboard is great, but just know it'll take longer and a higher % will need to come from funds.
5) References are more important than ever
On multiple occasions, I found out from another founder that their investor (who I loved meeting) did something shady when their company was in a vulnerable spot
Bad times reveal people's true characters so do your homework
Related Relay reading:
John on how onboarding users manually saved Vimcal (“To summon up a specific, stressful memory from that time: We were in touch with our lawyer, asking them about the prerequisites for shutting down, including how much money we had to put aside for legal fees.”)
#2: Three developer-focused SaaS models 📐
(From: Twilio’s Jeff Lawson) (Source: World of DaaS)
One of the early insights that we had along with AWS, Stripe, and a few others, was that developers would become a buying center and I remember trying to raise money — unsuccessfully — in 2008.
Two pieces of feedback I got. One, there was a financial crisis going on in 2008. Number two, things that were in my control was, ‘developers aren’t a market, they don’t have budget, they can’t make buying decisions.’
So investors were like: ‘go build an app that you can go sell to someone who’s got budget, if you want to add an API to it later, have fun, go for it, but you need to go find a buying centre.’
That was the conventional wisdom of software go-to-market.
….
If you look at the number of developer-focused companies, I think the ones that have achieved revenue scale, like real revenue scale. They’re one of three business models.
1)
Business development as a service. If a developer in the previous world was not empowered by their organisation to go cut a deal with a carrier, because those deals were complicated. They take time, there’s revenue commitments.
A developer would not have been empowered to go cut a deal with a carrier. Or open a bank account on behalf of the company. The developer just didn’t have the power, or the skillset, or the desire to do those things.
But now suddenly they can sign up for Twilio and get the result of having done business development i.e text message to a user…You empowered the role of the developer to establish a business relationship that they wouldn’t have been able to do otherwise.
2)
The second thing that does this that has a similar effect is opex as a service. Take something that used to be a capex and turn it into an opex. The data centre. Or telecom hardware. Things like that.
Again, you’re taking something that used to be a large expenditure of a company but it was a capex and you’ve turned it into an opex and now developers can actually buy it….
It’s gotta be well below the spending threshold for it to actually work. With Twilio, a developer can sign up on their credit card and build a prototype with a couple of dollars. That’s something that would have been again been 100s of thousands of dollars in the old world, now it’s just a few dollars.
3)
The third is arguably the hardest to do. I would say the rarest. Essentially an algorithm as a service. Some kind of algorithm that is so hard, so complicated that the developer can’t really replicate it themselves easily or even get it in terms of open source.
If you look at that category, Amazon DynamoDB or Google BigQuery, running a scaled data warehouse that can accept terabytes and terabytes of data, that is just really hard to build. Or now you look at it, you’d say large language models.
Something like that. Building language models, obviously. But even running them at scale. That is a set of algorithms that is so hard to replicate that your developer would be like ‘I’m not even going to try to build it myself. That’s a fool’s errand. I’m just going to use what’s already there.’
…
When I think about biz dev as a service and opex as a service, those are the biggest drivers. What are the major categories of spend that you can essentially do that to? Or the major relationships of spend that you can do that to?
Related Relay reading:
Released’s co-founder, Jens Schumacher, on building for developers and adjacent roles at once (“So, the real challenge? Crafting Jira in a way that it remains the go-to tool for developers craving depth, while also being the reliable, user-friendly platform for a broader audience.”)
#3: Hiring senior people from day one 📙
(From: Recast’s Michael Kaminsky) (Source: Relay)
When it comes to hiring senior people early, it wasn’t the case that we hired junior people and that didn’t work out. Fortunately, we didn’t have to learn this the really hard way.
This impetus instead came from a few things that we were trying to solve for when we started the company:
1- having a fully (without a central office) remote team from day one,
2- trying to build an operating culture that was very autonomous,
3- and minimizing the management burden for us co-founders and the company overall.
The implication for meeting those ends is that you want a workplace where every individual is incredibly autonomous and can work independently on hard problems.
Experienced people fit that description perfectly. They don’t need a lot of oversight and management. They can generally be pointed in roughly the right direction on a problem and they can then go, define it, and execute it themselves.
Of course, these hires are going to be more expensive.
Tenured engineers are really expensive. So there are real trade-offs here and this isn’t necessarily a super easy decision. Because we hired senior engineers our labor costs are relatively high and it also means that we don’t have a large pool of junior talent that we can train and promote from within.
But it has amazing, ongoing benefits. A big one being not needing a management layer. You can scale the early team without introducing these additional layers of complexity.
We actually just made our first junior hire 3 years into building the company.
…
As first-time founders, is it hard to evaluate senior hires?
In some sense, it’s easier.
Because you can judge them based on the work they’ve done in the past. Whereas with more junior folks, who don’t have much of a resume, one can only assess and hire based on potential.
And hiring for potential is really difficult because you’d only have a couple of hours in an interview with each candidate. Max. You’d have to make an assessment of their future output by observing just a small, early part of their trajectory.
Which could be an exponential curve or a flat one. You just don’t have enough data.
On the other hand, to give you an example, one of our first engineers had been working in tech for 30 years! :)) Going in, we knew exactly what this person had consistently executed on over that time period.
Additionally, we also brought in a bunch of people as contractors prior to having them join us full time once they had proven themselves out.
We were able to judge their communication style, their efficiency, and just their raw output all before making a full time commitment. Experienced folks are well set up for this approach as well since they’re further along in their careers and can take a bit more risk when it comes to finding their next role.
Getting junior hires on a contractual basis is more difficult.
Because you’d need a lot of management to get them pointed at the right problem, to constantly offer them feedback on the work itself and then how it ought to be done/handled/collaborated on. Additionally, junior folks often want (and need) the stability that comes with full-time employment.
…
How have we addressed the challenges around cost structures?
Well, a thing that’s special about Recast is that we have a lot of revenue for the stage we’re at. We’ve always focused on building a sustainable business from day one.
From the very beginning, we’ve prioritized getting substantial amounts of revenue into the business and have only grown the business that way.
We were at hundreds of thousands of dollars in annual recurring revenue when we raised our pre-seed round. And at millions of dollars when we got the subsequent seed. That sort of early cashflow has afforded us the flexibility to hire as we’ve wanted.
Again, it’s just a different philosophy for approaching company building from what a lot of early stage founders were attempting to do in the ZIRP era. And like any other choice, it has trade-offs. It’s harder to do.
It has been more stressful for my co-founder and I. Largely because of having less money in the bank — as opposed to some venture-backed founders with $10M in the bank we’ve had to fight and claw our way to keep burn rate low.
🤝 Founder social:
Until next year,
Team Relay (Chargebee for Startups)