Why We Proposed Astro for a Restaurant Brand (Instead of What They Asked For)

We received an RFP from a restaurant group that had done their homework. It was a detailed brief: clear goals, realistic timeline, reasonable budget. They had a technology preference: WordPress. They’d had a WordPress site before, their team knew how to use it, and they wanted to stay in the familiar.

We proposed Astro instead.

That’s a delicate move. The client has put real thought into their brief. They’ve come with a preference, not a blank slate. Telling them you think they’re wrong, even gently, requires a clear argument and the confidence that being honest serves them better than agreeing.

Here’s how we thought through it and what the conversation looked like.

The question we always ask first

Before we think about what technology to use, we ask three questions:

What’s the content model? How many content types are there, how are they related, and how often do they change? A restaurant group has menus (frequently updated), locations (occasionally updated), events (regularly added), and brand content (rarely updated). That’s a manageable content model, but it’s not nothing.

Who’s maintaining it? A full-time marketing team with a WordPress background has different requirements from a small office team who will log in once a month to update hours. The editing experience matters: a technically superior platform that nobody uses correctly isn’t actually superior.

What breaks at scale? This is the most important question and the one clients least often think to ask. “At scale” doesn’t mean traffic scale in this case. It means: as this site grows, what starts to get expensive or painful to maintain?

For WordPress specifically, the honest answer to the third question is: plugins. WordPress is an extraordinarily flexible platform, but that flexibility is delivered through a plugin ecosystem that requires ongoing management. Plugins need updates. Updates sometimes break other plugins. Security vulnerabilities in plugins create maintenance obligations. Over time, a WordPress site accumulates plugin debt, a growing list of dependencies that each require attention.

For a restaurant group whose core business is not managing a website, that maintenance burden has a real cost. Usually paid in developer time when things break at inconvenient moments (Friday before a big event, new menu launches, etc.).

Why Astro made sense for this brief

Astro is a static site generator with a component-based architecture and a simple CMS integration layer. For a content-heavy marketing site that doesn’t require dynamic server-side behavior on every request, it has several meaningful advantages:

Performance. Astro ships zero JavaScript by default, and components are rendered to static HTML. Pages load fast, Core Web Vitals are excellent from the start, and there’s no plugin layer adding script overhead. For a restaurant site where local search and mobile experience matter, this is a real competitive advantage.

No plugin maintenance. An Astro site connected to a headless CMS has far fewer moving parts than a WordPress site. There’s no plugin ecosystem to maintain, no security updates to apply to a dozen dependencies, no compatibility issues between tools. The ongoing maintenance cost is lower.

CMS-agnostic. Astro works with any headless CMS: Decap CMS (formerly Netlify CMS), Contentful, Sanity, Storyblok. We can match the editing experience to what the client’s team can actually use, not what the framework requires.

Graceful content model. Astro’s content collections make it straightforward to model distinct content types (menus, locations, events, posts) cleanly, with type safety built in. Adding a new content type is a development task, not a plugin installation.

How to present a technical counter-proposal without losing the relationship

The framing matters enormously. There’s a version of this conversation that sounds like “you’re wrong and we know better” and a version that sounds like “we want to make sure you get the best outcome, so here’s what we’re seeing.”

The approach we took:

Acknowledge the reasoning behind their preference. They chose WordPress because they know it, their team is comfortable with it, and it’s a reasonable default. That reasoning is valid. Starting the counter-proposal by dismissing it creates defensiveness.

Name the specific risks we’re concerned about. Not “WordPress is bad”. Instead: “for a site maintained by a small team with infrequent updates, WordPress plugin maintenance tends to create friction and cost over time, and here’s specifically what that looks like.” Concrete, specific, documented from our experience with similar projects.

Propose the alternative with an explanation of the trade-offs, not just the benefits. Astro has trade-offs too: it’s less familiar to most content editors than WordPress, adding developer-dependent functionality requires more upfront thought about the content model, and finding a developer to maintain it in the future is a smaller pool than WordPress. We said all of that. Clients who are told only the benefits of the proposed alternative have reason to be skeptical.

Let them decide. Our job is to give the client the honest analysis and let them make the call with full information. If they hear the argument and still want WordPress, we build in WordPress, carefully, with attention to the maintenance concerns we raised. Being honest about your recommendation doesn’t mean being inflexible about the outcome.

When we stay with what the client asked for

Not every client preference is worth pushing back on. We pick these moments carefully because clients have genuine expertise in their own business, and our job is to serve their goals, not to demonstrate our technical preferences.

We push back when:

• The technology choice will create a foreseeable problem that the client can’t see from where they’re standing
• The alternative genuinely serves the client’s interests better, not just our workflow preferences
• We can make the argument specifically and concretely, not just as a general technical opinion

We stay with the client’s choice when:

• Their reasons for the preference are valid and the trade-offs favor their position
• The proposed alternative is better in theory but worse in practice for their specific team and maintenance situation
• The performance difference is marginal and doesn’t justify the disruption of changing course

We build on WordPress. We build on Shopify, on Astro, on Next.js, on Hugo. The right tool depends on the problem. What we don’t do is recommend the tool we find most interesting or the tool that’s easiest for us to build in. We recommend the one that’s right for the client’s situation, even when that’s the familiar one they started with.

Last Updated: September 2026