What questions to ask a software company before signing the contract

Client guide: source code, intellectual property, warranty, post-launch support and SLA — what to clarify before signing a contract with a software company.

Choosing a software company should not be based only on price, portfolio or the promise that "it can be done". A software project is a serious investment, and the contract you sign at the start can decisively influence what happens during and after launch.

Many clients discuss features, delivery timeline and cost, but forget to ask essential things: who owns the source code, what rights they have over the application, what happens if bugs appear after launch, how support is provided, what maintenance includes, what warranty exists, how data is protected and what happens if the software company can no longer continue the project.

These questions may seem awkward at the start. In reality, they are a sign of a mature client and a healthy collaboration. A serious software company will not be scared by them. On the contrary, it will appreciate that you want clarity before the project begins.

A good contract is not made for situations where everything goes perfectly. It is made for situations where changes, delays, errors, misunderstandings or new needs appear. The more you clarify at the start, the lower the risk of conflicts later.

1. Who owns the source code?

This is one of the most important questions. Source code is the technical foundation of the application. Without access to it, you depend completely on the company that developed the software. If you want changes, extensions, maintenance or migration to another provider, source code becomes essential.

The question must not be asked vaguely. It is not enough to ask: "Will the application be mine?" You must clarify concretely:

• Will I receive the source code?
• When will I receive it?
• In what form will I receive it?
• Will it be in a Git repository?
• Do I have access during the project or only at the end?
• Can another team work on the code after project completion?
• Are there components that remain the provider's property?

A software company may use open-source libraries, frameworks, proprietary components or external services. Not all these elements can be "transferred" in the same way. That is why the contract must clearly explain what you actually receive.

For custom applications, it is normal for the beneficiary to request access to source code and the right to continue development, at least after full payment of the project.

2. Who owns the intellectual property of the application?

Source code and intellectual property are related, but they are not the same thing. You can have access to code but only a right of use. Or you can have extended rights over the application, including the right to modify, distribute, resell or further develop it. These details must be clearly established in the contract.

Useful questions:

• Are proprietary rights over the software transferred to the client?
• Is the transfer full or partial?
• Does transfer happen at contract signing or after full payment?
• Can I modify the application with another provider?
• Can I use the application for multiple companies, locations or clients?
• Can I resell the application or only use it internally?
• Are there reusable modules that remain the software company's property?

For an internal application, a broad right of use and the right to modify may be enough. For a SaaS product or platform you want to sell further, rights must be treated much more carefully.

Do not assume that "if I pay for the application, I automatically own everything". In software, these things must be written explicitly.

3. What happens with open-source or third-party components?

Most modern applications use open-source components, frameworks, libraries, external APIs or cloud services. This is normal and efficient. It does not make sense to build everything from scratch. However, you must know what dependencies exist.

Important questions:

• What technologies and frameworks will be used?
• Are there open-source licences with special obligations?
• Are there external services with monthly costs?
• Are there paid APIs?
• What happens if an external service changes price or terms?
• Can the application work without those services?
• Who manages accounts for external services?

For example, the application may use services for email, SMS, online payments, maps, file storage, authentication, data analysis or artificial intelligence. Costs and responsibilities for these services must be clarified.

A good offer should differentiate development cost from recurring external costs.

4. What exactly does the price include?

A price without structure can create misunderstandings. Two offers may seem similar in value but include completely different things.

Ask what is included in the price:

• analysis;
• UX/UI design;
• frontend development;
• backend development;
• database;
• admin panel;
• testing;
• deployment;
• server configuration;
• documentation;
• training;
• post-launch support;
• maintenance;
• licences;
• integrations;
• data migration.

Also ask what is not included. Sometimes the client assumes design is included, but the offer covers only development. Or they assume hosting is included, but it is billed separately. Or they believe unlimited changes are included, while the offer covers only initially defined features.

Financial clarity is essential. A serious company should be able to explain where the cost comes from and what you receive for it.

5. How are requirement changes managed?

In almost every software project, changes appear. This is normal. As you see the application, test flows and involve real users, new ideas or adjustments appear. The problem is not change. The problem is lack of a process for change.

Useful questions:

• How are new requirements treated?
• How is impact on cost estimated?
• How is impact on timeline estimated?
• Who approves changes?
• Is there a change request document?
• Are small changes included or billed separately?
• How are new features prioritised?

Without a clear process, the project can get out of control. A healthy change management process protects both client and provider.

6. Who is the project owner on the client side?

This question seems internal, but it is very important. A software project needs a responsible person on the client side. This person centralises feedback, makes decisions, validates deliveries and communicates priorities.

Ask the software company how it prefers to collaborate:

