When I published my first post about MaxOS, I expected to dive straight into building the application.
Instead, I've spent most of my time... writing documentation.
At first, that felt wrong.
Shouldn't I be coding?
The more I thought about it, the more I realized that jumping into development would probably create more problems than it solved.
Building the Foundation First
MaxOS isn't just another Electron app.
The goal is to create an AI-first workspace where AI isn't an extra feature—it's the center of the entire experience.
That's a much bigger challenge than building a nice UI.
Before I write thousands of lines of code, I want to answer questions like:
How should every part of the application communicate?
How do AI agents interact with each other?
Where does context live?
How can I make the system modular enough to grow over the next few years?
Those aren't questions I want to answer halfway through development.
What I've Worked On
Over the last couple of days, I've been designing the foundation of MaxOS.
So far I've finished the first part of the architecture, including:
The overall vision and mission
High-level system architecture
A scalable monorepo structure
Core application modules and their responsibilities
Instead of thinking about individual features, I've been thinking about how every future feature should fit into the system.
What's Next
The next pieces are probably the most exciting ones.
I'm going to start designing:
An Event Bus for communication between modules
The Context Engine that keeps track of everything happening in the workspace
An Agent Framework that allows different AI agents to work together
A Plugin System so MaxOS can grow beyond the built-in functionality
These systems will eventually become the backbone of the project.
What I'm Learning
One thing I've already learned is that architecture is much harder than writing code.
Writing a feature is relatively easy.
Designing something that you won't regret six months later is much harder.
I'm sure I'll still make mistakes, but I'd rather spend time thinking through the design now than rewrite half the project later.
Building in Public
I'm documenting everything as I go, even the boring parts.
The goal isn't just to end up with a working application.
I also want to look back in a year and see how the project—and my way of thinking as a developer—has evolved.
If you've built large Electron apps, AI tools, or developer platforms before, I'd genuinely love to hear your advice.
How do you approach architecture on large side projects? Do you design first, or start coding and refactor later? I'd love to hear your process.
Top comments (0)