The Quiet Line Items: Five Costs Your 2026 App Budget Probably Forgot

Every UK founder I've spoken to has the same spreadsheet. Design on one line, development on the next, a contingency row at the bottom that everyone quietly knows is fiction, and then the number that gets taken to the board.

It's a fine spreadsheet. It's just not a product plan. A budget is a set of decisions about what your app will be like on the day it goes live and in the six months afterwards. Miss a line and you haven't saved money — you've just chosen to cut a feature in month four, at the worst possible moment, with no time to think.

Here are five lines that turn up late in the process and cause disproportionate trouble. Ranges are ballpark for 2026, excluding VAT, with the usual caveat that London and the South East tend to run 15–25% higher.

1. Accessibility testing and remediation

Almost everyone says they're building an accessible app. Very few budget for finding out whether they have.

An independent audit against WCAG 2.2 AA for a mid-sized app typically lands somewhere between £3,000 and £9,000, depending on how many screens and flows are in scope. The number that actually hurts is remediation: assume 15–30% of your build budget if accessibility wasn't designed in from the start, which, statistically, it wasn't. Ongoing regression testing per major release runs from about £500 to £1,500.

It's also worth remembering that accessibility sits under the Equality Act 2010 rather than being a nice-to-have, and the public sector has been working to EN 301 549 for years. Ask suppliers: who does the testing, against which standard, and will you give me the raw findings rather than a summary slide?

2. Content design and microcopy

This is the line that gets absorbed into "design" and then quietly disappears. It shouldn't. Empty states, error messages, permission prompts, notification text, legal reassurance and the 40-odd strings that decide whether onboarding feels calm or chaotic are real work.

A first-pass UX copy deck for a moderately complex app runs £2,500–£8,000 depending on scope and whether you're writing for multiple nations. Ongoing content support, which you will want, is often £600–£1,500 a month.

Ask: who writes the strings, who owns them after handover, and can we see a sample of your microcopy before we sign? A supplier who can't show you three good error messages probably can't design your product's voice either.

3. App store asset refreshes

Screenshots feel like a one-off job. They're not. They're a seasonal asset, and they're often the highest-leverage design work you'll do all year, because most people decide whether to install based on them.

Budget £1,500–£5,000 per refresh cycle, and assume you'll want at least two in year one — one at launch and one after you've learned something from real conversion data. If you're running localised store listings for Scotland, Wales, Northern Ireland and beyond, multiply sensibly. If you're doing product page experiments on the App Store or Play Store, add design time for the variants.

Ask: who produces these, who owns the source files, and how quickly can we turn one around? The answer should be days, not weeks.

4. Customer support cover

Launch week support volume typically runs three to five times steady state, and it doesn't politely arrive between 9 and 5. It arrives at 11pm on a Sunday, in the middle of a bank holiday, usually about something you thought was obvious.

A dedicated UK support hire costs roughly £26,000–£32,000 a year once you've added employer costs, plus tooling at maybe £150–£400 a month. Outsourced per-ticket arrangements often come in at £3–£6 per contact, with out-of-hours cover carrying a premium. Either way, budget explicitly for a surge window of six to eight weeks after launch, and decide in advance what a weekend actually looks like.

Ask: what's your expected first-month ticket volume based on, and what's our escalation path at 2am?

5. The post-launch iteration reserve

Nobody enjoys this conversation. The app launches, the reviews are mixed, the analytics show everyone dropping out on step three, and suddenly there's no money left to fix any of it.

Set aside 15–20% of the build cost for the first three months of iteration. Not contingency — a real reserve with a name and a purpose. Release 2.0 usually lands somewhere in weeks two to six, and it's the release that determines whether your launch story has a second chapter.

Ask: what does your warranty actually cover, what counts as a change request, and what happens to the backlog after go-live? Get that last one in writing. "Warranty" is not the same as "roadmap".

Add it up before you're surprised by it

Run the numbers on a typical mid-complexity app and those five lines add something in the region of 20–35% on top of a build-only figure. That's not an argument for a bigger budget necessarily. It's an argument for honest scope.

If £40,000 in accessibility, content, store assets, support and iteration isn't available, that's a signal to ship a narrower product — fewer flows, fewer edge cases, fewer promises — rather than to hope the bill never arrives. It always arrives.

Put these in your supplier conversations

The five questions above work as a shortlist. Add three more: what's excluded from this quote and what would trigger a change request; who owns the code and assets at handover; and can we see a real cost breakdown from a past project? Anyone who can answer all eight without flinching is worth talking to.

The spreadsheet never tells the whole story. But the lines you leave out of it tell you quite a lot about the product you're actually going to end up with.