Short answer
Choosing a software development company should rest on the answers to questions about process, people, code ownership and support after launch, not on the price of the proposal alone. Before signing a contract, ask the 12 questions listed below and compare the answers in writing. It is especially important that the contract clearly transfers the economic (property) rights to the code and sets out personal data processing, the warranty period and the support terms.
Choosing a software company: why the cheapest proposal is often the most expensive
Two proposals for the same system can differ several times over. The difference usually comes not from the hourly rate but from what the proposal includes. The cheaper one often leaves out process analysis, automated tests, documentation, data migration or training. That work will still be needed; it simply turns up later as additional orders, at a point when changing supplier is already difficult.
That is why suppliers are best compared on four things: what will be built, how it will be checked, who will own the result and what happens after launch. The questions below are grouped under these themes. You can simply send them to every supplier and ask for written answers.
Questions about the process
1. Where does the project start, and what does the first stage deliver?
A serious supplier wants to understand the process before estimating a price: to talk to the people who will use the system and to see the existing files and applications. Ask whether the first stage ends with a document you can take away, such as a process description, a feature list and an estimate. Such a document is useful even if you later choose a different developer.
2. How often will we see a working part of the system?
A good answer names a specific rhythm, for example a demo every two weeks in a test environment where you can click through it yourself. A report saying "80% of the work is done" with nothing to try out tells you very little.
3. How will the completed work be accepted?
Acceptance testing is the stage where the client checks whether the system meets the agreed requirements. Ask who will prepare the acceptance scenarios, how much time you will have for checking, what counts as a critical defect and what happens if one is found. Clear acceptance criteria protect both sides: you get what you ordered, and the supplier knows when the work is finished.
Questions about the team and expertise
4. Who exactly will work on our project, and will there be subcontractors?
The people in the sales meeting are not always the ones who will write the code. Ask who will be responsible for the architecture, who will develop and test, and whether any of the work will be passed to subcontractors. If subcontractors will see your data, this also matters under the GDPR (see question 9).
5. Can you show us a similar project that is live?
Screenshots and descriptions are a start, but it is more valuable to see a working system or at least a demo of it. Ask what problem the project solved, what was hardest about it and whether the system is still in use.
6. Which technologies do you use, and why those?
How fashionable a technology is matters little. What matters more is whether, a few years from now, there will be developers on the market who can maintain the system. Widely used open-source technologies with an active community reduce dependence on a single supplier. If the supplier builds on its own closed platform, ask what will happen to your system if it stops developing that platform.
Questions about code and ownership
7. Who will own the economic rights to the source code?
This is one of the most important questions, and in Lithuania it is governed by the Law on Copyright and Related Rights. A computer program is protected as a copyright work. Under Article 10(2) of the law, the economic rights to a program created by an employee in the course of their job duties belong to the employer, unless the contract provides otherwise. This means that without a separate agreement the rights stay with the software company, even though you paid for the work.
Several rules of the law apply to the transfer of rights and are worth knowing:
- A copyright transfer agreement or a commissioning agreement for a work must be made in writing (Article 42(1)).
- The agreement must specify the rights being transferred and the ways the work may be used, the territory, the term and the remuneration (Article 40(1)).
- If the ways of use are not specified, only the rights needed to achieve the purpose of the agreement are deemed transferred. If the territory is not specified, the rights are deemed transferred for Lithuania only. If the term is not specified, either party may terminate the agreement with one year's written notice (Article 40(2) and (3)).
- Rights to ways of use that do not exist or are unknown at the time of transfer cannot be transferred (Article 38(3)).
In practice, the contract should state clearly that the rights to reproduce, modify, adapt and distribute the code are transferred without time limit and worldwide. Discuss separately which of the supplier's pre-existing components and which open-source libraries are used: for these you will usually receive a licence without ownership, and that is normal as long as the licence terms are clear. It is worth having a lawyer review the contract before signing.
8. Where will the code be stored, and will we have access to it?
Ask whether the code will live in a repository created in your name (for example on GitHub or GitLab) or only on the supplier's servers. It matters that you also hold the access credentials for the servers, the domain and the database.
If the code stays with the supplier, for example when you buy a licence for its platform, there are source code escrow agreements. This is a three-party agreement between the supplier, the client and an independent escrow company that holds the code and documentation. The code is released to the client when an event named in the agreement occurs, such as the supplier's insolvency or the end of support. It is worth checking the deposited material periodically to make sure it is complete and usable.
9. Will we sign a data processing agreement?
If the system will process personal data and the supplier will have access to it (while building, testing or maintaining the system), the supplier becomes a data processor under the GDPR. Article 28 requires the data controller to use only processors that provide sufficient guarantees of appropriate technical and organisational measures, and the relationship must be set out in a written (which may be electronic) contract.
Among other things, the contract must state that the processor processes data only on your documented instructions, ensures confidentiality of its staff and security measures, engages sub-processors only in line with the agreed rules, helps you handle data subject requests, deletes or returns the data when the services end and allows audits. If the supplier does not know what you are talking about, that is already an answer.
Questions about support after launch
10. What is the warranty period, and what does it cover?
Ask how long after launch defects are fixed free of charge, and what counts as a defect as opposed to a new request. If the contract is treated as a contract for work under Lithuanian law, Article 6.666 of the Civil Code provides that where no warranty period is set, defects in the work must be identified within a reasonable time, but no later than two years from the handover of the result, unless the law or the contract provides otherwise. Claims regarding defects are subject to a one-year limitation period (Article 6.667). A clearly stated warranty period and scope in the contract avoids disputes over how these provisions apply to software.
11. What are the support (SLA) terms?
An SLA (service level agreement) usually specifies the following:
| Term | What it means | What to ask |
|---|---|---|
| Response time | How quickly the supplier starts working on a problem | Does it vary by severity, does it apply at weekends |
| Resolution time | How quickly the problem is fixed or worked around | Is it a commitment or only a target |
| Availability | How much of the time the system must be up | How is it measured, what happens if it is missed |
| Updates | How security patches and version upgrades are handled | Are they included in the price, how often |
| Backups | How often they are taken and how long they are kept | When was a restore last tested |
It is worth converting availability percentages into minutes. 99.9% over a 30-day month allows about 43 minutes of downtime, 99.5% about 3.6 hours. The higher the requirement, the more expensive the infrastructure, so choose what your process actually needs.
12. What happens if we end the relationship?
This question is uncomfortable but essential. Ask what you will receive if the contract ends: code, documentation, a copy of the database, access credentials, and how quickly. This is worth writing into the contract before work starts, while the relationship is still good.
Answers that should worry you
Most of these answers do not mean dishonesty. They show that risk is being shifted onto you, and that is worth knowing before you sign.
| Question | Worrying answer | Why it matters |
|---|---|---|
| First stage | "No analysis needed, we'll start coding straight away" | An unclear scope later means additional orders |
| Interim results | "We'll show you when everything is finished" | Mistakes are noticed too late, when they are expensive to fix |
| Acceptance | "You don't need acceptance criteria, trust us" | You have no basis for requiring defects to be fixed |
| Team | Cannot say who will work on the project | It is unclear whether the right skills are there |
| Ownership | "The code stays with us, but you'll be able to use it" | Without a clear licence you cannot change supplier |
| Access | "We'll administer the servers and domain" | If the relationship ends, you have no access to your own system |
| Personal data | "GDPR doesn't apply to us, we only write code" | As data controller you are responsible for choosing the processor |
| Warranty | "Bugs will be fixed at the hourly rate from day one" | You pay for the supplier's mistakes |
| Exit | "That never happens" | There is no plan for taking over the system |
What to ask previous clients
References are most valuable when you speak to someone who uses the system every day. Ask the supplier for a contact and put a few specific questions to them:
- Was the project delivered on time and on budget, and if not, why?
- How did the supplier behave when disagreements or changes came up?
- How quickly are problems resolved after launch?
- Do you have the code and all access credentials in your own name?
- Would you choose this supplier again?
Pay attention not only to the answers but also to how long the system has been running. A project that has been used and developed for several years says a lot about the working relationship after launch.
What to do next
You can put these 12 questions to any supplier, including us. How we answer them is described on our process page: from a paid analysis stage to SLA-based support. If it is not yet clear what you need from a system, a good starting point is IT consulting and system design, and you can send us your questions via the contact page.
Sources
- Law on Copyright and Related Rights of the Republic of Lithuania (e-tar.lt, consolidated version, in Lithuanian)
- Civil Code of the Republic of Lithuania, Article 6.666. Time limit for identifying defects in work (in Lithuanian)
- Civil Code of the Republic of Lithuania, Article 6.667. Limitation period (in Lithuanian)
- GDPR Article 28. Processor (gdpr-info.eu)
- GDPR Article 32. Security of processing (gdpr-info.eu)
- techUK. What are the release events and clauses in software escrow agreements?