How to get an app built: freelancer or agency, cost and contract

You have a product idea, and perhaps customers already waiting for it. You need someone to build it. Hiring an employee means a salary, employer contributions, and a notice period on the day you part ways. So you think of an independent developer, a freelancer, found through your network or on a matching platform, or of a development agency, a company whose business is building software for others.

Before comparing developers or agencies, compare the contracts they offer. The contract decides who pays when your requirements change, when your users will get their hands on the product, who owns the code and how you will be able to leave. The accounts that keep your application running, and what happens on the day the person who knows the code is no longer available, are also settled before the first day.

What a freelance developer brings

They build what you entrust to them: a web application, a mobile app, a feature added to existing software. They often choose the technologies too.

You do not pay what an employee costs on top of salary: no employer National Insurance contributions, no workplace pension contributions, no holiday pay, no Statutory Sick Pay and no recruitment firm fees. And you work directly with the person who builds your software, with no intermediary.

You also choose a developer specialised in the technical piece your product needs: a mobile app, an online payment system, a connection to another system. You do not have to employ a full-time generalist. And they can start right away, whereas a candidate who already has a job must first resign and serve their notice period with their current employer before joining you.

They are paid for their work, whether or not your product finds its customers. A technical co-founder paid in equity, on the other hand, ties their future to your company’s.

What an agency brings, and what it does not replace

An agency builds what does not exist yet: a website, a mobile app, custom software. You have no position to create and no probation period to wait out. You sign a contract with a company, and development begins.

When an employee, a partner or a freelance developer writes the software alone, the knowledge of it rests on one person. An agency can put several developers on your product, and replace the one who leaves. It does not always do so: ask how many people will know your code.

App development cost: three ways to pay

A freelance developer or an agency most often bills in one of two ways. Billed by the day, it is time and materials: you pay for the time spent, at the agreed day rate. Billed by the project, it is a fixed price with fixed scope: one price for a list of features described at signing.

There is a third way to pay, which does not rest on an estimate. Under a fixed-budget, flexible-scope contract, the price is fixed, and so is the problem to solve. What stays flexible is how it is addressed: the features developed.

Your requirements will change along the way: your first users will show you what is missing and what nobody uses. Each of these contracts answers one question differently: who pays for that change?

Under a fixed price with fixed scope, the provider bears any error in estimating the signed list. The client bears the change in requirements, one contract amendment after another. Under time and materials, the client bears both. A change needs no amendment, but every extra day is added to the invoice.

The gaps can be large. Across 4,677 IT projects, the actual cost reached on average 1.8 times the estimated cost, or 80% more, according to a study published in 2022 by Bent Flyvbjerg, a professor at the University of Oxford, and his co-authors. This average is driven by a minority of projects with extreme overruns: in the same sample, the median overrun is close to zero. But nobody knows, at signing, which side their project will fall on.

Under a fixed-budget, flexible-scope contract, no feature list is signed: a change costs neither an amendment nor an extra day. The budget stays the same when requirements evolve; the features developed adapt. In return, this model asks for your time. You decide what has the most value for your users, and you reprioritise when your market changes. If you cannot give it that time, this contract is a poor fit.

A fixed price with fixed scope remains suited to requirements that will not change. A product still looking for its customers is not in that position. Price and schedule are not built the same way under a fixed price and under time and materials.

The cost of developing custom software depends on the time you decide to invest in its development and in its day-to-day adjustments to keep up with your business, weighed against what its absence costs you.

Before signing, ask your provider this question: if my requirements change, what changes in what I pay?

What the contract says about change

The UK government’s digital, data and technology playbook describes how a fixed-scope contract works: it rests on “a perfect specification that is fully costed and bound into a commercial agreement”. When the specification is imperfect, it produces “change requests to manage time, overruns or scope reductions which do not manifest themselves until much later in the contract”. And a clause saying that changes must be made in writing holds: in Rock Advertising v MWB [2018] UKSC 24, the Supreme Court held that a clause preventing a contract from being varied other than in writing is legally effective.

For a startup, this bites from the very first months. Your first users teach you what they are missing, and what is of no use to them. Every change to the signed list becomes an amendment, priced separately, that you pay for.

In France, in 2020, the Paris Commercial Court rejected the refund claim of a young company that had had two mobile apps and a website developed with an agile method, without a written specification. It had changed provider, and was claiming back the sums paid to the first one. According to Le Monde Informatique, the court noted that the agile method “leads to many back-and-forths between the parties”, and that the difficulties raised “are not abnormal in nature”.

In our view, two things protect you in that case: seeing the software in your users’ hands all the way through, and being able to end the contract as soon as it no longer suits you.

What you receive, and when

