Many founders discover a painful fact only when a relationship ends: the developer has the keys. The app lives in their account, the domain is registered under their name, the only person who understands the logic has moved on, and nothing is written down.

It does not have to be this way. A handful of simple arrangements, made at the start of a project, mean you can change developers, bring work in-house or simply sleep better. This guide lists them.

The five things you must own

The documentation you should receive

• The PRD, showing what was agreed and why.
• A data model description, listing data types, fields and relationships.
• A list of key workflows, in plain language.
• A list of integrations, what each does and where its keys live.
• A list of plugins and why each is used.
• Short walkthrough recordings of how the main parts work.
• A launch and rollback note, explaining how changes go from test to live.

This is not bureaucracy. It is what lets a new developer become productive in days rather than weeks, and it saves you money every time someone new looks at the app.

Contract points to agree up front

• You own the work product and all related accounts.
• Documentation is a deliverable, not an optional extra.
• What happens at the end of the engagement, including handover of access.
• Notice periods and how support continues or stops.
• Confidentiality of your data and your customers’ data.

Warning signs of dependency

• You cannot log in to your own app.
• Only one person knows how a key feature works.
• Invoices or accounts are in someone else’s name.
• Questions about structure are answered vaguely or defensively.
• There is no separate test version.

How to reduce dependency in an existing project

1. Ask for access to the app, domain and services in your name.
2. Request the documentation list above.
3. Schedule a recorded walkthrough with the developer.
4. Ask a second developer for a brief review to confirm it is understandable.
5. Put the arrangements in writing.

A fair partner will be comfortable with all of this. Reluctance is itself useful information. See our guide to choosing a development partner for more questions to ask.

How we work

Projects at Simple Automation Solutions begin with a written PRD from a Discovery Sprint, so scope and decisions are on paper from the first day. Documentation and ownership are things we recommend settling before any build begins, and support afterwards is billed from $35 per hour with no retainers and no minimums. See our process from discovery to launch.

Frequently asked questions

Is it normal for a developer to host the app in their own account?

It happens, but it creates dependency. Putting it in your account is the safer arrangement.

Does documentation add cost?

A little time, yes, but it is far cheaper than paying a new developer to reverse-engineer an undocumented app.

What if I am already stuck?

Start by securing access to the domain and services, then ask for the documentation. If that fails, an audit can map what exists.

Should I worry about lock-in to Bubble itself?

It is worth understanding. A Bubble app runs on Bubble’s platform and cannot be exported as code to run elsewhere, although your data can be exported. Whether that trade-off suits you is a real decision. See our comparison of Bubble.io and custom code for the details.