Will You Steal My Idea, and Do I Own the Code?

How to get an NDA in place

It takes one email and usually less than a day.

• Tick the box on the contact form. The contact form has an NDA checkbox. Tick it, keep the message to a one-line description of the area you are working in, and we will send a mutual NDA back before asking you anything specific.
• Or send us yours. If your lawyer has a document you prefer, send it. We read it properly rather than signing blind, and if something in it is genuinely unworkable we will say which clause and why instead of going quiet.
• Mutual, not one-way. Ours protects both sides. You will see our approach, our estimates and our technical assessments during scoping, and those are confidential to us in the same way your idea is confidential to you.
• Before you send the first email. Assume an unsolicited email is not yet covered. A single sentence — “a scheduling app for independent clinics” — is always enough to start the conversation, and you can hold the detail until the document is signed.

We will not make you chase this, and we will not treat asking for one as a sign of inexperience. The founders who ask are usually the ones who have been burned before.

What an NDA protects — and what it honestly does not

Most explanations of NDAs stop at the reassuring part. Here is the rest, because knowing it will make you a better client for whoever you end up hiring.

What it does protect. The specific things you disclose: your market research, your pricing model, your user data and metrics, your customer and supplier relationships, your technical designs and architecture, your business plan, your financials, and the specific way you intend to solve the problem. If we disclosed any of that or used it for our own benefit, you would have a contractual claim with real teeth.

What it does not protect. An idea, on its own, is not property and cannot be made into property by a contract. “An app for booking dog walkers” is not protectable, and nor is any similarly general concept — typically because several other people are already working on something close to it. An NDA also cannot stop information that is already public, that the other side already knew, or that they later develop independently without reference to yours. It cannot stop a court order. And practically, enforcing one means proving disclosure and proving loss, which is expensive and slow.

Where the value actually is. Execution. The specific implementation, the product decisions you make after watching real users, the data you accumulate, the distribution you build, the relationships you own and the speed at which you improve. Those are protectable by copyright in the code and by simply being ahead. This is why we push clients towards shipping a narrow first version quickly rather than perfecting a specification in private: six months of secrecy protects an idea considerably less well than three months of being live does.

Intellectual property: when it transfers, and what does not

On final payment, everything we built for you is yours. That covers source code, designs, prototypes, database schemas, infrastructure configuration and documentation created specifically for your engagement. It is an assignment, not a licence: you can modify it, sell it, open-source it, hand it to a different developer or shelve it, with no further reference to us. Until final payment clears we retain those rights and you hold a licence to use the deliverables for evaluation and testing, which is what makes milestone billing workable for both sides.

Two things do not transfer, and any developer telling you otherwise is either confused or misrepresenting how software is built:

• Our pre-existing know-how and internal tooling. The general skills, methods, boilerplate and internal utilities we had before your project stay ours, because they are in every project we do. Where any of it is embedded in your deliverables, you receive a perpetual, worldwide, royalty-free licence to use, modify and distribute it as part of your product — so it never limits what you can do with what you paid for. We gain no rights over your product, your data or your business logic.
• Third-party and open-source components. Covered in full in the next section.

We do not use client work in a portfolio, a case study or a pitch without your written consent, and never in a way that reveals anything confidential.

Open-source components and what their licences mean for you

Every non-trivial application is built partly from open-source libraries. Writing an encryption routine, an image loader or a date parser from scratch would cost you money for a worse result, so nobody does it. What matters is which licences those components carry, because a licence attaches to your product, not to us.

• Permissive licences such as MIT, Apache 2.0 and BSD are what we use by default. They let you use, modify and distribute the component commercially, including in closed-source software. The practical obligation is attribution — keeping the notices, and on mobile usually listing them on a licences screen, which we build in.
• Copyleft licences such as GPL and AGPL can require that software distributed with the component is itself released under the same terms. For most commercial products that is unacceptable, so we avoid them in client work. If one is genuinely the only sensible option for a specific problem, we raise it with you and explain the consequence before it goes anywhere near the codebase.
• Commercial licences — a paid SDK, a charting library, a premium font — are registered in your name and paid by you, so the licence is yours and survives the end of our engagement.

The handover documentation lists the third-party components used and their licences, so if you are ever asked during due diligence, an acquisition or an enterprise security review, the answer already exists in writing rather than needing to be reconstructed.

Your accounts, from day one

This is the part that quietly matters most, and it is where a lot of founders discover a problem far too late. Everything is registered to you at the start of the engagement:

• The source repository is created under your organisation, with us added as collaborators. Every commit from the first one lands in your account, not in ours.
• Cloud and infrastructure accounts — compute, database, storage, error monitoring, analytics — are opened under your company identity with billing on your card, and we work inside them with our own credentials.
• Apple and Google developer accounts are registered to your company. Apple charges an annual Developer Program fee and requires business verification that can take time, so we start it early; we are then added as team members with the access we need to build and submit.
• Domains, SSL and third-party service accounts are likewise yours.

If your accounts are currently registered to a previous developer, recovering them is one of the first things we deal with, and we will tell you honestly if any of them cannot be recovered rather than discovering it at launch.

If the engagement ends

Because nothing was ever held in our name, there is no handover negotiation and no leverage for us to use.

• We remove our own access from your repositories, cloud projects and store accounts.
• Any credentials we hold on your behalf are transferred by a secure method and then deleted from our side.
• You receive the architecture, deployment and operational documentation produced to that point, and we will answer reasonable handover questions from whoever takes over.
• Intellectual property in the work produced up to that point transfers once the amounts properly due for it are settled.
• Your confidential material is returned or destroyed on request, and the confidentiality obligations continue after the engagement ends — an NDA does not expire the day the invoice is paid.

We have no clause designed to make leaving expensive. A client who stays because leaving is painful is not a client relationship worth having.

How we handle your material while we hold it

• Need-to-know access. Only the people working on your project have access to your repositories, accounts and documents.
• Bound subcontractors. Where a specialist is brought in, they are under the same confidentiality obligations we are, and we remain responsible for their work.
• Credentials are never emailed in the clear. They go through a secure channel, and we ask for scoped access rather than an administrator password wherever a platform supports it.
• Production data stays in production. We work against anonymised or synthetic test data rather than copying live customer records into a development environment.
• Separation between clients. Your material is not reused, shown or referenced anywhere else, and no part of your product is offered to another client.
• Cleanup on exit. When an engagement ends, our local copies and any credentials we held are removed.

None of this is unusual for a competent development firm. It is worth asking any developer you are considering whether they actually do it, because a surprising number do not.

What is written down where

The NDA covers confidentiality before and during the engagement. The signed engagement agreement covers IP assignment, account ownership, payment milestones and exit, and it prevails over anything general if the two ever conflict. Our standard commercial position on all of it is set out in the Terms of Service, and how this website itself handles what you submit is in the Privacy Policy.

This page explains our position in plain language. It is not legal advice, and for anything that matters to your business you should have your own lawyer read the actual documents.