Software Debugging & Maintenance Services

What we do

Debugging and defect fixing

Reproducing, diagnosing and fixing the problems your users are hitting — including the intermittent ones that only appear in production, which are usually a race condition, a caching assumption or an environment difference rather than anything mysterious.

Performance work

Finding out why a system is slow before changing anything. Most performance problems are a small number of specific causes — an unindexed query, an N+1 pattern, a synchronous call that should be queued, or an oversized payload — and profiling finds them far faster than rewriting on instinct.

Security and dependency maintenance

Keeping libraries and runtimes patched, removing abandoned dependencies, and fixing the common classes of vulnerability. Most breaches exploit known issues in outdated components rather than novel attacks, which makes routine updating one of the highest-value security activities available.

Codebase takeover

Adopting a system whose original team has left — understanding it, documenting it, stabilising it, and getting it to a state where changes are safe to make.

Ongoing maintenance

A standing arrangement covering updates, monitoring, fixes and small improvements, so problems are prevented and handled rather than accumulated until something breaks badly.

Taking over a codebase you didn't write

This is a large part of what we do, and it has a reliable shape. The instinct when inheriting messy software is to rewrite it. That is almost always the wrong first move: a rewrite discards years of accumulated business logic — including the strange-looking parts that encode real requirements someone learned the hard way — and typically takes far longer than estimated while the existing system still needs supporting.

The approach that works is less dramatic. First, get it running reliably in a reproducible environment, because you cannot fix what you cannot run. Then establish safety: version control hygiene, a way to deploy and roll back, and tests around the most critical paths so changes can be made without fear. Then document what the system actually does, particularly the parts nobody understands — that document is usually worth more than any single fix. Only then start improving, in small, verifiable increments, prioritising what is actually hurting the business.

Handled this way, an inherited system usually becomes workable within weeks rather than requiring a year-long replacement. And if a rewrite genuinely is warranted, you'll be able to justify it with evidence rather than a first impression.

Why software rots even when nobody touches it

A system that worked perfectly a year ago can be broken today without a single line changing, and this surprises people who assume software is static. The environment moves underneath it. Dependencies release new versions and abandon old ones. Language runtimes and operating systems drop support. Browsers change behaviour. Payment providers, APIs and platforms deprecate endpoints. Certificates expire. Security researchers publish vulnerabilities in libraries you're using.

The practical consequence is that "we don't need maintenance, it's working fine" is a position with a shelf life. Deferred maintenance also compounds: skipping updates for two years turns a series of small, routine upgrades into one large, risky migration where several breaking changes must be handled simultaneously. Regular small updates are dramatically cheaper and safer than periodic emergency ones — which is the entire argument for a maintenance arrangement rather than calling someone when it breaks.

Who we work with

• Companies whose developer has left — needing someone to adopt the system
• Businesses with a buggy or slow product — where the problem is diagnosis, not effort
• Teams carrying technical debt — needing stabilisation before they can build again
• Anyone running unmaintained software — with dependencies years out of date

Why choose Baxance

• We take on other people's code — that's a normal engagement, not an exception
• Diagnosis before rewriting; we fix causes, not symptoms
• Stabilise first, improve incrementally, document as we go
• Honest advice on when a rewrite is and isn't justified
• Ongoing maintenance so problems are prevented rather than discovered
• You keep ownership and the documentation we produce

What an assessment tells you

Before committing to remediation work, most clients want to know how bad things actually are. A short assessment answers that, and it's deliberately structured to be useful whether or not you continue with us.

We start by getting the system running in a reproducible environment, which is itself diagnostic — if nobody can stand up a working copy, that's the first problem to solve. We then review the codebase for structure, obvious defect patterns and areas of concentrated risk; audit dependencies for versions, known vulnerabilities and abandoned packages; check how it's deployed, whether changes can be rolled back, and whether backups exist and restore; and look at what monitoring and error reporting are in place, since most teams discover outages from customers.

The output is a plain-language report: what the system does, its current state, the risks ranked by likelihood and impact, and a prioritised list of what to address first — separating what's genuinely urgent from what's merely untidy. That distinction matters, because a lot of code that looks alarming is working fine and doesn't warrant spending money on, while some innocuous-looking gaps (no backups, an unpatched public dependency) are serious.

You can hand that report to any developer. We'd rather you make the decision with an accurate picture than commit to open-ended work on a system nobody has examined.

How engagements work

We usually start with a short assessment: get the system running, review the code and dependencies, and report honestly on its state, the immediate risks and what it would take to stabilise. That gives you a clear picture before committing to anything substantial.

From there, work runs either as a defined stabilisation project or as an ongoing maintenance arrangement with an agreed response approach for urgent issues. Many clients continue into new feature work once the system is healthy — see custom software development and web development, or the wider IT and marketing services.

Frequently asked questions

Will you work on software you didn't build?

Yes — that's a large part of what we do, including systems whose original developers are unavailable and codebases with little or no documentation.

Should we fix our system or rewrite it?

Usually fix first. Rewrites discard accumulated business logic and take longer than expected. We stabilise, document and measure, so any rewrite decision is based on evidence rather than first impressions.

Can you find bugs that only happen occasionally?

Yes. Intermittent production-only bugs are usually race conditions, caching assumptions or environment differences, and are found through reproduction, logging and profiling rather than guesswork.

Why do we need maintenance if the software works?

Because the environment changes around it — dependencies, runtimes, browsers, APIs and certificates all move, and known vulnerabilities are published. Deferred updates compound into large, risky migrations.

Do you offer ongoing support?

Yes. Maintenance arrangements cover updates, monitoring, fixes and small improvements, with an agreed approach for urgent issues.