There are few principles that hold, I've found, when it comes to designing software at a startup.
Most companies of this size might not be around in a few years. For those first few years it's a good practice to refrain from thinking about the company as a software company (the notable exception being a startup that is literally building software products like libraries, databases, compilers, etc... then disregard this advice). It's a business trying to find product-market fit that happens to use software.
Under this lens it doesn't make sense to start writing software if you can avoid doing so: the company might not be around in the next year or two if it can't land those first customers and start growing. The less you write, the less you have to maintain, the more you can focus on what matters: finding that product-market fit.
This means optimize for doing the least amount of work and writing the least amount of software possible. Use frameworks (code you didn't write), libraries (code you didn't write), and services (code + infrastructure you don't maintain) as much as possible. TFA points out several of these: use an auth service, use a PaaS, etc.
The majority of your "software" often looks and feels like glorified configuration. You're pulling together frameworks and libraries on top of services that do most of the work for you. Good. You've kept your capital costs down and didn't spend time building something you're going to throw out at a moments notice!
It's when you gain traction and your services bills start ballooning and your customers start to demand transparency, reliability, that you need to start thinking about hosting your own software and building an architecture that suits your applications' usage patterns. This generally happens after the business has found a niche and is now focusing on adding customers rather than finding them.
I agree with most of what you wrote but I strongly disagree with the fact that customers starting to demand reliability is a scenario that should happen before you start thinking about hosting your own software.
Treating stability and reliability as an afterthought is one of the main things that's wrong with the tech industry at the moment, I would argue. It's a competitive market. Move fast and break things but at least have the requirement to be as reliable as possible from the get to.
Alas, this is written from a user and tech enthusiasts standpoint. I know it's a futile argument since reliability is not a requirement for growing a project far enough to get a worthwhile exit, so we will continue to "enjoy" unstable products.
Sorry but couldn’t disagree more strongly about reliability and stability. Those are afterthoughts because a buggy, unreliable service that solves a critical pain point for a customer is fixable, but a perfectly operational service that doesn’t do much for people isn’t.
Startups trying to find a market need to cut every corner imaginable to minimize any work that isn’t related to finding the customer, as this is the existential crisis.
There is a lot of wiggle room between a buggy, unreliable service and a perfectly operational service.
And yes, as I said, from a business point of view, I absolutely agree with what you say. From a user's perspective, I don't. And I hope more people will start to reject adopting buggy, unreliable projects in the future.
There’s great precedent for low reliability products becoming popular. ChatGPT and Twitter both became widely adopted despite frequent downtime.
This extends well beyond software. The Ford Model T other early motor vehicles weren’t exactly safe and reliable but still solved a real problem for millions of customers.
I understand your objection. I also value reliability. I would say I'm a bit more conservative about joining startups for this reason (and the fact that I have to be prepared to be out of a job in a year or two if things don't work out). I would prefer not to spend my time frustrated and compromising on my values unless I'm willing to take the risk for the payout.
But that's the reality of startups: spending too much time on reliability when it's not needed is wasted effort. As a startup you can at least pull the "choose boring tech" lever and rely on the frameworks/library's/services to care about reliability for you.
Most companies of this size might not be around in a few years. For those first few years it's a good practice to refrain from thinking about the company as a software company (the notable exception being a startup that is literally building software products like libraries, databases, compilers, etc... then disregard this advice). It's a business trying to find product-market fit that happens to use software.
Under this lens it doesn't make sense to start writing software if you can avoid doing so: the company might not be around in the next year or two if it can't land those first customers and start growing. The less you write, the less you have to maintain, the more you can focus on what matters: finding that product-market fit.
This means optimize for doing the least amount of work and writing the least amount of software possible. Use frameworks (code you didn't write), libraries (code you didn't write), and services (code + infrastructure you don't maintain) as much as possible. TFA points out several of these: use an auth service, use a PaaS, etc.
The majority of your "software" often looks and feels like glorified configuration. You're pulling together frameworks and libraries on top of services that do most of the work for you. Good. You've kept your capital costs down and didn't spend time building something you're going to throw out at a moments notice!
It's when you gain traction and your services bills start ballooning and your customers start to demand transparency, reliability, that you need to start thinking about hosting your own software and building an architecture that suits your applications' usage patterns. This generally happens after the business has found a niche and is now focusing on adding customers rather than finding them.