01
Stabilisation and bug reduction
Find the failures that recur, fix the cause rather than the symptom, and stop the bleeding.
Software services / Improve
Strengthen what exists
Make existing software dependable again.
Your codebase works, but nobody trusts it any more. We stabilise what you have — reducing failures, restoring confidence and making change safe without a full rewrite.
Discuss your system
Rewrites are a last resort Most systems can be recovered for far less than replacing them.
Who it is for
IT managers and operations leads carrying a system that still runs the business but has become slow, fragile, or impossible to change without something breaking elsewhere.
How it is sold
A day rate against an agreed backlog, or a fixed-fee block for a defined stabilisation scope. Ongoing support moves to a monthly retainer once the system is stable.
Start here
A fixed-price codebase assessment: we read the code, run the build, review the data model, and give you a written risk register ranked by what will hurt first.
Book a codebase assessmentWhat we take on
The work that makes a system safe to change.
Improvement work is rarely one problem. It is usually a short list of structural issues that compound until releases become frightening.
02
Refactoring and clean-up
Untangle the parts that block every change, without altering behaviour your users depend on.
03
Test and release safety
Automated tests and a repeatable pipeline, so a release stops being an event.
04
Performance and scale
Profile the slow paths, fix the queries and indexes, and make load predictable.
05
Security and access review
Authentication, authorisation, data exposure and dependency risk, assessed and closed.
06
Legacy modernisation
Move off an unsupported platform in stages, with the data intact and the business still running.
What is included
Diagnosis first, then the work that actually changes the risk.
Codebase assessment
Structure, dependencies, tests and the things that will hurt first.
Risk register
What is fragile, what it would cost to fix, and what to leave alone.
Data model review
Integrity, indexing and the reporting the model cannot currently support.
Automated test coverage
Tests around the behaviour you cannot afford to break.
Build and release pipeline
Repeatable deployment, so releasing is routine rather than risky.
Knowledge transfer
Documentation and walkthroughs for whoever maintains it next.
Why not just rewrite it
A rewrite restarts the risk you already paid for.
Existing software encodes years of real business rules. Replacing it throws that away and takes longer than anyone estimates. We recover first and replace only what genuinely cannot be saved.
- Behaviour is preserved
Rules your business depends on stay intact while the structure around them improves. - Change lands incrementally
Value arrives every few weeks instead of at the end of a long rebuild. - Risk is ranked, not guessed
Work is ordered by what is most likely to fail and most expensive if it does. - You keep running
The business carries on using the system throughout the work.
Tests added
Hot spots refactored
Existing systemKept running
Pipeline rebuilt
Data repaired
Improvements land around a system that stays in service
A different recovery standard
Most rescue work fails by fixing the wrong thing first.
Without a diagnosis, effort goes to whatever is most visible rather than whatever is most dangerous.
| Decision area | Typical rescue attempt | PsalmTech recovery |
|---|---|---|
| First move | Start fixing reported bugs | Assess the codebase and rank the risk |
| Scope | Open-ended and hard to stop | A defined block of work with an end state |
| Testing | Manual checks before each release | Automated coverage around critical behaviour |
| Releases | Infrequent, large and tense | Small, repeatable and reversible |
| End point | The same team is still needed | Your team can maintain it unaided |
The improvement engagement
From fragile to maintainable.
The sequence front-loads the diagnosis so you can decide how far to go before committing to the work.
01
Assess
Code, data, tests and pipeline.
02
Rank
Risk register, ordered by impact.
03
Stabilise
Stop the recurring failures.
04
Strengthen
Tests, structure and releases.
05
Hand over
Documentation and walkthroughs.
What you receive
- Risk register
- Stabilised system
- Automated tests
- Release pipeline
- Documentation
- Handover
Proof
Compliance output that cannot be allowed to drift
On 10Bucksonly the Section 18A and IT3(d) output has to stay correct release after release — exactly the kind of behaviour that automated coverage exists to protect.
Ready to stop firefighting?
Send us the codebase. Get an honest risk picture.
Tell us what keeps breaking, what nobody will touch and what a bad release costs you. We will tell you what is recoverable, what is not, and in what order to deal with it.