How to choose a software vendor: 12 questions before signing

Choosing a software company often starts simply. You send a brief to several firms, have a few meetings and receive proposals two weeks later.

One quotes PLN 180,000. Another asks for PLN 320,000. A third gives no total price, but proposes a team billed by the hour.

Every vendor says they understand the project, work agile and communicate openly. They show portfolios, client logos and technology lists. The presentations look professional, but you still do not know who will deliver.

That is normal. During sales, you have the least information and the vendor has the greatest control over what you see.

Do not choose solely on price, portfolio or first impressions. Ask questions that get behind the sales presentation and reveal what daily collaboration will look like.

Before you start: make sure everyone estimates the same project

The biggest mistake often happens before the first vendor meeting.

The client sends a broad idea, such as:

Each company builds its own interpretation.

One assumes configuration of an existing product. Another plans custom development. A third includes accounting and email integrations, while a fourth treats integration as a separate phase.

You receive four prices, but they are not four estimates for the same project.

Before selecting a vendor, prepare at least:

• a clear business problem;
• the main user groups;
• the key processes to support;
• first-release scope;
• required integrations;
• basic data and security requirements;
• the expected deadline;
• client-side responsibilities;
• criteria for comparing proposals.

This need not be hundreds of pages. It must be specific enough for vendors to answer a comparable question. That is the purpose of an IT project specification.

Only then can you meaningfully assess vendors.

1. Have you delivered a similar project, and what exactly was your role?

Asking about similar work is obvious. The problem is that a portfolio alone explains little.

A company may showcase a major e-commerce system after building only one module. The team that delivered an older project may have left. A famous client logo may represent only a short analysis phase.

Do not ask only about experience in your industry.

Ask:

• what the company was actually responsible for;
• what it built from scratch;
• which parts others supplied;
• how long delivery took;
• what problems arose;
• whether the current team worked on it;
• whether the solution is still maintained and developed.

Industry experience helps, but experience with a similar problem may matter more: multiple integrations, data migration, complex permissions or work across several companies.

2. Who will actually work on our project?

Sales meetings often feature the company's most experienced people: a CTO, senior architect and seasoned project manager.

After signing, a different team may handle day-to-day delivery.

Ask to meet the people actually assigned:

• the project manager;
• the analyst;
• the UX designer;
• the architect;
• the lead developers;
• the tester;
• the deployment and maintenance owner.

You are not recruiting for the vendor. But you should know which skills you are buying and whether those people are available when needed.

Also ask:

• how much time each person will allocate;
• how many other projects they will work on;
• who can cover for them;
• how knowledge will be transferred;
• whether changes to key people require prior agreement.

A company's CV does not deliver a project. People do.

3. Which assumptions underpin your estimate?

Every estimate contains assumptions. Some are documented; others exist only in the estimators' heads.

The vendor may assume that:

• migration data is clean;
• existing systems have current APIs;
• the client supplies complete content and materials;
• users are available for analysis and testing;
• performance testing is unnecessary;
• mobile means a responsive website, not a separate app;
• standard platform behaviour is acceptable;
• only basic security requirements apply;
• scope will remain broadly stable.

Each assumption can materially affect the price.

Request separate lists of:

• assumptions;
• excluded work;
• client obligations;
• external supplier dependencies;
• areas requiring further analysis.

A good proposal makes uncertainty visible and explains how to reduce it, rather than pretending every unknown is resolved.

4. How did you produce the estimate?

An attractive price is not enough; understand how it was calculated.

Ask whether the estimate was:

• based on scope analysis;
• prepared by the technical team;
• benchmarked against similar projects;
• built from estimates for individual items;
• inclusive of testing, management and deployment;
• supported by an explicit risk contingency.

Check whether the hours cover every role. A proposal may look cheap because it counts developers but excludes analysis, management, design, testing and deployment.

Do not expect absolute precision. Early estimates carry more uncertainty. But the vendor should explain the reasoning and the largest cost uncertainties. If you have an estimate to assess, an IT proposal and estimate review can help with exactly that.

5. What could increase the project's cost?

Ask directly, before the first additional invoice.

Ask which situations may require extra funding, such as:

• requirements changes;
• new integrations;
• unexpected data quality issues;
• missing documentation for existing systems;
• additional security requirements;
• a change of technology;
• client-side delays;
• rework of previously accepted work;
• more users or larger data volumes;
• additional testing.

Then agree how extra costs will be raised and approved.

Paid extra work should not begin on the basis of a casual meeting discussion. Each change needs a description, rationale, estimate and schedule impact.

6. How do you manage scope changes?

Change is normal in IT delivery. Users learn more about their needs, new information emerges and earlier assumptions may prove wrong.

The issue is change whose consequences nobody has consciously assessed.

Ask whether the vendor maintains:

• a change log;
• business justification;
• cost impact;
• schedule impact;
• impact on remaining scope;
• a formal client decision;
• a history of approved and rejected changes.

For a fixed budget, agree how scope can be exchanged. A new feature may replace work of similar effort without increasing the price.

That preserves flexibility without unlimited growth.

7. How will we verify real progress?

Hours worked do not tell you how much product exists.

“Working on the module” or “80% of tasks complete” is not enough either. Tasks differ in size, and completed items may still need integration, testing and fixes.

Ask the vendor:

• how often demonstrations happen;
• when you get access to a test environment;
• what can be accepted after each phase;
• how completion is defined;
• how delays are reported;
• whether reports forecast completion date and cost;
• whether you can access the backlog and documentation.

