Commissioning a Web Application: What You Need to Know as the Client
Most people who commission a web application for the first time are not developers. They run a business, a department, or a product, and they have a problem that a website cannot solve: staff copying data between spreadsheets, customers who want a portal, a process that lives in email threads and someone's head. Commissioning a web application is how that problem gets turned into software. You do not need to understand the code to do this well. You do need to understand what the development partner needs from you, how the work should be structured, and which parts of the contract protect you later.
This guide is written for the person signing the order, not the person writing the code. If you want the vendor's side of the story, we have covered what a custom web application development engagement should include and a buyer's checklist for comparing providers. Here the focus is on your homework and your contract.
A web application is not a website
The distinction matters because it drives cost, timeline, and the kind of partner you need. A website presents information. Visitors read it, maybe fill in a form. A web application does work: users log in, create and change data, trigger processes, and expect the system to remember state and enforce rules. A booking system, a customer portal, an internal tool for approving purchase orders, a dashboard that pulls from your ERP: these are applications.
That shift brings requirements a website never has. Someone has to design the data model. Someone has to decide who is allowed to see and change what. There is a database to back up, integrations to keep alive, and a security surface that grows with every feature. An agency that builds marketing sites in a page builder is not automatically the right partner for this, and a quote that looks like a website quote (a few pages, a design round, a launch date) is a warning sign.
What a serious partner needs before quoting
If a vendor sends you a fixed price after one phone call, they either guessed or they plan to renegotiate later. A partner who intends to deliver will ask for a set of inputs first. Preparing them in advance saves you weeks and makes quotes comparable.
Start with the problem, not the solution. Write down what currently happens, who is involved, and where it hurts. "Our field technicians report hours on paper, the office types them in on Friday, and invoicing is always two weeks late" is worth more than a feature list, because it lets the partner propose the smallest thing that fixes it.
Then describe the users. How many, in which roles, on which devices, how often. An internal tool for 12 colleagues on office laptops is a very different project from a portal for 5,000 customers on phones, even if the screens look similar.
List the systems the application has to talk to. Which systems hold data the application will need or produce? ERP, CRM, accounting, an old Access database, a supplier's API? Integration is where estimates go wrong most often, so name every system, even the embarrassing ones.
Be honest about budget and time. Vendors ask about budget because it determines which of three or four valid approaches they should propose, not to spend all of it. A rough range ("between 40,000 and 80,000 euros for the first version") is enough. The same goes for deadlines: a trade fair in March is a hard constraint; "as soon as possible" is not a date.
Finally, list the constraints that are not negotiable. Data must stay in the EU. The application must work with your existing single sign-on. The design has to follow your corporate identity. Say these things early, because retrofitting them is expensive.
How the project should run
A well-run project has recognisable phases, and each one ends with something you can look at and approve.
Discovery comes first, and it is usually paid work. Over one to three weeks the partner interviews the people who will use the application, reviews your systems, and produces a specification: the scope of the first version, a rough architecture, a data model, and an estimate you can hold them to. If a partner offers to skip discovery to save money, they are moving the risk from their side of the table to yours.
A prototype follows. Sometimes this is clickable screens, sometimes a thin working version with real data behind a few screens. It exists to catch misunderstandings while they are cheap to fix, so expect to change your mind here, and expect the partner to encourage that.
Development then runs in short cycles, typically two weeks, each ending with a demo of working software rather than a status report. You should be able to log into a test environment at any point and see what exists. Testing is part of each cycle, not a phase at the end, though there is usually a dedicated acceptance period before launch where your team works through real scenarios.
Launch is rarely a single evening. For anything replacing an existing process, plan a period where old and new run side by side, and agree in advance who decides when the old one gets switched off.
Operation is the phase clients most often forget to plan for. Software needs hosting, monitoring, security updates, and someone to call when something breaks at 8 am on a Monday. Decide before launch who does this and what it costs.
If you want the internal view of how we structure these phases, our web application development service page describes the process in more detail.
What belongs in the contract
Non-technical clients tend to read the price and the deadline and skim the rest. The clauses below are the ones that matter when something goes wrong.
Scope has to be written down in a form both sides can check against. A reference to "the specification dated X" is fine as long as that document actually exists and both sides have read it. "A web application for order management" is a topic, not a scope.
Acceptance criteria define when a deliverable counts as done. Without them, every disagreement about quality becomes a negotiation. Good criteria are testable: "a user with the role Approver can approve an order, and the supplier receives the confirmation email within one minute" beats "the approval workflow works."
Change handling describes what happens when you want something that is not in scope. You will, and that is normal. The contract should say how changes are estimated, who approves them, and how they affect the timeline. Fixed-price contracts without a change clause tend to end in either a bloated final invoice or a vendor who quietly cuts corners.
Source code ownership is the clause people most often get wrong. You are paying for the software, so you should own the code, or at minimum hold an unrestricted, perpetual licence to use, modify, and have others modify it. You should also have access to the repository during the project, not only a handover archive at the end. Ask explicitly about third-party components and licences the vendor plans to use; open-source components are standard, but you want to know which ones, and under which licence.
Data protection is not optional if the application processes personal data, which almost every application does. The contract needs a data processing agreement under Art. 28 GDPR if the vendor will host or access production data, a statement of where data is stored, and clarity on who acts as controller and who as processor.
Maintenance and warranty should be separated. Warranty covers defects in what was delivered, for a defined period, at no extra cost. Maintenance covers keeping the system healthy after that: security updates, dependency upgrades, small changes. Agree response times for the maintenance phase and what "critical" means.
Exit terms are unpleasant to negotiate and essential to have. If the relationship ends, what do you receive, in what format, and within what period? Code, database dumps, documentation, credentials, domain and hosting accounts in your name. An application you cannot move to another team is a liability.
Where outsourced projects go wrong
The failures we see when we are asked to audit a troubled project follow a small number of patterns.
The most common is a missing or vague specification. Both sides believed they agreed, discovered halfway through that they had not, and now argue about who pays for the difference. Discovery and written acceptance criteria exist to prevent exactly this.
The second is communication that breaks down after the sales phase. The person who sold the project disappears, and the client hears from the team once a month. Insist on a named technical contact, regular demos, and access to the test environment. If you cannot see progress, assume there is less of it than reported.
The third is hidden cost. Hosting, licences for third-party services, the maintenance retainer, the integration that "should be simple," the mobile layout nobody priced. A serious partner lists these upfront and tells you which are estimates. If a quote is far below the others, ask what it leaves out rather than assuming you found a bargain.
The fourth is quality you cannot see until it is too late. An application can look finished and still have no automated tests, no documentation, and a structure only its original author understands. You do not need to read the code to protect yourself: write the requirement for tests and documentation into the contract, ask for a walkthrough of the codebase before final acceptance, and consider having an independent reviewer look at it. That costs a few days and can save you the cost of a rewrite.
Pricing models deserve a mention here too, since the choice between fixed price, time and materials, and a retainer changes who carries which risk. We have written about how those models trade off for EU clients if you want to go deeper.
A short checklist before you sign
Before committing, you should be able to answer yes to each of these. You have a written specification with acceptance criteria. You know the phases and what you will see at the end of each. You own the code and can access the repository. There is a data processing agreement. Warranty and maintenance are defined separately, with response times. You know what the application costs to build and to run in the first year. You know what happens if either side walks away.
If any answer is no, that is the conversation to have before the kickoff, not after.
How Wolf-Tech works with clients
We build custom web applications for companies that usually do not have their own development team, so most of our clients are exactly the people this article is written for. Every project starts with a paid discovery phase, delivers working software every two weeks into an environment you can log into, and ends with code in a repository you own. If you are preparing to commission a web application and want a second opinion on your brief, your shortlist, or a quote you have received, write to hello@wolf-tech.io or visit wolf-tech.io. A short call is usually enough to tell whether a project is set up to succeed.