Taking over an existing web application: how to assess it first

Direct answer

Assess before you promise anything. When a web application lands on your desk from a departed developer, an old agency or an acquired company, the first job is not to add features but to find out what you actually have: whether you can get into it, whether it can be rebuilt from its own source, what it depends on, and what happens to the data if you touch it. Only then can you choose to stabilise it, rebuild it or replace it.

One honest limit up front: a real assessment depends on access to the code, the hosting and the data. Nobody can judge an app from its screenshots. It also depends on the stack. LATYNEX's own work is Next.js and React on the frontend with a proper backend, as described on the web application development page, so we can assess codebases close to that most reliably. For other stacks, we will say so early rather than pretend.

What to check first: can you get in?

Before reading any code, establish control. Many takeovers stall because a critical account is held by someone who has left.

• Who owns the domain and DNS, and can you log in to the registrar?
• Who owns the hosting or cloud account, and do you have admin rights?
• Where is the source code, and is it complete and current, or only a copy of an older version?
• Which third-party services does it use (email, payments, storage, maps), and whose accounts are they on?
• Are there certificates or keys that expire, and when?

Access you will need

Read-only access to the repository and to the production configuration is enough to begin. Ask for a written list of environments and how each is deployed. Deliberately avoid changing anything in production during assessment. The related page on web application access requirements lists what a vendor typically needs and how to grant it safely, with least privilege and revocable credentials.

If the code cannot be found at all, the assessment changes character: you are then dealing with a running system you cannot reproduce, and every later option carries more risk.

Code health: what can actually be judged

A reviewer can answer a few concrete questions without reading every file. Does the project install and run locally from the instructions? Is there any automated test, and does it pass? Is there a clear separation between interface, business rules and data access, or is everything mixed together? Is configuration separate from code? Is there version history that shows recent, steady changes?

Be cautious about strong verdicts such as 'it's a mess'. Unfamiliar code is often just unfamiliar. Better signals are practical ones: how hard is it to make a small, safe change, and how do you know the change worked? An app that cannot be run locally or verified is risky whatever its style.

Dependencies

Inventory the frameworks, libraries and runtime versions. The concern is not age alone but support: is the runtime or framework still receiving security fixes, and how far behind is the app? Falling far behind makes each upgrade bigger, and some jumps are effectively a rewrite of parts.

Also note anything that depends on a vendor service you do not control, or on a package that is abandoned or private. These are the dependencies that fail quietly later.

Hosting and operations

Find out where the app runs, how it is deployed, how it is monitored and how it recovers. A common finding is that production was configured by hand and nobody recorded how. Check for logs, error tracking, scheduled jobs and anything that runs outside the main application, such as cron tasks on a server. Ask what happens today if the server restarts.

Data

Data is usually the most valuable and the most fragile part. Find out what is stored, where, in what shape, whether it is backed up and whether a restore has ever been tested. Look for personal or sensitive data, because that changes how carefully you must handle access during assessment. Work on a copy in a separate environment, never on live data, and delete the copy when finished.

If you are considering moving to a new system, data structure quality often decides whether stabilising or rebuilding is cheaper. Messy, inconsistent data is a cost under either path.

Build a risk register

Turn findings into a short list, each with what is wrong, what could happen, how likely it is and what it would take to address. Rank by consequence to the business, not by technical interest.

• Loss of control: accounts, domain or code you cannot reach
• Loss of data: no backup, or an untested one
• Security exposure: unsupported components, exposed secrets, weak access rules
• Loss of knowledge: one person understood it and has gone
• Change risk: you cannot modify it safely because nothing verifies the result

Stabilise, rebuild or replace

Stabilise when the app does its job, the code can be run and changed safely, and the risks are addressable with documentation, backups, updates and some tests. Rebuild when the business logic is valuable but the foundation cannot be run, changed or secured. Replace when a standard product now does the job and the custom app no longer earns its cost. See internal business tools for when off-the-shelf beats custom.

Do not decide before the assessment is done, and be wary of anyone who commits to a fix or a price without seeing the code. LATYNEX agrees one scope and one price in writing before work starts, and if your app is outside what we can assess well, we will tell you straight. For backend concerns specifically, see API and backend development.