History is littered with dead startups that designed for scale before they had enough usage to justify it. Within reason, having users knock your site over resulting in failures like the Twitter Fail Whale is a good problem to have.
With that said, you need to be prepared to scale up quickly once you have this problem. There's a reason Facebook counts its users in the billions, and Friendster is a footnote in internet history.
> "So unless your product legitimately only sells to the likes of Google, Facebook, and Apple, you probably don’t need to be 'enterprise ready'" What in the actual fsck? Check out this list of companies ranked by the number of employees they have - https://companiesmarketcap.com/largest-companies-by-number-o... . Okay, Amazon is #2 - but notice the top 100 doesn't include Apple. There's a lot more to business than FA…
Although each of those companies is made up of 5 to 50 mini-companies, each with more business units/products/services. You have to understand which of them you're selling to, what they need, how they will use your product. Are two completely different tiny departments gonna hem and haw over trying your product, or will the whole org use your software? You might end up supporting a dozen users or 500,000. Will you still have to support the same features, or can the tiny teams get away with less? Is it even worth supporting the enterprise features if your product fit is smaller teams and you wouldn't get a large-scale contract anyway?
You actually do need to have Enterprise security and authentication features if you intend to sell to Enterprise customers. (SOC2, OAuth, SAML etc)
I am on calls all week with our banking clients about getting SAML/SSO squared away once and for all. We are having a lot more nervous takes around legacy LDAP/AD auth mechanisms these days.
I developed SAML/SSO integration for an application used by the Swiss UBS which initially relied on individual accounts, not even AD. Tricky stuff.
I like the article, but overall I think it's the same advice as "start small, limit scope, be ready to pivot" with a dash of "don't make enterprises an early customer". I obviously paraphrased quite a bit.
What is glaringly obvious from this article is that "enterprise" in this industry has lost much of its meaning. It's almost ubiquitous with "medium+", which I think is a self-defeating definition that starts to make sense only when you look at what features are commonly gatekept behind enterprise distributions of software.
Well it depends on what you're selling! Design for what you truly want to sell, and that will end up however it needs to end up, whether that's enterprise or not. This random blogger, and our random comments, can't tell you what you need. It has to emerge from the product development process like a sculpture from a block of marble.
Exactly this. It sounds easy but this type of creator who can do this is very rare but usually has a high success rate. This should be the defintion of the "10X dev"
I wonder if a recession or bear market environment will quickly make this type of advice – that worked well for the 2010s boom – obsolete in a harsher climate. Might be hard to scale your go-to-market by depending on startups who don't want 'enterprise-ready' features to spend money on your product.
> "So unless your product legitimately only sells to the likes of Google, Facebook, and Apple, you probably don’t need to be 'enterprise ready'" What in the actual fsck? Check out this list of companies ranked by the number of employees they have - https://companiesmarketcap.com/largest-companies-by-number-o... . Okay, Amazon is #2 - but notice the top 100 doesn't include Apple. There's a lot more to business than FA…
>The buyer is typically a VP, a director, possibly C suite, depending on what you’re selling
If a company has VPs buying things surely they have some sort of internal vendor management that usually involves accounting/legal/compliance reviews. Being enterprise ready means you have the roles/documentation/process/procedure to answer those questions
I'm working on a project where the backend devs decided to use Cassandra to manage a few hundred entities. Due to different access modes they had to denormalize the data into multiple tables and we're constantly running into consistency issues. A fucking sqlite db with a few tables and indexes would do just fine. Also, the tool has maybe a dozen DAUs. But it's web scale, so, yeah…
I wonder if a recession or bear market environment will quickly make this type of advice – that worked well for the 2010s boom – obsolete in a harsher climate. Might be hard to scale your go-to-market by depending on startups who don't want 'enterprise-ready' features to spend money on your product.
I think enterprise ready here refers more to scale than to features. People try and go the microservices, distributed DBs, hyper scale route way too early rather than focussing on their product, possibly building it as a monolith with simpler SQL DBs before going all out.