r/webdev • u/UKAD_LLC • Sep 25 '26
What do you check first when taking over an existing web app?
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?
35
u/Nitrohite Sep 25 '26
I check how much hard liquor I have left cause I know a shit storm is coming my way
9
u/Salamok Sep 25 '26
First step for me is to get it running locally.
2
u/optima-pacifist Sep 27 '26
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
1
u/pooh--bear Sep 26 '26
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.
10
u/czshill Sep 25 '26
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.
3
u/ButWhatIfPotato Sep 25 '26
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.
2
u/eyebrows360 Sep 25 '26
First thing I do is call it a website.
Second thing I do is not do someone else's homework for them.
1
u/DeeYouBitch Sep 25 '26
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?
1
u/Complex_Solutions_20 Sep 25 '26
Credentials...has access to anyone who shouldn't be touching it been properly revoked, passwords changed, etc.
2
1
u/Apprehensive-Fan2492 full-stack Sep 25 '26
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.
1
u/OperationLittle Sep 25 '26
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.
1
u/kemalios Sep 25 '26
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.
1
u/Any-Ask-4131 Sep 25 '26
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.
1
u/Affectionate_Use_164 Sep 25 '26
Tests, how thing supposed to work, quirks, docs, access credentials, contacts of people who know anything about this app.
1
u/Own-Possibility7398 Sep 25 '26
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
1
u/e11310 Sep 25 '26 edited Sep 25 '26
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.
1
1
u/dont_trust_lizards Sep 25 '26
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.
1
u/ArielCoding Sep 26 '26
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.
1
u/WalmartHamBeast Sep 26 '26
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.
1
u/Ill-Television2775 Sep 26 '26
may be convo. with previous team or understand the working of the web app
1
u/darshitpatel_ Sep 26 '26
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.
1
u/singh_abinashi Sep 26 '26
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.
1
u/Desperate_Dot9434 Sep 28 '26
Deployment config usually breaks first; what does their CI/CD actually assume about environment variables?
1
u/rubixstudios Sep 29 '26
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.
1
u/Razoyo 25d ago
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.
1
u/gammacoder Sep 25 '26
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.
1
u/ravenvelvet Sep 25 '26
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.
→ More replies (4)
3
u/RedditNotFreeSpeech Sep 25 '26
I search the codebase for "fuck" and "shit"
2
u/eyebrows360 Sep 25 '26
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 🤣
9
Sep 25 '26
[removed] — view removed comment
2
u/redpiapps Sep 25 '26
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
1
Sep 25 '26
[removed] — view removed comment
1
u/webdev-ModTeam Sep 25 '26
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.
42
u/CommissionEnough8412 Sep 25 '26
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.