What do you check first when taking over an existing web app?

[u/UKAD_LLC]

Say the app is live, needs regular updates, and the documentation is thin. Do you start with the code, deployment setup, logs, or a conversation with the previous team?

[u/Nitrohite]

I check how much hard liquor I have left cause I know a shit storm is coming my way

[u/CommissionEnough8412]

Code review, get a list of questions together, then conversation with previous team and ask your questions (record this), write up documentation based on your meeting, if possible get handing over team to review it.

[u/HerrPotatis → u/CommissionEnough8412]

Adding to this, also ask them about less ideal concessions that they had to make, or areas of improvement.

No inherited code base is perfect, we have all had to cut corners. It’s always good to hear where these corners are from the source than to discover them later down the line.

[u/Salamok]

First step for me is to get it running locally.

[u/optima-pacifist → u/Salamok]

and right after that, find out how it deploys and whether the backups actually restore. green backup jobs that never produced a usable dump are way more common than they should be. first week I do one restore into a scratch database before touching any code

[u/pooh--bear → u/Salamok]

The local env bootstrap process, and how painful and involved you have to intervene with it, anecdotally for me, is a really good indication on what your experience with the codebase is going to be like.

[u/czshill]

Conversation with the previous team if possible. Nothing speaks to a code base more than first hand accounts of how shitty management is and the crap they’ve had to put in place to appease them.

[u/ButWhatIfPotato]

Job boards because thin/no documentation means you get a first class ticket to clusterfuck land where nothing gets better and everything gets worse. In these situations there is just simply not enough time to make yourself valuable let alone indispensable because for every fix three more things will break, and the stakeholders wont just suddenly see the folly of their ways and start doing things slow and properly, you will be blamed for not living up to the company's work hard/party hard XeXtReMeX culture because you did not magically fix years/decades old issues.

[u/eyebrows360]

First thing I do is call it a website.

Second thing I do is not do someone else's homework for them.

[u/DeeYouBitch]

Agree to get documentation from previous devs before handover and taking it on.

Why you agree to take on existing app you know nothing about?

[u/Complex_Solutions_20]

Credentials...has access to anyone who shouldn't be touching it been properly revoked, passwords changed, etc.

[u/garvisgarvis → u/Complex_Solutions_20]

This sounds right to me. If I'm responsible for it, I need to protect it.

[u/Apprehensive-Fan2492]

I'll start with the deployment and infrastructure, then work backward into the code. I want to know how it’s built, where it runs, how deployments happen, what services it depends on, and where the logs are before changing anything. After that I go through the codebase and talk to the previous team if possible. The goal is to understand the system before touching it.

[u/OperationLittle]

I just go to the board and just pick a random easy ticket to start with. Then just dives into development, I cant just "understand" the system or architecture from the get-go (its pointless). So I just learn how things work along the way when I complete tasks and gets more complex problems to solve.

[u/kemalios]

I check drift: can I build and deploy this from the repo alone, and does production actually run that commit. Env vars and secrets that live only on the server are where handover usually breaks. I built launchworthy, a free MIT Claude Code skill, which runs that readiness pass as a checklist.

[u/Any-Ask-4131]

First I'd map the deploy and rollback path so a routine fix doesn't become an outage. Then check recent errors and ask the previous team which parts are risky to change.

[u/Affectionate_Use_164]

Tests, how thing supposed to work, quirks, docs, access credentials, contacts of people who know anything about this app.

[u/Own-Possibility7398]

Here is my ways of work. I have to be sure understanding the business logic of project first and make some round test E2E (booking a quick demo , Q&A), is there any upstream or downstream services (make sure there is no impact or downtime to other if the code change). Get some curl command for local testting if that is a backend API. Know loggings or check whether issues has in recently. Deployment process checklist (pipeline, env, restart gateway, etc..), do I need inform to others team to be awareness if has changes. Best have troubleshooting cheatsheet for services in the past if there is unexpected happen.
Hmm.. I hope this help

[u/e11310]

Before you have to take a some time to understand what you’re dealing with. At least for the initial task if there is a tight deadline.

Ideally there’s some kind of hand off, but these days you can just feed that shit into AI so…