In France, a practical guide on developing a mobile app, published in 2015 by Syntec Numérique (now Numeum, the trade federation of digital companies) with the law firm Staub & Associés, also describes how a fixed-price project unfolds. The provider first produces a mock-up of the application, the storyboard, which includes “the detailed functional specifications”. They make sure the client accepts it “before starting the development work”.

Then comes development, followed by acceptance testing, the stage where the client checks that the application conforms. In the sample clause, the client has 10 days for an initial check, then 30 days of checking in live use. For the provider, signing the acceptance report is an important step: it “releases the provider from its contractual obligations and generally triggers a significant payment milestone”.

In this model, your users discover the product once everything has been developed and checked. Under time and materials, nothing in the model requires usable software to be put in your users’ hands as development goes along.

Yet for a startup, it is use that tells you whether the product meets a need. The sooner your users have it in their hands, the sooner you know what to change. A minimum viable product exists precisely to check this.

So ask your provider when your users will be able to use the software.

You decide what to build, the provider decides how

Marty Cagan, founder of the Silicon Valley Product Group, a firm that trains product teams, was senior vice president of product and design at eBay. He identifies four risks in any product: nobody wants to buy or use it, nobody understands how to use it, it cannot be built with the time, skills and technology available, or it does not sustain the business. He assigns feasibility to the engineers, and both customer demand and viability for the business to the product manager.

In your startup, the product manager is you. The provider is responsible for feasibility. Whether customers want your product, and whether it sustains your company, remains your responsibility, whoever writes the code.

When the contract becomes an employment contract

UK law draws the same line between what you decide and what the provider decides. Whether someone is self-employed depends on several factors, not on the label alone: GOV.UK describes a self-employed person as someone who runs their business for themselves and takes responsibility for its success or failure, and lists among the signs that they are not under direct supervision when working. HMRC’s Employment Status Manual treats control, that is control over what the worker has to do and where, when and how they do it, as a significant pointer towards employment. French courts also look at the actual working conditions: Pierre Bonneau, a partner specialising in employment law at CMS Francis Lefebvre, points out in a 2016 article that they look at the actual conditions of the work, not at what the contract says. Among the indicators he cites: supplying the work tools, setting working hours, regular reporting, an assessment that can lead to sanctions.

Calling the developer self-employed does not settle it: their employment status determines their rights and your responsibilities as an employer, and courts and tribunals can make the final decision (GOV.UK).

So you set the expected result, and you judge what is delivered. The hours, the tools and the way of working remain theirs. If you want someone working full time under your direction, what you need is an employee, for example a first developer.

The same goes for an agency: it chooses its own way of working. If you want developers in your team, to whom you hand out work every day, that is recruitment, or staff placed with you on a time-and-materials basis. HMRC’s guidance on employment intermediaries describes an intermediary as a business that supplies workers to work for a client, and sets out the tax and National Insurance obligations that follow.

Who judges the provider’s work when you are not technical?

Judging what is delivered means being able to read it. A non-technical founder sees the screen, not the code.

What they have built, and what they have kept alive. Before signing, ask the provider to show you software they have put into production, then kept developing over several years. And ask their former clients how they work when a problem comes up.

An outside technical eye. A fractional CTO can read the code on your behalf: they check the work delivered, and defend your interests with the provider.

Who owns the code: the written assignment

When an employee creates software in the course of their employment, their employer is the first owner of the copyright, unless they have agreed otherwise (section 11(2) of the Copyright, Designs and Patents Act 1988). This rule covers employees, and applies neither to a freelance developer nor to an agency.

Paying the invoice does not make you the owner of the code. GOV.UK explains that a commissioned work stays with its creator unless the rights are assigned, and an assignment is not effective unless it is in writing signed by or on behalf of the person assigning (section 90(3) of the same Act). The development contract must therefore state in writing what is assigned or licensed to you. Do not rely on an implied licence: have the assignment say what is assigned.

State in the contract each right assigned, and define its scope, its purpose, the territory where it applies and its duration. State, too, whether the assignment is exclusive. If it is not, the provider can exploit the same code elsewhere, or license it to other companies.

Part of the code can also remain the provider’s. The French Syntec Numérique guide, intended for providers “of all sizes” that develop mobile apps, advises them to exclude their “prior knowledge” from the assigned rights in advance. Its model clause provides that the provider “remains the full owner” of the “means, processes and know-how” it uses, and grants the client “a non-exclusive right of use” to them.

This clause protects know-how that the provider reuses from one client to the next. For you, it means that part of your application’s code may not belong to you: you only have the right to use it, under licence. The same model clause allows the client to sublicense it “to any person of its choice”: that is what will let you hand your application over to another developer later. Ask which parts of the code remain the provider’s, and check that your contract leaves you that freedom.

Without an assignment, nothing in the contract obliges anyone to hand you the code on the day you ask for it. A first-hand account published in 2008 on LinuxFr.org, a French site, describes such a case. Have a lawyer review the clause before signing.

