Building The Website | Autobat Industries

Welcome to the first chapter of the Autobat Industries Lab journey.

Before diving into cloud labs, services, and blueprints, it’s worth sharing how this website itself was built — because the way it’s built reflects the same philosophy that guides the Lab: learn by doing, and build with purpose.

When I set out to create this site, I had a few clear goals:

Learn without wasting resources: I didn’t want to pay to run a headless CMS 24/7 on AWS to serve static content. Static-first was the right choice — dynamic content could come later, if needed — keeping cost, complexity, and maintenance low.
Practice front-end development: My day-to-day work focuses on cloud engineering and architecture. I don’t often get to work on the front end, so this was an opportunity to learn the tools again — to build out user-facing components and understand modern tooling from the ground up.
Use Next.js↗ for the framework: I have some experience with Next.js from previous client projects. It offers the right blend of static site generation (SSG), server-side rendering (SSR), and easy API integrations - perfect for a modern, scalable, lightweight website.
Explore new tooling: In past projects, I had successfully used StrapiCMS↗ and liked its developer experience. But for this site, I wanted to try something different. After some research and experimentation, I landed on PayloadCMS↗ — a newer headless CMS focused on extensibility, simplicity, and self-hosting flexibility. It allowed me to explore a different content management model, and build new patterns into the platform.

This site is the result of those choices:
Built with Next.js, connected to PayloadCMS, and deployed in a way that scales up only when needed.

The same principles apply throughout the Lab:
Practical, secure, efficient, and designed to grow as needs change.

ChatGPT & AmazonQ: Why should I have a headless CMS and separate rendering engine for a static website? Isn’t this just overhead?

ChatGPT

Not necessarily — it’s about decoupling and flexibility.

A headless CMS gives you a clean way to manage content without locking you into a particular front-end framework or layout. By separating the content layer (CMS) from the rendering engine (e.g., Next.js), you gain:

Greater control over presentation: You can design your front end exactly how you want, without being limited by the CMS’s templating system.
Modern dev workflows: With tools like Next.js, you get static site generation (fast, cheap to serve) with the option to add dynamic features later.
Reusable content: Your content isn’t tied to a single site — it can be consumed by multiple apps, services, or platforms.
Simplified scaling: Your rendering engine can generate static pages at build time, and your CMS doesn’t need to be live 24/7 unless content is actively changing.

Yes, it’s slightly more setup upfront — but you’re building a system that’s more flexible, scalable, and fun to work with in the long run.

Amazon Q

Using a headless CMS with a separate rendering engine might seem complex for a static website, but this modern approach offers real advantages.

Content teams can update the site without touching code or waiting for developers. They get a friendly interface while developers keep full control over the design and functionality. Everyone works faster, with fewer bottlenecks.

This setup also future-proofs your website. Need to add a mobile app later? Want to switch design frameworks? No problem - your content is ready to go anywhere. Plus, static sites are blazing fast and secure since pages are pre-rendered and cached.

For developers, it means cleaner code, easier testing, and better version control. While it takes some initial setup, the flexibility and efficiency gains make it worthwhile for sites that need regular updates or might grow in the future.