Your AI can build the app. Can it change the pricing page?

Building software used to be the slow part. You had an idea, then came wireframes, a developer, frontend, backend, a database, testing, deployment. Even something small took weeks before anyone could look at it.

That part got fast. Open Lovable, Cursor, v0, Replit or Claude Code, describe what you want, and you have a working product in an afternoon. Build me a landing page. Add three pricing tiers. Add testimonials and an FAQ. It works, and it's one of the better things to happen to software in years.

Then you launch, and the thing nobody warns you about starts.

The build ends. The editing never does.

Say your SaaS site is live. Homepage headline, product benefits, screenshots, three pricing plans, an FAQ, and a blog you've promised yourself you'll actually keep up with.

A week in: your co-founder hates the headline. Sales wants Pro moved from £29 to £39. Marketing has a customer story ready to go. One of the testimonials is from a company that no longer exists. You need a campaign landing page by Thursday, and you've committed to two articles a week.

None of that is a software change. It's all content. But if the content was written into the code when your AI tool built the site, every one of those edits goes back through the AI coding tool.

So you type: change the Pro plan from £29 to £39. The agent opens the project, finds the component, edits the file, redeploys. It works.

It also means you just ran a code change to edit a number. Somebody will do that on a Friday afternoon, something unrelated will break, and you'll spend the evening finding out why.

What a CMS is actually for

A CMS separates what your app says from how your app works.

Take the pricing card. Your code decides where the price sits, what the button looks like, how the card stacks on mobile, what happens when someone clicks "Start free trial". That's the application.

The plan name, the price, the description, the feature list: that's content. It changes on a different schedule, for different reasons, usually decided by different people.

Instead of "Pro, £39/month, includes 10 projects" living in a component file, it lives in the CMS. Your site asks for the current pricing plans, gets them back, renders them in the design your AI tool already built. Same for articles, FAQs, testimonials, docs, landing pages, SEO fields.

None of this is new. Headless CMS platforms have worked this way for a decade. What's new is who else is now touching your content.

There's a third user in the room

A CMS used to have two audiences. Developers wired it into the app. Content people logged into a dashboard.

Now there's an agent in the loop, and it isn't just writing version one anymore. It's the thing you ask when you want something changed.

Picture this. You're mid-session with your AI tool and you decide the pricing plans, FAQs and testimonials shouldn't be hardcoded. You want to say: move these into the CMS so they can be managed separately.

For that to go anywhere, the agent needs more than a login page. It needs to know what a page is in your system, how your content is shaped, which operations it's allowed to run, how to read what's already there, and how to write something new without guessing.

A dashboard designed for a human clicking buttons gives it none of that.

What "agentic CMS" actually means

Agentic is well on its way to becoming a word that means nothing. The idea underneath it is simple.

There's a difference between a CMS that uses AI and a CMS an AI can use.

A "Generate article with AI" button in the editor is the first one. Useful sometimes. But the CMS is still a thing a human operates, with a model bolted onto one corner of it.

The second one means the structure and capabilities of the CMS are available to the agent as a system it can reason about. You ask for an outcome:

Find the homepage and rewrite the main headline.

Turn these meeting notes into a draft article.

Add a fourth pricing plan using the same structure as the others.

Build a landing page for accountants using the structure of the healthcare one.

The agent reads what exists, works out which content type fits, and runs a defined operation. It isn't grepping your source tree and hoping it edits the right string.

Where MCP fits

For an agent to work with another system, both sides need a shared way to talk. The current answer is the Model Context Protocol, or MCP.

You don't need the spec to get the point. MCP is a standard doorway. An AI app knocks and asks: what can you do, what can you show me, how do I ask you to do it.

A CMS on the other side answers with its real capabilities. List the pages. Fetch this one. Create an article. Update this section. Handle these images. Set this metadata.

The important part is what that rules out. The agent isn't reverse-engineering your API from docs, and it isn't holding raw credentials to your database. The CMS publishes the operations it supports and the agent works inside them. When something goes wrong, it goes wrong inside a boundary you drew.

What the wiring looks like

Before:

Lovable → your website → pricing component → "Pro, £29/month"

The site works. The price is code.

After:

Lovable / AI agent → your website → content API → Garchi CMS → pricing content

Design still lives in your frontend. Lovable still helps you build it. The price now lives somewhere your marketing lead can change at 9am without opening an editor, and somewhere the agent recognises as content rather than a string in a file.

Small architectural difference. It compounds hard over a couple of years of a product's life.

Connecting it to the tool you're already using

We didn't want this to be a twenty-page integration guide. Most of the friction in adding a CMS to an AI-built project sits in the first ten minutes, and most of it is unnecessary.

Garchi has install instructions per tool: Lovable, Cursor, v0, Replit, Claude, Codex and others. Pick the one you work in and follow that page rather than a generic set of steps, because these products change their config formats often enough that a copy pasted into a blog post would be stale by the time you read it.

Connect Garchi CMS to your AI tool →

Once the connection is authorised, the tool discovers what Garchi can do for it. From there the conversation changes shape. Instead of:

call this endpoint with these parameters, parse the response, use field X

you say:

create a pricing section with three plans and connect it to this page

The first needs you to understand the integration. The second only needs you to know what you want.

Your database and your CMS aren't competing

If your AI-built app already has Supabase or Firebase behind it, the obvious question is why you'd add anything else.

Because they hold different things. The database has your users, subscriptions, orders, settings, activity. The CMS has your homepage copy, articles, FAQs, pricing descriptions, docs, case studies, SEO fields. There's overlap at the edges, and where to draw the line depends on your product.

Adding a CMS doesn't mean replacing a backend. It means putting a content layer next to one.

The payoff arrives later

Version one isn't where this pays for itself.

Your first prompt is "build a pricing page". A month later it's "put Pro up to £49". Then "add an Enterprise tier". Then "make an agencies landing page from our pricing and testimonials". Then "turn this customer interview into a case study and leave it as a draft for me".

If every one of those sends the agent back into source code, your content and your software are still welded together. If the content lives somewhere the agent understands, most of them stop being code changes. You don't regenerate a frontend because the business changed a sentence.

The dependency worth avoiding

Here's the part I keep coming back to. AI made it possible for someone without a decade of engineering behind them to ship real software. That's a big deal. But if every future change means going back into the coding agent, we've swapped "ask the developer" for "ask the agent" and called it progress.

For code, that's the right trade. For content, it isn't. Your marketing team should edit content directly. Your app should read it reliably. Your agent should help when it's useful. Whoever's accountable for the business should decide what goes live.

Those four things want the same source of truth, not four workflows that happen to touch the same website.

The question worth asking about any CMS now

The old headless CMS job was one sentence: separate content from presentation, let developers build the frontend however they like, let the content team manage what goes in it. Still true.

What's changed is that a content system now serves three parties at once. The application reading it, the people managing it, and the agents helping build and run it.

So the useful question about the next generation of CMS products isn't whether there's a writing assistant in the editor. It's whether your AI can understand your content system well enough to work inside it without breaking things.

Your AI can already build the app. Give it a content layer it can work with.

If you're building in Lovable, Cursor, v0, Replit, Claude, Codex or anything similar, connect your tool to Garchi CMS and let it handle the part that never stops changing.