How do you choose a web application development partner for your business?

A good web application partner should be assessed on more than price and a portfolio. They should understand the business problem, define the first stage clearly, identify assumptions and risks, and record how both parties will decide that the work has been completed. Before the project starts, you should also agree on ownership of code and data, access to repositories and accounts, testing, acceptance, deployment, handover and ongoing maintenance.

Quotes can only be compared fairly when they cover a similar scope and outcome. A lower price may exclude data migration, testing or support after launch. A higher price does not prove quality either if the quote does not explain what the business will receive.

A small, unambiguous task does not always need a lengthy analysis. However, if an application involves several roles, integrations, exceptions and important data, a quick quote based on very few questions deserves closer examination.

First check whether the partner understands the business problem

The first conversation should not focus solely on technology and a list of screens. Start by establishing who uses the current process, where delays occur, what data is involved and what should work differently after the change.

A capable partner asks questions such as:

• who performs each task and who makes decisions;
• which programs, spreadsheets or files hold the data;
• where work is repeated or performed manually;
• which exceptions occur in the real process;
• what must be included in the first stage and what can wait;
• how users and the person commissioning the work will assess the result.

It is also a good sign when the partner can recommend a simpler option. Configuration, an additional module or an integration may be enough instead of a completely new application. If a partner recommends building from scratch without considering those options, ask why the simpler routes were rejected.

You do not need a technical specification for the first conversation. A short account of the problem, the current way of working and the expected outcome is more useful. Our guide on describing the software you need without a technical specification can help you prepare it.

Find out how the partner deals with uncertainty

Some information is usually incomplete at the start of a new project. A business may understand its problem without yet knowing the final data flow, permissions model or integration method. An honest quote should separate confirmed requirements from assumptions.

Ask what the partner needs before providing a price and delivery estimate. Check whether they can identify:

• decisions that must be made before work begins;
• data and access that need to be examined;
• assumptions that affect the quote;
• items excluded from the first stage;
• risks linked to external systems or suppliers;
• situations in which the scope needs to be agreed again.

For a simple task, a few materials, a short call and a clear acceptance condition may be enough. When the project involves many processes, roles, data sources and integrations, a separate business analysis and MVP planning stage may be sensible. It should not be a compulsory addition to every assignment. Its purpose is to reduce uncertainty where the parties would otherwise be pricing different projects.

Compare the same first stage, not just the totals

Two quotes may use similar labels while covering very different work. One may include data migration, testing and deployment, while another covers only an application running with sample data. Before comparing prices, put both proposals against the same list.

For a fuller explanation of why quotes differ, read How much does a business web application cost?. An hourly rate alone does not show how much work is required, what will be checked or what the client receives at the end.

Agree on code, data and account ownership before signing

Ownership and access are often discussed only when a working relationship ends. That is the hardest time to organise them. Before starting, record:

• who receives rights to the project code and on what terms;
• where the repository is hosted and who can access it;
• who owns the domain, hosting and cloud accounts;
• whose account is used to pay for external APIs, email, SMS and other services;
• how the client will receive a data export and the materials needed for further work;
• which libraries, templates or services have separate licences;
• what happens to the partner's access when the engagement ends.

Do not assume that all rights, code, licences and accounts transfer automatically when an invoice is paid. The agreement must state what is included.

At Domin Software, we use a model in which the client remains the owner of the domain, hosting and billed service accounts, while we receive the agreed access required for our work. Responsibility, code and deliverables still need to be defined for each project.

Ask how the most important functions will be tested

“The application will be tested” is too vague. A contact form, an invoice import and a system with user roles, payments and access to customer data each require different checks.

Ask for straightforward answers to these questions:

1. Which processes are critical and how will they be checked?
2. Will acceptance take place in a test environment or through another safe method?
3. How will roles, permissions and sensitive operations be verified?
4. Who creates the backup before a change, and is the restore process known?
5. How will deployment and the immediate post-launch check work?
6. What happens if the deployment does not meet the acceptance criteria?
7. How are defects reported and who decides their priority?

Security should also be expressed as specific requirements and checks, not as a general promise. OWASP ASVS provides requirements that can support the design and verification of web application security. NIST SSDF describes secure development practices that can be integrated into an organisation's existing way of working. This does not mean that every small project must implement an entire standard. The level of assurance should reflect the risk, the type of data and the consequences of failure.

Test communication with a real example

A quick reply to a sales enquiry does not prove that communication will remain clear during delivery. Ask the partner to explain one important part of the proposal in plain language, such as acceptance, integration risk or the difference between the first stage and later development.

Check whether the partner:

• summarises agreements and identifies missing decisions;
• explains consequences instead of merely naming technologies;
• can say what is not yet known;
• distinguishes a defect from a change of scope;
• identifies decision-makers and the way changes are approved;
• states how often progress will be reported.

Clear communication does not mean avoiding difficult information. “We cannot price this reliably until we examine the data format and API documentation” is more useful than a precise figure built on assumptions.

A portfolio should show the work, not just the interface

A screenshot proves that an interface existed. It does not explain which problem the partner solved, which parts they delivered or whether the system is still used. In a case study, look for a separate explanation of the problem, the delivered scope, the limitations and a result that can be verified.

