Two documents are open on your desk. One is from a freelancer who replied within an hour, asked three sharp questions, and quoted a number you can actually pay. The other is from an agency: sixteen pages, a discovery phase, a named project manager, a QA line item, and a number two and a half times the first. Both promise twelve to sixteen weeks. You are trying to work out whether this is a bargain and a rip-off, or two different products.

It is the second one. A freelancer and an agency are not two prices for the same mobile app. You are choosing between a single point of failure with direct communication and almost no overhead, and a managed team with continuity and redundancy that you pay a coordination premium for. Which is right depends less on the build than on how long the software must stay alive and who maintains it in month eighteen.

The tradeoff, stated properly

Strip the sales language and the structural difference fits in a line. With a freelancer, one person holds the code, the context, the decisions and the reasons. With an agency, several people hold pieces and a layer of process keeps those pieces in sync. Everything else follows. The freelancer carries no coordination cost, so more of your money becomes code. They also have a bus factor of one: if that person is unavailable the project does not slow, it stops. The agency spends a real fraction of your budget on staying organised, and in exchange nobody’s flu is an existential event.

Here is the part agencies leave out of the deck. A good senior freelancer often outperforms a mid-tier agency on a small, well-bounded build. Decisions take minutes rather than ticket cycles, one head holds the whole product model, and nothing is lost handing off between a designer, a delivery lead and two developers with four other accounts.

That same person is far riskier over three years. Not because they are unreliable, but because life is. They take a full-time job, move, have a baby or a back injury, find a client who pays more, or lose interest in an app that is now maintenance rather than creation. That is the arithmetic of depending on one human for a multi-year commitment they never agreed to. The freelancer is usually the better build and the worse decade. Decide which half you are buying, then buy the missing half deliberately rather than by accident.

Who fixes this in month 18

This is what actually decides it, and almost nobody asks during procurement. A mobile app is not a website you can leave alone. It sits on two operating systems that change annually, and both platform owners enforce that change with dates.

On Android, Google Play sets a target API floor and raises it every year. Since 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, with an extension available to 1 November 2026. Standing still costs more than a warning: Google’s rule is that apps targeting Android 14 (API level 34) or lower “will only be available on devices running Android OS that are the same or lower than your apps’ target API level”. Your app is not removed. It quietly stops appearing for anyone holding a recent phone.

On iOS the mechanism is the toolchain. Apple sets a minimum SDK for App Store Connect uploads, and since 28 April 2026 apps “must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26”. That floor moves with each OS generation, so an app whose build environment is two generations old cannot ship an update until somebody upgrades the project and gets it compiling against the new SDK. Not a fifteen-minute job on a codebase nobody has opened in a year.

A third clock runs underneath. Under Apple’s App Store Improvements process, developers of apps “that have not been updated within the last three years and fail to meet a minimal download threshold” get an email identifying the app for possible removal, then are “asked to submit an update within 90 days” to keep it listed. Apps that crash on launch go immediately. Existing users keep a working copy, but the listing goes.

So there is a degradation schedule you can diarise. Roughly every twelve months, somebody competent spends real hours on target levels, SDK upgrades, dependency bumps, deprecated APIs, renewed credentials and a device re-test, with no new features to show for it. An unmaintained app does not fail the day you abandon it. It fails on the platform’s calendar, and the failure looks like “we can’t ship the fix”. If your answer to who does that work in month eighteen is “the builder, if they’re still around”, you are relying on a maintenance arrangement you have not bought.

What the agency premium buys, and what it doesn’t

• Project management. Someone owning schedule, dependencies and chasing. Worth a lot if you have no capacity to run the project, near nothing if you would have run it well.
• Independent QA. A tester who is not the author. The most underrated line in an app quote, because developers cannot find their own blind spots and mobile’s device matrix punishes optimism.
• Design as a discipline, rather than a developer’s best effort at screens, including the empty states nobody remembers to ask for.
• Redundancy. If an engineer leaves mid-build, a second has read the code and the company has reason to backfill. You cannot buy this from one freelancer at any price.
• An enforceable counterparty: a company with a bank account, a registered address and a reputation that outlives your project. Suing an individual who has moved on is practically pointless at these amounts.

