Although my company isn’t recognizable as a startup given its age, I can say confidently that the typical advice to avoid rolling your own is not a given.
Many new founders and businesses fail to consider the supporting systems they need outside the code their product or service is comprised of. This can cause a lot of unnecessary re-engineering later.
As we built our company we had to make a number of decisions about whether to build our own or go with a third party. At various points we did both, and for us the DIY approach has continuously been the better option over time. That doesn’t mean we write our own code for everything but it does mean we sometimes do, and it means we don’t just go with whatever is the most convenient. An increasing amount of our IT estate is self-hosted applications rather than SaaS apps, for example.
By way of example, we had started off with a really popular accounting package that everyone uses for everything but which isn’t very customizable (and which doesn’t provide backups). That became untenable after only a few years because we our service demanded a more bespoke approach to linking service and financial data. We knew that going in but we took the same “it’ll do for now” attitude. That ended up creating more pain later. We moved to an ERP platform that we can host (and backup!) and haven’t looked back.
We almost did the same with our infrastructure management. We had evaluated and used a number of proprietary products and services from AWS, Hashicorp, CI/CD, and RMM vendors.
Ultimately we created our own stack on the back of FOSS and custom code which took a lot longer to mature but which has proven to be much better for our needs.
-minimalism: no code designed for othere
-security: not necessarily more secure, but a different risk profile. You are safe from a lot of spearphishing vulns like log4j, but may be open to custom attacks, I think this is an advantage but ymmv.
- system knowledge: you can answer questions about your system, to clients and regulators.
- system flexibility: you understand your system you can modify it as needed. Which is not true if you import 1000 dependencies.
Many new founders and businesses fail to consider the supporting systems they need outside the code their product or service is comprised of. This can cause a lot of unnecessary re-engineering later.
As we built our company we had to make a number of decisions about whether to build our own or go with a third party. At various points we did both, and for us the DIY approach has continuously been the better option over time. That doesn’t mean we write our own code for everything but it does mean we sometimes do, and it means we don’t just go with whatever is the most convenient. An increasing amount of our IT estate is self-hosted applications rather than SaaS apps, for example.
By way of example, we had started off with a really popular accounting package that everyone uses for everything but which isn’t very customizable (and which doesn’t provide backups). That became untenable after only a few years because we our service demanded a more bespoke approach to linking service and financial data. We knew that going in but we took the same “it’ll do for now” attitude. That ended up creating more pain later. We moved to an ERP platform that we can host (and backup!) and haven’t looked back.
We almost did the same with our infrastructure management. We had evaluated and used a number of proprietary products and services from AWS, Hashicorp, CI/CD, and RMM vendors.
Ultimately we created our own stack on the back of FOSS and custom code which took a lot longer to mature but which has proven to be much better for our needs.