# 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. Canonical: https://erdibuilds.app/help/fix-bugs Last updated: 2026-11-06 (November 6, 2026) ## 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 place where the code is stored), 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. **Example plan to fix bugs** | | 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 | 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 (Small programs that check the product still works after every change) 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](https://erdibuilds.app/help/rescue-project). Not sure the issue is a bug at all? An [advice and code review](https://erdibuilds.app/help/advice-review) can find out first. For apps made with a visual builder, see [fixing a Bubble app](https://erdibuilds.app/help/fix-my-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. ### Can 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. ### Is 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. ### What 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. ### Does 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. ## Related - [Rescue a Stuck App or Software Project](https://erdibuilds.app/help/rescue-project): Your 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 Review](https://erdibuilds.app/help/advice-review): A 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 App](https://erdibuilds.app/help/fix-my-bubble-app): Your 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 developer](https://erdibuilds.app/build/web-app): How 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 developer](https://erdibuilds.app/build/mobile-app): Plan 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 Safely](https://erdibuilds.app/guides/how-to-hire-a-developer-safely): Hire 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.