~/en/blog/architecture-as-the-rock-your-software-is-built-on.md
#Arquitectura de Software#Diseño de Sistemas#Patrones de Diseño#Escalabilidad#Buenas Prácticas#Programación con IA

Architecture as the rock your software is built on

What actually keeps software standing over time? It is not the server or the language, it is the architecture. Using the Jenga analogy, this article explores why thinking about structure from day one keeps your project from collapsing.

Santiago Guzmán

Santiago Guzmán

Systems Engineer & Fullstack Dev

5 min read
Architecture as the rock your software is built on

Imagine you're about to play Jenga with your friends. You get everything ready, bring the game, bring snacks, and say: "Hey, want to play some Jenga?" Your friends love the idea, and you start setting up the game. What do you place it on? Do you think setting it up on top of jello, a bed, or a floatie in a pool is a good idea?

Chances are, even without asking yourself that question, you already pictured yourself in a living room, on a dining table, or in a game room. It probably never crossed your mind that a flexible surface was a good idea. Your brain instantly said: "Jenga goes on a flat, rigid surface, or it'll fall." And if that's what you thought, you were right.

Your brain already knows this, it just needs to be applied

Your mind, as we talked about in our article Learning every language won't make you a programmer, is 100% wired to solve problems, and finding the perfect spot to play Jenga is a problem, even if it feels completely normal. You can play around with your imagination, but if you go against physics, physics will make sure whatever you built comes crashing down.

Something similar happens in technology. If you don't lay solid foundations for your software from the start — like a table or a floor to set your Jenga on — the internet will make sure whatever you built comes crashing down too.

Picture your app running perfectly with 20 users during testing, but the day you share it and 5,000 people show up at once, the server collapses because every function depended directly on a single database, with no intermediate layer to distribute the load. Or worse: you fix a button on the login screen and, without realizing it, you break checkout entirely, because the whole codebase was tangled together with no separation of concerns.

What's really the solid rock of a software product?

Sometimes we think the solid rock of our software is having a good server, good performance, and above all, meeting every user need. But what actually makes software last over time? That question doesn't get answered with a couple of magic words that solve everything just by thinking them. There's more to it than we think. But don't worry, grab a coffee and let's talk about what architecture really means.

Architecture isn't some complex word that literally means pouring cement into your app and stacking bricks one by one. Architecture is thinking, from the very start, about all the foundations and columns that will hold your application up. For example, if you want an application that, no matter what, never drops its connection, you need to think about which type of architecture to use (decoupled, microservices, and so on).

I know we might be getting a bit technical here, and you might feel a little lost. But that's not the point. What I want you to take from this article is that it's not just about picking a programming language, your favorite AI, and some Linkin Park playing in the background. It's about thinking through the entire flow of a piece of software from the very beginning.

Architecture isn't the fine print, it's the essence

Software architecture means achieving a design and technical structure that lets all of a system's components organize, interact, and communicate with each other. It lays the groundwork to guarantee scalability, quality, performance, and long-term maintainability.

In the AI era, knowing how your software works at its core, understanding the connections between components, and building sustainable, scalable code is essential — because it helps us not "lose" the original essence of the software. We can tell an AI: "hey, build me an app like YouTube, don't make mistakes, and I'll send you my bank account so all the money lands there" — but if you don't actually think about what's behind YouTube and what keeps it running over time, all you'll do is burn tokens like a madman.

A route to start thinking about architecture

So, what's the way to use architecture in your favor instead of swimming against the current? Here's a small route I'd personally take:

  • Understand algorithms and data structures: you don't need to reinvent the wheel. Many algorithms for organizing, searching, and filtering data already exist. You don't need to memorize all of them either, but you can use them to your advantage. This is your first solid foundation so that, starting from your own functions, your code is fully optimized. Learn more at alg0.dev and visualgo.net.

  • Learn how design patterns work: the software world has countless design patterns used across many industries. They'll help you build better components and give you a solid foundation for building in a sustainable, scalable way. Learn more at refactoring.guru.

  • Get familiar with architectural styles: there's an architectural solution for your problem. Building an application meant for a global audience isn't the same as writing a personal script. Architectural styles will help you pick the right solution before ordering a rocket online just to travel to your own living room. And heads up: jumping into architectural styles can feel challenging and difficult at first, but don't stress. If something isn't clear, use your trusted AI or watch a few videos, and you'll understand it more clearly. Learn more at github.com/donnemartin/system-design-primer.

This isn't the only thing you need to know

Small disclaimer: this is a route I believe can help you understand, from the start, how to build scalable and sustainable software, but it's not the only thing you need to learn in tech. As I said in my previous article, this is a process that takes patience and discipline. So before diving headfirst into code, take some time to also learn these foundations, so your software can grow the way you actually want it to.

Don't worry if that last point still feels far away. That's normal, and you'll come back to it once you're building bigger projects.

AI can't read your mind (yet)

And I know the power AI gives you feels really good. Believing that a single prompt will make you a millionaire is a dream we'd all love to live, but if we sit down and really think about it, it's more complicated than we believe. Don't worry, AI is an excellent tool and it'll help you build a lot faster, but AI doesn't have all your context, and it can't read your mind (not in 2026, at least, haha). So for our next article, we'll look at why .md files aren't just pretty text.

Have a great week, and remember: it's better to program to deliver solutions than to just solve problems.

cd ~/blog (Back to blog)// EOF: End of article
grepsantiago@arch:~$cat sabados.md

Got 5 minutes on Saturdays?

Grab a coffee with me: weekly notes and real lessons on software architecture, artificial intelligence, modern tech, web performance, and engineering craft. Zero fluff, straight to the point.

  (  (   )
   )  ) (
 .--------.
 | ☕ DEV |]
 | COFFEE |
 \________/
  `------'
Saturday Edition
5 min read · Zero spam
Straight to your inbox every week
FREE SUBSCRIPTION
Zero spam. Unsubscribe anytime in one click.
>MORE ARTICLES FROM THE LOGView all →

LET'S CHAT

Let's work together on your next project!

*

MAIN // LOOP

EN_ LISTEN / ANALYZE / COLLABORATE / SOLVE / IMPROVE
ES_ ESCUCHAR / ANALIZAR / COLABORAR / RESOLVER / MEJORAR
FR_ ÉCOUTER / ANALYSER / COLLABORER / RÉSOUDRE / AMÉLIORER
GR_ ΑΚΟΎΣΤΕ / ΑΝΑΛΎΣΤΕ / ΣΥΝΕΡΓΑΣΤΕΙΤΕ / ΛΎΣΤΕ / ΒΕΛΤΙΏΣΤΕ
Santiago Guzman 2026
V 1.0.4

SANTIAGO

LOADINGLOADING