Fix bugs and problems in your product
To get bugs fixed, describe each problem with the steps that cause it, what you expected and what happened instead. A developer then reproduces it, fixes it and shows you the result in a milestone.
Last updated:
Typical situations
A bug is any behaviour that differs from what it should do. Some are small, such as a button that does nothing on one phone. Others hurt the business, such as users who cannot log in or payments that do not arrive.
- Users report crashes or error messages and you cannot see why.
- The app is slow, or gets slower the more people use it.
- Something worked last month and broke after an update.
- A feature works on your computer and fails for other people.
- Emails, notifications or payments sometimes do not go out.
What to prepare
The better the description, the faster the fix. A bug report that a stranger can follow saves hours.
A useful bug report has
- Steps
- Numbered steps that lead to the problem, starting from a fresh page or screen.
- Expected result
- What should have happened.
- Actual result
- What happened instead, with a screenshot, a screen recording or the exact error text.
- Where
- Device, browser or phone model, operating system version and app version.
- How often
- Every time, or only sometimes? Since when?
- Impact
- Who is affected, and how much does it matter to the business?
Also prepare access: the repository, the hosting account, and a test login. If your product has error logs or a tool that collects crash reports, share that too.
How it runs in milestones
Bug fixing is best done in a small number of clearly sorted batches. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks. Milestones are from 50 to 2,000 each in your project currency. Agree up front how each fix is shown to you, for example with a short video or on a test version.
| Topic | What you get | Example timing |
|---|---|---|
| Phase 1: Triage | Every problem reproduced, sorted by impact, with a short plan and the likely cause of each | One milestone, for example 1 week |
| Phase 2: Fix the urgent ones | The problems that block users or money, fixed and tested | One milestone, for example 1 to 2 weeks |
| Phase 3: Fix the rest | Smaller problems cleaned up, plus tests that catch the same bugs in the future | One milestone, for example 2 weeks |
Phase 1: Triage
- What you get
- Every problem reproduced, sorted by impact, with a short plan and the likely cause of each
- Example timing
- One milestone, for example 1 week
Phase 2: Fix the urgent ones
- What you get
- The problems that block users or money, fixed and tested
- Example timing
- One milestone, for example 1 to 2 weeks
Phase 3: Fix the rest
- What you get
- Smaller problems cleaned up, plus tests that catch the same bugs in the future
- Example timing
- One milestone, for example 2 weeks
Example only: the weeks are for illustration. Developers set the length of each milestone in their proposal, and each real milestone runs 1, 2, 3, 4, 6 or 8 weeks.
Questions to ask developers
- How will you find the cause of a bug you cannot reproduce?
- Do you add automated tests for the bugs you fix?
- Will you tell me if the real cause is bigger than the bug I reported?
- How do you make sure a fix does not break something else?
- How will I confirm that a bug is really gone?
Sometimes many bugs point to one bigger problem in how the product was built. If that happens, a developer should say so openly, and you may want to look at the rescue help type.
Not sure the issue is a bug at all? An advice and code review can find out first. For apps made with a visual builder, see fixing a Bubble app.
Frequently asked questions
What if I cannot reproduce the bug myself?
Share what you know: who reported it, when, on which device. A developer can look at logs and add monitoring so the next occurrence is captured.
Link to this answerCan bug fixing have a fixed scope?
Yes, if the list is clear. Unknown causes are harder to plan, so many projects start with a short triage milestone and plan the fixes after it.
Link to this answerIs a slow app a bug?
It can be treated like one. Ask the developer to measure first, so you can see the numbers before and after the change.
Link to this answerWhat if the fix creates a new problem?
You can request changes when a milestone is delivered, before you approve it. Agree up front that a fix includes checking nearby functions.
Link to this answerDoes the developer need to know my technology?
Yes, it saves time. Developers list technologies as Expert in or Also works with, and matching takes that into account.
Link to this answerRelated pages
- Rescue a Stuck App or Software ProjectYour developer disappeared or nobody can change the app anymore. See the first steps, a milestone plan and what to ask a rescue developer.
- Get Expert Advice or a Code ReviewA second opinion on your plan or code before you go further. Learn what a review covers, what to share and how to use the report.
- Fix a Slow or Messy Bubble AppYour Bubble app got slow or confusing to change. See what can be fixed inside Bubble, when moving to code makes sense, and how to find help.
- Build a web app with an independent developerHow to plan a browser-based web app: common technologies, an example milestone plan, what to write in the brief and how to judge a developer.
- Build a mobile app with a developerPlan an iPhone and Android app: typical technologies, an example milestone plan, what to put in the brief and how to spot a developer who fits.
- How to Hire a Developer SafelyHire a developer with confidence: pay per milestone, fund before work starts, keep payments on one platform, and get access to your code as you go.