DEV Community: Max Paardekam

I Finally Stopped Designing and Started Building MaxOS

Max Paardekam — Thu, 23 Jul 2026 23:43:47 +0000

A few weeks ago I started sharing my idea for MaxOS, an AI-first workspace that puts AI at the center of the desktop experience instead of treating it like another app.

Since then, I've spent a lot of time thinking about the architecture, generating UI concepts, and planning how everything should work.

At some point I realized I had a problem.

I was spending way more time designing than actually writing code.

So I decided to stop chasing the perfect UI and start building the real application.

Turning mockups into a real app

I used Google Stitch to generate a lot of interface ideas. It was honestly a great way to explore layouts and workflows.

The HTML it generates isn't something I'd want to maintain though.

Instead of trying to clean it up, I used the screens as references and rebuilt everything with React, TypeScript, Tailwind CSS, and reusable components.

That turned out to be a much better approach.

Where the project is now

Right now MaxOS has the basic structure it needs to grow.

So far I've built:

A reusable design system
The application shell
Dashboard
Projects page
Code editor interface
AI chat interface
Command palette
Memory page
Agent manager
Settings
Zustand state management
Routing

Most of it still runs on mock data, and that's completely intentional.

I'd rather spend time building a solid foundation than rush into features I'll have to rewrite later.

What's next

Now comes the part I've been looking forward to the most.

The next milestones are things like:

Local filesystem access
Monaco Editor
Terminal integration
Git integration
AI providers
Context engine
Memory engine

This is where MaxOS starts becoming more than just a nice interface.

Building in public

I'm still a software development student, so I'm figuring out a lot of this as I go.

That's also why I'm sharing everything publicly.

I'll probably make mistakes, change my mind, and rewrite parts of the project. That's all part of the process.

If you've built Electron apps or AI tools before, I'd love to hear your advice.

Thanks for following along.

Building MaxOS #7: The First Line of Code

Max Paardekam — Thu, 23 Jul 2026 13:15:34 +0000

For the past few weeks, almost every update I've shared about MaxOS has been about architecture.

System diagrams.

Agent workflows.

The Context Engine.

The Plugin System.

The AI Layer.

A lot of planning…

…and almost no code.

That finally changed.

The Architecture Phase Is Over

I made a conscious decision to spend far more time designing than coding.

As an 18-year-old developer, that's not how I normally build projects.

Usually I have a running prototype within a day.

This time, I wanted to try something different.

I wanted to treat MaxOS like a real software platform instead of another side project.

That meant asking difficult questions before opening a code editor.

How should modules communicate?

How do multiple AI agents share context?

Where does memory live?

How do plugins extend the platform without touching the core?

How do I avoid building myself into a corner six months from now?

Only after answering those questions did I finally start implementing.

Turning Documents Into Software

The first implementation milestone wasn't glamorous.

There wasn't an AI writing code.

There wasn't a fancy interface.

Instead, I focused on building the foundation.

I initialized the entire monorepo.

Set up Electron.

Connected React, TypeScript, Tailwind CSS, and Vite.

Created the initial application shell.

Defined the project structure.

Started turning architectural decisions into real code.

For the first time, MaxOS actually launches.

It's mostly placeholders right now…

…but that's okay.

Seeing a window open after weeks of planning felt surprisingly rewarding.

Reality Is Different Than Diagrams

One thing became obvious almost immediately.

Architecture diagrams always look cleaner than implementation.

The moment you start writing code, you begin discovering edge cases you never considered.

Some ideas become simpler.

Others become more complicated.

That's exactly why I spent so much time designing first.

The architecture isn't there to be perfect.

It's there to give implementation a direction.

What's Coming Next

The next milestone is where MaxOS starts becoming recognizable.

Over the coming weeks I'll be building:

The workspace layout
The file explorer
The integrated code editor
The terminal
Project management
The first pieces of the AI layer

Once those exist, I'll finally have something people can actually interact with.

Why I'm Sharing This

One of the reasons I started posting here was to document the journey honestly.

That means showing the slow parts too.

Not every update is a flashy demo.

Sometimes progress looks like deleting bad ideas.

Sometimes it looks like writing architecture.

And sometimes it looks like staring at a blank Electron window thinking:

"Okay... now let's build something amazing."

That's where I am today.

The real work starts now.

If you've ever built a desktop application, developer tool, or long-term side project, I'd love to hear what your first implementation milestone looked like.

Building MaxOS #6: The Architecture Is Finished. Now It's Time to Build.

Max Paardekam — Thu, 23 Jul 2026 12:15:25 +0000

A few weeks ago, MaxOS was just an idea sitting in my notes.

