Build, Buy or Hire: What a Developer Actually Costs, and the Line AI Moved

You've got a problem in your store. Checkout leaks, the feed is a mess, or you need a bundle feature that no app quite does. Someone says build it. Someone says buy an app. Someone says get an agency.

Everyone in that conversation is guessing, because nobody has costed any of the three properly. So let's cost them, using HMRC's published rates, public salary data and vendor pricing pages, and let's include the fourth option that never makes the list.

There are four options, not three

Configure

Do it with what you already own. Unfashionable, free, and correct more often than anyone admits. A surprising share of "we need a developer" requests are settings nobody has read the documentation for. Shopify shipped over 150 changes in one Editions release; some of what you're about to pay for probably arrived free in the last year^[1].

Buy

An app or SaaS product. Fast, metered, and the price grows with your business by design.

Hire

An employee. Slow to start, cheapest per hour at volume, and carries costs that never appear in the salary conversation.

Contract or agency

Expensive per day, no employment overhead, and the quality range is enormous.

If the thing you're weighing is a whole platform rather than a feature, start with the platform choice piece and the replatforming piece instead, because those decisions have different economics entirely.

Always price all four. The moment you frame it as build versus buy you've already excluded the option that wins about a third of the time.

What hiring actually costs, from HMRC's own tables

People compare a salary to an agency day rate and conclude the salary is cheaper. It isn't, and the gap is bigger than most founders think.

Employer National Insurance

For 2026 to 2027, employer secondary Class 1 National Insurance is 15%, charged from a secondary threshold of £5,000 a year^[2]. Employment Allowance for the year is £10,500^[2].

That threshold is the part that changed the maths. NI now applies to almost the entire salary rather than kicking in part way up, so on a £55,000 developer you're paying 15% of £50,000. Employment Allowance offsets some of it if you qualify, and many growing businesses do, which is worth checking rather than assuming.

The full loaded cost

Line	On a £55,000 salary	Source
Gross salary	£55,000	Your offer
Employer NI at 15% above £5,000	£7,500	HMRC[2]
Employer pension, minimum 3%	~£1,400	Auto-enrolment minimum
Holiday, 28 days statutory	Already in salary, but it's 11% of the year	GOV.UK[3]
Equipment and software	£1,500 to £3,000 year one	Estimate
Recruitment	15 to 25% of salary if agency-sourced	Market rate
Year-one cash cost	Roughly £70,000 to £78,000	Sum, before Employment Allowance

Against about 225 working days after holiday and typical sickness, that's an effective day rate of roughly £310 to £350 for an employee you're paying £55,000.

Now compare that to a contractor day rate. The gap narrows enormously, and it disappears completely if you don't have twelve months of work to give them. Which is the actual question: not what does a developer cost, but do you have a year of work.

Getting the salary number right

Use published data rather than what a recruiter tells you. ONS publishes UK earnings by occupation^[4], and IT Jobs Watch tracks advertised rates for specific skills like Shopify development from actual job postings^[5]. Both are free.

The IR35 question, before you get creative

If you're thinking of hiring someone full-time as a contractor to avoid the employment overhead, read the off-payroll rules first^[6], and understand that employment status is determined by the reality of the working relationship rather than by what the contract calls it^[7]. ACAS covers the practical side^[8].

A single contractor working your hours on your systems under your direction for a year is an employee wearing a different invoice. HMRC has views about this and they're expensive views.

Does this actually impact you? Classify the problem first

The right answer depends almost entirely on which of four things you're actually facing.

A configuration problem

The capability exists and isn't switched on or set up correctly. Never hire for this. Buy two days of a specialist's time or read the documentation.

An integration problem

Two systems that need to talk. Contract or agency, with a clear spec and a maintenance clause. Do not hire an employee for one integration, because the work ends and the salary doesn't.

A bespoke feature problem

Something your business does that no app models. This is the genuine build case, and the test is whether the thing is a competitive difference or just a preference. Preferences should bend to the software.

An ongoing product problem

You need continuous change, not a project. This is the only case where hiring is clearly right, and it needs at least a year of visible work to justify the loaded cost above.

What we found: AI moved the line, but not where the pitch says

The claim is that AI coding tools make building cheap, so build more. The primary data on how developers actually experience those tools says something more specific.

The 2025 Stack Overflow Developer Survey, the largest recurring survey of working developers, found 84% using or planning to use AI tools, with 47.1% using them daily. And then the awkward part. 46% actively distrust the accuracy of AI output against 33% who trust it, with only 3.1% saying they highly trust it. The top frustration, at 66%, is AI solutions that are almost right but not quite. And 45% report that debugging AI-generated code is more time-consuming^[9].

What that actually means for your decision

Read those numbers together and a pattern falls out. AI makes writing code faster and makes verifying it slower. Which changes the economics unevenly.

