Your app already has users, saved data and behaviour people rely on. When you bring in a developer to fix a bug or add a feature, those existing commitments are part of the work.
I start by understanding the current system and the change you need. You can help with a clear example, a map of the services involved and a list of what must keep working. This guide covers what to prepare and what to expect from the review.
Describe the change in terms of user behaviour
“The app is slow” is a useful starting point. “On a phone, opening the orders page takes several seconds when a customer has a long order history” gives us something to investigate. For a new feature, describe what the user should be able to do and what they can do today.
For a bug, send the steps that lead to it, what you expected, and what happened instead. Include the device or browser if it seems relevant. A short screen recording can help; remove customer information and private messages before sharing it.
Tell me how often the problem happens, who it affects, and whether there is a workaround. A checkout failure affecting active customers needs a different response from a visual issue on an internal page.
Here is a fictional bug report with enough detail to begin investigating:
On the orders page, choose “Last 30 days”, then open the second page of results. The date filter resets and older orders appear.
Expected: the date filter stays selected while moving through the results.
This happens every time in Chrome on my laptop. Our staff can work around it by searching for an order number, but reviewing recent orders takes longer.
Give me a map of the current system
You do not need to know every technical detail. Start with the pieces you know, and tell me who can answer questions about the rest.
Where the code is stored, who owns the repository and which version is currently live.
Where the application runs and how changes are currently deployed.
The database, file storage and external services it uses.
Any setup instructions, automated checks or existing documentation.
Known problems, unfinished work and previous attempts to fix this issue.
Whether the previous developer or another team is available for questions.
If you have a staging environment (a separate copy used to try changes before they reach customers), tell me how to access it. If you do not have one, that is something to plan for when the work needs it.
Mention what the current system must preserve: existing links, saved data, user permissions, integrations or mobile app versions still on customers’ phones. These are easy to overlook when discussing a single new screen.
Share access through invitations
Keep ownership of your repository, hosting, domain and payment accounts. Invite a developer using each service’s access controls, with the permissions needed for the work. Where the provider supports it, a review can begin with read access and a test environment.
Do not paste passwords, production API keys, customer exports or a complete environment file into a project brief. We can agree on how to provide required secrets separately. Test accounts and sample data are usually more useful for reproducing a problem than unrestricted access to live customer data.
Understand the review before the estimate
For an existing codebase, I need to check how it runs, trace the relevant behaviour and understand the parts a change could affect. A seemingly isolated feature may touch permissions, billing or a database migration.
We agree on the scope and terms of the review before it begins. Its written result should explain:
What was inspected, what could be reproduced and what access or information is still missing.
The recommended change, including any alternatives worth considering.
Which existing features or data could be affected.
How the work will be checked, released and recovered if there is a problem.
What can be estimated now and what needs further investigation.
Ask for a reason before a rewrite
Older code can still do its job well. A different framework or a new developer’s preferences are weak reasons to replace a working system. Often the right change is a focused fix, a missing test, or an upgrade made in stages.
Sometimes a replacement is justified. Ask which requirements the current system cannot reasonably meet, which parts could be retained, and how the transition would work. The comparison needs to include moving data and preserving existing behaviour, as well as writing the replacement.
Agree on how changes reach users
Before deployment, we should know how the change will be tested, who will review it, and what happens if something goes wrong. For a live product, I want an agreed release plan and a way to recover. Reverting code alone may not reverse a data change, so database migrations need their own plan.
For the date-filter example, we would check that the selection survives pagination and that other filters still behave correctly. You should be able to review that behaviour in a preview before the fix reaches the live site.
At handover, you should be able to see what changed, how it was checked and any follow-up work. New setup steps, configuration changes and known limitations belong in the documentation.
What to send me first
Here is the product and who uses it: …
Here is the feature or problem, with an example: …
Here is what must keep working: …
Here is what I know about the code, hosting and current developer: …
Here is the impact, priority and any deadline: …
Start with that context through the contact form. You do not need to clean up the entire project or write technical documentation before asking for help.