Bug Fixing and Emergency Support
Triage and fix production issues that are actively costing you orders, customers or working time, on an application GullySystem built or one you brought us that someone else did.
What Counts as an Emergency
Not every bug is an emergency. A typo in a label can wait; a checkout that fails, a login that locks customers out, or a report that miscalculates payments cannot. Emergency support is reserved for issues that are actively affecting revenue, customers or compliance right now.
How We Triage a Reported Bug
Reproduce It Reliably
Before anything is changed, we confirm exactly what triggers the issue, since a fix built on a guess usually creates a second bug.
Isolate the Affected Area
Narrowing the problem to the specific module, integration or data condition responsible, rather than the whole application.
Assess the Business Impact
Deciding how many users or transactions are affected, and whether a temporary workaround is needed while the real fix is built.
Fix and Verify
Applying the fix on a copy of the application first where possible, then confirming it against the original steps that caused the failure.
Root Cause vs Quick Patch
A quick patch stops the immediate pain; it does not always stop the bug from returning. Where time allows, we trace the issue to its actual cause. Where the business cannot wait, we apply a safe temporary fix and come back to the underlying cause once the pressure is off, and we tell you which one we did.
Keeping the Business Running While We Fix It
- A manual workaround for staff while the underlying fix is built
- A status update to your team so support staff know what to tell customers
- A note on which data, if any, needs to be corrected after the fix goes live
Frequently asked questions
What makes something an emergency rather than routine maintenance?
Whether it is actively stopping customers or staff from completing something right now, such as a broken checkout, a failed login or an incorrect financial calculation, rather than a cosmetic issue that can be scheduled into regular maintenance.
What decides how quickly a bug gets attention?
How many people or transactions it affects, whether a workaround exists, and whether revenue or compliance is at risk. A checkout failure is worked ahead of a display glitch on an internal report.
Do you need production access to fix a live bug?
Yes, at minimum enough access to reproduce and diagnose the issue. Where possible we work on a copy of the application first and only touch production to release the verified fix.
What if the bug is in code you did not write?
That is a common starting point. We read the relevant part of the codebase, confirm what it is meant to do, and fix the specific issue without needing to take over the entire application first.
What decides the cost of emergency fixes?
How reproducible the bug is, how much of the codebase is involved, and whether the fix touches one function or several connected ones.
Can this run without a maintenance contract in place?
Yes. Emergency support can be engaged as a standalone fix. Many businesses move to an ongoing maintenance arrangement afterward once they see how often this kind of issue recurs.
What do you need from us when reporting a bug?
The exact steps that trigger it, roughly when it started, and how many users or orders it appears to affect. The more specific the report, the faster it can be reproduced.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private