Skip to content
fullstack.sg
Menu

For inherited and unfinished applications

Taking on an application someone else started

Who it’s for
Product owners, Agencies, Teams with stalled projects
To start, send
Access to the code
Pricing
Quoted for each project

We get an inherited or unfinished application running, tell you what state it’s in, and help you decide what to do next.

Discuss a projectHow pricing worksOne-pager for your proposal
  1. Interface (not central to this service)
  2. Logic (not central to this service)
  3. Data (used by this service)
  4. Integrations (not central to this service)
  5. Deployment (not central to this service)

Is this for you?

Applications change hands for ordinary reasons. A freelancer moves on, an agency relationship ends, a product is bought, or the one developer who knew it leaves. What’s left is some code, a few hosting accounts and a list of things that were nearly done. Before deciding anything, you need to know what you actually have.

So we start with a fixed-price review, with no commitment beyond it. You get a written report covering what’s there, what state it’s in, the main risks and what we’d do next. It’s yours to keep, whether or not we do the follow-on work.

Who it’s for

  • Product owners

    You’ve inherited an application and want someone independent to tell you what state it’s in.

  • Agencies

    A new client came with a site or app built by their last supplier, and you need to know what you’re taking on before you quote.

  • Teams with stalled projects

    The build is half-finished, the original developer can’t be reached, and the launch date has slipped.

Usually, one of these has just happened

  • The previous developer is no longer available, and nobody else has run the code.
  • Hosting or domain accounts are registered to someone who has left.
  • Features were promised but are only half-built, and nobody knows how much is left.
  • The software it relies on is years out of date, and there are security warnings.

What you get

  1. A list of everything it depends on

    Every account, service, domain and password the application needs, who owns each one, and what needs transferring to you.

  2. A working build

    The application running on our machines and on a test server, with the setup steps written down.

  3. A written report

    The state of the code, the software it relies on, the data and the hosting, with risks listed by how much damage they could do.

  4. Options with estimates

    Usually a choice between making it safe, finishing what’s there, or replacing the parts that can’t be saved, each with its own estimate.

What the assessment contains

It’s written for whoever decides what happens next, with enough technical detail for whoever does the work. Sections grow or shrink depending on what we find.

Sample findings are illustrative
Application assessmentStructure + sample notes

  1. 1Summary

    • Current state in plain language
    • Top risks and recommended next step

    Example finding“Runs in production, but nobody can deploy it safely today. Fix that first; most other risks are manageable.”

  2. 2Access and ownership

    • Accounts, owners and transfer status
    • Secrets and where they're stored

    Example finding“The domain and hosting are registered to the previous developer’s personal email. Transfer before any other work.”

  3. 3Running the application

    • Setup steps that were missing
    • Staging environment details

  4. 4Code and dependencies

    • Framework versions and upgrade paths
    • Security advisories
    • Structure and consistency

    Example finding“Framework is three major versions behind; two packages have published security advisories. Upgrade path is incremental.”

  5. 5Data

    • Schema, migrations and backups
    • Data quality issues found

  6. 6Unfinished work

    • Status of each incomplete feature
    • Reusable versus replace

    Example finding“The booking admin is about 60% done and worth keeping; the reporting page should be rebuilt.”

  7. 7Options

    • Stabilise, finish or selectively rebuild
    • Scope and estimate for each

Before we start

What we’ll need from you

Access to the code
Read access is enough to start. We’ll need more before changing anything.
Hosting and service accounts
Or at least a list of them, so we can see the whole picture.
Any documents or history
Old briefs, lists of known bugs, handover notes or chat exports. It all helps.
Contact details for the last developer
If you have them. A short conversation can save days.
What you need next
Launching a feature, fixing a bug and reducing risk lead to different advice.

Decisions we’ll help you make

Fix it or rebuild it?

Rebuilding is rarely as cheap as it looks, because the old system already handles situations nobody wrote down. We only recommend it when the review shows the existing code can’t support what you need.

Update everything now, or later?

Security problems first. Big framework upgrades can often wait until there’s a test server and some automated checks in place, which makes them much safer.

Keep the current hosting?

If it works and the account is yours, usually yes. Moving hosting while also taking over the code adds risk, so we’d do one at a time where we can.

How the work runs

  1. 1

    Agree the review

    What it covers, who gives us access, and when the report is due.

  2. 2

    Check access

    We list every account and password and tell you straight away about any ownership problems.

  3. 3

    Get it running

    We set it up from scratch on our machines and a test server, writing down each step.

  4. 4

    Review

    The code, the software it relies on, the data, any tests and the unfinished work.

  5. 5

    Report

    The written report, and a call to talk it through with whoever makes the decisions.

  6. 6

    Next step

    If you carry on with us, a plan and a quote. If not, the report is still yours.

Usually included

  • Reviewing web applications and writing up what we find
  • Setting up development, test and live environments
  • Recovering and transferring access you’re entitled to
  • Fixing, finishing or maintaining it afterwards, if you’d like

Not included unless agreed

  • Recovering accounts you don’t have a legal right to
  • Formal security penetration testing
  • Disputes with a previous supplier
  • Guaranteeing the previous developer’s work

The review depends on access. If someone who won’t reply holds the accounts, getting them back through the provider’s support team can take longer than the technical work.

The full process, from first message to handover, is on How we work.

How the costis worked out

The review has its own fixed price, based on the size of the application, so you know what finding out will cost before committing to anything bigger. Any follow-on work is quoted from the report.

After a first call, we send a written quote that says what’s included and what isn’t.

What affects the cost

  1. How big the application is and how many services it uses
  2. Whether it currently runs anywhere
  3. Whether there are documents, or developers we can ask
  4. How many accounts need transferring
  5. How thorough the review needs to be, for example before buying a business

Questions

What if the code turns out to be in poor condition?

Then the report says so, specifically, and explains what that means for cost and risk. Messy code can still be perfectly usable. What matters is knowing which parts are.

Do we have to use you for the follow-on work?

No. The report is written so any competent developer can use it.

Can you work with any framework?

We’re strongest with JavaScript and TypeScript applications, such as React, Next.js and Node.js. If yours uses something else, we’ll tell you at the start whether we’re the right people.

Can you start before we have all the access?

Usually, with just the code. The review isn’t complete until we can see the hosting and services too.

Inherited an application?Discuss a project →Tell us what it is, what it’s built with and what you need it to do next. We’ll explain what the review would cover.