• Who must provide feedback?
• How often are meetings held?
• How are features validated?
• What happens if feedback is delayed?
• How are decisions documented?

On your side, you must designate an internal owner. If feedback comes from five different people with contradictory opinions, the project gets blocked. Good collaboration has clear responsibilities on both sides.

7. What working methodology do you use?

You do not need to be an expert in Agile or Waterfall, but you must understand how the project will be managed.

Useful questions:

• Do you work with incremental deliveries?
• Will we see demos along the way?
• How often do we receive progress?
• Are there defined sprints or stages?
• Can we test modules before the end?
• How is feedback managed?
• Is there a roadmap?

The goal is to avoid the situation where you see the application only at the end and discover it does not meet expectations. For custom applications, incremental deliveries are very useful.

8. What warranty do you offer after launch?

Warranty is a subject that must be clarified before signing. In software, warranty usually refers to fixing errors for features delivered according to specifications. It does not mean free development of new features.

Important questions:

• Is there a warranty period?
• How long is it?
• What types of problems are covered?
• What is a bug?
• What is not considered a bug?
• How are errors reported?
• What is the response time?
• Does warranty cover problems caused by external services?

For example, if the application does not correctly save an order according to specifications, that is an error. If after launch the client wants a new type of report, that is a new feature. The difference must be clarified, otherwise difficult discussions appear.

9. What post-launch support exists?

Launch is not the end of the project. After launch, questions, adjustments, bugs, new users, business changes and optimisation needs appear.

Ask:

• Do you offer post-launch support?
• Is it included in the price?
• For how long?
• What support channels exist? Email, phone, ticketing, chat?
• What is the response time?
• Does support include only bugs or also usage questions?
• Are there monthly support packages?

For business applications, support is essential. An application without support can quickly become a problem, especially if it manages important processes: orders, clients, documents, invoices, appointments or reports.

10. Is there an SLA?

SLA stands for Service Level Agreement. It is an agreement that defines the level of service: response times, intervention times, availability, priorities and responsibilities.

Not every small project needs a complex SLA. But if the application is critical for business, SLA becomes important.

Useful questions:

• Is there an SLA?
• What is the response time for critical incidents?
• What is the response time for normal issues?
• Is there weekend support?
• Is there out-of-hours support?
• How are incidents classified?
• What happens if the application is unavailable?
• Who monitors the application?

For a presentation website, a strict SLA may be unnecessary. For an order portal, transport platform, medical system or financial application, SLA can be essential.

11. Who handles hosting, servers and infrastructure?

The application must run somewhere. Hosting and infrastructure must be clarified in advance.

Important questions:

• Where will the application be hosted?
• On the client's server or in the cloud?
• Who administers the server?
• Who pays for hosting?
• Who configures backup?
• Who monitors the server?
• What happens if the server goes down?
• Does the client have access?
• Is data stored in the EU?

For applications that process personal or sensitive data, infrastructure location and security are important. It must also be clarified whether the software company has production access and under what conditions.

12. How is backup done?

Backup is one of the most important safety measures, but it is often ignored until a problem appears.

Essential questions:

• Is there automatic backup?
• How often is it performed?
• Where are backups stored?
• How long are they kept?
• Is backup restoration tested?
• Who is responsible for backup?
• What happens in case of data loss?

An untested backup does not offer sufficient safety. There must be a clear restoration plan. For critical applications, backup must be treated as part of business infrastructure, not as a technical option.

13. How is personal data protected?

If the application manages users, clients, employees, patients, partners or any other individuals, obligations regarding data protection arise.

Useful questions:

• What personal data does the application process?
• Who is the data controller?
• Is the software company a processor?
• Is there a data processing agreement?
• What security measures are implemented?
• Are there access logs?
• Can data be exported or deleted on request?
• What happens to data after contract termination?
• Are there subcontractors with access to data?

GDPR is not just a formal checkbox. If the application manages important data, its protection must be planned from the design stage.

14. Who has access to production data?

During development and support, the software company may need access to server, database or administrative accounts. This must be controlled.

Important questions:

• Who has access to the production environment?
• Is access limited?
• Are there logs?
• Are individual or shared accounts used?
• Can access be revoked?
• Do developers use real data in testing?
• Is production data anonymised in test environments?

These questions are very important for security. Real data should not be freely copied into test environments without clear rules.

15. Is there documentation?

Documentation does not need to be excessive, but it must exist.

Useful questions:

• Will I receive technical documentation?
• Will I receive user documentation?
• Are there instructions for administrators?
• Is there API documentation?
• Is there an architecture description?
• Is there an installation or deployment guide?

Without documentation, you become dependent on the people who initially built the application. If the team changes, maintenance becomes more difficult. For custom applications, documentation is part of project value.

16. How is project handover done?

Handover does not mean only "the application is live". A complete handover may include:

• source code;
• repository access;
• server access;
• documentation;
• administration credentials;
• deployment instructions;
• list of external services;
• accounts and credentials;
• backups;
• user guide;
• training;
• status of delivered features.

Ask from the start what you receive at the end. Otherwise, you may discover the application works but you do not have real control over it.

17. How is maintenance treated?

Maintenance is different from warranty. Warranty usually covers errors in delivered features. Maintenance covers keeping the application functional and updated over time.

Useful questions:

• Is there a maintenance contract?
• What does it include? Security updates, monitoring, backup, optimisations?
• Framework updates?
• Periodic checks?
• User support?
• New features?
• How much does it cost monthly?

For business applications, maintenance must not be ignored. Technologies change, external services update, vulnerabilities appear and business evolves. An application without maintenance ages.

18. What happens if we want to change provider?

It is a sensitive but very important question. A serious client must know whether they can continue the project with another team in the future.

Useful questions:

• Can I move the project to another provider?
• Will I receive the source code?
• Will I receive documentation?
• Will I receive the database?
• Will I receive infrastructure access?
• Are there clauses that limit collaboration with another team?
• Is there a transition period?

A serious company should not build artificial dependency. It is normal to have commercial and contractual rules, but the client must have clarity over their options.

19. How is project completion measured?

A software project must have acceptance criteria. Otherwise, completion becomes subjective. The client says the application is not ready, the provider says they delivered according to contract.

Useful questions:

• How is it established that a feature is complete?
• Are there acceptance criteria?
• Is there a testing process?
• How much time does the client have for validation?
• What happens if they do not provide feedback on time?
• How are bugs documented?
• How are partial deliveries accepted?

Acceptance criteria protect both parties. The client knows what they must receive, and the provider knows what they must deliver.

20. What are the project risks?

A very good question is: "What are the main risks you see in this project?" The answer says a lot about the software company's maturity.

A serious company will not promise everything will be simple if the project is complex. It will identify risks such as:

• unclear requirements;
• difficult integrations;
• data migration;
• dependencies on external providers;
• very tight deadlines;
• limited budget;
• lack of a project owner;
• incomplete data;
• users hard to involve;
• security;
• performance;
• scope changes.

A company that openly discusses risks is not trying to scare you. It is trying to build a realistic project.

21. What experience do you have with similar projects?

Portfolio matters, but you do not necessarily need to find a company that did exactly the same project. More important is to see whether it understands the type of complexity.

Useful questions:

• Have you worked on similar applications?
• Have you done integrations with external systems?
• Have you built portals, dashboards, CRMs, internal applications?
• How do you approach projects with roles and permissions?
• How do you manage data migration?
• How do you test business applications?

You can ask for anonymised examples, case studies or explanations about relevant projects.

22. What happens if delays occur?

Delays can appear in any project. What matters is how they are managed.

Useful questions:

• How do you communicate delays?
• How is the timeline updated?
• What happens if the delay is on the provider's side?
• What happens if the delay is caused by client feedback?
• Are there milestones?
• Is payment linked to deliveries?

A good contract must treat delays realistically, not pretend they cannot exist.

23. What does communication look like along the way?

Poor communication is one of the main causes of problems in software projects.

Ask:

• Who is the contact person?
• How often do we have meetings?
• Do we receive demos?
• Do we receive progress reports?
• Where do we report feedback?
• Do we use email, ticketing, project management?
• How are decisions documented?

A good project has a communication rhythm. There should not be unnecessary meetings, but there must be transparency.

24. What must we prepare as beneficiary?

A software project is not only the provider's responsibility. The client must provide information, feedback, access, decisions and validations.

Ask the software company:

• What do you need from us?
• Who must participate in discovery?
• What documents must be prepared?
• Do we need to provide report examples?
• Must we provide access to existing systems?
• Who tests the application?
• Who validates deliveries?

This question helps a lot. It shows you treat the project as a collaboration, not as an order thrown over the fence.

25. What must definitely be written in the contract?

A good software contract should clarify at least the following:

• project scope;
• included features;
• deliverables;
• price and payment terms;
• estimated schedule;
• party responsibilities;
• requirement change process;
• source code rights;
• intellectual property rights;
• warranty;
• post-launch support;
• maintenance;
• SLA, if applicable;
• confidentiality;
• data protection;
• hosting;
• backup;
• project handover;
• termination conditions;
• liability limitations;
• acceptance procedure.

Not all contracts need to be complicated, but all must be clear.