By Fredric, Principal at Bright Plum

Every budget season, a client asks me some version of this. How much should we set aside for the website next year?

It's a hard question to answer well. I've been in tech almost twenty years, most of it working with colleges and universities, so I know what's riding on the number. You have to walk into a room and defend it. Get it wrong and you either run out of money in March or you hand back budget you'll never see again.

The real answer has a lot of factors in it. But a convoluted answer isn't an answer. "It depends" is what you get from most vendors, and it leaves you where you started.

Somebody is going to ask you for this number in April. You should already have one.

So here's the answer. $45,000 a year for a primary university website, maintained the way it should be. Add about $10,000 for each additional property you own if they share the same codebase.

That's not an industry survey. It's our own book of higher-ed clients. Here's how it breaks down.

$30,000 is the minimum. At $30,000 you're covering security and the basics of accessibility and compliance, and that's all. No documentation. No performance work. No monitoring for search. Nothing set aside for what's coming next year.

$45,000 basically buys the rest: documentation, platform health, page speed, and monitoring for both search engines and answer engines. Answer engine optimization (AEO) is the newer half of that. It's the work of making sure your programs come up when a prospective student asks ChatGPT about them instead of typing a search query.

The rest of this is how you get from that range to your number.

First: what did you spend last year?

This can feel like a sales question. It isn't meant to be. It's the fastest way to a number you can defend.

I had a client ask what they should budget for the website this year. They had close to eight Drupal and WordPress sites. The Wordpress sites shared one codebase and the Drupal sites had two different codebases. In the question, all of it had collapsed into "the website."

So I went back to what they spent with us the prior year. Round number, $100,000. Then I told them what it covered: eight sites. Divide it evenly and that's $12,500 per site per year.

The money never split evenly, though. The main site carries more visibility and more weight than a department site nobody has touched since 2019, but still needs to be maintained. When I looked at the real breakdown, about 40% went to the most visible site and 60% went to the other seven.

That puts the main site at $40,000, right where I said it would be. The other $60,000 is the cost of seven sites nobody counted when they said "the website."

Somebody is going to ask you for this number in April. You should already have one.

That's the conversation you can't have until you know what you spent. It will change what you ask for. "We need $100,000 for the website" is a number your VP will push back on. "We support eight sites, the main one takes 40% of the effort, and here's what that bought" is a number your VP can approve.

If you just finished a rebuild or a rebrand, your last-year number will be large, and that's still useful. Ask for the line-item breakdown and sort it into two piles.

One pile is one-time work. Content migration and content strategy usually belong here. You paid for them once. You won't pay for them again next year, so take them out of the baseline.

The other pile is repeatable. Back-end development, front-end development, component development. As your authors and your users keep working in the site, that work keeps coming. It stays in the baseline.

Most of the sticker shock in budget season comes from leaving one-time costs in the recurring number.

Second: what's coming this year?

Once you have a baseline, look forward. These are the things we tell clients to plan for.

Accessibility audits, at least quarterly, plus the remediation that comes out of them. The audit is the cheap part. Fixing what it finds is the line item people forget.

Security review, at least monthly, plus remediation. That means hardening packages and checking whether any modules or front-end packages need to be deprecated because of a known issue.

Major version releases. If a new major version of Drupal or WordPress is projected to land in your fiscal year, set money aside now.

Documentation of how your site works. Most higher-ed teams run on knowledge that lives in one person's head, and that person is going to leave.

Platform health and performance.

Search and answer engine monitoring, if you have goals there.

Here's the math. Start at the $30,000 floor. Add 25% to 40% of it for the forward-looking work on that list and you're at $38,000 to $42,000. Add the third question below and you land at $45,000. That isn't a coincidence. That's where the number comes from.

That percentage is money spent before anything breaks. It's the least popular line item to defend and the one that decides whether your year is calm or on fire.

Third: what are you trying to accomplish?

The first two questions get you a number for keeping the site alive. They don't cover what you're trying to do with it.

If you have growth goals or engagement goals, those cost money. If you have board meetings and accreditation reviews, somebody has to prepare for them, and somebody has to make sure your VP walks in with the materials they need.

We don't write content. What we can do is monitor, make suggestions, and hand your content people prompts and ideas they can act on. Interview a few current students. Interview prospective families. Turn what comes out of that into prompts your writers can use, especially if you care about showing up in answer engines.

That work belongs in the budget too, and it's usually the first thing cut, because it's the hardest to point at.

What to do before your budget meeting

Budget decisions at most institutions land in April for the next fiscal year. The work that gets you a good number happens well before that.

Pull last year's invoices. Count how many sites that money covered. Split the line items into one-time and repeatable, and drop the one-time work out of your baseline. Then add 25% to 40% for what's coming.

You can do all of that without calling anyone.

Fredric runs Bright Plum. We handle web operations for higher-ed marketing teams that don't have a developer of their own.