After launch, do we need a retainer with the studio or can our own team maintain the site?

A retainer sold right after launch is usually sold as insurance. You pay a fixed monthly amount so someone is available if something goes wrong. The problem is that the month after launch is the quietest month the site will ever have. The pages are new, the copy was just approved, and nobody has a reason to change anything yet.

In our projects, the work that arrives in the first three months after launch is almost all content. Swap a headline. Add a customer logo. Publish two blog posts. Change a form’s thank-you text. None of that needs the people who wrote the code, because the CMS was built so a marketer can do it without asking permission.

The honest test is whether you can name the work. If you can list five specific things you want changed in the next quarter, price those five things. If you cannot name any, you are about to buy availability you will not use.

Write down every change you can imagine wanting in the next year. Then put each one in one of three buckets. The bucket decides who can do it, and that decides whether you need anyone on retainer at all.

Most lists come out roughly 70 percent content, 25 percent component, and 5 percent system. That ratio is the whole argument. A retainer priced for the 5 percent is charged every month for work that appears twice a year.

• **Content work.** New copy, new images, a new blog post, a new case study, reordering sections on an existing page. Done in the CMS. No code, no deploy, no designer.
• **Component work.** A page type that does not exist yet. A pricing table with a fourth column. A testimonial block with video instead of a photo. This is new code built from existing tokens and existing patterns.
• **System work.** Changing the type scale, adding a colour to the palette, changing spacing across every page, adding a whole new page template family. This touches the foundations, so it changes pages nobody asked you to change.

Be unkind here. “Our developer could probably pick it up” is not the same as “our developer has shipped a component in this repo.”

Content work needs one person who has actually published something in the CMS since launch. Not been shown it. Published in it. If nobody has, that is a training problem, not a retainer problem, and one hour of screen sharing fixes it.

Component work needs someone comfortable with the stack the site is built on. For a Glasspage site that means Next.js, React, TypeScript and Tailwind. A backend engineer who has never touched a front end can learn it, but the first component will take them three days instead of three hours. That gap is a cost, and it is a cost you can choose to pay.

System work is the one place where the people who built the system are genuinely faster. They made the decisions and know which ones were deliberate. A repository with tokens and a written record of why things were decided closes most of that gap, but not all of it.

This is the question retainer pitches avoid. Very little breaks. Most of the difference is speed.

Nothing breaks on the content side. The CMS keeps working, the site keeps deploying, analytics keeps recording. On a Glasspage build the code, the repository and the deployed site are the client’s from day one and live in the client’s own accounts, so there is no switch anyone else can flip.

What gets slower is component work, and it gets slower in a specific way. An in-house developer who does not know the token names tends to hardcode values. One hex code, one pixel spacing, one font size, straight into the component. It looks fine. Then you change the brand colour eighteen months later and four pages do not change with it. That is the real failure mode, and it comes from missing documentation rather than a missing retainer.

So the fix is documentation, not a subscription. Ask for the token list, the component inventory, and a short record of the decisions behind them. Then a hardcoded value is a mistake someone can catch in review instead of a mystery.

There are three, and one of them is free.

**Option one, nothing.** You maintain it yourself and call someone when a specific job appears. Cost is zero until it isn’t. This is the right default for a stable page set edited quarterly.

**Option two, hours on demand.** You agree a rate, and you buy work in named chunks. “Build the integrations page template” is a quote. “Be around in case” is not. You pay only for output.

**Option three, a fixed retainer.** Sensible only when the demand is real and continuous. Compare it honestly: a retainer at a given monthly figure has to buy more work per year than the same money spent on named jobs, or it is worse than option two by definition.

Here is the arithmetic that decides it. Say component work costs you roughly a day of studio time each, and you need one new page type a month. A retainer that covers twelve of those beats buying them one at a time, because you also stop paying for the studio to reload context every time. Now say you need two a year. The same retainer bought ten months of nothing.

Three signals, and you want at least two of them before you commit to a monthly fee.

If all three are true, a retainer is not insurance. It is a queue you are actually going to fill, and that is a fair thing to pay for monthly.

• You are shipping new page types every month, not new pages. New pages are content. New page types are code.
• No one in-house owns the front end. Not a developer who could, an actual owner with the time.
• The design system is still growing. If the token set and component library are still changing shape every few weeks, the site has not settled and someone has to hold the shape.

Also three, and any two are enough to cancel.

We have watched teams sit on retainers for six months, use them for two hours of copy edits, and renew because cancelling felt risky. Cancelling is not risky when the repository, the code and the deployment all belong to you. You can hire the same studio again next quarter.

• Your changes are quarterly copy edits and the occasional new image.
• The page set is stable. Same templates, same navigation, same structure as at launch.
• You have a capable internal developer who has already shipped something in the repository.

If you want cover without a subscription, three things do most of a retainer’s real job for a fraction of the money. Ask for them at handover, while everyone still has the project in their head.

Banked hours. A block of hours bought once and drawn down as needed, with no expiry or a long one. You pay for work, not for waiting.

A documented escalation route. One named contact, a written response window, and a clear line between a bug the studio fixes and a change you pay for. Agreeing that line in advance prevents the argument later.

An upgrade window. A defined period after launch where the studio revisits the system, refreshes anything that has drifted, and answers questions from whoever inherited the code. Book it once, six or twelve months out, rather than paying monthly for the option.

The reader’s original question was whether their own team can maintain the site. For most stable marketing sites, yes, and the thing that makes it true is not a contract. It is tokens, a component inventory and a decision log sitting in a repository you own. Ask any studio for those before you ask them for a monthly invoice.