The Two Questions Founders Ask Last and Should Ask First

Getting an NDA in place

There is a checkbox on the contact form that says you would like an NDA before sharing details. Tick it and send a short, deliberately general description — “a booking system for a multi-site clinic” is plenty — and we will come back with a mutual agreement to sign, at no cost and with no conditions attached to it. If your solicitor has a form they prefer, send it and we will normally sign yours rather than insisting on our own paper; where we do ask for a change it is usually to make a term mutual rather than one-sided.

We ask for it to be mutual for a practical reason. During a build you will see how we estimate, how we structure work and what our internal tooling does, and a one-way agreement leaves that unprotected while asking us to protect everything of yours. Mutual is also faster to agree, because neither side is trying to work out why the other wanted asymmetry.

What confidentiality does, and where it stops

The useful distinction is between an idea and an implementation. Ideas are not property in UK law. “An app that lets tenants report maintenance issues with photographs” is a category, not an asset, and several firms are already building in it. What can be protected is specific: your data, your customer relationships, your pricing and margins, the particular workflow you have worked out, the designs, and the code that implements it. An NDA protects the specifics you disclose and gives you a contractual claim if they are misused. That claim is the real mechanism — a document that makes a breach expensive and provable.

Standard carve-outs apply and you should expect them in any NDA worth signing: information already public, information a party already held without obligation, information independently developed without reference to the disclosure, and disclosures required by law or by a court or regulator. An NDA that purports to have no exceptions is not stronger, it is simply less likely to be enforced as written.

The commercial answer sits alongside the legal one and is worth stating plainly. Our business is building software for people who pay us to build it. Competing with the clients who tell us what they want built would destroy the only asset this kind of firm has, which is being recommended by the last client to the next one.

Two points of UK law that catch people out

An assignment of copyright must be in writing and signed to be effective. Under the Copyright, Designs and Patents Act 1988 a transfer of copyright is not effective unless it is in writing and signed by or on behalf of the assignor. A verbal agreement, an email saying “of course it is yours”, or an invoice marked “full rights included” does not do the job. This is the single most common defect we see when auditing an inherited project: the client paid in full, genuinely believes they own the code, and has nothing signed that says so. Ask any supplier to point you at the clause, and read it.

Database rights are separate from copyright. UK law recognises a sui generis database right in a database where there has been substantial investment in obtaining, verifying or presenting its contents, and that right can exist independently of any copyright in the database structure. A well-drafted assignment covers it explicitly rather than leaving it to be argued about. Ours does, and if you are reviewing someone else’s contract it is worth checking that theirs does too, particularly where the value of what you are building sits in an accumulated dataset rather than in the software around it.

When intellectual property transfers, and what does not

Rights in the bespoke software, designs and documentation created specifically for you are assigned to you on receipt of payment in full for the engagement. Until then you hold a licence to evaluate and review the work but not to exploit it commercially, which is the ordinary position and the reason the assignment is tied to payment rather than to delivery.

Two things stay outside the assignment, and this is true of every software supplier whether their contract admits it or not. The first is our pre-existing materials and general know-how — internal libraries, patterns, templates and skills that existed before your project. Where any of that ends up embedded in what we deliver, you get a perpetual, irrevocable, worldwide, royalty-free licence to use, modify and sublicense it as part of the deliverable, including the right to have somebody else maintain it. In practice that licence gives you everything ownership would, because you can do what you like with the delivered software and you are not dependent on us to keep running it.

The second is third-party components, dealt with next.

Open-source components and what their licences mean for you

Modern software is assembled as much as it is written. Your build will sit on open-source frameworks, libraries and tools written by other people, and those remain theirs under their own licences. In the ordinary course we use permissive licences — MIT, BSD, Apache 2.0 — which let you use, modify and distribute the result commercially, generally requiring only that the original notices are preserved. That is normal, it is what every competent supplier does, and building from nothing instead would multiply your cost for no benefit.

The licence family worth paying attention to is copyleft: the GPL and AGPL in particular, which can oblige you to make your own source code available in certain circumstances. We will not introduce a component on one of those licences without telling you first and getting your agreement, because it is a commercial decision rather than a technical one and it is yours to make. At handover you receive a list of the components used and their licences, so a future investor, acquirer or auditor asking the question can be answered in an afternoon rather than a fortnight.

Your accounts, and what happens to credentials at the end

Everything production-related is created in your company’s name in the first week: source control, the cloud project, the database, error monitoring, analytics, the domain and the Apple and Google developer memberships. We work inside those with our own named accounts. We do not register them to ourselves and transfer them at the end if the relationship stayed friendly, because that arrangement gives a supplier leverage over a client and we would rather not have any.

Credentials you give us — access to an existing system, a payment provider, a third-party API — are held in a password manager, shared only with the people who actually need them, and used only for the engagement. On exit we revoke our own access, hand back anything we hold through a secure channel rather than by email, and tell you which keys and tokens should be rotated as a matter of routine hygiene. We would recommend rotating them whether or not you have any concern, and we will tell you exactly which ones.

What is written down, and where

The mutual NDA covers confidentiality from the first detailed conversation. The engagement letter carries the assignment of intellectual property, the licence back for pre-existing materials, the confidentiality obligations for the term, and the exit provisions. Where personal data is involved, a separate data processing agreement under Article 28 of the UK GDPR sits alongside it. Our standard position on all of this is set out in the terms of service, and how this website itself handles data is in the privacy policy.

If any of it does not survive contact with your solicitor, tell us what needs to change. That is a normal request from a company doing its job properly, and a supplier who reacts badly to it is telling you something useful.