Engineering foundations you need to get right at any stage

As a CTO-level consultant, I work with startups that have raised $5m or more but whose tech is holding them back. Some of the work I do involves fixing mistakes that were made earlier [1]. So, if you’re an early-stage startup who cannot afford to hire me yet, here’s a list of decisions I hope you get right now itself:

1. Choose tech that lets you iterate as fast as possible. Try low code. If it doesn’t work, for your backend, try Firebase BaaS. If it doesn’t work, try FaaS like Lambda. Which specific one you pick among this list can change over time, but the principle of picking the one that lets you focus as much as possible on creating business value rather than doing tech work for the sake of tech work is valid across stages of the startup. For the frontend / mobile, if you’re not using low code, maintain only one codebase as long as possible. If you need to support both desktop and mobile, build a PWA. If you need to support iPhone and Android but not desktop, use Flutter or React Native. Learn more.
2. Use RDS or Google Cloud SQL, running MySQL or Postgres, with a Multi-AZ configuration [2]. In general, use a managed database, and an open-source one.
3. Use Cloudflare, AWS or Google Cloud as your cloud provider. The others don’t offer powerful abstractions like FaaS.
4. Use continuous deployment. Whenever an engineer commits a change, it goes live immediately.
5. Optimise for fast iteration and experimentation, tolerating the temporary problems they cause for a better foundation for the future.
6. Have enough engineers on board. Most startups don’t, and then they wonder why work isn’t getting done fast enough.
7. Hire people with bias for action, and who are entrepreneurial, such as those who (co)founded a startup, built an app by themselves, built an app to streamline their dad’s business, freelanced, worked as the first engineer in a startup, advised a startup… The work matters more than the job title or formal recognition. For example, if someone helped a friend’s startup overcome a problem, he’s an advisor, even if nobody called him that.
8. Sometimes we work around a problem repeatedly. Say it takes 1 hour to work around it, and 2 hours to fix it. If you’ve already worked around it thrice, you’ve wasted more time than you saved, so at this point, you should spend the 2 hours to fix it. Don’t be short-sighted.
9. Use session-replay analytics like FullStory or LogRocket, to get a bird’s eye view of what users are doing.
10. Use the monitoring tool that comes with your cloud, like CloudWatch.

[1] This is different from decisions that are right at an earlier stage but wrong now. In other words, there are two kinds of decisions: one that need to be flipped when the startup grows, and one kind that are not justifiable even at an early stage.

Here’s an analogy: when you go to college, you need to do some things differently from primary school. In primary school, you ask loudly in front of the whole class, “Ma’am, can I go to the toilet?” If you do that in college, everyone will laugh at you. What was right in primary school is not right in college. But if you tear up your textbook and throw the pieces at the teacher, that’s not right irrespective of whether you’re in primary school or college.

Similarly, some decisions that were right at an early stage are not right later, while some decisions are not right irrespective of stage.

[2] AWS says that this reduces data loss: