How to Choose the Right Software Development Company

To choose the right software development company, compare providers on relevant delivery experience, discovery and requirements processes, technical approach, the team assigned to your project, estimate transparency, testing evidence, software ownership, communication, and post-launch support. Evaluate the evidence behind each claim rather than choosing mainly on price, portfolio presentation, or sales promises.

Choosing a software development company affects more than the initial project price. The decision can shape delivery cost, system quality, operational continuity, security exposure, software ownership, and your organisation’s ability to maintain the product or change providers later.

A credible provider should support its proposal with evidence. Look for relevant case studies, a clear discovery process, sound architecture reasoning, named team roles, documented estimate assumptions, visible project controls, defined testing and acceptance evidence, practical access to critical project assets, and clear post-launch responsibilities.

In our project reviews, we treat weak evidence as an early warning sign. Unsupported estimates can lead to budget increases, unclear workflows can create scope gaps, and poor architecture decisions can require structural rework. We also pay close attention to repository control, testing evidence, documentation, and handover because weaknesses in these areas can make future support or provider replacement harder.

This guide explains what to look for when hiring a software development company, which questions to ask, what evidence to request, which warning signs justify further investigation, and how to compare shortlisted providers against the same criteria before signing a contract.

What Business Problem Should the Software Solve?

Before comparing software development companies, define the business problem, target users, workflows, integrations, constraints, ownership requirements, support needs, and success criteria for the project. Giving every shortlisted provider the same project information makes their proposals, estimates, and technical recommendations easier to compare.

For example, “build a customer dashboard” is too broad for reliable estimation. A provider still needs to know who will use it, which records each user can access, which actions they need to perform, which systems provide the data, and what operating conditions the software must support. A dashboard for 50 internal employees has different technical and security requirements from a client portal serving 20,000 users.

Your project definition should cover:

• The business objective

• Users and their roles

• Current and expected workflows

• Required integrations and data sources

• Timeline, budget, regulatory, and technical constraints

• Expected ownership of code, accounts, and data

• Support and maintenance requirements after launch

• Measurable outcomes that will define project success

These details create a common project boundary. Each provider can then assess the same workflows, dependencies, constraints, ownership conditions, and support responsibilities.

A feature wish list alone does not define the operating problem, business rules, dependencies, or acceptance conditions. Without that context, different providers may price different interpretations of the same project. Their quotes can appear comparable while covering materially different work.

Do not compare software development proposals until each shortlisted company has received the same core project information. Otherwise, differences in price, timeline, and technical approach may reflect different assumptions rather than differences in provider capability or value.

Has the Company Delivered Projects Similar to Yours?

Look for evidence that the software development company has delivered projects with similar workflows, integrations, security requirements, user volumes, technical complexity, and delivery constraints. Relevant experience should be supported by case studies, working examples, client references, and a clear explanation of what the provider was actually responsible for.

Industry experience alone is not enough.

For example, a company that built a basic healthcare booking website has some healthcare-sector context. That does not necessarily demonstrate capability to deliver a clinical platform with 12 user roles, sensitive records, audit trails, legacy-data migration, and five external integrations. The underlying workflows, risk, architecture, and operational requirements are substantially different.

When reviewing case studies, compare:

• User workflows and business rules

• Integration and API requirements

• Data sensitivity and security controls

• User volume and operational dependence

• Technical and delivery scale

• Regulatory or security-sensitive requirements

• Migration or legacy-system dependencies

• The provider’s responsibility for architecture, development, testing, deployment, and release

The strongest evidence combines a relevant case study with a working product example, a client reference, and a clear explanation of the technical challenge. Examine what the provider actually delivered, which risks it managed, what outcomes it achieved, and where the earlier project differed from yours.

The provider’s actual role matters as much as the project itself. A company may display a well-known product in its portfolio while having contributed only a small feature, design component, or subcontracted task. A company may display a well-known project in its portfolio while having contributed only a small feature, design component, or subcontracted task. Evidence is more useful when the provider can explain its direct responsibilities and the results of its work.

A large portfolio does not necessarily indicate stronger suitability. Give more weight to comparable workflows, integrations, constraints, risks, and technical responsibilities than to the number of projects or logos displayed.

How Does the Company Define Requirements Before Development Begins?

A credible software development company should use discovery to turn initial ideas into documented workflows, requirements, dependencies, assumptions, acceptance criteria, and unresolved questions. The purpose is to establish what is known, what remains uncertain, and which risks need investigation before the provider commits to a full technical plan, budget, or delivery schedule.

During discovery for a logistics management platform, our team reviewed five planned third-party integrations before development began. One carrier integration could not support the required two-way real-time data flow because its API restricted update frequency and did not expose all shipment-status fields required by the proposed workflow.

We identified the issue within the first four days of discovery. The finding changed the integration design, moved automated exception handling into a later delivery phase, and increased the initial integration estimate by approximately 15%.

Resolving the limitation before development started prevented the team from building the shipment workflow around an API that could not support the required operating process. It also gave the client a more realistic delivery sequence before engineering resources were committed.

The discovery process should produce evidence such as:

• Workflow documentation

• A prioritised requirements backlog

• A dependency and integration list

• An assumption register

• Initial acceptance criteria

• Identified technical and delivery risks

• A record of unresolved questions

• Documented discovery outputs that can support estimation and planning

This evidence separates confirmed scope from assumed scope. It also shows which parts of the project are understood well enough to estimate and which still require validation.

Test how the estimate changes when an important assumption proves false. If major assumptions about integrations, data, workflows, migration, or technical feasibility remain untested, treat the estimate as provisional. If major assumptions about integrations, data, workflows, migration, or technical feasibility remain untested, the estimate should be treated as provisional rather than as a reliable commitment.

Discovery is particularly important when the project includes unclear workflows, third-party integrations, legacy data, migration, technical uncertainty, security constraints, or complex acceptance conditions.

One lesson we have learned from discovery work is to be cautious when every requirement appears settled too early. In real projects, integrations, migration rules, workflow exceptions, and technical dependencies often expose assumptions that were not visible in the first brief.

A strong provider should make that uncertainty visible, record the assumptions behind the proposal, and identify what still needs to be validated before the next major commitment.

Does the Proposed Architecture Support Your Current and Future Needs?

The proposed software architecture should fit the product’s users, workflows, integrations, security requirements, operating environment, expected growth, and maintenance needs. A credible provider should explain how the system will be structured, where data will move, how access will be controlled, who will manage deployment, and why each major technical choice is appropriate for the project.

A list of programming languages, frameworks, databases, or cloud platforms is not enough. The provider should be able to explain why the proposed architecture fits your specific requirements and which trade-offs it creates.

For example, a multi-tenant SaaS platform serving 30 organisations may need tenant separation, role-based access controls, subscription logic, audit records, integration boundaries, and scaling controls. A single-company internal application may justify a simpler architecture because it supports fewer users, lower data-isolation risk, and one operating environment.

A useful architecture review should include:

• A system architecture diagram

• A data-flow diagram

• An integration and API approach

• Hosting and infrastructure recommendations

• Defined security and access-control responsibilities

• Deployment and environment responsibilities

• Technical decision records for major choices

• Known third-party and platform dependencies

• An explanation of maintenance and scaling implications

On one SaaS platform project, the initial architecture proposed six independently deployed microservices running on Kubernetes for a product expected to support around 2,500 active users and approximately 20,000 daily transactions.

During architecture review, our team found that the expected load, integration requirements, and deployment model did not justify that level of infrastructure. We recommended a modular monolith using Node.js, PostgreSQL, and AWS managed services, with clear module boundaries that could support later separation if usage increased.

The revised approach removed five separate deployment units, reduced infrastructure dependencies, and simplified testing, monitoring, and release management. It also avoided the operational overhead of managing Kubernetes during the product’s early stage while preserving a clear path to scale the application as transaction volume and integrations increased.

Identify who owns system-wide architecture decisions and how those decisions are documented, reviewed, and updated as the project changes.

Approve the technical approach only when the provider can explain how the architecture supports the project’s current requirements without creating unnecessary complexity, cost, dependence, or maintenance risk.

Who Will Lead and Deliver Your Software Project?

Before choosing a software development company, identify the actual people who will be responsible for architecture, development, testing, delivery management, and client communication. Review each person’s role, seniority, availability, expected time allocation, and replacement process, including any subcontractors who may access project systems or data.

The people on the sales call are not necessarily the people who will deliver the software. The proposal should identify who will make architecture decisions, write and review the code, test each release, manage delivery, and work directly with your product owner or internal team.

A clear delivery-team structure should show:

• Named roles and responsibilities

• Seniority and relevant experience

• Expected time allocation

• Access to the technical lead or architect

• Responsibility for code review and testing

• Use of subcontractors or external specialists

• Replacement and knowledge-transfer procedures

• Ownership of technical and delivery decisions

In project reviews, we have seen how quickly technical decisions become difficult to trace when senior involvement reduces after the initial planning stage. Important architecture choices may remain in conversations rather than documentation, leaving developers to interpret earlier decisions later.

For that reason, we define who owns technical decisions, where those decisions are recorded, and how knowledge is transferred when responsibilities change during delivery.

Availability also matters. A senior developer assigned one day per week does not provide the same delivery capacity as a full-time technical lead. The same applies to QA, architecture support, delivery management, and product coordination. Confirm not only who is assigned, but how much time each key person will actually spend on the project.

Subcontractors require the same level of scrutiny. The client should know who employs them, which systems and data they can access, what responsibilities they hold, and which company remains accountable for their work.

Test the continuity plan as well. If a key team member leaves, current documentation, shared technical knowledge, and accessible project records should allow another person to take over without disrupting delivery.

Evaluate the named delivery team, not only the company profile. A capable software company can still create delivery risk if the assigned team lacks seniority, availability, technical ownership, or continuity planning.

Which Scope, Exclusions and Assumptions Support the Estimate?

A software development estimate should clearly state what is included, what is excluded, which assumptions it depends on, and which responsibilities sit with the provider or client. Compare providers only after confirming that each proposal covers the same workflows, dependencies, testing, deployment, documentation, support, and acceptance conditions.

A lower quote is not necessarily better value if it covers less work.

For example, one proposal may include data migration, deployment, user acceptance support, technical documentation, and 30 days of post-launch defect support. Another may exclude all five. The prices may look comparable, but the providers are not estimating the same project.

Review each estimate for:

• Included features and workflows

• Explicitly excluded work

• Technical and client dependencies

• Data migration responsibilities

• Testing and acceptance support

• Deployment and release responsibilities

• Documentation deliverables

• Post-launch support

• Third-party licences, platforms, and service costs

• Client responsibilities and required inputs

• Change triggers and pricing rules

Pay particular attention to assumptions. An estimate may assume that an external API is fully documented, the client provides clean migration data, required licences are already available, and stakeholders approve decisions within two working days. If any of those assumptions prove false, the provider may need additional work, time, or budget.

Separate validated assumptions from unresolved ones. The more important the untested assumption, the less confidence you should place in the headline estimate.

In our experience, the estimates that concern us most are those that look highly precise while important dependencies remain untested. A detailed number can still be unreliable if it assumes clean migration data, unrestricted API access, confirmed workflows, or fast stakeholder decisions without evidence.

The proposal should also explain how changes are handled. A useful change process records the effect of a requested change on scope, cost, priority, acceptance criteria, dependencies, and delivery dates before the work is approved.

Normalise shortlisted proposals before comparing price. Align the scope, exclusions, assumptions, dependencies, client responsibilities, acceptance conditions, deployment work, documentation, and support so that each estimate represents substantially the same project.

An apparently cheaper proposal can become more expensive through change requests, omitted responsibilities, third-party costs, delayed delivery, or incomplete handover. Compare the cost of equivalent delivery, not just the headline quote.

Who Will Own and Control the Code, Data and Project Accounts?

Before signing a software development agreement, confirm both legal ownership and practical control of critical project assets. These can include the source-code repository, cloud environment, hosting account, domain, deployment pipeline, production credentials, project documentation, and business data.

The contract should also define when intellectual property transfers, which third-party or background intellectual property remains licensed, who can access project data, and what the provider must transfer if the relationship ends.

For example, a contract may state that the client owns the completed source code. That protection is limited if the active repository and production cloud account remain under the provider’s company account and the client has no direct access. The client may still depend on the provider for deployments, permission changes, maintenance, incident response, and transition to another supplier.

Before signing, establish:

• Who owns the source-code repository

• When the client receives repository access

• Whose organisation controls cloud, hosting, and domain accounts

• Who controls production credentials and deployment permissions

• How user and administrator access is granted, reviewed, and removed

• When intellectual property transfers to the client

• Which pre-existing or background intellectual property remains with the provider

• Which third-party licences affect continued use of the software

• Who owns or controls project documentation and configuration records

• What assets, credentials, data, and documentation must be transferred at exit

Where the software processes personal data, the agreement should also define responsibilities for data access, processing, security, retention, deletion, incident handling, and access removal. These responsibilities should reflect the provider’s actual role and the systems and information it can access.

Practical control should be visible in the account structure, not only in the contract. Useful records include an account register, access matrix, licence register, credential-transfer process, repository permissions, and written exit obligations. Useful records can include an account register, access matrix, licence register, credential-transfer process, repository permissions, and written exit obligations.

We have learned that ownership problems often become visible only when a client needs to deploy independently, change permissions, investigate an incident, or move the software to another provider. That is why we treat repository access, account ownership, credentials, and handover as operating requirements rather than paperwork to resolve at the end.

Test the exit scenario before committing. Consider whether the client could obtain the current code, deployment information, credentials, documentation, data, and other agreed assets if the relationship ended during development or immediately after launch.

Legal ownership without practical access still creates provider dependency. Choose a delivery arrangement in which the client can control, maintain, and transfer its critical software assets when necessary.

What Evidence Will Prove the Software Is Ready for Release?

A credible software development company should base release approval on documented testing, acceptance status, defect records, retesting evidence, security checks, deployment readiness, and rollback planning. Before launch, the business should be able to see what was tested, what passed, what failed, what was retested, and which remaining risks were explicitly accepted.

A statement such as “quality assurance included” is not enough. It does not show what was tested, which requirements were covered, which defects remain open, whether fixes were retested, or who has authority to approve the release.

Release readiness should be supported by:

• An agreed test plan and scope

• Clear acceptance criteria

• Completed test results

• Traceability between important requirements and test evidence

• Open and resolved defect records

• Evidence that defect fixes were retested

• Relevant security-review evidence

• Deployment and release checklists

• A rollback or recovery plan

• A record of outstanding risks and accepted defects

• Documented release approval

In our experience, successful-path testing alone creates false confidence. The defects that matter most often appear around failed requests, repeated actions, incorrect permissions, unexpected data, third-party service failures, or recovery conditions. That is why we look for evidence that testing covers realistic failure scenarios as well as normal user journeys.

For example, a payment workflow may pass a standard purchase test but fail when a payment timeout triggers a repeated callback and creates two orders. Useful testing therefore covers more than the successful path. It should also examine relevant failure conditions, repeated requests, recovery behaviour, permissions, and data accuracy.

Different tests provide different evidence. User acceptance testing helps confirm that the software supports the agreed business workflows. Regression testing checks whether recent changes have damaged previously working behaviour. Security testing examines relevant access, data-handling, configuration, and technical risks. The exact mix should reflect the product and the consequences of failure.

Also establish who has authority to approve release. The development provider can supply technical evidence, but the client should understand which unresolved defects, operational risks, or acceptance exceptions remain before making the final business decision.

Release approval should depend on visible evidence rather than verbal reassurance. The client should know what passed, what failed, what was retested, and which residual risks it is accepting before the software goes live.

What Support Will the Company Provide After Launch?

Post-launch responsibilities should be clear before development ends. The support model should define the warranty period, defect criteria, severity levels, response expectations, maintenance scope, monitoring responsibilities, security updates, pricing, and handover obligations. Post-launch support should define the warranty period, defect criteria, severity levels, response expectations, maintenance scope, monitoring responsibilities, security and dependency updates, pricing, and handover obligations.

The agreement should also distinguish between warranty defects, ongoing maintenance, incidents, and new development. Without clear definitions, the client and provider may disagree later about which work is included and which requires additional payment.

Review these areas before launch:

• Warranty period and covered defects

• Defect definitions and severity levels

• Response and escalation conditions

• Maintenance scope

• Production monitoring responsibilities

• Incident ownership and communication

• Security and dependency updates

• Third-party integration changes

• Future development and change-request processes

• Maintenance and support pricing

• Documentation and handover obligations

For example, a payment-provider API may change six months after release. The support agreement should explain who monitors for the change, assesses its impact, updates the integration, tests the revised workflow, deploys the change, and pays for the work.

The provider should also define the difference between a defect and a new requirement. If an existing feature fails to meet an agreed requirement or acceptance criterion, that may fall within defect or warranty support. A request for new behaviour, an additional workflow, or a changed business rule is usually new development. Clear definitions reduce disputes over responsibility, cost, and delivery times.

Real users, production data, third-party services, traffic patterns, and live infrastructure can expose issues that did not appear during development. Support arrangements should therefore address monitoring, incident handling, recovery, software updates, security fixes, and operational communication.

The support arrangement should also cover the end of the relationship. The client should be able to obtain current documentation, credentials, configuration information, deployment instructions, outstanding issue records, and other agreed project assets. The client should be able to obtain current documentation, credentials, configuration information, deployment instructions, outstanding issue records, and other agreed project assets so that another provider can continue the work.

Choose support terms that make ownership, response, cost, escalation, and handover clear. Post-launch support should preserve operational continuity rather than create a new dependency on the original provider.

What Should You Ask Before Signing a Software Development Contract?

Each due-diligence question should lead to something that can be reviewed before you commit. Strong answers are supported by named people, written processes, project records, account structures, contract terms, or relevant delivery examples. A confident answer is still weak if the provider cannot support it with a named person, written process, project record, account structure, contract term, or relevant delivery example.

Do not evaluate answers in isolation. They should be consistent across the proposal, contract, delivery process, and actual account structure.

For example, a provider may state that the client owns the source code while the contract gives repository access only after final payment. Another may promise a dedicated technical lead while the delivery plan assigns that person for only a few hours each week. These contradictions leave ownership, continuity, and delivery responsibility unresolved.

Treat vague, conflicting, or unsupported answers as open risks until the provider supplies evidence or the agreement is clarified.

A useful due-diligence question should help you make a decision. The value of the answer depends less on how confidently it is presented and more on whether the evidence behind it can be reviewed, recorded, and enforced.

How Can You Score Software Development Companies Against the Same Criteria?

Use a weighted scorecard to compare shortlisted software development companies against the same evaluation criteria. Score the quality of the evidence behind each provider’s claims, not the quality of the sales presentation or the number of documents supplied.

A consistent scorecard reduces the influence of persuasive presentations, different proposal formats, and low headline prices. It also makes it easier to explain why one provider is stronger than another.

Score each area from 0 to 5:

• 0 — No evidence: the provider has not demonstrated capability in this area.

• 1 — Weak evidence: the answer is mainly verbal, generic, or unsupported.

• 2 — Partial evidence: some relevant information exists, but important details remain unresolved.

• 3 — Clear evidence: the provider supplies specific, reviewable information that addresses the requirement.

• 4 — Strong evidence: the evidence is detailed, relevant, and supported by named ownership or documented processes.

• 5 — Strong, proven evidence: the provider combines clear evidence with relevant delivery examples, references, records, or demonstrable outcomes.

Multiply each score by the assigned weight to calculate a weighted result, then compare totals across shortlisted companies.

For example, if a provider scores 4 out of 5 for relevant delivery evidence, and that category carries a 15% weighting, it receives 12 weighted points out of 15 for that area.

Do not rely on the total score alone. Some issues should be treated as critical risks or minimum conditions rather than weaknesses that can be offset by strong scores elsewhere.

For example, a provider may score highly for experience, communication, and technical approach but refuse to give the client appropriate access to the source-code repository or critical cloud accounts. A strong overall score does not remove that ownership and continuity risk.

Review areas such as the following separately:

• Security responsibilities

• Intellectual-property terms

• Source-code and account control

• Data access

• Acceptance and release authority

• Exit and handover obligations

• Unresolved contractual dependencies

Consider defining minimum acceptable conditions for these areas before calculating the final shortlist. A provider that fails a critical requirement may need to resolve it before progressing, regardless of its weighted score.

Use the scorecard to make providers easier to compare, not to automate the final decision. The strongest choice combines a high evidence-based score with no unresolved critical risks in security, ownership, acceptance, or continuity.

How Square Root Solutions UK Reduces Early Software Project Risk

Square Root Solutions UK applies the same evidence-based approach described in this guide when helping businesses plan and assess software projects.

Our UK software development team has worked in software development for more than 10 years, supporting businesses with project planning, technical delivery, software ownership, and post-launch continuity.

That work includes AI integration projects designed to automate workflows and reduce manual operational steps. Projects of this kind require more than implementation capacity. They depend on clear workflow mapping, reliable integration planning, controlled data access, testable acceptance conditions, documented technical decisions, and practical handover arrangements.

When reviewing an early-stage software project or proposal, Square Root Solutions looks at the evidence behind areas such as:

• Project scope and business workflows

• Technical dependencies and integrations

• Architecture and hosting assumptions

• Estimate assumptions and exclusions

• Software and account ownership

• Testing and acceptance evidence

• Support and maintenance responsibilities

• Exit and handover requirements

Across more than 10 years of software development work, our team has supported software discovery, new product development, project continuation, and software modernisation engagements where the initial brief did not reveal the main delivery risk.

In some projects, deeper assessment has exposed hidden dependencies around third-party integrations, existing data, undocumented workflows, hosting arrangements, and technical account ownership. These findings can affect the architecture, development sequence, project scope, estimate, and delivery plan before substantial engineering work begins.

Our team also reviews whether the delivery model gives the client practical control over the software. This includes checking source-code repository access, cloud and hosting accounts, project documentation, credentials, deployment responsibilities, third-party dependencies, and handover requirements.

We have found that these issues are easier to resolve during discovery than after development has started. Identifying them early gives the team more opportunity to change the technical approach, clarify responsibilities, and reduce avoidable rework or delays.

This experience is one reason we place discovery before major development commitments. The purpose is to test assumptions, expose dependencies, and clarify ownership before they become larger technical or commercial problems later in the project.

Speak With a UK Software Development Team

Discuss your software scope, technical dependencies, estimate assumptions, and delivery risks before committing to a full development agreement.

Conclusion

Choosing the right software development company is not mainly a question of finding the lowest price, the largest portfolio, or the most persuasive proposal. It is a question of whether the provider can produce credible evidence that it understands your project, can deliver it responsibly, and will leave you with sufficient control over the software and its future operation.

Start by defining the business problem and giving shortlisted providers the same project information. Then compare their relevant experience, discovery process, technical approach, delivery team, estimate assumptions, testing evidence, ownership arrangements, and post-launch support against consistent criteria.

Pay particular attention to what can be verified. A strong provider should be able to explain its assumptions, identify unresolved risks, introduce the people responsible for delivery, show how progress and quality will be evidenced, and clearly define who controls the code, data, accounts, documentation, and handover process.

Do not rely on a weighted score alone. Serious weaknesses in areas such as security, intellectual property, source-code access, acceptance, or exit arrangements should be resolved before they are offset by strengths elsewhere.

The strongest software development partner is therefore not simply the company that promises the most. It is the one that provides the clearest evidence, makes uncertainty visible, accepts appropriate accountability, and gives your organisation confidence that the software can be delivered, maintained, and transferred without unnecessary operational or commercial risk.

Frequently Asked Questions

Q.

How long should software discovery take?

