Every change takes longer
Each addition breaks something elsewhere. The team spends more time fixing than building.
Engagement model
Application audit and takeover
for products nobody
dares to change any more.
A slow, fragile application, difficult to evolve or left without a team. We assess the existing system, prioritise risks and take over the product when that is the right decision.
diagnosticDIAGNOSTIC
Error handling
Payment failures provide no useful feedback: the user is blocked and the incident is not logged.
RECOMMENDED ACTION
Isolate the payment flow, add an error message and server-side logging.
Dependencies
Versions frozen for several release cycles, including two with published security patches.
Tests
Critical flows are not covered: no warning before deployment.
TOP PRIORITYCODE · OPERATIONS · TESTS
Situations
What calls for a diagnostic.
The product is unstable in production
Crashes, regressions, incidents that are hard to reproduce and no useful monitoring.
The previous agency abandoned the app
It no longer replies or has closed down. Nobody knows the codebase, documentation is missing or outdated, and access is incomplete.
A rebuild is being considered
Someone proposes rewriting everything. You want to know whether that is justified before committing the budget.
Diagnostic scope
What we examine in your application.
A useful diagnostic requires read access to the repository, environments and tracking tools, plus a conversation with the people who know the product.
Architecture and code
Structure, coupling, dependencies, versions and differences from current platform practices.
Quality and tests
Actual coverage, integration pipeline reliability and the ability to deliver without regressions.
Operations and security
Deployment, monitoring, secret management, personal data handling and vulnerable dependencies.
Performance and costs
Response times, infrastructure consumption and avoidable costs.
User journeys
Where journeys break down: reported drop-offs, unusable screens and inconsistencies accumulated over releases.
Diagnostic deliverables
A map of the existing system, prioritised risks, reasoned options and an estimate for the next increment.
Method
What happens after the diagnostic.
- 01
Three possible outcomes
Keep and fix, rebuild a part, or make a reasoned case for a rewrite. A rewrite is not the default: it also revisits decisions already validated.
- 02
Stabilise critical journeys
The flows supporting usage and revenue are isolated and secured first, through tests and useful monitoring. Remaining debt is documented, not concealed.
- 03
Migrate progressively
When migration is chosen, it proceeds in phases while the product remains in production, rather than a single cutover.
- 04
Take over maintenance
If a takeover is agreed, maintenance and evolution are covered by a subsequent agreement with defined scope and rhythm.
Responsibilities
Who decides what.
A typical division of responsibilities, agreed for each engagement.
| Topic | Your team | Black Tide |
|---|---|---|
| Access | You provide read access | We work within the agreed scope without copying data outside your organisation |
| Diagnostic scope | You set the priorities | We flag what this scope leaves out |
| Decision | You choose the approach | We document the consequences of each option |
| Stabilisation | You prioritise fixes | We secure critical journeys first |
| Next steps | You decide who takes over the product | We prepare the handover to us or another team |
Selected work
A deadline-driven audit. A live product takeover.
Parkto
Audit and stabilisation in four weeks before a fixed launch: mapping debt, isolating three critical journeys, then handing over a remediation plan. This was the schedule for that engagement, not a standard delivery time.
Read the Parkto caseBlisterr
An ongoing takeover of a live product: phased application migration and table-by-table backend migration, without service interruption.
Read the Blisterr caseA takeover is measured by what has been stabilised and documented, not by a promise to make everything new.
Working arrangements
How we scope a diagnostic.
Duration and scope
Duration depends on codebase size and available access. We agree it with you before starting, together with the list of areas to examine.
The diagnostic is a paid engagement
It involves reading the actual code and understanding operations. We do not offer a free audit as a sales tactic.
Maintenance takeover
If a takeover is agreed, maintenance and evolution are covered by a separate agreement, with defined scope and rhythm.
Handover to another team
Deliverables are written so another team can take over. Working with us afterwards is not a condition of the diagnostic.
Useful questions
Before a diagnostic.
Does everything have to be rewritten?
Rarely. A complete rewrite revisits validated decisions and edge cases already handled. We propose it when the cost of maintaining the system exceeds rebuilding it, with evidence to support the choice.
Can you audit without access to the code?
We can examine the context and symptoms, but a technical code diagnostic requires repository access. We make the limitations explicit.
Our agency no longer replies: how do we recover the code and access?
Start by listing what is in your name: code repository, App Store Connect and Google Play Console accounts, domain name, hosting and third-party services. We help you build that inventory and request the transfers; the diagnostic then covers what has been recovered.
The App Store and Google Play accounts belong to the previous agency: is that a blocker?
No, but it must be settled before any new release. Apple and Google both provide an app transfer procedure between developer accounts, which keeps the listing, reviews and existing users. We prepare it with you.
What happens during stabilisation?
We isolate critical flows, fix priority issues and add appropriate tests and monitoring. Changes are coordinated with your team.
Can you take over maintenance afterwards?
Yes, if it meets your needs. The maintenance scope and ongoing support arrangements are agreed separately.
Next step
Let’s prepare a diagnostic.
Describe the symptoms, available access and your deadline. We explain what a diagnostic can establish and under which conditions.