What it does not buy matters more. Not better engineers: an agency’s ceiling is whoever they hired, and the incentive is to staff the cheapest person who can plausibly do it. Not speed, because three people plus process are often slower to a working build than one strong person with no meetings. Not accountability by itself, since a firm can absorb a bad outcome and move to its next client. And not maintenance: the build agreement ends, the app’s obligations do not. Without a signed support arrangement carrying named response times, month eighteen is as unowned with an agency as with a freelancer.

The hybrids almost nobody asks for

The market presents this as binary. The three most useful arrangements are blends.

Freelancer plus a paid technical reviewer. Hire the strong individual for the build, and separately retain an experienced mobile engineer for a few hours a month to review the repository, the architecture decisions and the release process. You get the freelancer’s economics plus a second pair of eyes and, crucially, a second person who has read your codebase and could take it over. Good freelancers welcome that; the ones who take offence have told you something useful for free.

Small agency for the build, freelancer on retainer for maintenance. This inverts the usual assumption and often prices better. Buy the team, the QA and the redundancy for the weeks when parallel work genuinely helps, then move to a named individual on a monthly retainer for OS-cycle work, small changes and incidents, which one competent person holds comfortably. The condition is a real handover: documentation, a runbook, a recorded walkthrough and a fortnight of overlap, named in the build contract rather than requested afterwards.

An augmented team where you hold the product role. Instead of buying a project you buy people: one or two engineers, a designer part-time, a tester part-time, all working in your repository and your definition of done, while you or someone you appoint owns priorities and acceptance. You pay for skills rather than a delivery layer, and the institutional memory accumulates on your side. It works only if somebody on your side actually does the product job, weekly and in writing. An augmented team with an absent product owner is the most expensive way to build the wrong thing.

How each one fails, and the clauses that cover it

With a freelancer, the risks are availability, illness, disappearance and knowledge living in one head. The mitigations are boring and effective. Everything happens in a repository you own, with build pipeline and deployment targets in accounts under your billing, from week one rather than at handover. Documentation is a paid deliverable of every milestone, including a runbook: how to build, sign and release, and where the secrets live. Milestones run one to two weeks, so your maximum loss is one payment and a fortnight. Require a named continuity contact, the person they would hand to if hospitalised. Agree a notice period, an offboarding package, IP assignment covering subcontractors, and an explicit right to bring in an independent reviewer.

With an agency, three risks recur. Substitution: you interviewed a sharp senior engineer and got two juniors and a Slack channel. Fix it with a key-person clause naming individuals, committing a minimum share of their hours, requiring written notice before substitution, and giving you the right to refuse a replacement. Junior delivery behind a senior pitch: require a rate card by seniority and invoices reporting hours by person, not one line called “development”. A firm that will not say who wrote your code has made it impossible to assess what you are paying for. Change-order economics: fixed-scope agencies earn their margin on changes, so settle the process before signing. Fix the change rate in advance, define what counts as a clarification rather than a change, allow hours for discovered work neither side can yet specify, and agree that ambiguity in the scope resolves in your favour.

Comparing two quotes that are not comparable

You cannot set these numbers side by side as they arrived, because one prices fewer things. Normalise first.

One: restate both as the same deliverables list, covering design, the app, the backend and database, an admin panel, QA and device coverage, crash reporting, store submission and rejection handling, release automation, documentation, handover, and a post-launch stabilisation window.

Two: mark what appears in one and not the other. Freelancer quotes commonly omit independent QA, design polish, the admin panel, release automation and documentation, usually because nobody raised them. Agency quotes commonly include discovery and management you never asked for.

