How to Choose a Software Company: Questions, Contract, Code

This is the most important question. If the contract does not state plainly that the source code passes to the client once payment is complete, the code may stay with the agency. If you later want to work with another team, or if you and the agency part ways, your access to your own product is then at risk. Picture a flooring manufacturer that falls out with the agency that wrote its ordering system. If the code sits on the agency's server, the manufacturer may not even be able to reach its own workflow.

Alongside ownership, access matters. In whose name are the code repository, the server, the domain name and the third-party accounts opened? Having them opened in the client's name settles, at the outset, the point that causes the most trouble later. For the detailed legal drafting it is sensible to consult a lawyer.

Handover is more than going live. A good handover includes the orderly transfer of the source code, the setup notes, the environment details and the administrator access. If another developer can bring the product up from those documents, the handover is complete. A practical way to test this is to have an independent developer read the setup notes before delivery.

Acceptance criteria and the testing process should be written down beforehand. A warranty period should also be discussed: fixing faults that appear after delivery free of charge for a set time is a safeguard offered by most serious companies.

• The source code and its version history are transferred to the client.
• Setup and environment notes are provided in writing.
• Administrator access is set up under the client's own account.
• Acceptance criteria and the test process are written in advance.
• The period for fixing faults after handover is defined.

Software does not end at handover. It needs security updates, dependency renewals and small improvements. The maintenance agreement should state plainly what it covers, how a fault is reported and what the response time will be. Otherwise every small request becomes a separate negotiation, and in an urgent fault there is an argument about who is responsible.

The company that maintains the system need not be the one that built it, but tidy, documented code is what makes such a move possible. A company that does not discuss maintenance at the start of a project usually does not discuss it afterwards either. Asking about it in the first meeting is therefore the quickest way to learn whether a company stands behind its product.

If a small company's work depends on a single developer, the project can stall when that person leaves. So you need to ask who will run the project, whether there is a back-up person and how knowledge is shared.

Written documentation, code review and a shared development routine are the concrete signs of continuity. It matters just as much to find out whether the person at the sales meeting is the person who will do the work. If you can, speak once directly to the developer who will do it; the ability to explain technical matters in plain language is a good sign.

The commonest mistake is choosing on the quoted figure alone. A low quote usually means a narrow scope, a vague definition or extra requests that arrive later. The second mistake is not checking references. Talking to earlier clients about what happened after delivery is more instructive than most presentations.

The third mistake is not questioning the technical choices. The technology the product is built in decides whether another team can carry it on later. Widely used and well-documented technologies generally carry less risk. A very new structure, or one that only that company understands, can make maintenance costly and difficult.

• Looking only at price: scope and assumptions should be compared.
• Not asking for references: speak to an earlier client.
• Not reading the contract: the ownership and maintenance clauses get skipped.
• Confusing the salesperson with the developer: ask who will do the work.

A company that quotes a price at once, without asking about scope, should be assessed with care. A company that proposes solutions without listening, refuses to hand over the source code or insists on keeping access credentials in its own account may leave you dependent later. None of these is proof of bad faith on its own, but each is a point on which an explanation should be requested before you sign.

A large software company is unnecessary for a small, one-off job, and a one-person team is risky for a critical, long-lived system. The right choice is the one where the size and structure of the company match the size and lifespan of the work.