Type of work	Effect of AI tools	Decision impact
Throwaway scripts, data migrations	Dramatically faster	Build more of these yourself
Well-specified small features	Meaningfully faster	Build tips slightly more attractive
Integrations with real failure modes	Faster to draft, same to verify	Little change. Verification was always the cost
Anything touching payments or stock	Faster to draft, riskier to accept	Buy, or hire someone who reads it properly
Long-lived systems	Faster to write, harder to maintain if unreviewed	Unchanged. Ownership is the cost

The build-versus-buy line moved for prototypes and barely moved for production. Anyone quoting you a build on the basis that AI halves the cost is quoting the writing and ignoring the reviewing, and the survey data says the reviewing got worse^[9].

I'd add a first-hand note. The code these tools produce is usually plausible, which is a specific and dangerous property. Wrong code that looks wrong gets caught. Wrong code that looks right ships.

What buying actually costs

Apps look cheap because you compare a monthly fee to a project fee. Two things get missed.

Metered pricing compounds

Most ecommerce apps price on something that grows without you doing anything: orders, profiles, sessions, GMV. That's fair, and it also means your app bill grows with your revenue while a one-off build's cost stays flat. Over five years the ranking can invert.

The switching cost is the configuration

Exporting data is easy. Rebuilding the rules, flows and templates you configured over three years is a fortnight nobody scheduled. This is the real lock-in in almost every category, and it's why entry tiers are cheap.

The honest counterweight

And before you conclude your app stack is bloated and needs replacing with a build, check the actual numbers in the app bloat piece. The problem is smaller than the discourse.

Bought software gets maintained, patched, and updated against platform changes by somebody else. That is worth a great deal and it's the thing build advocates consistently undervalue. Which brings us to the line nobody budgets.

The maintenance line that sinks builds

Every custom thing you own needs somebody to look at it forever, because the platform underneath it moves.

Shopify

A new API version quarterly, each supported for at least 12 months, with at least 9 months of overlap^[10]. That's a generous policy and it still means every custom integration needs an annual review, forever. New public apps have had to use GraphQL since April 2025^[11], so REST-based custom work carries migration debt.

Adobe Commerce

Version lifecycle governs everything, and support windows are hard dates^[12][13]. A custom module is version-bound, so your upgrade project and your custom-code project are the same project whether you planned it that way or not.

WooCommerce

The core REST API is stable^[14]. Your risk is the plugin stack around it. High-Performance Order Storage moved where orders live, and any custom code that queried the old tables directly is broken or getting there^[15]. On Woo, custom code is cheap to write and unpredictable to maintain, which is the opposite of the usual story about self-hosted platforms.

BigCommerce

Low churn, clean REST management APIs, the calmest of the four to own custom code against^[16]. Watch the GMV thresholds that auto-upgrade your plan when you model total cost^[17].

The number to put in the model

Budget 15 to 25% of the original build cost, every year, forever, for anything custom you own. It's an estimate rather than a measured figure, and I'd defend it as conservative. Anyone quoting a build without a maintenance line is quoting half the project.

The decision table

One row per situation. This is the artefact.

Situation	Do this	Not this
Capability exists, not configured	Two days of a specialist	Anything else
One integration, clear spec	Contract, fixed scope, maintenance clause	Hire an employee
App exists at 80% fit	Buy it. Change your process for the 20%	Build for the 20%
App exists but pricing scales badly	Buy now, model the build at year three	Build now on principle
Genuinely bespoke, competitive edge	Build, with a maintenance budget	Bend it into an app that doesn't fit
Continuous change, 12+ months visible	Hire	Rolling contractors at day rates
Under £2M revenue, no technical staff	Buy and configure	Build anything
Nobody can specify the requirement	Two days of discovery, paid	Any build. It will be built twice
Urgent, business-critical, today	Contract a specialist	Start a hiring process

The row I'd defend hardest is the 80% one. Most bespoke builds exist because somebody refused to change a process to fit good software. That refusal costs more than the software, forever, and the process was usually an accident in the first place.

The five contract clauses that matter

If you go the agency or contractor route, these five decide whether you own the outcome. I've been on both sides of all five.

IP assignment. Explicit, on payment, covering everything produced. Absent this, in some jurisdictions the contractor owns the code you paid for.

Source access. You get the repository, with history, on a service you control. Not a zip file at the end.

Maintenance and platform versioning. Name it, with a response window. Otherwise the API upgrade arrives as a new quote in eighteen months^[10].

Handover documentation. A named deliverable with acceptance criteria, not a promise. What it does, how to run it, what breaks it.

Third-party dependencies. Listed, with licences and who pays for them. The number of builds I've seen with a paid API key registered to a contractor's personal email is not small.

Building with AI, and who the regulator thinks you are

One genuinely new consideration if the thing you're building or buying involves AI.

