Why we rebuilt Gruntwork’s website four times in 3 years

We just finished replatforming gruntwork.io and terragrunt.com from Webflow to a static Astro site, which is to say: raw code. It's our fourth replatform in 3 years, and it's finally delivering what we wanted from the start: anyone at the company can change the site and make improvements or additions with quality and consistency.

This is the story of how we went from raw code, through three CMSs, a healthy six figures of agency and contractor spend, back to raw code. These lessons may sound familiar to anyone who manages infrastructure that includes marketing sites. What changed in 2026 is that AI made "just put it in code" practical for non-engineers too. If you're planning a website rebuild or fighting a CMS, we hope you'll find these lessons useful.

Version 1

Simple Requirements, Simple Solutions

The website began as a Jekyll site which served us well (pun intended) for nearly 7 years. Jekyll is a static site generator, meaning it takes as input a combination of data and code, and renders a fully featured site that requires no sophisticated servers to render. This worked when everyone at Gruntwork was an engineer, and reading that data and code, and making changes to it, was simple to train and maintain.

As the company matured, our needs, and thus requirements for the site changed and became more complicated. We started hiring non-engineers and we wanted to do more with our website. Our for-engineers codebase, with very few bells and whistles, started to become an obstacle to making visual or content changes. We wanted to make new pages and have them be visually consistent with old pages, to make changes without touching raw source code, to include dynamic elements, have more forms and so on. Around the same time, our brand had undergone a visual refresh and our products also changed. So in this context, it seemed appropriate to start from scratch with a “fancier” solution.

Version 2

The Fully Outsourced Storyblok Disaster

Gruntwork's expertise is in infrastructure as code, not marketing websites, so we decided to bring in the experts. We hired a firm on a roughly $100,000 USD all-in contract to design and build our website on Storyblok CMS. About three months into the project we started to get nervous. Four months in and it was still nowhere near done.

Five months in, in Q2 2024, we had a company-wide onsite, called a Gruntcon. Collectively we were all a bit anxious about the delays on the site, so on day one of the onsite we chose our focus for the week to be to ship the website ourselves. That meant learning the codebase, finishing design implementation and writing a ton of copy.

We broke up into five groups of two, and worked all week on it. Some groups working on copy, some design, some code, occasionally swapping around. Whiteboards were covered, pizza was eaten and much debate was had.

On Thursday night we flipped the switch, and Friday morning we celebrated the launch of Version 2 before each getting on a plane to go home.

The fun was short lived, however. Over the coming weeks we noticed the number of people who converted by hitting "contact us" or "book a demo" on the site measurably decreased. Within a month we were having conversations about throwing away version 2 and reverting back to version 1.

Further compounding the misery, the new site didn't actually deliver on many of the promises we had hoped for moving to a hosted CMS. It was still difficult and time consuming to add new content; content, visuals and layout were not consistent; and the lead time to get new content up was long.

Version 3

The Partially Outsourced SanityCMS Mess

After launching version 2 and discovering the conversion rate dropoffs we of course attempted to analyze why conversion got worse. Was it content? Structure? Visual design? We couldn't know for sure, so we decided we could do better on all of it and greenlit redoing everything for version 3. We also felt we had learned enough about how not to efficiently build a website that another rebuild would be cheaper and easier. Specifically, we wanted to adopt a set of standardized components we could reuse to expand our content over time.

The plan for version 3:

• Get rid of the stuff the expensive outsourced firm built that didn’t work
• Focus on building standardized components that deliver internal consistency and reusability.
• Hire several engineering contractors and manage them ourselves
• Build on SanityCMS
• Goal: Ship it in 30 days.

If you've ever built a website before you know exactly what happened next. Yep, we sailed straight into the iceberg, again. 30 days turned into 6 months. The initial two contractors eventually turned into four, and cost ballooned to perhaps even match version 2. Standardized components were taken too literally and we ended up with dozens of component subvariations for every usecase, defeating the spirit of the requirement.

By December 2024, exhausted from rebuilding websites, we shipped version 3, having not meaningfully moved the needle on our goals.

Version 4

Webflow & WYSIWYG Frustration

