Fretting over scaling issues too soon, often means laboriously imagining and lugging product freight from the future. It’s believing that the faint, distorted, mostly unreachable calls of possible features and overnight adoption fears matter more than the asks of the present roadmap.
In the following exchange, Contenda’s founder, Lilly Chen (@lilly), advises fellow enterprise SaaS founders to, at first, doggedly solve for the current problem-set instead of toiling over “future-proofing” or being “enterprise-ready.”
— The ever-rising bar of enterprise software (and why that’s okay)
— How you can do without “enterprise-ready” bells and whistles
— Why thinking about future scale can wait (lessons from Twitter’s origins)
— How to deal with the enterprise builder’s dilemma
— Brief notes on Contenda’s engineering culture
Shipping beautiful software is faster than ever
The quality bar for software has continued to move further. There’s also a trend of software that’s just old stuff but prettier. Classic examples being Notion and Typeform. Those products, as concepts, aren’t necessarily new. They’re just beautifully designed and rendered.
That being said, while it certainly takes longer to build beautiful software, the floor for hitting that quality bar is now also much lower and accessible. Because there are a lot more engineering tools being made.
Hence it’s faster than ever to deploy something. It’s faster than ever to connect a lot of different integrations. Those are things that used to take a stand-alone team just to set up.
If you think about software like Netlify, which makes it super easy for anybody to deploy a front-end in literally minutes. Setting up CI/CD for a personal website used to take a long time. And some people never really got around to it.
Which meant the development cycles were longer and longer. Today, a bunch of new dev tools have significantly shortened those cycles. Making it faster for you to ship, giving you access to stuff you can review and be aware of in advance.
So, I do think that the overall time to ship quality software has actually increased but not by as much as you think.
Before assessing readiness, define what “enterprise” means for you
Enterprise SaaS startups, quite often, start to consider the scaling challenge too soon. Truthfully, most business software does not need to worry about scale for a long time.
Let’s take Contenda’s example.
Currently, we only sell design partnerships. We don’t have general availability. There’s no public pricing page. Our design partnership recently has been going for $8k a month.
A design partnership gives customers early access to a solution for their biggest pain point, while also giving us a tighter feedback loop.
If you think about that price point for enterprise SaaS, $8K a month is just shy of a $100K ACV. That is a lot of money. So you only need 5-6 design partnerships, theoretically, to break even depending on your burn and where you’re located. Could be even smaller than that.
And you can support those handful of customers on entry-level infrastructure. You don’t need to get fancy at all.
We use the Serverless framework, which is just AWS Lambda functions, for our backend. It’s paid by invocation and by the length of time that the function runs. So if nobody is using it, it’s free. And if people start using it more, you pay more and scale it up.
But if you’re talking about 5 customers and their respective orgs, as far as approximate users are concerned you’re talking about maybe 500 or probably fewer. 500 active users isn’t a lot.
Plus, usually there is a ton of work that needs to go into selling and building enterprise software if you have to go through a standard procurement process.
‘Enterprise,’ technically, should mean extremely large companies such as Meta. But I feel that the phrase, ‘enterprise B2B software,’ has actually expanded to also include a lot of mid-market customers.
If you’re talking about selling to startups that are in that growth (series B/C) stage, you actually don’t have to go through elaborate procurement procedures.
Procurement process means that you have to go through a security review. You need to go through multiple layers of hierarchies within different (finance, legal, etc.) departments.
With a scale-up, mostly it’s just the buyer who needs to sign off on it. The buyer is typically a VP, a director, possibly C suite, depending on what you’re selling.
But that person can usually sign the thing and as long as their CEO doesn’t object, they’ll just pay the invoice and you’re fine. So unless your product legitimately only sells to the likes of Google, Facebook, and Apple, you probably don’t need to be “enterprise ready” and invest in developing bells and whistles such as single sign-on.
To add to that, it’s even okay if the platform doesn’t yet do all the things you’ve built in different places. It’s okay for some of it to be self-serve and for some of it to be manual.
You can actually get away with that as long as the value that you bring is unique enough to your customer. And if they value that promise more than how much they get annoyed with the limitations.
“There will be ways around it, when you get there”
Founders often ponder over and prioritize future-proofing: ‘This data schema needs to work for X situation, what if we decide to add Y feature or bring on Z integration.’
The truth is until there is a business reason to add that feature, to make that integration, you just shouldn’t do it. And you shouldn’t worry too much about whether or not your database will scale to that feature.
If it’s fairly simple, fine, go implement it. But if you’re having to overthink the addition and if it’s getting very complicated and messy in your schema, just focus on whatever your current business problem is.
Let me share a popular example.
Twitter, as you know, or rather the modern version of Twitter, revolves a lot around anonymity. So it’s less about sharing stuff with your friends (unlike Facebook) and more about people you might want to know.
But back in the day, Twitter used to be much closer to Facebook, conceptually. If you look at Twitter’s API today, a tweet is still called ‘status’. Pretty analogous to the ‘Facebook status,’ minus the character limits.
And, originally, Twitter was using a relational database. Because that’s what makes the most sense when you’re enforcing a two-way connection between users.
As Twitter evolved, though, you saw the rise of people just following others in a way that didn’t enforce two-way connections. Most of the time you followed somebody, they didn’t follow you back.
Even more so, most people on Twitter just scrolled through the timelines. They didn’t write much. And that meant that the data delivery had to be different.
If you’re Kim Kardashian and you’ve got a million+ followers, when you tweet something, that means it needs to be delivered to a lot of timelines. If you’re user73452, though, and you tweet something, that gets delivered nowhere; but you probably follow a couple thousand people and consume tweets a lot more.
Twitter, then, moved to a queue system where instead of using a relational database, they’re in a document style database that pulls into a queue. And everybody gets their timelines actually triggered from a single endpoint. Which is incredibly interesting.
They didn’t change the backend because they had to evolve to something new but because they had an emerging, pressing business challenge to address.
That being said, the relational database still exists. So they migrated it in pieces. And depending on the type of user you are, you’re exposed to a different data path. If you’re a celebrity, they optimize for your writes, if you’re a new user, they optimize for your reads.
The takeaway? If you’re lucky enough to ever scale to a point where you need to figure out a better delivery system because, say, you have huge celebrities on the platform, you can hire people and they will help you figure things out. There will be ways around it.
But most startups never make it that far. So you should focus less on attending to a hazy future. And just build for the present problem-set as best and as fast as you can.
Ship with transparent determination, week after week
You don’t want to show something that’s too rough to a potential sales lead. On the other hand, you don’t want to wait too long polishing something to figure out if it is truly valuable.
Thus you want to ship as fast as possible and get it out there to get feedback but at the same time you don’t want to scare somebody into thinking that you’re incompetent. That, right there, is the enterprise builder’s dilemma.
What I’ve learned and what I would encourage founders to do is to not view the two as mutually exclusive.
If you can be honest with somebody about what your product’s vision is, the problem that you hope to solve for them, and be transparent and say ‘hey, I built this in a week, I want to validate a specific area that I’d love to show you and get your feedback on,’ that’s feels much better.
Because when they hear that from you, they wonder, ‘alright, this is somebody I can trust, who, week over week, is going to deliver, going to push towards the massive, pain-in-the-butt problem that I’m having and chip away at it.’
Showing up with great transparency and intent on progress is actually so much better than disappearing for five months, coming back with something new and asking for the very first time, ‘what do you think?’
“We’re coding to solve business problems”
If there’s a principle that drives us the most, it’s ‘don’t accept the status quo.’ That means if you’re working in a system and you notice a repetition or a pattern of errors or a particular type of failure, call it out! Let’s talk about why that is.
We don’t accept that something is just ‘the state of things.’
Because I do feel that sometimes when you notice a problem and tell people that a bug comes around a lot for instance, and they’re like ‘we’ve been seeing this bug for the past two years, we just reset it every time it comes up,’ that’s a problem.
Although, we also have a very strong business focus. We’re a startup. We’re not engineers in the sense that we’re coding for the sake of coding. We’re coding to solve business problems.
And sometimes, you run into a bug, and you realize that the only way to fix that bug would be to permanently rearchitect the entire thing. And that’s not worth it. Most of the time.
It’s not going to be worth it to resolve that inconsistency by having to spend a month doing a complete overhaul. And in those situations we have to evaluate that trade-off and do that as engineers and business owners.
That’s probably one of the key things for all the engineers on Contenda, that they have a very strong business focus.
Another important cultural practice is that we do not set traditional individual engineering goals. We don’t bother with them. Because typically goals are tied to promotions or status changes. And we don’t believe titles should be goals.
Goals that we do care about and we help everyone achieve are different. As I’m also everyone’s engineering manager, I talk to them about: what they want to learn next? Or what they want to experiment with? Or what was a problem that they found especially interesting? And then I support what I gather as their goals.
Related reading from the Relay archives:
— Tara AI’s co-founder, Iba Masood, on workflows and culture that tie engineering with growth
