Every new hire raises your software bill. A CRM, field-service or project tool priced per seat looks modest at ten staff and becomes a major overhead at forty, yet no invoice asks whether the total has passed the cost of owning the software. This article gives you the crossover calculation — the formula, an AED table by team size and per-seat price, and the adjustments that move the flip point — so you can locate your own number.
The short answer: the formula, and the seat counts where it flips
Divide the five-year cost of owning a custom app by the five-year cost of one SaaS seat. The result is the seat count at which the two cost the same; above it, owning is cheaper on paper. The owning side: build quote + (5 × annual maintenance) + (5 × annual hosting). The seat side: monthly per-seat price × 12 × a rise factor — 5.00 if prices never rise, 5.53 at a 5% annual rise, 6.11 at 10%.
On the illustrative assumptions used throughout — maintenance at 20% of the build quote a year, hosting at AED 300 a month, seat prices rising 5% a year — a firm paying AED 200 per seat per month crosses over at about 11 seats against a AED 60,000 build, and about 21 seats against AED 120,000. Every figure below is worked arithmetic, not market data.
The problem: a bill that grows with every hire, compared against nothing
Per-seat pricing is designed to feel small. The decision is framed monthly — one more licence for one new starter — so the annual and five-year totals are never presented to anyone.
The comparison is unfair: vendors quote a monthly per-seat price, builders a one-off project, so the monthly figure always looks trivial and the project always looks large.
The two five-year sums, side by side (formula box)
Five-year SaaS cost = seats × monthly per-seat price × 12 × rise factor — 5.00 at 0% annual rises, 5.53 at 5%, 6.11 at 10%. Add any setup or migration charges your vendor applies.
Five-year custom cost = build quote + (5 × annual maintenance) + (5 × annual hosting, database and backups) + your own time specifying and testing. Maintenance must come from your builder's written quote; where none exists, run the sum at more than one assumed percentage.
One anchor for scale: WebStackRank's Basic Business Web App starter is AED 4,990 for a basic app of defined scope — a starter, not a like-for-like replacement for a mature SaaS platform. Crossover-scale builds are quoted individually, so the table is parameterised for your own quote.
The crossover table: seats × per-seat price, in AED (worked scenarios)
Assumptions, all illustrative: maintenance at 20% of the build quote per year, hosting at AED 300 a month, seat prices rising 5% a year. One seat then costs AED 6,631 over five years at AED 100 a month, AED 13,262 at AED 200 and AED 23,208 at AED 350. Owning costs AED 78,000 over five years against a AED 30,000 build, AED 138,000 against AED 60,000 and AED 258,000 against AED 120,000. Dividing one by the other:
| Build quote (your input) | AED 100 per seat/month | AED 200 per seat/month | AED 350 per seat/month |
|---|---|---|---|
| AED 30,000 | Custom cheaper from ~12 seats | From ~6 seats | From ~4 seats |
| AED 60,000 | From ~21 seats | From ~11 seats | From ~6 seats |
| AED 120,000 | From ~39 seats | From ~20 seats | From ~12 seats |
Read it honestly: at low seat prices and high build quotes, the crossover sits beyond most firms' size and SaaS wins outright. Price rises move every cell earlier — at a 10% annual rise, the middle row's AED 200 crossover falls from 11 seats to about 10; with no rises, it slips to about 12. Only your own quote inputs should drive a decision.
The costs that move the crossover earlier (idle seats, price rises, premium-tier creep, integration add-ons)
Idle seats. Licences for leavers, seasonal staff and people who never log in are pure addition to the SaaS side. Reprice per used seat: divide the seat price by the share of seats actually used. Purely as arithmetic, if a fifth of seats sit idle, an AED 200 seat effectively costs AED 250 per used seat, and the AED 60,000-build crossover falls from 11 seats to about 9.
Price rises. A 5% annual rise compounds, which is why the rise factor is 5.53, not 5.25. Use your vendor's real renewal pattern, not a guess.
Premium-tier creep. If one needed feature sits on a higher tier, the whole team moves up, not one user. Use the tier you will occupy in year three, not the one you signed up on.
Integration add-ons. Paid connectors and per-flow automation charges belong in the seat-side sum: a custom build absorbs the same connections into its own scope.
The costs that move it later (maintenance, hosting, your time specifying and testing)
The custom side has its own costs, and understating them rigs the maths the other way. Maintenance is the largest: patching, backups, monitoring, small fixes and forced updates when components change. Leaving it out flatters the build side as surely as ignoring price rises flatters SaaS.
Hosting and backups are smaller but permanent. Your own time is the most omitted line: someone senior must specify the workflow, test releases and decide changes, during and after the build.
Where SaaS still wins at almost any size (commodity tools you should never build)
Some categories should stay subscribed at any headcount. Email, accounting and payroll, video meetings, payment processing and document tools are commodities: the vendor spreads development, security and regulatory updates across thousands of customers. Rebuilding them means paying alone for what the market maintains collectively.
SaaS wins below the crossover and on a short horizon. The table is a cost test, not a building licence, and for commodity tools it should never be run.
The hybrid most firms land on: buy commodity, build the one core workflow
Most firms that run these numbers land in the middle. Commodity tools stay subscribed. The one workflow that is theirs — the job-tracking sequence, the order flow, the approval chain staff bend spreadsheets around — is the custom-build candidate.
The hybrid disciplines the crossover: a narrow tool doing one workflow is a smaller build than a platform replacing three subscriptions, so its flip point arrives earlier.
Decision criteria and how to run your own numbers in an hour
Four inputs, all obtainable quickly. One: twelve months of invoices, listing seats paid each month, so idle seats show up. Two: the vendor's per-seat price for your tier, from its official pricing page, plus your renewal history. Three: a build quote for the narrow workflow, with annual maintenance in writing. Four: your expected headcount in two to three years.
Then run the formula at today's seats and at the future count, stress-testing the rise factor at 0%, 5% and 10%. Decide on the pattern, not a single cell: if custom wins across most assumptions and the workflow passes the commodity test, the case is real; if it wins only on optimistic assumptions, it is not a case yet. Our guide to how much a website and app project costs explains what drives the build quote itself.
Common mistakes (comparing a monthly fee to a build quote; forgetting maintenance; counting licences you don't use)
The founding mistake is comparing a monthly fee with a project quote and calling the fee cheaper; over five years that fee is a project-sized sum paid in instalments, with nothing owned at the end. The mirror-image mistake is pricing the custom side as the build quote alone — no maintenance, hosting or specification time — manufacturing a crossover reality will not honour.
Seat-count errors run both ways: counting unused licences inflates the SaaS side, while counting every employee as a seat, when only part of the team uses the tool, rigs the sum towards building. Using today's entry-tier price when an upgrade is foreseeable understates the seat side.
FAQ
At what team size does a custom app usually become cheaper than SaaS?
There is no universal headcount: it moves with your per-seat price and build quote. On this article's illustrative assumptions it ranges from about 4 seats, for an expensive tool against a small build, to about 39 seats, for a cheap tool against a large build. Run the formula with your own two numbers.
How much should I budget each year to maintain a custom app?
There is no standard percentage to take on trust. Ask every builder quoting you for a written annual maintenance figure — patching, backups, monitoring, small fixes — and use it in the five-year sum. The 20% of build cost in the examples here is an illustrative assumption, not a market rate.
Should part-time and seasonal staff count towards the seat count?
Count the seats you actually pay for across the year, not your headcount. Seasonal staff holding paid seats for twelve months cost twelve seat-months each, logged in or not. Check whether your plan allows reductions at renewal or cheaper light-use seats.
If we are past the crossover, does that mean we should build?
No. The crossover is a cost threshold, not a decision. Building must also pass the fit test: a stable workflow, specific enough to your business to be worth owning, and not a commodity a mature product handles better. Many firms past their cost crossover stay on SaaS for good non-cost reasons.
What if our team is still growing quickly?
Run the table at today's seat count and at the headcount you expect in two to three years. SaaS cost grows with every hire while owning cost barely moves, so a firm below the crossover today may cross it mid-contract.
Past your crossover? Scope the build (CTA)
If your own numbers put you past the crossover for one core workflow, the next step is a scoped quote for that workflow alone, with maintenance stated in writing. WebStackRank builds custom web applications on that basis: an itemised proposal within 24 business hours, 50% deposit to begin and 50% at launch, full ownership of the code on final payment. Bring your worksheet and we will test it rather than applaud it — if the numbers say keep subscribing, that is the advice you will get. Questions first? Contact us or WhatsApp +971 52 595 3174.