A similar process may matter more than the same industry. Experience with a booking system can be relevant to a project involving several roles, calendars and settlements even when the new client works in another sector.

Our case studies show different types of complexity:

• 44Islands presents a booking process and a system developed in stages for different roles;
• HUB.ITM.PL presents a historical project that mapped data from different accounting programs into the EDI++ format;
• HUB-2-API presents a historical flow covering products, eBay.de listings, orders and an API used by three clients in France.

HUB.ITM.PL and HUB-2-API are no longer in production. They demonstrate earlier work with data, integrations and business processes, not the current availability of those external services. Similar limitations should be visible when you review any portfolio.

Agree on handover and maintenance before the project starts

Accepting a working application does not settle every responsibility. Decide what the client receives at the end of a stage and who will look after the solution later.

The handover may include:

• access to the repository and the relevant code version;
• startup instructions and a description of important dependencies;
• credentials transferred through a secure channel;
• a list of external services and billing dates;
• a copy or export of data within the agreed scope;
• acceptance results and known limitations;
• information about backups, monitoring, updates and defect reporting.

Support may be included in the project, covered by a separate agreement or commissioned when needed. There is no single model that suits every company. Terms such as response time, support hours and included updates need a precise meaning. If you want to separate development from ongoing care, see our application and online store maintenance service.

Warning signs that deserve another question

One warning sign does not automatically disqualify a partner, but it should lead to a clear question. Be cautious when:

• a full price and deadline appear before roles, data, integrations and exceptions have been examined;
• a chosen technology is presented as a guarantee of security or scalability;
• the proposal does not explain ownership of the repository, data and accounts;
• there are no acceptance criteria or explicit exclusions;
• nobody can explain how the solution will be tested and deployed;
• the portfolio does not say what the company actually delivered;
• the rules for changes, fixes, maintenance and ending the engagement are unclear;
• the partner pushes for a quick signature before basic assumptions are resolved.

The risk is not a difference of opinion or the need for further analysis. The greater risk is leaving important questions unanswered while both parties assume they understand the scope in the same way.

What should you prepare for the first conversation?

You do not need to start with a lengthy specification. Prepare materials that show the real problem:

1. a one-sentence description of the situation and desired outcome;
2. the current workflow and the people involved;
3. the main data sources, systems and required integrations;
4. three priorities for the first stage;
5. constraints relating to time, budget or existing infrastructure;
6. examples of unusual cases and exceptions;
7. a person who can make decisions;
8. sample materials without passwords, keys or real customer data.

You can use our free Project Brief Builder. It guides you through the main questions and creates a structured summary for the next conversation. It does not send the project automatically and does not replace analysis of a larger scope.

Frequently asked questions

Do we need a complete technical specification before choosing a partner?

No. A description of the problem, current process, users, data and expected outcome is enough to begin. A technical specification can be prepared later, once the solution and scope are better understood.

Is a freelancer, a small company or a software house the better choice?

There is no universal answer. It depends on project size, risk, required availability, specialisation and communication. More important than the label is knowing who will deliver the work, what happens if that person is unavailable and how the code and system knowledge will be handed over.

How can we compare two application quotes with different scopes?

First compare the first-stage outcome, functions, roles, data, integrations, testing, deployment and exclusions. Assess the price afterwards. If the scopes cannot be placed on the same list, ask the partners to clarify their proposals.

Who should own the code, repository and data?

The terms should be explicit and written into the agreement. The commissioning company should at least know where the code and data are stored, who can access them, which licences apply and how the required materials will be received when the engagement ends. Paying for a stage does not replace those arrangements.

Is paid analysis always required before a quote?

No. A simple task with a clear outcome can often be priced from a short description and supporting materials. A separate analysis is useful when several processes, data sources, roles, integrations and uncertainties materially affect the scope.

What should we ask about testing and security?

Ask which processes will be checked, where acceptance will take place, how roles and sensitive operations will be verified, who will create a backup and how deployment will be controlled. The depth of testing should reflect the project's risk.

What should be handed over when the project ends?

It depends on the agreement, but it is usually worth covering code and repository access, startup instructions, dependencies and external services, a data export, acceptance results and known limitations. Agree on a secure way to transfer credentials and remove the partner's access later.

Must application maintenance be part of the same agreement?

No. Maintenance may be included in the project, purchased as a separate service or transferred to another partner. Before launch, decide who is responsible for monitoring, backups, updates, incidents and communication with infrastructure providers.

Give every partner the same starting point

Begin with the problem, the first required outcome and the main constraints. Use the Project Brief Builder to prepare one summary for every partner you compare. This gives each conversation the same starting information.

If you are looking for a partner for a custom application, see Domin Software's PHP and Laravel development services. After reviewing the description, we can say whether a short call and a small stage are enough or whether separate analysis should come first. We do not provide a full price and schedule without understanding the scope, data, integrations and acceptance method.

Sources

• OWASP Application Security Verification Standard, OWASP, stable version 5.0.0 published on 30 May 2025, accessed 30 October 2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, published February 2022, accessed 30 October 2026.