Retrospective: What I’d Do Differently if I Rebuilt HCD Today

Looking back on my time at Holiday Caravans Direct (HCD), I’m proud of what I built. As a solo developer, I designed and implemented a fully functioning booking platform, evolved its architecture, and navigated complex requirements with minimal support. But like any big project, hindsight brings clarity.

If I had the chance to rebuild HCD today — with the benefit of experience and modern tooling — here’s what I’d do differently.

1. Start With Modular Boundaries

At the time, I built HCD as a single codebase with clear logical layers — but it was still a monolith. If I were rebuilding it today, I’d structure it using modular boundaries within the monolith from the outset, treating each core domain (bookings, pricing, availability, messaging) as a self-contained unit with its own models, services, and API interfaces.

This would:

• Improve maintainability

• Accelerate onboarding if more devs joined

• Make it easier to extract microservices later, if needed

  
  

2. Automate Infrastructure Sooner

Initially, deployments were manual. Over time, I introduced some automation — but had I started with infrastructure-as-code and a CI/CD pipeline, I would’ve saved hours of time and stress.

Today, I’d reach for tools like:

• GitHub Actions or Azure DevOps for deployment

• Terraform or Bicep for provisioning

• Application Insights for monitoring from day one

  
  

3. Use Event-Driven Patterns Earlier

At HCD, many workflows were tightly coupled — a booking action would trigger pricing recalculations, availability adjustments, and emails all in one request.

If I could redo it, I’d introduce an event-driven architecture early on. By publishing events like BookingCreated or PricingUpdated, I could decouple processes, add retry logic, and allow other services (like reporting or notifications) to evolve independently.

4. Document Decisions as I Go

As a solo dev, it’s easy to rely on memory. But projects like HCD last years, and future-you becomes a different person. I wish I had:

• Documented architectural decisions (even briefly)

• Maintained API change logs

• Captured reasoning for business rule oddities

These would’ve made updates smoother and reduced the mental overhead of revisiting older modules.

5. Include Testing as a First-Class Citizen

Most testing was manual. While I wrote some utility-level tests, I’d now introduce:

• Unit tests for core logic

• Integration tests for API contracts

• Snapshot tests for pricing scenarios

It’s not about aiming for 100% coverage — it’s about having a safety net for key behaviors.

Final Thoughts

None of this takes away from what HCD achieved. But these are the things I’d do differently today — not because I failed the first time, but because I’ve grown.

That’s the value of retrospectives. They aren’t just about what went wrong — they’re about learning what’s possible next time.

HCD gave me a foundation in ownership, delivery, and architecture. If I ever get the chance to build something similar again, I’ll do it even better — because of what I learned the first time around.