Three: price the missing items at the cheaper party’s own rates and add them to the cheaper quote. Suppose the freelancer is at $24,000 and the agency at $60,000. Add design help, an admin panel, a QA pass, release automation and a written handover, and the freelancer’s real figure might be $38,000. The gap survives, but it is no longer two and a half times, and it now sits between two comparable things.

Four: extend both to a 24-month total cost of ownership. On each side add two annual platform cycles of target-level and SDK work with dependency upgrades and device re-testing; store account fees; cloud, database and third-party services at your expected usage; a monthly allowance for incidents and small changes; and the line nearly everyone omits, the cost of a cold handover to somebody new. That last one is your bus-factor insurance premium: a code audit plus a new engineer’s ramp-up on an unfamiliar codebase. Price it as happening once inside the 24 months, because for solo arrangements it frequently does.

Due diligence, which differs for each

For a freelancer, references and a paid trial do most of the work. Ask for two clients who ran engagements of at least three months, and ask them two specific questions instead of “were you happy”: what happened when this person was unavailable, and who maintains that app now. Then look at the stores, where their shipped apps name a seller and both listings carry a last-updated date. Finally, buy a small real slice of work at their normal rate and judge the process as much as the output: the questions asked, whether they flagged something you had got wrong, how long replies took when nobody was chasing.

For an agency, reference calls are curated and the portfolio belongs to the firm rather than your team, so aim the questions at staffing. Ask who specifically will write the code, by name, and whether they are employees or subcontractors. Ask their notice periods, and what happens if one resigns in week six. Insist on speaking to the named engineer rather than the account manager, and use that call to pose a technical tradeoff question and grade the reasoning. Then check their case-study apps in the stores for recent updates, which tells you whether clients stay after launch.

The decision rule, stated plainly

Choose a freelancer when the build is small and well bounded, you or someone you trust can hold the product and technical judgement role, the app supports the business rather than being the business, you could survive a six-to-eight week gap if the person vanished, and you will put maintenance on a named retainer from day one.

Choose an agency when the app is the revenue or downtime costs you customers; when nobody on your side can run the project week to week; when scope crosses into regulated data, payments or security review; when a date requires several people in parallel; or when a multi-year roadmap means you need an organisation to still exist rather than a person to still be interested.

Choose neither yet when you cannot describe the app’s core loop in one sentence; when demand is unvalidated and this build is the test rather than the product; when nothing in the feature list needs the camera, offline use, push notifications or a home-screen icon, which means version one wants to be a mobile web app; or when the budget covers the build but not two years of ownership. A dead app is worse than no app.

One rule overrides the rest. If you can afford the build but not the upkeep, buy a smaller app from whichever party will sign a maintenance agreement. Scope is negotiable. The platform calendar is not.

If the conclusion you have reached is that the maintenance seat needs filling, or you want those two quotes normalised by someone who has read a lot of them, that is work AB7 Solutions takes on directly. We supply named mobile and backend engineers through contract staffing and staff augmentation, working inside your repository and your cloud accounts: the augmented-team and retainer-maintenance patterns above, with a bench behind them instead of one person’s calendar. We also build applications and APIs outright where a managed team fits better, and we will review a freelancer’s scope and continuity terms before you sign. The reason to call us for this problem specifically is what neither a solo freelancer nor most build shops offers: someone still responsible for the app through the OS cycles after launch, who will also say plainly when your existing freelancer is good and only the contract needs fixing. Call +1 321 341 7733, email ab@ab7solutions.com or director@ab7solutions.com, or start at www.ab7solutions.com.

Sources: Google Play Console Help, Target API level requirements for Google Play apps (Android 16 / API 36 from 31 August 2026, extension to 1 November 2026, device availability limits for apps targeting API 34 or lower); Apple, Upcoming requirements (Xcode 26 and iOS 26 SDK minimum for App Store Connect uploads from 28 April 2026); Apple, App Store Improvements (three-year update and minimal-download threshold, 90-day update window, immediate removal of apps that crash on launch). Platform requirements verified at time of writing and subject to change.