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.
The comparison to writing was spot on. I’ve written technically sound pieces that went nowhere because I didn’t know what I wanted the reader to walk away with. Seeing intention framed as the thesis and editing as refactoring makes a lot of sense. Before my next piece, I’m going to write the intention first, then cut one paragraph that doesn’t serve it, even if I like it. That constraint feels less limiting and more clarifying. Thank you for making such an accurate comparison to writing with this technology newsletter Idris Elijah!
I loved the music analogy here! I’ve definitely polished tracks endlessly without knowing what emotional destination I was aiming for. When the intent isn’t clear, you end up with clean production that doesn’t move anyone. Thinking of the motif as the core domain and the arrangement as system design actually gives me language for decisions I usually make by instinct. Before I write another song I’m writing the intent in plain words and stripping out one element that doesn’t support it. Thank you Idris Elijah for sharing these valuable ideas with us today!