AdAstro logo AdAstro

Why I Built This

By Adastro Team Updated Apr 10, 2026
480 words 3 min read Audio available
Adastro john
Audio version0:00 / 0:00
Narrated article playback
1x
Skip 15s back or 30s forward without leaving the article.

I have been building websites for a long time, but not from the path most people would expect.

I started in the era of static HTML, Dreamweaver, and early CMS platforms. Over time that path led through tools like Mambo, Joomla, and eventually WordPress. For years, that was enough. WordPress was practical, familiar, and flexible enough to carry a lot of projects.

But over time I became increasingly frustrated with what that flexibility usually meant in practice. Performance often depended on restraint that the platform did not naturally encourage. Complexity accumulated through plugins. Operational behavior drifted into a mix of code, dashboards, hosting quirks, and one-off fixes that made the whole system harder to reason about than it should have been.

At the same time, I wanted a serious excuse to learn how modern web architecture feels now. Not in theory, and not from a tutorial project, but through something real enough to expose tradeoffs. I wanted to work with Astro, React, Supabase, modern deployment workflows, CI, server-first rendering, and a more disciplined approach to application boundaries.

That is where AdAstro started. The question was simple: could I build a CMS from scratch that felt modern, stayed fast, and still behaved like something an actual publishing team could own?

AI assistance changed the shape of that experiment. I am not pretending the project was built by hand in isolation. It was built with heavy AI assistance, especially for implementation speed, regression coverage, documentation, and repetitive engineering work. Used badly, that would have produced a shallow pile of code. Used well, it became a multiplier. The important part was not generating code quickly. It was learning how to steer that process hard enough that the result stayed coherent.

Some parts of the project became more serious than I originally expected. The setup flow had to become clearer. Auth and role boundaries had to fail closed. Localization needed to move from an idea to a release-ready public model. AI features had to stay reviewable instead of pretending to be autopilot. Migration tooling had to support trial runs and rollback instead of assuming every import would be clean.

That is probably the biggest difference between the original experiment and the product now. AdAstro no longer feels like a sketch. It feels like a real publishing stack with clear opinions: keep the core strong, keep public pages lean, keep advanced features optional, and document the operational boundaries as carefully as the user-facing ones.

I still would not pitch it as a universal answer for every team. It is open source, maintained by one developer, and honest about its scope. But that honesty is part of the point. AdAstro is what happened when learning modern web architecture stopped being abstract and had to survive contact with real product decisions.

Comments

Loading comments…