At one point, most of my thinking around software revolved around pages.
- landing pages
- dashboards
- admin panels
- APIs
- components
- layouts
And while those things still matter, over time I realized something important:
Most complexity in modern applications doesn’t come from screens.
It comes from flow.
Data flow.
Operational flow.
Deployment flow.
Communication flow.
Validation flow.
Infrastructure flow.
Eventually I stopped asking:
“What page are we building?”
And started asking:
“What system flow are we designing?”
That single shift completely changed how I approach architecture.
Applications Are Really Pipelines
Underneath almost every modern application is a series of transformations.
A request comes in.
Something validates it.
Something transforms it.
Something authorizes it.
Something enriches it.
Something stores it.
Something logs it.
Something renders it.
Something caches it.
Something distributes it.
Most systems are pipelines whether we intentionally design them that way or not.
The difference is whether the flow is explicit or hidden.
Hidden Flow Becomes Hidden Complexity
One of the biggest problems I kept running into in modern web development was invisible architecture.
Logic scattered everywhere:
- hooks
- middleware
- event systems
- decorators
- global state
- lifecycle callbacks
- framework magic
- plugin injections
At small scale, it feels convenient.
At larger scale, it becomes difficult to reason about.
You start asking questions like:
- “Where is this actually happening?”
- “What modified this request?”
- “Why did this state change?”
- “What order does this execute in?”
- “Why is debugging this so painful?”
Eventually I realized the issue wasn’t necessarily the tooling itself.
It was that the system flow wasn’t obvious anymore.
And once flow becomes invisible, architecture becomes harder to trust.
Explicit Pipelines Changed How I Think
The more systems I worked on, the more I started preferring explicit pipelines over hidden execution patterns.
Instead of:
“Something somewhere modifies this.”
I wanted:
“This enters here, moves through these stages, and exits here.”
That sounds simple.
But it changes everything.
Because now:
- debugging becomes easier
- observability improves
- onboarding improves
- testing improves
- scaling improves
- reasoning about the system improves
The architecture becomes understandable.
And understandable systems scale better organizationally.
Not just technically.
A Request Is Rarely “Just a Request”
Think about a modern application request.
Even something simple like:
POST /api/orders
Usually involves:
- authentication
- validation
- rate limiting
- business rules
- inventory checks
- database writes
- event creation
- notifications
- analytics
- caching
- auditing
- logging
- response transformation
That’s not a route.
That’s an operational flow.
And once I started viewing applications this way, the idea of “pages first” architecture started feeling incomplete.
Why I Started Designing Around Pipelines
This thinking heavily influenced how I approach systems now.
Especially in projects like:
- WebEngine
- Seltzer
- Nectarine
- KiwiPress
I became less interested in:
- massive controllers
- hidden middleware chains
- implicit execution
- deeply coupled framework logic
And more interested in:
- contracts
- stages
- transformations
- pipelines
- explicit runtime behavior
Because explicit systems are easier to maintain over time.
And maintainability becomes increasingly important as projects grow.
Flow Is Bigger Than Backend Architecture
This idea extends far beyond APIs.
Businesses themselves are pipelines.
Orders move through stages.
Content moves through stages.
Deployments move through stages.
Users move through stages.
Products move through stages.
Infrastructure moves through stages.
Even teams operate through pipelines:
- planning
- development
- testing
- deployment
- monitoring
- iteration
Once you start thinking in flows instead of isolated screens, you begin designing systems differently.
You stop building disconnected features.
You start building operational ecosystems.
The Industry Often Optimizes for Speed of Creation
A lot of modern tooling optimizes for:
- fast setup
- rapid prototyping
- shipping quickly
And again:
that matters.
But eventually systems reach a size where operational clarity becomes more valuable than short-term convenience.
Because complexity compounds.
Especially when:
- multiple developers touch the system
- infrastructure grows
- integrations increase
- business logic expands
- AI-generated code enters the stack
- scaling requirements appear
At that point, architecture quality matters a lot more than whether setup was fast in the beginning.
AI Makes This More Important, Not Less
I actually think AI increases the importance of explicit flows.
Because generated code can introduce even more hidden complexity if the surrounding architecture isn’t disciplined.
If systems are pipeline-driven and contract-driven:
- behavior becomes easier to validate
- execution becomes easier to trace
- generated logic has clearer boundaries
- architecture remains understandable
Without clear flow design, systems eventually become difficult to reason about regardless of whether humans or AI wrote the code.
What I Think We Need More Of
I think the industry needs more emphasis on:
- explicit runtime architecture
- operational clarity
- observable systems
- predictable pipelines
- modular transformations
- maintainable flow design
Not because it sounds architecturally “pure.”
But because software eventually becomes operational infrastructure.
And infrastructure needs clarity.
Final Thoughts
I still care about good UI.
I still care about developer experience.
I still care about elegant frontend systems.
But nowadays, when I look at an application, I don’t primarily see pages anymore.
I see movement.
I see:
- requests flowing
- systems communicating
- data transforming
- operations scaling
- workflows evolving
In other words:
I stopped designing websites.
And started designing flows.
Top comments (0)