Building for Scale
June 23, 2026 · 3 min read
A functioning app is step 1 of many
Software is easier to build than ever before. At one point in time, building a website with auth, a db, and its intended functionality took an exceedingly long time to build. Now we have all sorts of tools and frameworks to make coding simpler, and of course AI. With the rise of AI, a website takes a day maybe two to build. But realistically, all that has been completed is a prototype. It takes a deeper understanding of systems to build something well.
The Gaps
Software has ALWAYS been deployed with gaps. Sr. Devs that complain about AI slop often do so because they’ve deployed systems and have first hand experienced those gaps in production. Security issues, auth issues, query speeds, api latency, react bugs, all sorts of issues that they’ve had to go in and figure out with stack overflow. Over time you build an intuition because your subconscious starts to recognize poor design patterns. So what does that mean? It just means the floor is higher. A website used to be impressive, now it’s par if you can create a website with a live backend, db, mobile and web view, and you have to have very strong UI. This website only took me a couple days to build. The really impressive projects are the projects where people push a boundary and understand limits.
What is impressive now?
Nowadays, there are some extremely interesting engineering challenges. Can you build a website that has multiple themes (not just light and dark) that lets a user pick between drastically different layouts, and still handle multiple screen sizes well? Can you build a strong security layer? Can you build something that scales, and there is a strong understanding of the bottlenecks (can your db handle load? Your api layer? How many concurrent users can you handle? Can you reduce latency in different regions?) Did you use Kubernetes, Terraform or another IaC/Containerization combo to horizontally scale your software easily, and to be able to quickly redeploy your service if something goes horribly wrong? These gaps are much more impressive, and it’s also impressive to say “I build this layer to handle x concurrency intentionally” and explain why it’s cheaper than an alternative, because you aren’t expecting a massive load of data to flow through at any given moment. Systems design is impressive, and being able to actually show your systems gaps with observability and methods to show that are the types of concepts that people should be learning. There is something to be said about learning a language with depth, but the reality is having strong knowledge of systems will pay off more. If you constantly look for gaps, you will find where your code can be improved, and you will be able to ship successful and maintainable software.