I've been programming as a hobby since I was about 15 and now work as the only developer at my family's digital marketing agency. I appreciate the job, but maintaining our WordPress-based workflow has become exhausting. There is a lot of content entry, recurring troubleshooting, and friction for both developers and the internal team. Because I handle everything myself, complex problems can take many hours to resolve, yet the effort is often invisible to non-technical management.
I also deal with ADHD and anxiety, and outside work I mainly program in Rust while exploring compiler development. I want to improve our agency's process rather than simply keep patching the same problems. My current plan is to learn JavaScript and the DOM more deeply, then React, and eventually move our marketing sites to Astro with ApostropheCMS. The goal is a more pleasant development and editing experience, along with strong performance and SEO. I'm also considering Shopify for e-commerce projects.
Would ApostropheCMS be a dependable choice for a solo developer moving away from WordPress? Is Astro a sensible fit for marketing sites, or would another CMS or frontend approach be easier to maintain?
I'd also appreciate advice on communicating technical work to non-technical managers. How do you explain roadblocks, hidden complexity, and estimates when a problem takes eight hours to fix but looks like a five-minute task from the outside? I've even considered building a Rust-based DOM diff tool to make behind-the-scenes changes easier to demonstrate, although I'm not sure that would actually solve the communication problem.
5 Answers
You may not need to replace the CMS immediately. A gradual approach is to keep WordPress for editing and build a separate server-rendered frontend, then migrate pieces only when there is a clear benefit. Astro can be used this way, and other lightweight frontend options may be easier than adding React, a new CMS, and an e-commerce platform all at the same time. A staged migration will also let you measure performance and maintenance costs instead of betting the agency on an untested stack.
For management, don’t try to prove every detail technically. Keep a short work log showing the problem, what you investigated, what was ruled out, the current blocker, and the next step. Give estimates as ranges with assumptions, and call out scope changes as soon as they appear. Explain the business impact in plain language, such as ‘the editor was saving incomplete data, so publishing safely required tracing three separate systems.’ A DOM diff tool sounds interesting, but it may become another project instead of improving communication. A consistent status format and written record will probably help more.
It also helps to separate engineering time from the total delivery schedule. You can estimate the work you control, but requirements, approvals, testing, content, and last-minute changes belong to the wider project team. Make those dependencies visible instead of accepting responsibility for the entire timeline.
Before changing the whole stack, map out how WordPress is actually being used: simple brochure sites, blogs, custom integrations, or stores all have different requirements. ApostropheCMS can be a solid option and works well with Astro, but its content and widget system has a learning curve. It may be worthwhile for complex editorial workflows, while simple sites could end up with more infrastructure than they need. Build one internal pilot first rather than migrating every client at once.
Be careful about turning this into too many simultaneous learning projects. JavaScript fundamentals, the DOM, React, Astro, a new CMS, and an e-commerce integration is a lot for one person who is already burned out. Pick one small project and learn only what it requires. You can also improve your JavaScript skills through something related to your Rust interests, such as building a small desktop application, rather than forcing every experiment into the agency stack.
Don’t dismiss WordPress just because the current workflow is painful. It is still a practical choice for a solo developer when the team already knows it and the sites are relatively conventional. Before replacing it, see whether the biggest problems come from plugins, hosting, deployment, content modeling, or unclear requirements. Improving those areas might provide most of the benefit without forcing you to maintain both a legacy stack and a completely new platform. For e-commerce, evaluate the total cost and operational constraints carefully rather than assuming another hosted platform will automatically be easier.
Directus is another option worth evaluating with Astro. It takes some setup, but the admin interface and flexible data model have worked well for several projects. The important part is testing the editor experience with the actual people who will maintain the content.