The accounts: domain name, hosting, repository

Software is more than its code. To be online, it also needs a domain name, a host, and a repository, the place where its source code is kept. If these accounts are opened in the provider’s name, the provider is the one with access: you will need them for every change, and to leave.

Open these accounts in your company’s name before the first day of work, and give the provider access. For a mobile app, do the same with the accounts used to publish it on the app stores. When you move to someone else, you simply revoke their access.

To be able to reach the source code if the provider defaults, the French legal news site Le Monde du Droit recommends an escrow agreement: the code and its documentation are deposited with a third party, and updated at an agreed frequency. In our view, a repository opened in your company’s name settles the question more simply: you have the code every day, without waiting for the provider to default.

When the developer is no longer available

With a single developer, another client project, holidays or illness are enough to make them unavailable. As long as the knowledge of the software is not written down, it leaves with them.

From the start, ask them what another developer would need to know to take over the software: how to install it, how to deploy it, which tests check that a change does not break what was working. And have it written down as the work progresses.

If they have already left, taking over the application with another provider starts with securing access and writing tests before any change.

Being able to leave

A provider should also be chosen on how easily you can leave them. Mélina Loupia, a journalist specialising in technology and cybersecurity, warns in a guide published by the French technology news site Clubic in February 2026 that without a reversibility clause, a company can find itself unable to change provider without losing months of work. The contract must cover data recovery, access to configurations, handover of documentation and the notice period. That notice is often two months. Leaving a fixed-price contract on a fixed scope before completion has a cost, and what it is depends on the contract’s termination clause: read that clause before signing. Fixed-price contracts also often carry termination penalties.

A clause in writing does not prove that leaving is possible. Only a trial run proves it. Do it once, before you need it: ask for the code and the documentation to be handed over to you, then give them to someone other than the provider. If that person manages to get the software running from what you were given, you can leave.

Being able to leave also changes the relationship. In our view, when the client can end the contract at any time, their provider has every reason to do the job well: otherwise, the client ends the contract.

When a freelance developer or an agency is the right answer

Y Combinator, an American startup accelerator, advises non-technical founders that their team should have the skills to build its product itself, rather than handing it to someone else. Bringing in a freelance developer or an agency means handing your product to someone else. In our view, this advice matters most when your product is first and foremost a technology, whose technical difficulty is what makes it valuable. Technical decisions there are strategic decisions, and they belong to a technical co-founder.

In our view, a freelance developer is the right answer when the work has a clear outline and someone other than them can judge what they deliver. Three situations lend themselves to it.

A precise skill on a product that already exists. A connection to accounting software, an online payment system.

An MVP, the minimum viable product. It is not a first version of the product, but the smallest test that checks whether the idea is worth building. Decide before the first line of code whether this test is disposable or will become the foundation of your product. If it becomes the foundation, its code must be production quality from the start, and everything above applies: the assignment, the accounts, the takeover.

A founder with support. A partner, a fractional CTO or a technical adviser reviews what is delivered.

If your product has to keep changing for years, the developer who builds it will not necessarily be the one who maintains it. The assignment, the accounts and the documentation are settled before the first day.

In our view, an agency suits you when several developers need to know your product’s code, provided the contract says so: ask how many people will know it.

A freelance developer or an agency has to be paid in cash. If your product has to move forward before you have funds, that leaves the technical co-founder, paid in equity, at the price of part of your company’s capital.

Questions to ask before signing

• What have you put into production, and kept developing? Their work, and what their former clients say about it.
• If my requirements change, what changes in what I pay? Under a fixed price with fixed scope, every change goes through an amendment; under time and materials, it adds days to the invoice; with a fixed budget and flexible scope, the amount does not change, only the priorities do.
• When will my users be able to use the software? A date when they have it in their hands, not a project end date.
• Who on your side will know my product’s code? And what happens if that person leaves?
• Does the assignment of rights name each assigned right? Which parts of the code remain under licence, and can I hand them over to another developer?
• Are the accounts in my company’s name? The domain name, the hosting, the code repository, the publishing accounts.
• How can I leave? The notice period, the return of the data, the handover of the documentation. And the trial takeover, once.
• Who will judge the quality of the work delivered? If you are not technical, someone who is.
• Are you setting a result, or working hours? A result belongs to a service contract, working hours to an employment contract.

DEVEDANOS: an agency on a fixed budget

Of these three contracts, we chose the fixed-budget, flexible-scope contract, because a product looking for its customers changes along the way. You can change direction whenever you want, with no contract amendment and at no extra cost.

We also make the technical decisions your product calls for, as a CTO would: the technologies, the architecture, how it is tested and put into production. We align them with your objectives.