Working outcomes should demonstrate progress, rather than activity reports alone. If you want someone to oversee that continuously, consider client-side IT project oversight.

8. How do you control quality, and who tests?

“The system will be tested” is too vague.

Ask:

• which types of testing are included;
• who performs them;
• when testing starts;
• how results are recorded;
• how defects are classified;
• which tests are excluded;
• who prepares test data;
• how you participate in user acceptance testing;
• which conditions must be met before production launch.

Separate the vendor's responsibilities from the client's.

The vendor verifies technical quality. The client checks that real business processes work as expected. User testing must not replace the vendor's quality assurance. For organising your own testing, see software acceptance and UAT.

9. What do you do when a project starts slipping?

Do not ask whether delays are possible. Of course they are.

Ask what happens at the first material deviation from the plan.

You need to know:

• when the problem is reported;
• who investigates the cause;
• how forecasts are updated;
• which options you will receive;
• whether scope can be reduced;
• who makes the decision;
• how recovery actions are monitored.

A mature vendor does not promise a world without problems. It shows how problems are detected early, discussed openly and addressed methodically.

Costly delays often start with small slippages that leave the official final date unchanged for weeks.

10. How do you protect our data, and who can access it?

Security requirements depend on the system and information involved. A simple brochure site differs from a system handling customer, employee, payment or medical data.

Ask, for example:

• where data is stored;
• who can access environments;
• whether subcontractors are involved;
• how access is granted and revoked;
• whether test environments contain real data;
• how backups are created;
• how incidents are handled;
• how vulnerabilities are managed;
• which external tools are used;
• whether code or data can enter generative AI tools;
• what happens to data after the agreement ends.

“We comply with GDPR” is not enough. You need concrete practices and responsibilities.

11. What exactly do we receive at the end?

A system is more than the screens users see.

At handover, you may need:

• source code;
• change history;
• technical documentation;
• user documentation;
• configuration;
• administrative access;
• data and export capabilities;
• licensing information;
• a component inventory;
• deployment instructions;
• maintenance procedures;
• integration documentation;
• known limitations.

Not everything must become your property. The system may use open-source libraries, vendor components, licensed products or cloud services.

But you must know your rights and whether you can:

• keep using the solution after the agreement ends;
• develop it with another vendor;
• move your data;
• rebuild the environment;
• maintain it without permanent dependence on the current provider.

Agree these points before signing, not when the relationship starts deteriorating.

12. How do maintenance and exit work?

Production launch does not end costs or responsibilities.

Ask:

• who fixes defects after launch;
• what the warranty covers;
• incident response times;
• how changes and development are charged;
• whether a minimum monthly retainer is required;
• how libraries and infrastructure are updated;
• who monitors the system;
• what happens after notice is given;
• how long handover takes;
• whether the vendor helps onboard a successor;
• which migration fees may apply.

An exit procedure is responsible risk management, not a declaration of distrust.

A healthy relationship does not require technical captivity.

How to compare vendors' answers

Conversations alone are not enough. After several meetings, answers blur and the decision risks returning to impressions.

Prepare a scorecard before starting.

It may cover:

• understanding of the business problem;
• completeness of scope;
• team experience;
• estimate transparency;
• change control;
• progress reporting;
• quality and testing;
• security;
• maintenance terms;
• rights to code and data;
• ability to change vendors;
• total cost over several years.

Weight each criterion. A medical-data system, an online shop and a simple internal tool have different priorities.

Set criteria before deciding. Creating them after meetings makes it easy to favour the most impressive presentation. If proposals still lack a common basis, use a structured software vendor comparison.

Common vendor-selection mistakes

Choosing solely on price

The cheapest proposal may be best, but check that it covers the required scope. Low cost can reflect capability and experience, or omitted analysis, tests, migration, documentation and maintenance.

Overvaluing the portfolio

Well-known client names do not guarantee an equally experienced team on your project.

Not meeting the technical team

Salespeople may understand the sales process well, but they will not make daily delivery decisions.

Unclear selection criteria

Without agreed rules, selection becomes a presentation contest.

No exit plan

The client considers how to start working together but not what happens at the end.

Signing before resolving discrepancies

“We will work it out” rarely substitutes for clear scope and commercial terms.

Will a good vendor answer everything perfectly?

No.

A small company can work very well without elaborate procedures. A large provider can have excellent processes but assign the wrong team.

There is no single perfect answer.

Check whether the working model fits:

• the project's scale;
• its risk level;
• your organisation's capabilities;
• the intended relationship;
• security requirements;
• available budget;
• plans for further development.

A vendor needs to build the system and work effectively with your organisation.

A good vendor does not promise no problems

IT projects contain unknowns. Requirements can change, integrations can be harder than expected and assumptions may need revisiting.

The best vendor is not the one claiming to have predicted everything.

It is a team that:

• states assumptions clearly;
• discusses risks;
• shows outcomes early;
• does not hide problems;
• records decisions;
• controls changes;
• protects quality;
• lets you retain control of your own system.

You are not choosing the best sales presentation.

You are choosing a partner for difficult decisions over months, sometimes years.

Unsure how to compare the proposals you have received?

If estimates differ in scope, price or delivery model, clarify them before signing.

An independent review establishes:

• what each proposal actually covers;
• what is missing;
• where additional costs may arise;
• which questions to ask vendors;
• which option best fits the project's goals and risks.