Today, I finished designing the architecture that will power it.

Ironically, I still haven't written much application code.

And I think that was the right decision.

Looking Back

When I started this project, I thought I'd spend most of my time inside Cursor writing TypeScript.

Instead, I've spent days designing.

At first, that felt like I wasn't making progress.

Now I realize this was the progress.

Because MaxOS isn't just another Electron application.

It's something I hope will grow for years.

What Has Been Designed

Over the last week I've completed the first version of the project's architecture.

That includes:

Vision & Mission
High-Level System Architecture
Monorepo Structure
Core Modules
Event Bus
Context Engine
Agent Framework
Plugin System
Local Database
AI Layer
UI Architecture
Development Roadmap

Seeing everything together for the first time made the project feel real.

Not because there's a lot of code.

Because there's finally a blueprint.

The Biggest Lesson

The biggest thing I've learned so far is that software architecture forces you to think differently.

Instead of asking:

"How do I build this feature?"

I've started asking:

"What kind of system makes every future feature easier to build?"

That's a much harder question.

But I think it's also the more important one.

The Real Goal

People often ask whether MaxOS is supposed to replace Windows or macOS.

The answer is no.

I don't want to replace the operating system.

I want to replace the workspace.

Instead of opening ten different applications throughout the day, I want one intelligent environment that understands what I'm doing and helps me get there faster.

Whether I'll succeed...

I honestly don't know.

But I think it's worth trying.

What's Next

This is where things get exciting.

The architecture phase is finished.

The next milestone is building the first working version.

That means:

Initializing the monorepo
Creating the Electron shell
Building the first UI
Connecting the AI layer
Turning diagrams into software

For the first time since starting MaxOS, my next step isn't another document.

It's code.

I'm excited—and a little nervous—to see if the architecture I've designed actually holds up once implementation begins.

If you've ever spent weeks designing a project before writing code, I'd love to know: was it worth it in the end?

Building MaxOS #5: The Moment It Started Feeling Like a Real Platform

Max Paardekam — Thu, 23 Jul 2026 12:01:16 +0000

When I first came up with the idea for MaxOS, I imagined an AI-powered desktop workspace.

It sounded exciting.

But over the last few days, something changed.

After designing the Context Engine, Agent Framework, and Plugin System, I realized I'm no longer designing an application.

I'm designing a platform.

One AI Isn't Enough

At first, I imagined a single AI assistant that could do everything.

The more I thought about it, the more that idea fell apart.

A single AI trying to manage projects, edit code, search documentation, run terminal commands, write documentation, and interact with Git would quickly become a giant mess.

Instead, MaxOS will eventually have multiple specialized agents.

For example:

Planner Agent
Developer Agent
Documentation Agent
Git Agent
Research Agent
Terminal Agent

Each agent has one responsibility.

Instead of making one AI smarter, I'm trying to make multiple AIs work together.

Shared Context

Of course, multiple agents create a new problem.

How do they know what's happening?

That's where the Context Engine comes in.

Instead of every agent collecting information independently, they all share the same understanding of the workspace.

That means every agent can instantly understand things like:

the active project
open files
Git status
recent conversations
user preferences
workspace history

Without asking the user to repeat themselves.

Why Plugins Matter

The final piece I designed this week was the Plugin System.

One of my goals is making MaxOS extensible from the beginning.

I don't want every feature to live inside the core application.

Eventually, plugins should be able to:

add sidebar panels
register commands
contribute AI tools
provide context
add new agents
integrate external services

If I get this right, MaxOS won't just be software I build.

It'll become something other developers can build on.

Looking Back

A week ago I thought I was starting an Electron project.

Today it feels much closer to designing an operating environment.

There's still almost no code.

And honestly, I'm okay with that.

Every architecture decision I make now is one less thing I'll have to rewrite later.

What's Next?

The next step is finally getting closer to implementation.

I'll be designing the local database, the AI layer, and then I'll start building the first working version of the application.

That's where this project starts becoming real.

If you've built plugin systems, AI agents, or modular software before, I'd love to hear what mistakes I should avoid.

Building MaxOS #4: I Think Context Is the Hardest Problem in AI

Max Paardekam — Thu, 23 Jul 2026 11:55:33 +0000

When people talk about AI, the conversation is usually about models.

GPT-5.

Claude.

Gemini.

Open-source models.

But while designing MaxOS over the last few days, I've become convinced that the model isn't the hardest part.

Context is.

AI Is Only as Smart as Its Context

Imagine asking your AI assistant:

"Continue working on the authentication system."

A chatbot has no idea what that means.

Which project?

Which repository?

Which authentication system?

