The Two Questions Founders Feel Awkward Asking
Will you take my idea and build it yourself, and at the end of this, do I actually own the app? Both are reasonable questions, both get asked less often than they should, and both are answered here without hedging.
“Will you take my idea?”
No, and there is a signed document you can hold us to. Beyond the legal answer there is a commercial one that is worth more: we are a development studio, not a product company. We do not operate apps, we do not have a portfolio of our own products competing for attention, and we have no route to market for your idea even if we wanted one. Building and running a consumer app is a multi-year commitment to marketing, support and funding that has nothing to do with what we are good at.
The blunter version: ideas are the cheap part. The expensive parts are execution, distribution and the years of maintenance afterwards. A studio that stole client concepts would also have to abandon the paying work that funds it, and word travels fast enough in this business that it would be the last idea we ever got shown.
“Do I own the app?”
Yes, and the useful part of that answer is the detail of when and how. Full intellectual property in everything we build for you transfers on final payment. The repository is in your organisation from the first commit rather than being handed over at the end. The Apple and Google developer accounts are created in your company name in week one. The signing keys are yours and you hold your own copy.
“You own the code” on its own is close to meaningless. Code you cannot build, cannot sign and cannot publish because the accounts belong to someone else is not ownership — it is a folder of text files. Ownership of a mobile app is four things: the code, the store accounts, the signing keys and the credentials. All four are covered below.
Getting a Mutual NDA Signed, Usually Inside a Day
There is no gatekeeping here and no requirement to talk to a salesperson first. Four ways to get one in place.
Tick the Box on the Contact Form
The enquiry form has an NDA checkbox. Tick it, keep the message itself to a one-line description, and we will send a mutual NDA back before asking you anything specific about the idea.
Or Send Us Yours
If your lawyer has a document you already use, send it. We would rather sign a form you are comfortable with than argue over clauses. We read it properly and come back with any genuine issue, which in practice is rare.
It Binds Both Directions
Ours is mutual, not one-way. You will see our approach, our estimates and our technical opinions during a scoping conversation, and those are ours to protect in the same way your idea is yours.
Assume the First Email Is Not Covered
Until it is signed, nothing is protected by it. Keep that first message general — the category of app, roughly who it is for, the rough budget. That is always enough for us to say whether it is worth a call.
What the Document Actually Stops, and What It Does Not
An NDA is worth having and it is worth understanding. A lot of founders believe it does more than it does, and that belief is what makes them careless about the things that matter more.
What It Does Protect
Real, Enforceable Cover
- Your concept, product plans, roadmap and unreleased features
- Designs, screens, wireframes and prototypes you share with us
- Business information: pricing models, financials, growth plans, funding conversations
- Customer lists, partner names and commercial relationships
- Technical material: existing code, architecture, credentials and data
- A contractual right to act if any of that is disclosed or misused
What It Does Not Protect
Where People Overestimate It
- An idea in the abstract. Concepts are not property; specific expressions of them are.
- Anything already public, or already known to us before you said it
- Somebody else independently building something similar without ever meeting you
- Your app being copied after launch, when it is visible in a public store to anyone
- A patent, a trademark or a registered design — an NDA is none of those
- A disclosure the law requires. That exception exists in every NDA, including yours.
The practical conclusion: sign the NDA, then stop worrying about it and spend the energy on getting to the store first with something people keep. In mobile, the defensible position is a live listing with real reviews, an install base and a habit — not a document in a drawer.
When the Rights Move, and the Three Things That Stay Behind
Everything Built for You Transfers on Final Payment
Source code for both platforms, the designs and prototypes, exported assets, build configuration, backend services we wrote for the app, and the handover documentation. The transfer is written into the engagement agreement and it is outright, not a licence. Until that payment lands we hold the rights, because it is the only security a supplier has — but in day-to-day terms it is a formality, since the repository has been sitting in your organisation the whole time.
Open-Source Components Keep Their Own Licences
Every real mobile app stands on libraries written by other people: networking, image loading, charts, analytics clients, database layers. Those belong to their authors and reach you under their own terms, which is normal and is how the entire industry works. We keep the list, and we will give it to you with each component’s licence whenever you ask — usually because an acquirer or an enterprise customer has started asking.
Our Pre-Existing Know-How Stays Ours
Generic scaffolding, internal build and release tooling, and the general skill we brought with us are not sold with your project. Where any of it is embedded in your app you get a perpetual, irrevocable licence to keep using it for the life of the app, so nothing you rely on can be withdrawn. What you do not get is exclusivity over general technique — and no client of any studio ever does.
Everything You Supplied Was Always Yours
Your brand, your content, your data, your existing designs and any code you brought with you never become ours at any point, including during the build. We also will not use your production data as test data, and we will not quietly retain a copy of your database after the engagement ends.
A Note on Licence Types, Because It Matters in an App Binary
Permissive licences such as MIT, Apache 2.0 and BSD ask for little more than an attribution notice, and those are what we use by default. Strong copyleft licences can carry obligations that are awkward in software distributed through an app store, so we do not pull one into a client build unless you have asked for it and understand what it implies. Anything with a commercial licence is bought in your name, so the entitlement stays with you rather than with us.
Your App Lives Inside Two Accounts. They Must Be Yours.
An Apple Developer account and a Google Play developer account are not administrative details. They are where your listing, your reviews, your ratings history, your install base, your subscriptions and your payout details live. Whoever is the legal holder of those accounts controls whether your app can be updated, renamed, repriced or taken down — and that is true no matter what your contract says about who owns the code.
So we create both in your company name, with your organisation as the account holder, from the first week of the project. Apple and Google bill you directly. Two-factor authentication sits on a device you control. We are added as a member with the access the work needs, and you can see exactly what that access is and remove it in one click.
It costs us nothing to do it this way, and it removes the single most common trap we see clients walk into. We will not hold your store accounts on your behalf even if you ask us to.
What Goes Wrong When the Agency Owns the Accounts
None of these are hypothetical scenarios invented for a website. They are the reasons people arrive at our contact form.
How a Transfer Works, and When It Cannot Be Done
This is fixable more often than people assume, and it is the first thing we deal with when we take over an app from another team. Do not start it in the same week you are trying to ship something.
1. Find Out Who the Account Holder Actually Is
Not who has been doing the uploading — who is named as the legal account holder, and under which organisation name and identifier. Both consoles show this. Surprisingly often the answer is a freelancer’s personal account rather than the agency’s company, which changes what is possible.
2. Set Up Your Own Organisation Account
An app can only be transferred into an account that already exists and meets the platform’s requirements, so this comes first. It needs your legal entity details and, for an organisation account, the identity verification each platform requires — which is the step that takes real calendar time, so start it early.
3. Clear the Platform’s Transfer Conditions
Both stores allow an app to be transferred between accounts, and both attach conditions — things like the app having no outstanding agreements pending, no in-flight submission, and certain entitlements or capabilities not being in use. We check the current conditions against your specific app before promising anyone a date.
4. Initiate From the Old Side, Accept on the New
Transfers are always started by the current holder. That is the moment when you find out whether your previous developer is going to cooperate, which is why it is worth asking politely and early rather than after a dispute. Once accepted, the listing moves with its reviews, ratings and install base intact.
5. Move the Keys, Credentials and Services Too
A transfer moves the listing, not everything around it. Signing assets, push credentials, analytics and crash reporting projects, backend hosting, the repository and every third-party account have to be dealt with separately. We work from a written checklist so nothing is discovered six months later.
When It Cannot Be Done
If the previous holder refuses, has disappeared, or the company has been dissolved with nobody able to sign in, the app cannot be transferred. The fallback is publishing under your own account as a new listing — you keep the code and the users can migrate, but the reviews, the ratings and the install history do not come with you. That loss is exactly why the accounts should have been in your name from the beginning.
Lose the Android Signing Key and the App Cannot Be Updated
Of everything on this page, this is the one with the harshest failure mode, and it is the one nobody thinks about until it has already happened.
Why Android Is the Unforgiving One
Android verifies that an update was signed by the same key as the version already installed. If that key is lost and no recovery route was set up, there is no appeal, no support ticket and no workaround: the existing listing can never receive another update. The only remaining option is a brand-new listing with a new package identifier, which means your installs, reviews, ratings and any ranking history start again from nothing, and your existing users have to be persuaded to move by hand.
Google’s app signing service materially reduces this risk by holding the app signing key for you and letting you rotate an upload key, and we enrol client apps in it as a matter of course. That is a safety net, not a reason to be careless about where your own copies live.
How We Handle Keys and Certificates
- Keys and signing assets are generated under your accounts and belong to you
- You hold your own copy in your own password manager or vault, not only ours
- Nothing is ever emailed or pasted into a chat — secrets move through a proper secure channel
- Keystores and passwords are never committed to the repository
- Every certificate, profile and key is on a dated inventory with its expiry
- On iOS, certificates and provisioning profiles are reissuable from your own account — annoying to lose, not fatal
- The handover document says where each key lives and who can reach it
What Happens to the Credentials When We Leave
Because you hold the accounts throughout, leaving is a tidy-up rather than a negotiation. There is nothing for us to release, so there is nothing to withhold.
A Written Handover Note
The state of the app, how to build and release it, which certificates and keys exist and when each one expires, every third-party service it depends on and what that service costs. Produced whether the engagement ended well or badly, and not charged for.
Our Access Removed, Not Yours
You remove our membership from the developer consoles, the repository and any shared service, at a time you choose and once you have confirmed you can build and release without us. Nothing is switched off from our side before you are ready.
Your Copies Deleted
Working copies of your keystores, credentials and any data we held are destroyed once the handover is confirmed. Confidentiality obligations do not end with the engagement — they continue under the NDA and the terms of service after we have stopped working together.
Get the NDA Signed, Then Tell Us the Whole Idea
There is an NDA checkbox on the contact form. Tick it, keep the message to one line, and we will send a mutual NDA back before asking a single question about what you are building.