Hiring a web application development firm, because you are buying software and not a website

If people log in and the thing remembers them, you are buying software. That one test separates a web application development firm from a web design agency, and it changes almost every term you should be negotiating. A website is finished when it is published. An application has users with accounts, data that must survive, a runtime that ages, and a stream of small failures that need somebody on the other end of an email. Buy it as a one off project and you will pay for it twice.

The demand here is steady rather than huge. In India, web application development firm ran at 390 a month and app and website development companies also at 390 a month, both harvested on 22 October 2026 against Google's India location on its own. In the United Kingdom the same application phrase ran at 260 a month and the combined app and website phrase at 90 a month, harvested the same day against the United Kingdom on its own. Each figure is one country's demand and none of them are added together.

Where a website ends and an application begins

The boundary is not visual. A beautiful site can be a brochure and a plain one can be a system of record. Four questions place any project in about a minute.

• Do users have accounts, and does losing one person's data matter to that person?
• Does the thing calculate, decide or schedule anything, rather than only display it?
• Does it talk to another system, such as a payment provider, an accounting package or a warehouse?
• Will somebody inside your company be doing a daily job inside it?

One yes makes it software. Two or more and you need a firm that measures its own work in releases rather than in pages. This matters when you read a portfolio. A shop whose best work is twelve handsome marketing sites may still be the wrong supplier for a booking engine, and saying so is not a criticism of the sites.

Four contract shapes, and what each one is honest about

Fixed price works when the thing is genuinely known. It is honest about your budget and silent about change, so it rewards whoever wrote the specification and punishes whoever did not. Use it for a defined first version with a short list of features.

Time and materials is honest about uncertainty and tells you nothing about the total. It suits work where you expect to learn as you go, and it needs a reporting rhythm you will actually read.

Capped time and materials is the shape most buyers want and fewest ask for. You pay for the hours worked, the firm stops at an agreed ceiling, and anything beyond it is a new conversation rather than a surprise invoice. It gives the supplier no reason to pad and gives you a number you can take to a board.

A retained team is a standing group of named people for a monthly fee. It is the right shape once the thing is live and changing, and the wrong shape for a first build, because you will be paying for capacity before you know what to point it at.

Whichever you pick, ask one question before signing. If the project runs over, who absorbs the first two weeks? A firm with a clear answer has thought about it. A firm that says it will not happen is making a claim about the future rather than a commercial offer.

The specification that makes a fixed price fair to both sides

A fixed price is only honest if both parties can tell when the work is done. That requires a list of user stories, each written as somebody doing something and getting a result, and each with a test that can pass or fail. A story reading "admin dashboard" is an invitation to argue. A story reading "an administrator can suspend a user account, the suspended user is signed out within a minute, and an email records who did it" can be demonstrated in front of you.

Write the ten stories that matter most yourself, even badly. The firm will rewrite them properly, and the act of drafting them will surface the three decisions you had not made. Then insist that the signed scope lists what is out as well as what is in. Exclusions are the cheapest clause in software and the one most often missing.

Own the repository, the environments and the accounts from the first day

This is the part that decides what leaving costs, and it costs nothing to get right at the start. Create the accounts in your own company's name and invite the firm in as a collaborator. That applies to the code repository, the hosting account, the domain registrar, the database, the error tracking tool and any paid service the application depends on.

The failure mode is ordinary rather than dramatic. A firm spins everything up on its own accounts because it is faster, the project goes well for two years, and then the relationship ends and nobody can say with certainty where the production database backups are. Ask for a written list of every account the application touches, who owns it and who pays for it, and ask for it before the first deployment rather than after the last.

Settle source code rights in the same clause. The firm should assign the code it writes for you on payment, and you should expect it to keep using any general purpose libraries it brought with it. Both of those are normal. What is not normal is a licence to use your own application that can be withdrawn.

Escrow, and when it is worth the paperwork

A source code escrow agreement places a copy of the code with a third party and sets out the events that release it to you, such as the supplier ceasing to trade. It costs real money and real administration, so it is worth it in a narrow band of cases. If the application runs a process your business cannot do manually for a week, escrow is cheap. If you could fall back to a spreadsheet for a fortnight, it probably is not.

For most buyers there is a lighter version that delivers most of the benefit. Take a full copy of the repository and a database export on a schedule, store it somewhere only you control, and test once a year that somebody other than the original firm can start the application from it. That annual test is the whole point. An untested backup is a belief.

The maintenance cliff, and the three numbers to agree before launch

Applications do not sit still. Dependencies release security updates, browsers change, payment providers deprecate endpoints, and the runtime your code sits on reaches the end of its own support window. None of that is a defect in the build, and all of it arrives whether or not anybody budgeted for it.

Agree three numbers before launch. First, the monthly cost of keeping the thing patched and running, separate from the cost of new features, so you can see each one. Second, the response time you are buying for a failure that stops users working, in hours, with the hours of the day it applies in. Third, the rate for new work after launch, so the first enhancement does not require a new negotiation.

Then ask which version of the language and framework the application will be built on, and look up that version's published support dates yourself. Every major runtime publishes them. A firm proposing a version that leaves support within the year is proposing an upgrade project you have not agreed to.

Checking a firm you have not met

For a United Kingdom supplier, the Companies House service at find-and-update.company-information.service.gov.uk is free, needs no account, and gives you incorporation date, registered office, officers and the filing history. A development firm whose accounts are overdue is worth a question before it is worth a contract. For an Indian supplier, ask for the GST registration and the company identification number and check the name on them matches the name on the proposal.

Then ask for two references where the application is still running and the firm is no longer involved. A reference from a current client measures the relationship. A reference from a former client measures the handover, which is the thing you are actually worried about.

Questions buyers ask before signing a web application build

How much of the specification should we write ourselves?

Enough to describe the outcome and the constraints, and no more. Write the problem, the people who will use it, the ten most important things they must be able to do, and anything it must connect to. Let the firm design the solution. A buyer who writes the implementation has hired an expensive typist.

Is a bigger firm safer than a small one?

A larger firm survives the loss of one person and a small one often does not, which is a genuine risk for a system you will run for years. A small firm gives you the people who sold you the work. Price the risk rather than guessing at it, by asking who else in the firm can deploy this application, and getting a number.

What is a fair deposit?

Between a quarter and a third of the first phase is ordinary, with the rest tied to demonstrable stages. Be cautious about any schedule where more than half the money is paid before anything can be shown working.

Should we build a mobile app at the same time?

Usually no, and the reason is not cost. A web application and a native app are two products with two release processes, and launching both at once doubles the number of things that can go wrong on the day you can least afford it. Ship the web application, learn what people actually do in it, then decide whether the app is the same thing in a smaller window or something else entirely.

How do we judge progress without reading code?

Ask for a working version you can click, deployed somewhere you can reach, every two weeks from the start. Not a screenshot and not a status percentage. A clickable build is the only progress report that cannot be written optimistically.

The description of your product that you did not write

Once an application is live, people start asking assistants about it, and the answers are assembled from whatever is publicly readable. For a logged in product that is usually your marketing pages and a handful of third party mentions, which means the description in circulation is often a year behind the product. A firm choosing a development supplier runs into the same thing from the other side, because an assistant asked to name a web application development firm answers from published material rather than from delivery record. AI Knows Us measures which names come back on questions like that and which pages the answer was built from. If the application you are commissioning will replace a manual process, our note on the five build time decisions and the handover checklist covers the build choices that are hardest to reverse later.