Codebase and architecture assessment
A written read of what exists: structure, dependencies, test coverage, security exposure, and the specific things most likely to break. You keep the document whether or not you continue with us.
Taking over an existing software project someone else built, and keeping it running.
We take over projects other teams started, work out what is actually there, and move the product forward without a rewrite you cannot afford.
- Codebase, architecture, and risk assessment
- Handover from a previous team or vendor
- Platform, framework, and cloud migration
- Staged revamp instead of a risky full rewrite
Inheriting a codebase is not the same job as building one. The people who made the decisions have gone, the documentation is thin or absent, and the parts that look worst are often the parts holding everything together. Meanwhile the product still has users, and they still expect it to work on Monday.
The usual advice is to rewrite. That is usually wrong. A rewrite spends months producing nothing a customer can see, and it throws away years of accumulated fixes for edge cases nobody remembers discovering. We start by finding out what you actually have, then change it in pieces small enough to release and reverse.
Sometimes the honest answer is that a component genuinely should be replaced. We will tell you which one, why, and what it costs, with the reasoning written down so you can disagree with it.
What the engagement includes
Handover from the previous team
Repository access, environments, credentials, deployment path, domains, and third party accounts, tracked to completion. The gaps found here are usually the expensive ones.
Stabilise before changing
Get the build reproducible, the deploy repeatable, and monitoring in place, so the first change you ship is not also the first time anyone has deployed in months.
Migration where it earns its cost
Framework, runtime, database, or cloud moves, sequenced so the product keeps running throughout rather than stopping for a big-bang cutover.
Staged revamp
Replace the parts that hold the product back, one at a time, each behind its own release. The product improves while the work happens, not after it finishes.
Documentation as we go
Architecture decision records and runbooks written while the context is fresh, so the next person to inherit this is not in the position you are in now.
Whether this is the right fit
We would rather tell you now than three weeks in. If the right column describes you, say so on the call and we will point you somewhere better.
Best when
- The product is live and has users you cannot disrupt
- The original team or vendor is gone, or leaving soon
- You need to keep shipping while the foundations are repaired
- Nobody can currently say with confidence what the system does
- A previous rewrite attempt stalled or was abandoned
Not the right fit when
- You want a full rewrite quoted without an assessment first
- The real problem is that the product has no users, which engineering cannot fix
- The budget only covers the build and nothing for the mess underneath
- Nobody on your side can answer questions about intent or priorities
- You need a decision this week and cannot spare time for a proper read
How it runs
Access and first read
We get into the codebase, the environments, and the issue tracker. Within days you get a first impression, including anything urgent enough that it should not wait for the full assessment.
Assessment, fixed price
A bounded piece of work producing a written assessment: what exists, what is at risk, what it would take to move forward, and options with costs attached. This is a real deliverable, not a sales document.
Stabilise
Reproducible builds, a deployment that anyone can run, monitoring, and the highest severity fixes. Short, and it makes everything after it cheaper.
Adaptive delivery
Migration and revamp work under time and materials with a budget cap, weekly demonstrations, and a backlog you can see and reorder.
Rolling partnership, if it suits
Once the cadence is proven, reserved monthly capacity keeps the product maintained and improving without renegotiating every few months.
How this is priced
The assessment is fixed price, because its scope is genuinely knowable in advance. What follows is usually time and materials with a budget cap, because nobody can honestly quote a fixed price for work inside a codebase they have not read. Once the pace is understood, ongoing work often moves to rolling monthly.
Where the work happens
The work is done on GMT+7. On a takeover that matters more than it sounds: the reading happens while your day is ending, so the questions that come out of your codebase are usually waiting for you the next morning rather than the next week. TPSolutions is a registered business, and the registration is checkable before you hand anyone access.
Before you ask on the call
Can you quote the whole job before seeing the code?
No, and neither can anyone else honestly. What we can quote is the assessment, which is fixed price and bounded. It ends with costed options for the work that follows, based on what is actually in the codebase rather than what we hope is there.
What if the assessment says the code is beyond saving?
Then we say so, in writing, with the reasoning. You keep the assessment and are free to take it elsewhere. We would rather lose the follow-on work than start a rescue we do not believe in.
Do you work with the previous developers?
Where they are still available and willing, yes. A cooperative handover of even a few hours saves weeks of archaeology. Where they have gone, the assessment covers the gaps instead.
Can you keep shipping features while fixing the foundations?
Usually yes, after stabilisation. Trying to do both before the build and deploy are reliable tends to produce two half-finished jobs, so we sequence it deliberately.
What technologies do you take on?
Mainstream web and backend stacks. If the product is built on something we cannot support well, we will tell you at the first read rather than after the invoice.
If this is not quite the shape of it
The engagements next to this one, and the reason you might want them instead. All five are in the Services menu at the top of the page.
Tell us what you inherited.
Thirty minutes by video with Tai. Describe the product, who built it, and what is worrying you. You will leave with a view on whether an assessment is worth paying for.
Bring the codebase, or just the worry about it. Either is a fine place to start.