TechGurus
Strategy Automation Intelligence
Client login ↗Book a Strategy Call
Services / Code Takeover & New Features
Service

Code Takeover & New Features

Somebody else built it and you need a feature added, a stalled build finished, or a fault fixed properly. We read the code, work out how it fits together, and then do the work.

New FeaturesCode ReviewProject TakeoverUnfinished BuildsIntegrationsHandover & Documentation
How it runs
Establish what you own
Source code, hosting, domains, accounts, data. This is often the hardest part of a takeover, particularly where a handover never happened, and it is work we have done many times.
Read the code
A read-only review of the code, its dependencies, the hosting and the data, working out how the pieces fit together and where a change would have to go. Nothing in your live system is touched.
Your decision
You decide what happens next with the report in hand. Taking it to another developer is a legitimate outcome, and the report is written so that you can.
The work
If you want us to carry on, we do it in the agreed order: the feature you came for, the unfinished parts, or the faults. We document as we go, so you are never in this position again.
Problems it addresses

If any of this sounds familiar, it is worth a conversation.

Your site or app does its job, and the one feature you now need keeps being quoted as a rebuild.

A build was paid for and stopped part-way, and nobody can tell you how much of it is usable.

You have parted ways with the previous developer, and nobody currently understands the system your business runs on.

It works, but not properly, and every attempt to fix one thing seems to break another.

What we deliver

A working outcome, not a slide deck.

All four come out of one fixed-scope review, whether you are adding to the system or deciding what to do with it. The report is yours, and if you take the work elsewhere it goes with you.

01

Fixed-Price Code Review

A read-only assessment of the source code, the hosting and the data. We take a copy, work on the copy, and change nothing you are running. Your previous developer's cooperation helps, but is not required.

02

Plain-English Condition Report

What the system does, how the pieces fit together, what state it is in and the risks worth knowing about, written for a business owner rather than an engineer.

03

Effort Breakdown

The work to add the feature, finish the build or fix the fault, set out task by task with the dependencies and the order things have to happen in, so you can see exactly what you are being asked to pay for.

04

Keep, Extend or Replace Recommendation

A straight answer on whether to build on what you have or start again, with the reasoning written down so you are able to challenge it. Most of the time the answer is to build on it.

The engagement

What's involved

A fixed-scope review. Here is what is involved, activity by activity, so you can see what the assessment actually covers.

Breakdown of the engagement activities and what each one involves.
ActivityWhat's involved
Ownership and access checkEstablishing what exists and what you control: source code, hosting, domains, accounts and data
Source code reviewStructure, dependencies, quality, and how much of the intended work is genuinely finished
Security and dependency checkKnown vulnerabilities, out-of-date components, exposed credentials and anything left open
Hosting and data reviewWhere it runs, how it is backed up, and whether the data is in a state you can rely on
Feature and gap assessmentWhat works, what does not, and what is missing against what you were expecting
Effort breakdownThe remaining work set out task by task, with dependencies and the order it has to happen in
Report and recommendationWritten findings, the keep, extend or replace call, and the reasoning behind it
Walk-through sessionGoing through the report with you and answering questions in plain terms

Finishing, fixing or extending the system is scoped separately, from the effort breakdown the review produces.

Delivery process

How an engagement runs.

STEP 01

Establish what you own

Source code, hosting, domains, accounts, data. This is often the hardest part of a takeover, particularly where a handover never happened, and it is work we have done many times.

STEP 02

Read the code

A read-only review of the code, its dependencies, the hosting and the data, working out how the pieces fit together and where a change would have to go. Nothing in your live system is touched.

STEP 03

Your decision

You decide what happens next with the report in hand. Taking it to another developer is a legitimate outcome, and the report is written so that you can.

STEP 04

The work

If you want us to carry on, we do it in the agreed order: the feature you came for, the unfinished parts, or the faults. We document as we go, so you are never in this position again.

Pricing approach: discovery is a fixed fee. Build work is quoted as a fixed scope and price once discovery is complete, so you decide with the numbers in front of you. Ongoing support is a monthly retainer you can stop at any time.

Questions

Frequently asked.

Our website works fine, we just want a feature added. Is that this?+

Yes, and it is the most common version of this work. Adding to code somebody else wrote means understanding how it fits together first, because a feature bolted on without that understanding is what breaks the parts that were working. Where the question is narrow the review is short, since we are reading with one specific change in mind rather than assessing the whole system.

We have lost contact with the previous developer. Can you still help?+

Usually, yes. What matters is what you can establish ownership of: the domain, the hosting account, the source code repository. We help you work out what you hold and what needs recovering, and in most cases there is enough to work with. Where something genuinely cannot be recovered we tell you early, rather than after you have paid for the attempt.

Do you need the previous developer's cooperation?+

It helps and it is not required. A good handover conversation saves time, but the code itself tells us most of what we need, and we have picked up plenty of systems with no handover at all.

Will you just tell us it has to be rebuilt?+

Only if it does, and most of the time it does not. Rebuilding is the most expensive recommendation anyone can make, so it needs the strongest evidence behind it. The more common answer is that most of what you own is sound and the trouble is confined to one part of it.

What if the previous work turns out to be poor?+

We will tell you plainly what condition it is in, because you need to know. We will not spend your money running down whoever built it. There is usually a reason: a budget that ran out, a brief that changed, a handover nobody arranged. What matters is what it costs you from here.

Is our system safe during the review?+

Yes. The review is read-only and runs on a copy, so nothing you are running changes. Access is limited to the people doing the work and removed when it is finished.

What does it cost?+

The Code Review is fixed-price, so you know where you stand before committing to anything further. Work after that is quoted from the effort breakdown, which means you are approving something specific rather than an estimate. Book a call and we will scope it properly.

Further reading: Before you hand over your code · 6 minute read

Tell us what you need it to do, and we will tell you what that takes.

We will tell you honestly whether this is the right answer for it.

Book a Code Review