The obligations differ depending on whether you built the system or deployed somebody else's, and merchants building their own recommendation, pricing or chat systems can take on responsibilities they'd avoid by buying. That's a real factor in a build-versus-buy decision now and it wasn't three years ago. Our EU AI Act compliance guide for ecommerce sets out where the line falls for a merchant.

Buying isn't automatically safer. It does move some of the paperwork to somebody whose job it is.

What agents change about the decision

Modest but real, and it cuts toward buying.

Agentic commerce protocols are moving specifications with named versions, maintained by consortiums^[18][19]. Building your own compliance with a spec that's still changing means re-implementing it every time it changes. That's exactly the kind of work platforms and vendors absorb well and individual merchants absorb badly.

How urgent? Not very. Kaiser and Schulze's peer-reviewed work across 973 sites puts ChatGPT under 0.2% of ecommerce traffic^[20], against Shopify reporting AI-referred orders up roughly 13 times year on year^[21]. Small, fast-growing.

The sensible position is to make your product data clean and standards-compliant, which helps regardless, and to let somebody else chase the spec revisions.

What to do this week

• Classify the problem. Configuration, integration, bespoke, or ongoing. The answer follows from that more than from anything else.
• Calculate the loaded cost of your proposed hire. Salary plus 15% NI above £5,000, plus pension, divided by 225 days^[2].
• Check Employment Allowance eligibility before you model NI at full rate^[2].
• List twelve months of work for the hire. Actually list it. If you run out at month five, contract instead.
• Add a maintenance line to any build quote at 15 to 25% a year, and see whether the comparison survives it^[10].
• Read your last agency contract for the five clauses. Particularly IP and repository access.
• Check whether the thing you're about to buy arrived free on your platform in the last twelve months^[1].

The takeaway

A £55,000 developer costs roughly £70,000 to £78,000 in year one and about £310 to £350 a day of actual availability, once you apply 15% employer NI from a £5,000 threshold^[2]. That makes contracting much more competitive than the headline comparison suggests, unless you genuinely have a year of work.

AI tools shifted the economics for scripts and prototypes and barely shifted them for anything touching money or stock, because 46% of developers distrust the output and 45% say debugging it takes longer^[9].

And the maintenance line is where builds go wrong. Not the build.

I've argued for building things I should have bought, more than once, mostly because building was more interesting. The bundle engine I insisted on writing in 2019 took nine weeks and got replaced by an app in 2022 that did more for £29 a month. Nobody remembers the nine weeks except me.

What's the twelve-month maintenance cost of the thing you're about to build? If nobody's said a number out loud, that's the conversation to have first.

Sources

1. Shopify, "Shopify Editions". Accessed 22 July 2026.
2. HM Revenue & Customs, "Rates and thresholds for employers 2026 to 2027". Employer secondary Class 1 NI 15%; secondary threshold £5,000/year; Employment Allowance £10,500. Primary government source.
3. GOV.UK, "Holiday entitlement". Accessed 22 July 2026.
4. Office for National Statistics, "Annual Survey of Hours and Earnings, 2025". UK national statistics.
5. IT Jobs Watch, "Shopify Developer" advertised rates. Derived from UK job postings. Accessed 22 July 2026.
6. HM Revenue & Customs, "Understanding off-payroll working (IR35)". Accessed 22 July 2026.
7. GOV.UK, "Employment status: employee". Accessed 22 July 2026.
8. Acas, Advisory, Conciliation and Arbitration Service. Accessed 22 July 2026.
9. Stack Overflow, "2025 Developer Survey". 84% using or planning to use AI tools; 46% distrust accuracy vs 33% trust; 66% frustrated by "almost right, but not quite"; 45% say debugging AI-generated code is more time-consuming.
10. Shopify, "API versioning". Quarterly releases, 12-month support, 9-month overlap. Accessed 22 July 2026.
11. Shopify, "New public apps must use GraphQL from April 2025". Developer changelog.
12. Adobe, "Software lifecycle policy". Accessed 22 July 2026.
13. Adobe, "Released versions". Accessed 22 July 2026.
14. WooCommerce, "REST API". Accessed 22 July 2026.
15. WooCommerce, "High-Performance Order Storage". Accessed 22 July 2026.
16. BigCommerce, "Orders API". Accessed 22 July 2026.
17. BigCommerce, "Pricing". Accessed 22 July 2026.
18. Agentic Commerce Protocol, specification repository. Maintained by OpenAI and Stripe.
19. Google, "Under the Hood: Universal Commerce Protocol (UCP)". Google Developers Blog.
20. Maximilian Kaiser and Christian Schulze, "ChatGPT Referrals to E-Commerce Websites", Marketing Science. Peer-reviewed; 973 sites, $20B revenue.
21. Shopify, financial reports, Q1 2026. AI-referred orders up roughly 13x YoY.