At DEVEDANOS, we develop your custom software, usable within a month, for a fixed monthly budget, and we adjust it continuously as your business evolves. The budget is built with you, from your figures and your goals: together, we set the amount and the problem your application has to solve. Your application’s users work with it from the first month of development, and how they use it determines the next feature or features.

Our approach is adaptive: it predicts what is predictable, the monthly budget and the development days per month, and does not try to predict what your users will do with a feature before they have it in their hands.

And so that what worked last month still works this month, we apply a zero-regression guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.

The source code, infrastructure, deployment pipeline and documentation are your intellectual property once the first monthly invoice is paid. A trial period of up to 15 working days in the first month: no invoice if you do not want the deliverables.

You can terminate the contract in writing at any time, without justification. During the reversibility month, we support your team until they can build, test and deploy without us. The pipeline goes on protecting every future change, whichever developer makes it.

We need full autonomy over how we work, from the start of the project to its end. So we do not place developers in your team, and we do not take on projects where you set the working method yourself. It is this autonomy that lets us answer for an application usable within a month, and for every regression.

Among other things, we build marketplaces, business applications and mobile apps.

Further reading

Looking for a developer or an agency to have your app developed? Shall we talk?

Sources

• M. Cagan, “The Four Big Risks” (the four risks of a product: feasibility belongs to the engineers, value and viability to the product manager), Silicon Valley Product Group, 4 December 2017.
• Silicon Valley Product Group, profile of Marty Cagan (his career, including his role as vice president of product and design at eBay), accessed 24 October 2026.
• P. Bonneau, “Les Urssaf, remparts à l’uberisation de l’économie ?” (the judge looks at the actual conditions of the work, and at the indicators of subordination), CMS Francis Lefebvre, 8 August 2016.
• M. Loupia, journalist, technology and cybersecurity specialist, “Choisir un prestataire informatique : 8 questions essentielles à poser” (the reversibility clause, and what the contract must provide for in order to leave), Clubic, 16 February 2026.
• “Développement de logiciel par un prestataire : ce qu’il faut savoir sur votre contrat” (the escrow agreement), Le Monde du Droit, 5 December 2022.
• Syntec Numérique and Staub & Associés, “Sécuriser le développement d’une application mobile” (scope changed by amendment, the storyboard and acceptance testing, prior knowledge excluded from the assignment), PraTIC legal guide, 2015, pp. 2 to 6.
• Journal entry “Propriété du code d’un logiciel commandé” and its comments (a client who cannot obtain the code of the software they commissioned), LinuxFr.org, 8 October 2008.
• J. Cheminat, “Méthode agile : la justice rappelle l’importance du cahier des charges” (a young company’s refund claim rejected, after an agile development without a written specification), Le Monde Informatique, 9 November 2020, on Paris Commercial Court, 7 October 2020.
• B. Flyvbjerg, A. Budzier, J. S. Lee, M. Keil, D. Lunn, D. W. Bester, “The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution” (across 4,677 projects, an actual cost of 1.8 times the estimated cost on average, and a median overrun close to zero), Journal of Management Information Systems, 39(3), 607-639, 2022.
• Copyright, Designs and Patents Act 1988, section 11(2) (an employee’s work belongs first to their employer) and section 90(3) (an assignment must be in writing signed by or on behalf of the assignor), legislation.gov.uk.
• GOV.UK, “Ownership of copyright works” (the employer owns, a commissioned work stays with its creator, assignment in writing), accessed 26 October 2026.
• GOV.UK, “Employment status: self-employed and contractor” (a self-employed person runs their business for themselves), accessed 26 October 2026.
• HMRC, Employment Status Manual, ESM0519 (control over what, where, when and how the work is done), accessed 26 October 2026.
• HMRC, “Employment status and employment intermediaries” (an intermediary supplies workers to a client, and the obligations that follow), accessed 26 October 2026.
• Rock Advertising Ltd v MWB Business Exchange Centres Ltd [2018] UKSC 24 (a clause preventing variation other than in writing is legally effective), UK Supreme Court, press summary, 16 May 2018.
• UK government, “Contracting for agile: guidance note”, para 3.3 (a fixed specification costed in advance, and the change requests it produces), Digital, Data and Technology Playbook.
• GOV.UK, “Running payroll: employer’s National Insurance” (the employer pays National Insurance contributions on an employee’s earnings above a weekly threshold), accessed 27 October 2026.
• GOV.UK, “Workplace pensions: what you, your employer and the government pay” (the employer pays into the employee’s pension each payday), accessed 27 October 2026.
• GOV.UK, “Holiday entitlement” (workers are legally entitled to 5.6 weeks’ paid holiday a year), accessed 27 October 2026.
• GOV.UK, “Statutory Sick Pay (SSP)” (an employee too ill to work gets Statutory Sick Pay, paid by the employer, for up to 28 weeks), accessed 27 October 2026.