Over the last few years, I kept running into the same problem while building projects:
Every tool solved its own problem well, but the overall system kept getting more chaotic.
Frontend frameworks handled UI.
Backend frameworks handled APIs.
Cloud platforms handled deployment.
CMS platforms handled content.
IaC tools handled infrastructure.
But stitching everything together into one coherent system always felt fragile.
At some point, I realized I wasn’t actually interested in building “another framework.”
I was more interested in building:
- contracts between systems
- predictable runtime behavior
- modular infrastructure
- portable application architecture
- reusable blueprints
- and long-term maintainability
That shift in thinking eventually became the foundation for what is now evolving into KiwiEngine and the broader CitrusWorx ecosystem.
The Problem I Kept Seeing
Modern development often optimizes for:
- speed
- abstraction
- convenience
- shipping quickly
And honestly, those things matter.
But the longer I worked on larger ideas and multi-system projects, the more I noticed a different problem appearing:
The architecture itself was becoming secondary.
A lot of projects were effectively becoming:
- dependency collections
- plugin chains
- framework lock-in
- undocumented runtime behavior
- implicit coupling between systems
Things worked...
until they didn’t.
And when they broke, debugging the system became archaeology.
The Shift Toward Runtime Thinking
Instead of asking:
“Which framework should I use?”
I started asking:
“What contracts should exist between these systems?”
That single question changed how I started approaching software entirely.
Instead of designing applications around frameworks, I started designing around:
- contracts
- adapters
- pipelines
- runtimes
- boundaries
- execution flow
That led to ideas like:
- Seltzer
- Nectarine
- Juice
- GrapeVine
- Sugar
- KiwiPress
- WebEngine
All of them solve different problems, but they’re all connected by the same philosophy:
Systems should be composable instead of tightly coupled.
Why I’m Building in Public
Recently, over 10+ of these libraries became publicly available on NPM.
That’s exciting, but also slightly terrifying.
Because once software becomes public:
- people inspect your decisions
- your abstractions get tested
- assumptions get challenged
- architecture becomes visible
But honestly, I think that’s healthy.
I think more developers should share:
- unfinished ideas
- architecture experiments
- runtime concepts
- infrastructure thinking
- long-term system design
Not just polished success stories.
What This Series Will Be
This series is going to document the real process of building KiwiEngine and the CitrusWorx ecosystem as a solo founder.
Some posts will be technical.
Some architectural.
Some operational.
Some probably about burnout and decision fatigue.
But overall, I want this series to explore a bigger question:
What would software ecosystems look like if they were designed intentionally from the beginning instead of assembled reactively over time?
That’s the road I’m currently exploring with KiwiEngine.
And this is the start of documenting it publicly.