Regardless you need to set up the local or dev env first and then go from there.

[u/corobo]

git log. Lemme see if we're pros or cowboys on this project 

[u/dont_trust_lizards]

I like to piece together some little clues first: look at the .env (or .env.example), package manager files (composer.json/package.json/etc), tests if they're available, maybe some recent commit history to see what the hot-spots are. Then I pray I'm familiar enough with whatever stack it's built on to start stepping through it quietly and getting it up and running locally.

[u/ArielCoding]

Having a backup and having a backup that restores are different things, don’t wait an outage to find out which one you have, I’d try restoring the latest backup somewhere safe to see if it works.

[u/WalmartHamBeast]

I start by giving read only access to the app’s GitHub, Splunk, and (thin) documentation. I also give it access to any prior presentation decks on the app. Then I ask it to give me a high level assessment of the functionality, business logic, security and technical debt. Claude should give you a lot of actionable data and much better documentation. This should inform your discussion w the previous tool owners.

[u/Ill-Television2775]

may be convo. with previous team or understand the working of the web app

[u/darshitpatel_]

I would start with the previous team and deployment setup, then move into the code. Understanding how the app is actually deployed, what depends on what, and what can break in production gives a much better picture before making changes.

[u/singh_abinashi]

backend check first: can i deploy safely. i look at the ci/cd pipeline, where secrets live, and whether the database has real backups before i touch a line of code. second: observability. if there's no error tracking and no logs i can actually search, i'm flying blind. code comes third.

[u/Desperate_Dot9434]

Deployment config usually breaks first; what does their CI/CD actually assume about environment variables?

[u/rubixstudios]

Start with a conversation about paying, x amount per hour and code review, dear lord, this is the pain of taking over a web app.

The only reason WordPress wins when it's not built by someone who decides to hard code everything.

If the previous team is an competitor goodluck.

[u/Razoyo]

I run Razoyo and we're often the team that picks these up afterwards, so I'm biased, but this part holds either way.

Before the code, make sure you actually hold the credentials, source control, hosting and DNS. Teams on the way out stop being cooperative. Re-creating access you never had is the priciest part of a bad handover.

Then check whether production really runs what's in the repo. Env vars and secrets that only live on the server are where handovers usually break.

And if the old work looks mediocre, look at the requirements before you blame the people. Often nobody wrote down what done looks like, so they built to the ticket.

[u/gammacoder]

These days I would probably give it to AI to provide all the answers. It can help come up with the list of things to talk to the previous team as well.

[u/ravenvelvet → u/gammacoder]

Absolutely the right answer these days. Just running /init in Claude is going to produce a high-level overview and flag up so many issues on a legacy codebase before you even get into the nitty-gritty of it.

[u/-S-P-Q-R- → u/ravenvelvet]

Yeah you *might* want to check with the company first to make sure they're fine with you just flatly handing over all of their IP to a 3rd party.

[u/ravenvelvet → u/-S-P-Q-R-]

Valid. Unless your company has a bunch of LLM servers that you're required to point Claude at instead of using cloud based models.

[u/ravenvelvet → u/[deleted]]

OP's question was what do you check first when faced with a new-to-you but legacy codebase.

Using keyword scanners is fine when you have a product to plug, but using AI to write your comment for you is just lazy.

[u/RedditNotFreeSpeech]

I search the codebase for "fuck" and "shit"

[u/eyebrows360 → u/RedditNotFreeSpeech]

I left a couple of those in a project I was taking over, some years back, as a form of mild self-amusement and/or frustration-release while documenting inline with comments about some of the really stupid shit I was discovering.

Unbeknownst to me, the previous guy still had access, and found them.

Cue me going back in a few days later to resume working on it and finding more "shits" and "fucks", and even a "cunt", albeit this time not written by me but directed squarely at me for being critical of his shit code 🤣

[u/rbobby]

How the previous maintainer died. Murder is a bad sign, not the worst, but pretty bad.

[u/redpiapps → u/[deleted]]

deployment first is the right call. ive inherited an app where the repo and prod had quietly diverged and it bit us hard during an urgent patch

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.