For owners
How to build with AI and keep control of the work
Put business accounts, spending decisions, code and recovery under your control from the start. Give collaborators named access, agree handover responsibilities and build a useful first version with continuity in mind.
Control starts before the finished screen
Approval of a final interface is only one decision. Control also means knowing where the domain, billing, repository, data and deployment access live. Decide who can change each one and how that access can be recovered.
Name the rails
For each asset, record the client organisation as controller where appropriate, named users, recovery route, ongoing cost and handover owner. Keep client accounts, code repositories and billing under client control. Use individual accounts and appropriate roles. Shared passwords make it difficult to know who acted and difficult to remove access cleanly.
Agree the end of the engagement
Discuss handover while the work is small. State what documentation, repositories, data exports and operational instructions will be available, and which third-party licences or hosted services remain subject to their own terms. Ownership and licensing depend on the agreed arrangement.
Build a useful version with continuity
Test the smallest usable loop before adding integrations or complexity. Give a person ownership of exceptions and measure the loop before automating it. Chart Reporter illustrates one deliberate access decision: its terminal pushes trade data out, so the product does not need a user's broker login. That is an example of limiting required access, not a claim that every setup has the same architecture.
Dave can help define the ownership checklist, build an agreed proof of concept or coordinate specialist work.
An ownership checklist in practice
Illustrative example: a small product may have a domain, source repository, deployment account, analytics account and data store. For each, record the business owner, named collaborators, recovery method, monthly cost and person responsible for handover. The list often reveals that access was granted informally and no one has tested recovery.
Review the list at each milestone. Remove unused access, record changes and keep a short operating note with the repository. This makes continuity a routine part of delivery.
Access should match the job
A collaborator who needs to review code does not automatically need billing access. A specialist who configures a service needs a named account and a documented change. Narrow permissions make decisions easier to trace and make the eventual handover less disruptive.
- Put the business account and billing owner first.
- Give each collaborator named, role-appropriate access.
- Test recovery while the builder is still involved.
- Record the handover owner and ongoing service cost.
Common questions
Who owns the code?
That depends on the contract, contributors and third-party components. Record the arrangement clearly and check licences before making a promise.
Can my business keep operating if the builder leaves?
Plan for continuity through client-controlled accounts, named access, documentation and an explicit handover route.
Does client control mean hosting everything ourselves?
No. A hosted service can still be practical when the account, access and spending decisions are under your control and its terms are understood.
Book a conversation
Talk through what you want to move forward, what is getting in the way and the help that would make progress practical.