What changed since yesterday?

Now imagine your workspace already knows:

which project is open
which files you're editing
your current Git branch
your terminal history
recent conversations
project documentation
your notes

Suddenly, that same prompt becomes incredibly powerful.

The model didn't become smarter.

The context did.

Designing the Context Engine

Instead of treating context as something that's generated for each prompt, I'm designing MaxOS around a dedicated Context Engine.

Its job is to continuously understand what's happening inside the workspace.

Not just when you ask a question.

All the time.

Eventually, it should be aware of things like:

Active projects
Open files
Git repositories
Running terminals
Selected text
Recent conversations
User preferences
Workspace history
Installed plugins

Instead of rebuilding context for every request, the AI should already know what's going on.

Why This Is Hard

The challenge isn't collecting information.

The challenge is deciding what's actually relevant.

Giving an AI everything is usually worse than giving it the right things.

So the Context Engine has to answer questions like:

What's changed recently?
What matters for this task?
What can be ignored?
How much information fits inside the model's context window?

That feels like one of the most interesting engineering problems in the entire project.

Looking Ahead

I've now finished designing:

✅ Vision
✅ High-level Architecture
✅ Monorepo Structure
✅ Core Modules
✅ Event Bus
✅ Context Engine

Next up is something I've been looking forward to since day one:

The Agent Framework.

That's where MaxOS starts becoming more than an AI chat window.

It's where specialized AI workers begin collaborating to complete real tasks.

I'm excited to start designing it.

As always, if you've built context-aware applications or AI tooling, I'd love to hear how you approach context management.

Building MaxOS #3: Designing the Architecture Before Writing the Application

Max Paardekam — Wed, 22 Jul 2026 23:06:27 +0000

One of the biggest mindset shifts I've had while building MaxOS is this:

I'm no longer thinking about screens.

I'm thinking about systems.

When I first started the project, I imagined building a nice Electron app with an AI chat, a file explorer, and a code editor.

That would've worked.

For a while.

But the more I thought about the long-term vision, the more I realized that MaxOS isn't really about the UI.

It's about what happens behind it.

The Layers

Instead of designing features first, I've started designing the entire system as a collection of layers.

Right now, the architecture looks something like this:

User Interface
AI Layer
Agent Framework
Context Engine
Integrations
Local Operating System

Every layer has a single responsibility.

The UI presents information.

The AI decides what should happen.

Agents perform work.

The Context Engine keeps track of what's happening.

Integrations communicate with external tools.

Windows, macOS, or Linux simply provide access to the hardware and operating system.

Why This Matters

Imagine asking:

"Find the authentication bug, fix it, run the tests, and commit the changes."

That's not one action.

It's dozens of actions.

The AI needs to understand your project.

It needs to know which files are open.

It needs to interact with Git.

It needs to execute terminal commands.

It needs to understand the results.

Without a clear architecture, those responsibilities quickly become tangled together.

Building for the Future

One design decision I'm trying to make early is keeping everything modular.

The file explorer shouldn't know how AI works.

The AI shouldn't know how Git works.

The terminal shouldn't know anything about plugins.

Instead, each part should have one clear responsibility and communicate through well-defined interfaces.

Hopefully that means adding new features won't require rewriting old ones.

What's Next?

The next document I'm working on is probably the most important one so far:

The Context Engine.

If MaxOS is ever going to feel truly intelligent, context is everything.

That's the piece I'm most excited to design.

As always, if you've built large applications or have thoughts on software architecture, I'd love to hear how you approach these kinds of projects.

Building MaxOS #2: Why I Haven't Written Much Code Yet

Max Paardekam — Wed, 22 Jul 2026 22:59:42 +0000

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.

Building MaxOS: My Journey Begins

Max Paardekam — Wed, 22 Jul 2026 21:18:52 +0000

Hey! I'm Max.

I'm an 18-year-old Software Development student from the Netherlands, and I've decided to start sharing what I'm building instead of waiting until everything is "perfect."

For the past few months I've been thinking a lot about AI and how it could change the way we use our computers. Most operating systems are built around apps. I keep wondering, what if everything was built around AI instead?

That's the idea behind MaxOS.

It's not really an operating system. It's an AI-first workspace where AI helps you build, organize, learn, and automate your work from one place.

I have a lot to figure out, and I'm sure I'll make plenty of mistakes along the way. That's fine. I think sharing the process is more interesting than only showing the finished result.

I'll be posting about what I'm building, the problems I run into, what I learn, and the decisions I make. Hopefully other developers can learn something from it too, and maybe even point me in the right direction when I get stuck.

This is my first post, so thanks for stopping by.