"I want to ask an engineer, but I don't know what to ask."
This is the sentence I hear most in this field. And — you don't need to know. I'll ask the questions.
That said, preparing a few things makes the quote faster, cheaper and more accurate. That is what this article is for.
1. What sets the cost is not the amount of code
An unintuitive fact first.
The cost of a handover or an investigation is not set by lines of code. It is set by how much is unknown.
When an engineer produces a quote, the internal calculation looks like this:
amount of work + amount of unknown × risk
The second term dominates. "This probably takes a day, but I don't know what I'll hit, so I'll allow three." That is not dishonest — it is an honest quote for something unknown.
Which means: reduce the unknowns and the quote comes down. And most of that reduction is work only you can do.
2. The five things to provide
(1) Where the code lives
A GitHub repository URL, or an invitation.
If you aren't using GitHub (everything lives inside Lovable or Bolt), the first step is exporting and putting it on GitHub. That itself takes minutes using the platform's own feature.
If you don't know where it is, say so plainly. "I don't know where it lives" is not unusual in this field.
(2) A list of the external services in use
This is more valuable than it looks.
example:
- hosting: Vercel
- database & auth: Supabase
- payments: Stripe
- email: Resend
- AI: Anthropic Claude API
- analytics: Google Analytics
If you don't know, an AI can produce 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 variables, and
the URLs called in the code.
(3) A list of environment variable NAMES (not the values)
You do not hand over the values. Only the names.
example:
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
SUPABASE_SERVICE_ROLE_KEY
STRIPE_SECRET_KEY
STRIPE_WEBHOOK_SECRET
RESEND_API_KEY
From this alone an engineer can establish what is required and where risk is likely. Looking at the list above, for instance, they can confirm that SUPABASE_SERVICE_ROLE_KEY does not carry a NEXT_PUBLIC_ prefix.
Values become necessary only when someone needs to run it locally. At that point they go through a safe channel, such as a password manager's sharing feature. Avoid pasting them into email or chat.
(4) The live URL
The production URL. If it isn't running, the URL where it used to run is still useful.
Providing one test account moves things along faster still.
(5) What counts as correct behaviour ← the most valuable
This is the most important, and the one only you can write.
An engineer reading the code can determine what it does. They cannot determine what it should do. Only you know that, because you know what the app is for.
Bullet points are enough:
example:
- a user can edit only their own posts; others' posts are visible but not editable
- only paid-plan users can use the export feature
- at the end of each month, that month's summary is emailed out
- the same email address cannot register twice
- after a user leaves, their posts remain but the name shows as "deleted user"
Reading the code cannot tell you whether these are the specification or a bug. When someone finds that other people's posts are editable, whether that is a defect or intended is a question only you can answer.
Having this list alone visibly lowers the quote, because it removes the risk allowance.
3. What not to hand over
Key and password values. Not needed at the consultation stage. The names are enough.
Production data containing customers' personal information. Even where data is needed to reproduce behaviour, fictional test data is usually sufficient. Handing over production data is itself provision of personal data to a third party, which requires a contract and a process.
"The note with all the passwords on it." I have seen this. It is dangerous for the person handing it over too. Only what is needed, only when it is needed.
4. Three patterns that make quotes expensive
Knowing these in advance lets you avoid them.
Pattern 1: nobody knows what correct behaviour is
The state where item (5) above is missing.
The engineer then carries the risk that "fixing this might break something else." Every behavioural change requires checking whether it was intentional.
What to do: write down ten things that must always hold. Ten is enough.
Pattern 2: unclear whether production matches the code
"I don't know which version is deployed." "At some point I started editing things directly in the dashboard."
Investigation has to come first, because what is running may differ from what you have.
What to do: establish which code the running version came from. If you deploy from GitHub, it is usually the latest commit.
Pattern 3: real data in production with no test environment
With a single environment holding real users' data, every piece of work is production work. Nothing can be tried out.
Proceeding carefully takes time.
What to do: this one is hard to arrange yourself, so just say so. "Building a test environment" becomes the first task.
5. Is "rebuilding would be faster" true?
Sometimes you'll hear it: "honestly, rebuilding this would be faster."
It is not always true. Here is the material for deciding.
What a running app already holds
An app that is live carries value not written in the code:
- You know how users actually use it
- You know which features were needed and which weren't
- There is data in it
Rebuilding discards that knowledge too. What starts as "build the same thing again" often becomes "learn everything we already learned, again."
Where the line falls
Cheaper to fix when
- Problems are concentrated in specific areas (payments only, authorization only)
- The overall structure is reasonable and easy to extend
- You already have users and cannot take it down
Cheaper to rebuild when
- The same problem is scattered across every file
- The requirements have changed and you are building something different now
- You have no users yet, or very few
The order to work in
Before deciding on a rebuild, get a prioritised set of findings first.
Lay out "where the risk is," "how long fixing would take," and "how long rebuilding would take," and then decide. Deciding to rebuild without that material usually costs more.
6. Prepare for the questions you'll be asked
These come up in almost every first conversation. Having answers ready moves things along in the same session.
"Roughly how many people use it?" Zero, ten, or ten thousand — the available options change completely. At zero you can take it down and fix it.
"Is money moving?" Whether payments exist. If they do, priority jumps.
"Are you holding personal data?" Even just email addresses counts.
"What's troubling you most?" "A vague sense of unease" is a fine answer. If that's the honest one, say it.
"By when, and in what state?" If there is a deadline, the prioritisation changes.
"Do you have a budget in mind?" An awkward question, but even just an upper limit helps a lot. It lets someone assemble what fits inside it. "I don't know yet" is a legitimate answer too, and then the options get laid out in stages.
7. Have an AI write the handover document
Most of the above can be generated.
Produce a handover document for this project, aimed at an engineer. I am not an
engineer, 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
(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. Correct whatever looks wrong. That alone produces a fairly accurate handover document.
And item (5) from section 2 — what counts as correct behaviour — is the one an AI cannot write. Add that yourself.
8. 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
- Made a list of environment variable names (values excluded)
- Confirmed the live URL
- Wrote down ten things that must always hold
- Established current user count, whether payments exist, whether personal data is held
- Can state in one line what is troubling you most
When commissioning the work
- Discussed a non-disclosure agreement
- Decided how repository access will be granted (invitation, permission level)
- Decided how keys will be transferred (through a safe channel)
- Agreed that keys will be reissued once the work is complete
Summary
- What sets the cost is not the amount of code but how much is unknown. Organising alone lowers the quote
- Five things to provide: the repository, external services, environment variable names, the live URL, and what counts as correct behaviour
- The last one is the most valuable, and only you can write it
- Key values aren't needed at the consultation stage. The names are enough to judge from
- "Rebuilding would be faster" is not always true. Get prioritised findings first, then decide
And finally: you can start the conversation without perfect preparation. Conversations that begin from "I don't understand any of this" are entirely normal, and in that case establishing the current state is what we do together first.
If you'd rather establish it yourself first, run the free self-check — 20 questions, no signup. The result doubles as part of your handover document.
What to check on the technical side is in Before you launch the app you built with AI.