The short answer: the more you organise up front, the faster and more accurate the quote
When an engineer is going to review or take over an app or internal business system you built with AI (Claude Code, Cursor, Lovable, v0, Bolt and the like), what you need to prepare comes down to three things:
- Where everything lives — the code, external services, environment variable names, the live URL, production data and accounts
- What counts as correct behaviour — bullet points are enough, and only the buyer can write them
- A plan for sharing it safely — an NDA (non-disclosure agreement), the least access people need, and keys starting from their names rather than their values
What sets the cost is not the amount of code but how much is unknown. The more of the three above you have ready, the less an engineer has to allow for "I don't know what I'll find."
This article is for people who decide on the work without reading the code themselves: sole proprietors, owners and executives of small and mid-sized businesses, and whoever is responsible for development at a company with no CTO (no one in charge of technology). It works just as well for an app you built on your own.
You can start the conversation without having all of this ready. If you write "don't know" against an item, that itself is input to the quote. If you'd like to find out first how much you already have a handle on, try the free self-check (20 questions, no signup). The questions you get stuck on become your list of unknowns.
Already live, or handling money or personal data?
An engineer reads your AI-built app and tells you what is actually dangerous
1. What sets the cost is not the amount of code but how much is unknown
The cost of a handover or an investigation is not set by lines of code. In my experience, a quote works out roughly like this:
amount of work + amount of unknown × risk
The second term is the one that matters. "This probably takes a day, but I don't know what I'll hit, so I'll allow three." That isn't padding — it is an honest quote for something unknown.
Which means that reducing the unknowns brings the quote down and makes it less volatile. And most of that reduction can only be done by the people who use the app and had the AI build it.
2. What to provide: the five basics
(1) Where the code lives
A GitHub repository (the place the code is stored) URL, or an invitation.
- If everything lives inside Lovable or Bolt: both have an official feature that syncs with GitHub. Use it to get the code into a repository first. Lovable's integration lets you choose whether the repository is created under a personal account or an organization (a shared organization account).
- If the system runs part of your business: put the repository in your company's organization rather than an individual's account. It makes managing access much easier later (section 4 explains why).
- If you don't know where it is: say so plainly. That becomes the first thing to check.
(2) A list of the external services in use
Hosting (the server it is published from), database, login, payments, email, AI APIs (the interfaces your app uses to call an outside AI service) and so on. For a business system, also note whose name each one is contracted under (section 3 explains why).
example (fictional):
- hosting: Vercel (contract: company / admin: someone in the admin team)
- database & login: Supabase (contract: the builder's personal account)
- payments: Stripe
- email: Resend
- AI: Anthropic Claude API
If you don't know, an AI can draft it:
List every external service this project uses, with a one-line explanation of
what each is used for. Judge from package.json, the environment variable names,
and the URLs called in the code. Do not write out any environment variable values.
(3) A list of environment variable NAMES (not the values)
Environment variables are settings kept outside the code, such as API keys and passwords. You hand over only the names, never the values.
example:
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
SUPABASE_SERVICE_ROLE_KEY
STRIPE_SECRET_KEY
STRIPE_WEBHOOK_SECRET
RESEND_API_KEY
From the names alone, an engineer can work out what is required and where risk is likely (what they look for is in section 10, "Notes for engineers"). The values only become necessary once someone actually runs it locally.
(4) The live URL
The production URL. If it isn't running, the URL where it used to run is still useful. If the app requires a login, preparing one test account moves things along faster.
(5) What counts as correct behaviour ← the most valuable
An engineer reading the code can tell what it does. They cannot tell what it should do. Only the people using it know that.
Bullet points are enough:
example (a fictional business app):
- a sales rep can see only their own customers; a manager can see the whole team's customers
- a quote cannot be sent to a customer until a manager approves it
- when an order is confirmed, stock is allocated automatically
- the same email address cannot register twice
- a leaver's account is disabled, but the quotes they created remain
Reading the code alone cannot tell you whether these are the specification or a bug. When someone finds that a sales rep can see other reps' customers, whether that is a defect or intended is something only the buyer can answer. Having this list removes the allowance for "it turned out the thing I fixed was intended."
3. For a system your business runs on, three more
For a system that runs internal operations, information that lives outside the code moves the quote a great deal.
(6) Who uses it, for which business process
- Who the users are (how many employees, business partners, members of the public)
- Which process, and which step of it, the system is part of (for example: of order → shipping → invoicing, the order and invoicing steps)
- What breaks if it stops, and whether there are hours when it can be stopped
The more it is wired into operations that can't stop, the more carefully the switch-over has to be planned, which changes how the work is done.
(7) Where production data lives, and whose name the accounts are in
- Where the production data is (a database, a spreadsheet, inside an external service), and whether backups exist
- In whose name, and with whose email address and payment method, each account is held: GitHub, hosting, database, domain (the "example.co.jp" part of the URL), payments and so on
- Who can log in as an administrator
As general advice, I think accounts a business depends on are best held in the company's name (a company email address and payment method), with the people doing the work given only the access they need. If they were opened under the builder's personal account, there is a risk that when that person changes role or leaves, nobody can log in or reassign access. If accounts are in a personal name, moving them into the company's name becomes the first task of the handover and goes into the quote. Why ownership should stay with the company, how to move a repository from a personal account into the company's organization, and how to hold cloud accounts are covered in the account-ownership sections of deciding between in-house and outsourcing, SaaS and building from scratch.
For reference, when I take on development work, the repository and cloud are set up in the client's name from day one, and I work with collaborator access. When the engagement ends, you simply remove that access.
(8) Existing documents
They don't need to be complete.
- Requirement notes, operating manuals, screenshots of the screens
- Quotes or proposals you got from other companies before
- Your conversation history with the AI (the instructions you built it with). It is a good clue to the intended specification. If you ever pasted a key into it, remove that part before sharing
4. What not to hand over, and how to share safely
What not to hand over
Key and password values. Not needed at the consultation or quoting stage. The names are enough.
Production data containing customers' personal information. For checking behaviour, first consider whether fictional test data would do.
Under Japan's Act on the Protection of Personal Information, when the handling of personal data is outsourced within the scope needed to achieve the purpose of use and the data is provided as part of that outsourcing, the recipient is not treated as a "third party" for the purposes of the third-party provision rules (Article 27(5)(i)). The business that outsources it, however, must exercise "necessary and appropriate supervision" over the contractor so the data is kept secure (Article 25). If you do hand over production data, settle the scope, handling and deletion after the work in the contract first. If your case needs a specific judgement, check with a professional.
"The note with every password on it." It is dangerous for the person handing it over too. Only what is needed, only when it is needed.
Sharing safely: widen access stage by stage
| Stage | What to hand over | How |
|---|---|---|
| Consultation and quote | The documents from sections 2 and 3, the screens | After signing an NDA. You can start without handing over the code |
| Investigation | Viewing the repository | Invite with view-only (Read) access (when the repository is in your company's organization; a personal-account repository can't be limited to viewing) |
| Work | The key values needed, write access | Keys through a password manager's sharing feature or similar; only the access the work requires |
| End | Nothing | Remove access and reissue the keys you shared |
The principle underneath is least privilege. NIST's glossary (the US National Institute of Standards and Technology) defines it as a security principle that restricts users' access privileges "to the minimum necessary to accomplish assigned tasks."
NDA first. A non-disclosure agreement is normally signed before any code or documents are shown. I can sign an NDA before any commercial discussion, and on your own template if you prefer.
Repository access (on GitHub). This one involves a company decision, so here is a little more detail.
- Collaborators can't be given read-only access to a repository owned by a personal account. GitHub's official documentation states this. Anyone you invite can write as well as read
- For finer-grained permissions, GitHub suggests creating the repository in (or transferring it to) an organization
- In an organization you can choose from five roles: Read, Triage, Write, Maintain and Admin. A sensible default is Read (view and discuss only) for the investigation and Write once someone starts making changes. There is rarely any need to give an outsider Admin, which includes deleting the repository and managing security
- For someone who isn't a member of your organization, there is the "outside collaborator" arrangement, which gives access to specific repositories only. When the work ends, remove their access to that repository
Reissue keys when the work ends. The safe practice is to reissue any key you shared once the work is done, so the old one can no longer be used. If a key gets committed to a repository, GitHub's documentation says the first step is to revoke or rotate it — before any work to scrub it from history. If one gets pasted into a chat, I think the same applies: reissuing the key first is the safe move.
5. What drives the quote
The unknowns below move a quote more than the amount of code does. The right-hand column is what the buyer can prepare in advance.
| Factor | Why it raises the quote | What you can prepare to lower it |
|---|---|---|
| Nobody knows what correct behaviour is | The quote carries the risk that a fix turns out to change intended behaviour | A bullet list of things that must always hold (section 2, item 5) |
| Unclear whether production matches the code you have | Investigation into what is actually running has to come first | Where and how it is published; notes on anything changed directly in a dashboard |
| Only a production environment, no test environment | Every piece of work is production work and has to proceed carefully | Say so if there isn't one; building a test environment becomes the first task |
| Money or personal data is moving | The scope of what must be checked widens, and priority rises | Whether payments exist; a list of the kinds of personal data you hold |
| Unclear whose name the accounts are in, or how to log in | Work starts with recovering access or moving accounts into the right name | A list of account owners and administrators (section 3, item 7) |
| Wired into operations that can't stop | The switch-over has to be planned carefully | Users, the business flow, and hours when it can be stopped (section 3, item 6) |
| The request is "please look at everything" | The wider the scope, the more there is to investigate | What troubles you most, and your deadline, in one line |
| External services or features aren't fully known | Each one has to be investigated | The list of external services (section 2, item 2) |
6. What a specialist does first once you commission the work
This is the general sequence.
- Read without touching production — read the code and configuration with view-only access, and get a sense of the overall structure and where the risks are likely to be.
- Reproduce outside production — run the app locally or in a test environment and reproduce the problems for real, using test data.
- Order the risks by priority — for example, "fix now (money, personal data, unauthorised access)", "fix soon", and "can wait".
- Agree the scope — decide, while looking at the findings, what to fix and what not to, in what order, and whether to fix or rebuild.
The output at this stage is findings — what is dangerous, and how much — not the fixes themselves. The quote for fixing comes after the scope is settled.
The scope, deliverables, confidentiality and ownership of rights go into the contract. The difference between contract types (fixed-scope contract-for-work versus quasi-mandate) is covered in choosing a system-development contract. If you're looking for a contract template, IPA (Japan's Information-technology Promotion Agency) publishes a model contract for information systems, drafted with the aim of not tilting the advantage toward either the user company or the IT vendor.
If you ask me
The first consultation (30 minutes) and the quote are free. After hearing about your situation I give you a rough estimate, and I propose a paid requirements-definition phase only when more precision is needed. Talking it through while looking at the existing code, or a review of that code, is handled as a spot technical consultation (from ¥15,000 per hour).
If you only want to check the security state first, a security review is one option. It is not a requirement for a handover quote. What each review covers and costs is on the security review for AI-built apps page. If you want someone to carry on development after the handover, or to take on the role of technical decision-maker itself, see fractional CTO / external development lead.
7. If you're told "rebuilding would be faster"
You may hear it when you ask for advice: "honestly, rebuilding this would be faster." It is not always true.
A running system holds knowledge of how users actually use it and which features matter, plus the data already in it. Rebuilding means letting go of that knowledge, at least for a while. Before deciding, get prioritised findings and check them against the fix-or-rebuild decision table to see whether the case is "fix and keep", "partly rebuild" or "rebuild". Laying quotes for both "fix" and "rebuild" side by side makes the comparison easier.
8. Questions you'll be asked (have the answers ready)
These come up in almost every first conversation. Having answers ready moves things along in the same session.
- How many people use it right now? At zero you can take it down and fix it. For a business system, also how many employees use it daily
- Is money moving? If there are payments, priority goes up
- Are you holding personal information? Even if it's only email addresses or names, answer "yes"
- Which part of the business suffers if it stops?
- What's troubling you most? "A vague sense of unease" is a fine answer
- By when, and in what state? A deadline changes how priorities are set
- Is there an upper limit to the budget? Even just the ceiling lets someone put together what fits inside it. "I don't know yet" is a valid answer too
9. Have an AI write the handover document
Most of the documents above can be drafted by an AI.
Produce a handover document for this project, aimed at an engineer. The readers
include non-engineer executives, so add a short explanation to any technical term.
Include:
(1) What this app does (about three lines)
(2) The technologies and external services used, and what each is for
(3) The names of the environment variables and what each value is for
※ Never write the values themselves. Do not write out the contents of .env files either
(4) The main features and which screen/URL corresponds to each
(5) The database tables and what each stores
(6) How it is deployed (where and how it is published)
(7) Known defects and unfinished areas
(8) Anything you noticed while reading the code that needs care
Write it as a single Markdown file.
Then read the output yourself once and correct whatever looks wrong. That alone produces a fairly usable handover document.
But item (5) in section 2, what counts as correct behaviour, and items (6) and (7) in section 3 — who uses it for which process, and whose name the accounts are in — cannot be read from the code. Add those yourself. And before you share it, always check that no key values have slipped into the output.
10. Notes for engineers (what the receiving side checks first)
This section is for the engineer taking over. Buyers can skip it.
- Variables prefixed
NEXT_PUBLIC_: in Next.js, environment variables starting withNEXT_PUBLIC_are inlined at build time into the JavaScript sent to the browser, while those without it are only available on the server (the Node.js environment). The first thing to check in the list of names is whether anything that should be secret carries this prefix. - Supabase's
service_rolekey (the secret key in the newer scheme): Supabase's documentation says a secret key bypasses every Row Level Security (row-level access control) policy, and must never be put in a browser, a shipped application or source control.service_roleis the legacy version of it. In the example in section 2, you can confirm from the names alone thatSUPABASE_SERVICE_ROLE_KEYdoes not carryNEXT_PUBLIC_. - Build a reproduction environment first: investigate in a local reproduction environment built on a test project and test keys, not production keys. If there is only production, put building a test environment into the scope as the first task.
- Confirm where the deploy came from: check the hosting provider's deployment history for which commit (recorded change) production was built from before trusting the code you have locally.
The explanation for buyers is in NEXT_PUBLIC_ and service_role, explained.
11. Preparation checklist
Before the conversation
- Confirmed where the code lives (a GitHub URL, or established that there isn't one yet)
- Made a list of the external services in use (for a business system, including whose name each is under)
- Made a list of environment variable names (values excluded)
- Confirmed the live URL and prepared a test account
- Wrote down the things that must always hold
- Established who uses it for which process, and what breaks if it stops
- Established where production data lives, and the owner and administrators of each account
- Established the number of users, whether payments exist, and whether personal data is held
- Can state in one line what is troubling you most
- Signed an NDA (before handing over the materials from sections 2 and 3)
When commissioning the work
- Decided how repository access will be granted, and at what level (start with view-only, widen as needed)
- Decided how keys will be transferred (never pasted into email or chat)
- Decided whether to hand over production data and, if so, settled its handling and deletion in the contract
- Agreed that access will be removed and keys reissued once the work is complete
Summary
- What sets the cost is not the amount of code but how much is unknown. Organising what you hand over makes the quote faster and more accurate
- Provide the five basics (repository, external services, environment variable names, URL, correct behaviour); for a business system, add users and processes, production data and account ownership, and existing documents
- Don't hand over key values or production personal data at the consultation stage. An NDA, the least access needed, and at the end, remove access and reissue keys
- The first output after you commission the work is prioritised findings and an agreed scope, not fixes
- Decide on "rebuilding would be faster" after seeing the findings