Guide
How to scope a front-end bug fix
Most bug fix requests go wrong at the scoping stage — not the code. A clear, bounded description gets you a fast quote and a fast fix. Here's what to send and what to leave out.
Define one problem, not a wishlist
A fix is a single, scoped issue: a broken form, a hydration error, a layout glitch on iOS Safari, a checkout step that fails. If your list has five unrelated items, that's a support retainer or a project — not one fix. Pick the highest-impact item first.
What to include in your brief
Send: the URL where it breaks, steps to reproduce, expected vs actual behaviour, browser/device if relevant, error messages from the console, and when it started (after a deploy? an app install?). A 2-minute Loom is worth more than a page of vague description. Repo or staging access saves a round-trip.
Fix vs rebuild — how to tell
If the bug is localised (one component, one page, one integration), it's almost certainly a fix. If the codebase has no tests, no types, and the "bug" is really "nothing works", you need a rebuild conversation. A good developer will tell you which camp you're in before taking your money.
Size indicators
Small fix (same-day): CSS regression, single JS error with a clear stack trace, broken API call with known endpoint. Medium fix (1–2 days): hydration issues, app script conflicts, auth flow problems. Large (custom project): full migrations, architectural rewrites, multi-system integrations.
Key takeaways
- →One scoped problem per fix request
- →Include URL, repro steps, and console errors
- →A short Loom beats a long email
- →If it's architectural, ask for a project quote instead
Ready to ship a fix?
Flat pricing from £599. Same-day turnaround on scoped issues.
Submit your fix →