Software development: briefing a developer and keeping control of your code

A good brief describes the problem, not the screens. Explain what your staff or customers do today, where it breaks down, and what a successful system would change. Name the people who will use it and roughly how many, and list the systems it has to talk to: accounting software, a CRM, a warehouse system, a payment provider, Microsoft 365.

Separate what you must have at launch from what would be nice later. Developers price uncertainty, so an open-ended wish list produces either a high fixed price or a loose estimate. If you have no written specification, many firms offer a paid discovery phase of workshops and prototypes that ends in a specification and a firmer price. That is often money well spent, and the document belongs to you even if you take it to someone else.

• the business problem and who uses the system
• existing systems, data sources and any integrations
• platforms: web, iOS, Android, desktop or back end only
• where it will be hosted and who pays for hosting
• security and personal data involved
• accessibility requirements for staff or public users
• deadlines that are real, such as a contract start or a system being switched off

A fixed price suits a well-defined piece of work. The developer carries the risk of underestimating, so expect a contingency in the price and a strict change-control process: anything not in the specification becomes a paid change request. Make sure the contract states the acceptance criteria, meaning the tests that decide whether a feature is finished.

Time and materials means you pay for the hours or days worked, usually in sprints of a few weeks. It fits projects where you expect to learn as you go, but the risk of overrun sits with you. Ask for a day rate per role, a regular report of time spent against the backlog, and the right to stop after any sprint with everything built so far handed over.

Many projects combine the two: a fixed-price discovery phase, then time and materials with a budget cap and a review point before the cap is reached. If you engage individual contractors through their own limited companies rather than through a firm, the off-payroll working rules (IR35) may make your business responsible for deciding their employment status, depending on its size. HMRC's guidance explains when that applies.

Paying for software does not by itself make you the owner of the copyright in it. Under the Copyright, Designs and Patents Act 1988 the author is the first owner, and when an outside company writes the code, that company is the author, not you. An assignment of copyright only takes effect if it is in writing and signed by the party giving up the rights. Without such a clause you may have only an implied licence to use the software, which can be a problem when you want to change supplier or sell the business.

Read the intellectual property clause before signing. Common arrangements are a full assignment of everything written for you, or ownership staying with the developer while you get a perpetual licence, often because the developer reuses its own framework across clients. Either can be reasonable, as long as you know which you are getting.

Two practical safeguards help whatever the ownership model. Have the code kept in a repository in your organisation's own account, with the developer given access, so you are never locked out. And if you are licensing a product that your business depends on, ask about a source code escrow agreement: an independent escrow agent holds a current copy of the source code and releases it to you if the developer stops trading or stops supporting the product. Also ask for a list of the open-source components used and their licence terms, since some licences impose conditions on how you distribute the software.

Source: legislation.gov.uk

If the software handles personal data about customers, staff or patients, your business is normally the controller under UK GDPR and the developer or host is a processor. The law requires a written contract with a processor that covers, among other things, confidentiality, security, the use of sub-processors and what happens to the data at the end. The ICO publishes guidance on what that contract must contain.

For high-risk processing, such as profiling, large volumes of sensitive data or automated decisions about people, you may need a data protection impact assessment before the system goes live. This comes up often with AI features. Ask the developer which third-party AI services the system would send data to, where those services process it, and whether your data is used to train their models.

Security should be part of the specification rather than an afterthought: authentication, role-based access, logging, encryption, and a security test before launch. For a baseline on the developer's own house, ask whether it holds Cyber Essentials, the government-backed scheme run by the NCSC with IASME. Some public sector contracts require it from suppliers.

Software does not stay finished. Operating systems, browsers, app store rules and third-party libraries all change, and security patches arrive constantly. Agree before launch who keeps dependencies up to date, how quickly faults are fixed, and what that costs each month. A support agreement should define response and fix times by severity, the hours covered, and how hosting, backups and monitoring are handled.

Insist on handover material that another developer could work from: documentation, deployment instructions, credentials held by you, and automated tests. It is the best protection against being tied to one supplier for years.

You describe the project once, with your company size, the platforms, whether a specification exists and your timescale. We confirm your phone number by text code and your email by link, then show the request without your name or contact details to software firms in your area. One company can buy it. Once bought, it disappears from our marketplace, and before the buyer sees your details we email you the company's name, address and phone number.

The service is free for you. There is no promise that a developer takes on every request, and unsold requests are withdrawn after 21 days. Offrano confirms that buyers are registered businesses, but it does not assess their code or their project record, so ask for references and examples of similar work. The contract for the project is between you and the developer.