Building Better Software

At Thoughtful, my focus and passion continue to revolve around this concept of radical complexity reduction which I believe is the key to building software that can be run by intentionally small teams while still being secure, maintainable, and scalable. Lately my work has generally fallen into three categories: (1) building better software, (2) throwing away code and finding vendor software and no-code tools to replace it, and (3) team building + hiring. In this letter, I want to share some more thoughts about this first and very important category.

I’ve identified five fundamental considerations for building high quality software based on the work I’ve done to help startups solidify their technology over the past few years.

Maintainability. It's easy to write code, but the fact is that for every dollar spent on a line of code, many more dollars are spent maintaining that line of code. As a company evolves, software needs to evolve too. The best engineers are always thinking about the lifespan of their code: who else will be reading this code after me? What changes could possibly be made to this code in the future? What will happen when my code dependencies are no longer maintained? Taking these considerations into account from the beginning may require a bit more time up front, but they will pay dividends in the time and money saved over the lifetime of the software.

Scalability. I’ve seen companies build software quickly and cheaply without considering scale. Their product technically “works”. They build fancy spreadsheets showing how they will then send thousands or millions of users over to use their shiny new product and profit. They go on to gain traction and begin getting thousands of users just as they had hoped, but then one day it all comes crashing down when their server unexpectedly goes down and they are forced to acknowledge the shortcomes of their system. The next thing they know, 80% of their engineering budget is paying down this technical debt - simply trying to stay afloat - while their competitors are actually moving full-speed ahead with new features. While premature optimization is certainly deadly for startups, a failure to consider scalability is also a silent killer: rather than destroying a company before it ever launches, it slowly drains companies of all their forward momentum until they come to a slow and painful death by a thousand cuts.

Security. A lot of startups figure that security doesn’t matter because they’re too small to be targets. While in practice this isn’t entirely wrong (big companies are definitely bigger targets), the truth is that skimping on security is like picking up pennies in front of a steamroller. You’re playing a game of risk and you’ll probably win for awhile, but when you lose, you might lose your entire company. And security is especially important for startups because it is actually more about how a product is designed than the usual checklists of things like security updates, penetration testing, and SOC 2 that often come to mind when you hear the term. Every new external surface is an opportunity for a leak that must be hardened and every new piece of code creates opportunity for unintended consequences. Similar to other architecture considerations, the most secure software is also the software that has the fewest moving parts, and the best time to plan for security is at the very beginning of a project’s life.

Cost. Cost isn’t just about money, but rather, allocating resources. Software is naturally complicated and requires a diverse set of technical experience to build and manage successfully. Software is so much more than just a bunch of code running on a computer somewhere: there are humans that have to be hired, motivated, communicated with, paid, and rewarded to build and maintain it. Then there are all of the indirect considerations about the product, too: marketing, sales, branding, advertising, and legal, to name a few. I’ve seen many startups under-fund their ideas and struggle to succeed simply because they are under-resourced. When it comes to managing teams and technology, there is often a minimum amount of funding necessary to make an idea successful. The best way to ensure your product will be built well is to adequately fund it and be careful not to cut corners that will result in expensive technical debt later on.

Optionality. And finally, the best for last. Optionality is the most important architecture consideration for startups! The single biggest problem I see with startup tech stacks is that they have already made so many assumptions about what the future will look like, and these assumptions are usually wrong: how many times have founders guessed exactly how their users will want to use their product on the very first iteration? None. This idea of optionality is to the engineer what lean startup is to a founder. Specifically, optionality is most important to consider when deciding on databases and vendors because each is complicated and expensive to migrate between due to the fact that they are heavily coupled to your data model. Thus, I believe it is most important to focus early on designing the simplest possible data model that you can. (Can I invent a new concept, "minimum possible data model"?) I work hard to think through these considerations with my clients: I’m always trying to anticipate future scenarios and maximize technology optionality so that my clients can focus on growth and be ready for whatever comes next. The reality is that no startup does technology perfectly. Every founder knows that running a company is a lot like balancing three bowling pins on your head while doing improv comedy. But being aware of the tradeoffs and ideals of building quality products, even if you can’t achieve all of them all of the time, will dramatically increase your chances of success. This is why I’m here to help.