Skip to content
  • There are no suggestions because the search field is empty.

4. Deliver: Testing Boundaries & Warranty Guidelines

We focus on critical functionality to deliver a stable, business objective aligned launch while keeping your budget firmly under control.

No software can account for every single edge case, browser combination, or usability quirk without a bottomless budget and a challenging ROI. Instead, we focus on high-impact stability, security, and core functionality to ensure your platform delivers to your business objectives and real value on day one.

Managing Your Testing Budget

Testing and bug fixing is capped at 15% to 20% of your total development budget. When working within a tighter budget or compressed timeframe, fewer variables can be tested before launch. This means some projects will naturally require more post-launch out of scope bug fixes than others.

If you put pressure on the budget, you directly impact how much testing can occur. When budget and timeline pressures occur, it is important to ruthlessly prioritise critical, high-impact functional bugs first.

If your allocated testing and fix time is exceeded and you find new critical bugs, it will be at the discretion of your PM on whether these will be resolved at no additional change, if deemed outside of the reasonable scope/budget we will raise a change request to fund additional troubleshooting.

Expect that if more bugs emerge beyond the budget, or if we need to spend time troubleshooting and supporting areas outside of our build, e.g. 3rd parties, out of scope features or inconsistent environments we will need to secure additional funding to address them.

Defining Bug and Defect Scope

We focus on corrective maintenance to ensure the final product matches the approved specifications and wireframes. These documents are the final authority and override all early-stage discussions.

To keep the project moving forward fairly and professionally, we apply strict scope limits.

  • Corrective Maintenance: We fix reproducible bugs where the build deviates from the final spec or design.

  • Excluded Maintenance: Perfective work, performance optimisations, and system hardening are excluded unless detailed in the project specification. Rare edge cases are also excluded unless explicitly stated as in scope.

  • Reproducibility: Only issues consistently replicated qualify for fixes. Items that cannot be replicated using provided instructions will be closed.

  • Edge Cases: Rare scenarios are excluded unless explicitly detailed in the specification and the project scope (approved Quote or SoW).

  • Design phase deliverables supersede prior agreements and inclusions: The approved spec, registers and designs define the final solution; original requirements serve as reference only.

  • Unauthorised Changes: Modifications to the source code, CRM, or related environemnts by the client or third parties immediately void the warranty.

  • Unauthorised Change Issues: Issues caused by updates to third-party platforms, APIs, or browsers are treated as new maintenance tasks rather than warranty defects.

  • Investigation Costs: Time spent managing issues eventually traced back to client-led changes, legacy data, changes to approved specifications or external updates, will be charged as time and materials.

Post-Launch Optimisation

We recommend opting into an ongoing support contract for life after launch. This provides a clear, structured path to handle the perfective maintenance, optimisation, and edge cases that naturally arise once real users start interacting with your platform.