Skip to content
MERVENORBook a triage call

02 · FixFirmora, the stabilisation sprint

Stop the firefighting: make your app safe to run and to change

Two or four weeks of focused senior engineering on an application that keeps breaking, cannot be deployed with confidence, or has no tests. We fix the incidents that hurt most and reduce the technical debt behind them. Fixed scope from the Perlustra audit, fixed price, 50% on signature and 50% on acceptance.

PIPELINEbuildbreaksgreentestfailinggreendeployby handgreenmonitornonegreenINCIDENTS PER WEEKsprint startacceptance
Length
Two or four weeks
Price
Fixed, set by the audit
Payment
50% on signature, 50% on acceptance
Starts
After the audit

Scope and exclusions are written in the statement of work.

01In the sprint

What a stabilisation sprint contains

  • Reproduce and fix the incidents that hurt most (the audit ranks them).
  • A test harness around the critical paths — enough to make the next change safe, not 100% coverage.
  • A build and deploy pipeline that works from a clean machine, with staging and a rollback plan.
  • Dependency hygiene: patch known vulnerabilities, remove dead packages, pin what must be pinned.
  • Monitoring and error reporting that tells you something broke before your customers do.
  • A README and runbook written for the next engineer, whoever that is.

02Not in the sprint

What it does not contain

  • New features or redesigns
  • Data migrations or framework upgrades (those are the Renascia sprint)
  • After-hours support
  • Work on code outside the agreed repositories

Found mid-sprint?

Anything found mid-sprint is written up and priced as a change — never absorbed silently, never billed by surprise.

03Fixed price

How we keep a fixed price honest

The sprint is priced after the audit, so unknowns are known. Milestones are agreed in writing; you see a demo at each; acceptance criteria are stated in the statement of work.

A 10% contingency line is quoted only where the audit found genuine uncertainty — and refunded if unused.

04Questions

Frequently asked questions

Not answered here? Ask on the triage call.

How is spaghetti code handled during recovery?

By isolating the paths that matter, putting tests around them, and refactoring only where it reduces risk. We do not rewrite for aesthetics.

What is the typical timeline for a takeover transition?

Audit in one week; a two- or four-week stabilisation sprint; then either a retainer or a clean handover. The plan is built to get an application to a safe state within about six weeks of first contact.

Can you start without the audit?

No. Fixed prices on unread code are how projects fail. If the situation is an emergency, the triage call tells you what to do in the first 48 hours while the audit runs.

Will you work in our tools?

Yes: your repositories, CI, hosting, issue tracker and chat. Nothing of yours lives on our systems.

What happens after the sprint?

You receive the documentation and a handover call. You can continue on a Servata retainer or take the application back in-house; both are planned for from the start.

05Start

Tell us about the application

Thirty minutes, no slides, no sales script. You leave with a view on what to check first.

Length
Two or four weeks
Price
Fixed, set by the audit
Payment
50% on signature, 50% on acceptance
Starts
After the audit