Version 3 was a flop, but we were exhausted from replatforming. We worked on top of version 3 for a quarter, but the pain of the mismatch between platform and requirements compelled us to, once again, seek an alternative.

This time we considered tools simpler and more visual than the typical headless CMS, from Wix to Webflow to Squarespace. We landed on Webflow as a solid compromise between flexibility and ease of use.

Webflow promised to solve all our problems. The idea is you design reusable components using point-and-click styling in Webflow’s own system, and then a marketing person can click/drag those components to new pages/layouts and just fill in the copy or other parameters for the components. And to Webflow’s credit, that part worked. The problem was how expensive it was to build those components, and then how painful it was to implement process around the design.

The component design system is essentially just CSS, so to achieve a particular design requires someone who understands how web layouts and style work, basically a frontend engineer. So immediately there goes a bunch of cost saving, we’re paying $100+/hour for a competent frontend engineer to point and click. This is about as inefficient as it sounds - the total time and cost to develop the initial set of components was months and tens of thousands of dollars. Perhaps faster than a from-scratch site. Perhaps.

I know what you’re thinking, the main components are built, everything should be smooth sailing now! Cost should go down now, and speed should go up. And it did. But quickly we ran into other expensive issues. Outside enterprise plans, Webflow offers no branching, so if two people are editing the site at once and one publishes, the whole thing goes live, including the work in progress of their peer. There’s also no versioning or easy checkpointing, so rolling back is effectively impossible (nightly backups don't count). Hand-editing rich text was a nightmare, so we built an API integration and had to jump through hoops to avoid data integrity issues since rich text fields always come back empty on a readback, a known bug for years.

And yet, despite all that frustration, the WYSIWYG editor was still the closest thing to the dream of any of the platforms so far. Things were pretty stable on our Webflow front by mid-late 2025.

Version 5

AI and Astro finally take us to the promised land

One fateful afternoon our designer attempted to implement a brand new page on the webflow site. He mocked it up in Figma and then started working in Webflow design mode to implement the page. He spent an afternoon and had only finished about half of the first section, maybe 5% of the whole page. He mentioned this to me in passing and I was insistent, “Dude, don’t even bother, Claude should crush this.” I hooked him up with Webflow MCP 2.0 and he got to work vibing.

The challenge he ran into is that Webflow's MCP server was missing key features to enable AI to actually iterate on designs and be productive. It was slow, clunky, required a browser be open and didn’t let AI take screenshots to proof its own work.

A whole day of work later and maybe only 15% of the page was correct. We were both seriously bummed that AI had barely moved the needle on Figma to Webflow productivity.

Meanwhile, I had vibe-coded an entire new section, with sophisticated behaviors and integrations, to an internal application in about an hour. The contrast couldn’t be more stark.

Disheartened by our designer’s experience, I mentioned (with significant trepidation), at a Cafe that perhaps someday we should consider a fifth version of our website, one in raw code, that AI could be highly prolific in. I wasn’t asking anyone to do it, it wasn’t prioritized or budgeted or scheduled, just a shower thought out loud.

Of course nearly every engineer on the team took my very explicit non-request as a personal challenge.

Within one day we had several vibe-coded versions competing to replace the site. One week later we launched the initial rewrite of Gruntwork.io on Astro/Vercel, and two weeks later terragrunt.com had also moved over. All for $0 extra - we did not exceed the "included usage" on our Claude Team plan to make it happen.

Now anyone can ask AI in Slack "fix the typo on the platform solutions page" and within seconds a PR is open. In the first few weeks we've already had nearly half the company contributing to the site!

Version 5 is a straightforward Astro site using traditional GitOps. A PR is opened, CI automation runs tests and also does a visual render of any changed pages, any visual diffs from main are posted as comments on the PR for easy QA, and merges to main go straight to production, including blog posts like this one!

AI didn't exist when we started this journey, and wasn't practical for custom websites until 2026. We tried our best with what was available, but in the end, it turns out it was a techtonic shift in technical capabilities with AI that enabled us to build an ideal solution.

At Gruntwork, marketing sites are just like infrastructure that deserves to be "As Code" with all the associated benefits PRs, and reviews, tests, automation and AI-friendly development lifecycles.