Intention Is the Real Architecture (Frameworks Won’t Save You)
Most web systems don’t fall apart because the code is bad.
They fall apart because no one agreed on why the system exists.
The more I learn on my software development journey, the more I realize how vital intent is and not necessarily the technologies we use to bring our dreams to reality.
We like to blame frameworks. Or scale. Or the last developer who touched the codebase. But under the hood, most architectural problems are clarity problems.
We built something before we decided what it was for.
Here’s the paradox: we focus so much on structure that we forget about the one thing that truly holds it together, which is intention.
Architecture Starts Before Code
In IT and web development, intention is not a mission statement, a vision deck, or just a feeling.
Intention is the set of priorities that quietly shape every technical decision:
Who is this system primarily serving?
What outcome matters more than all the others?
What must never break?
What are we willing to sacrifice?
When those questions are unanswered, the system still gets built.
It just gets built accidentally.
That’s how you end up with:
Over-engineered stacks solving simple problems
Under-engineered systems handling critical ones
Endless debates about tools instead of outcomes
Rewrites that feel necessary but change nothing
None of these are technical failures.
They’re intention failures.
Intention is the Architecture
Real architecture isn’t diagrams or abstractions.
It’s the translation of intent into constraints.
When the intent is clear, decisions become straightforward, and that’s actually a good thing.
If the intent is “this app must never go down,” you choose redundancy, monitoring, and boring tech.
If the intent is “this must ship fast and change often,” you choose simplicity over elegance.
If the intent is “this handles sensitive data,” you accept friction in exchange for safety.
If the intent is “this must be cheap to run,” you design for efficiency from day one.
The code doesn’t lead.
The intent does.
Architecture is just intention made executable.
The six questions that should come before any build
Before writing any code, every web project should be able to answer these questions clearly and in plain language:
1. Who is this system primarily serving?
2. What is the one outcome it must deliver consistently?
3. What are the top two failure modes we are optimizing against?
4. What tradeoff are we choosing on purpose?
5. What must still be true when usage increases 10×?
6. What is explicitly out of scope—even if it’s tempting later?
If you can’t answer these, no framework will save you.
Best practices won’t save you.
More abstraction won’t save you.
Another rewrite won’t save you.
Why senior developers argue less about tools
Experienced engineers don’t win debates by knowing more libraries.
They win by anchoring decisions to intent.
Instead of asking:
“What’s the best practice?”
They ask:
“What best serves the system we’re trying to build?”
Intention becomes the tiebreaker.
It kills bike-shedding.
It limits scope creep.
It gives teams permission to say no.
Not because something is “bad,” but because it does not support the architecture that truly matters.
A small, boring example (the good kind)
Consider an internal admin dashboard.
The intent is simple: reliable, boring, easy to maintain.
So the architecture follows:
Monolith over microservices
Server-rendered pages over heavy frontend frameworks
Simple role-based access instead of a complex permissions engine
And just as important: what doesn’t get built.
No real-time features.
No fancy UI.
No premature APIs.
The result isn’t impressive.
It’s stable.
And stability is often the real success metric.
The same rule applies outside of code
This principle isn’t exclusive to software.
Writing works the same way.
Without intention, you get technically correct articles that no one finishes.
With intention, structure becomes obvious.
The thesis is the system goal.
The outline is the architecture.
Each paragraph is a component.
Editing is refactoring.
Music works the same way, too.
Without intention, you get clean production with no emotional destination.
With intention, arrangement choices become clear.
The motif is the core domain.
The arrangement is system design.
The mix is performance optimization.
Different mediums.
Same rule.
Every creative system collapses without a clear why.
The challenge
Before your next ticket, feature, rebuild, article, or song:
Write the intention in five lines or fewer.
Then remove one thing that doesn’t serve it.
That single act will improve your architecture more than any new tool ever will.
Because in the end, intention isn’t a nice-to-have.
It’s the real architecture.
What stood out to me is how universal this principle is. Whether it’s code, writing or art, things fall apart when we build before we decide why we’re building. Intention as constraint feels like permission to say no, to simplify, to stop chasing impressive and start chasing effective. The challenge at the end feels doable and powerful: write the intent, remove one thing and trust that clarity will do the rest. As we head to the end of the year and the start of a new one this is the perfect time to apply these principles, no matter what field we’re in. Great tips today Idris and thank you for teaching me something new!
This really resonated with me outside of tech. Learning dance with my daughter has taught me how much intention matters before technique. When I focus on why we’re dancing: connection, confidence and joy, everything else gets simpler and less stressful. I’ve actually applied a lot of what I learned from your e-book already and this newsletter helped me see why it worked: clear intention removes overwhelm. Writing the intention down and letting go of what doesn’t serve it feels like something I can use not just in learning, but in parenting too. Thank you for creating useful tools that respect real life Idris Elijah!