The Laravel rebuild is live -- what I'd do differently
The site is live. After seven months of building it in the margins of client work, the new webxdevelopers.com is running on Laravel with a proper CMS, structured content types, and a deployment pipeline that does not involve me manually FTPing files to a server. I should feel relieved. Mostly I feel like I learned a lot of things the expensive way.
I want to write these down before the hindsight makes them sound more obvious than they were.
What took too long and why
The original estimate for this rebuild was three months. I built it alongside a team of two, fitting work in between client deadlines. What I did not account for was how much of the "easy" work was actually decision work. Every time I sat down to build a feature, I had to decide something. How should journal posts differ from blog posts? Should case studies be a separate content type or just a tagged category? How many navigation levels before we need a mega menu?
These decisions sound small. But each one required stopping, thinking, sometimes mocking up two options, and choosing. In a focused build with a clear spec, those decisions happen once in a planning phase. When you build in fragments over months, you make them over and over, sometimes inconsistently.
The lesson is obvious in hindsight: a two-week intensive planning phase with a locked content model and component inventory would have saved at least six weeks of rework.
The things I would not change
Choosing Laravel was right. The ecosystem is mature, Eloquent is clean to work with, and the templating through Blade is fast enough for what we need. Hosting on a VPS with Laravel Forge meant I had actual control over the server configuration without needing a sysadmin background.
The decision to build our own lightweight seeder-based CMS instead of reaching for a third-party package has also aged well. It means our content model is exactly what we need it to be. No fighting a plugin's assumptions. No upgrade anxiety when a CMS package changes its API.
What I would do differently
Scope. I kept adding things. A journal section, a resources area, a richer case study format, an improved blog with structured categories. All useful. All unnecessary for launch. Every added feature pushed the launch date and meant more context-switching between writing code and writing content.
The version that should have launched in month three was a fraction of what actually shipped in month seven. Clients do not see the content model. They do not notice the seeder architecture. They notice whether the site loads fast, looks clean, and answers their question. The first version could have done all three.
Next rebuild, and there will be one eventually, I want a hard "launch scope" list agreed on day one. Everything else goes on a post-launch list that cannot be touched until the thing is actually live.