There is no fixed duration for software discovery. It should last long enough to clarify the important users, workflows, integrations, constraints, assumptions, dependencies, and delivery risks before major development commitments are made.

UK government service guidance says a discovery phase typically lasts around 4 to 8 weeks, although a familiar or well-understood problem may require less time and a complex or unfamiliar problem may require longer.

The right duration should be determined by the uncertainty that needs to be resolved, not by a fixed calendar target.

Q.

Should I pay for software discovery, or should it be free?

A detailed discovery phase is usually paid work because it can involve user and workflow analysis, technical investigation, integration research, architecture input, risk identification, estimation, and documented outputs.

A free introductory consultation can help determine whether a provider is suitable, but it should not be treated as a substitute for project discovery.

Before paying for discovery, confirm:

• What activities are included

• Which deliverables you will receive

• Who will own and control the outputs

• Whether another provider can use them

• The fee and duration

• What decision the discovery is intended to support

Q.

Who owns the code if the software project stops halfway?

Code ownership depends on the contract, payment terms, intellectual-property provisions, and the status of the work when the project ends.

The agreement should state:

• Which completed and partially completed deliverables transfer to the client

• When intellectual-property rights transfer

• Which pre-existing or third-party components remain licensed

• Whether the client receives the current repository and work in progress

• Which credentials, documentation, configuration, and data must be transferred at exit

Do not rely only on a general statement that “the client owns the code.” Confirm both the legal rights and the practical ability to access and continue the work.

Q.

Should a software project use fixed-price or time-and-materials pricing?

Fixed pricing can work well when the scope, dependencies, acceptance criteria, and delivery boundaries are sufficiently understood. Time-and-materials can provide more flexibility when requirements are expected to evolve through research, testing, or user feedback.

For projects with significant uncertainty, a paid discovery phase followed by staged or phased delivery may provide more control than fixing the entire project price before the main risks are understood.

UK government guidance on agile contracting says there is no single correct commercial model for every agile project. It notes that rigid whole-project fixed pricing is less suitable where uncertainty is high and that time-and-materials may be appropriate for discovery or as part of a hybrid pricing structure.

Q.

How many software development companies should I shortlist?

For many projects, a shortlist of three to five credible providers is manageable enough for meaningful comparison without creating an unnecessarily large procurement exercise.

The exact number matters less than the quality of the shortlist. Apply initial qualification criteria first so that each provider has relevant experience, appropriate capacity, and a realistic ability to deliver the project.

Then compare the shortlisted companies using the same requirements, evidence requests, and evaluation criteria.

Q.

What is a normal warranty period after software launch?

There is no universal warranty period for custom software. The appropriate term depends on the project size, risk, acceptance process, contract, and release conditions.

The agreement should define:

• The warranty duration

• Which defects are covered

• Excluded circumstances

• Response expectations

• Whether defect fixes are included

• What happens when the warranty ends

It should also distinguish warranty defects from maintenance, third-party changes, and new requirements so that responsibility and cost remain clear.

Q.

Can I run discovery with one company and build with another?

Yes, provided the discovery agreement gives you the right and practical ability to use and transfer the outputs.

Useful discovery deliverables can include:

• Documented workflows

• Requirements and priorities

• Assumptions and unresolved questions

• Architecture decisions

• Integration findings

• Acceptance criteria

• Research outputs

• Dependency and risk records

Confirm ownership or usage rights before discovery begins, and make sure the outputs are stored in accessible formats and accounts. A new development provider should still validate important assumptions before relying on the earlier estimate or technical approach.

Q.

What is the difference between a software defect and a new requirement?

A defect occurs when the delivered software fails to meet an agreed requirement, acceptance criterion, or expected behaviour already included in the project.

A new requirement adds or changes behaviour that was not previously agreed.

For example, if the agreed checkout flow should calculate VAT correctly but produces the wrong total, that is a defect. If the client later asks for support for an additional tax jurisdiction that was not in scope, that is a new requirement.

The contract and change process should explain how defects and new requirements are classified, evidenced, approved, and priced because the distinction affects whether work is covered by the original scope, warranty, maintenance agreement, or a paid change request.