Hard-coded API keys and other things to check before you inherit an app

You're about to take over an app someone else built. Maybe the original developer went quiet. Maybe you bought the company that owns it. Maybe your in-house guy left and nobody else knows how it works. Whatever the reason, you're now responsible for software you didn't write, and you need to know what you're walking into.

Start with the most common finding. API keys hard-coded right into the source code, in plain text. An API key is a password that lets one system talk to another, and it should never be sitting in a file that anyone with repository access can read. That's the kind of thing you find in the first hour if you know where to look.

Here's what to check, in plain English, before you sign anything or take ownership.

Start with the passwords. Every app talks to other services. Payment processors, email senders, mapping tools, accounting systems. Each connection needs a credential, and those credentials should live in a separate, protected place that the code reads at runtime. Environment variables, a secrets manager, an encrypted config store. Any of those work.

What you don't want is the key typed directly into the code. When that happens, every developer who ever touched the project has your production keys. So does every contractor. So does anyone who cloned the repository to a laptop that later got sold on eBay.

The practical risk isn't theoretical. Hard-coded keys end up in version history, which means deleting them from the current file doesn't remove them. Git keeps everything. We've pulled twelve-year-old commits and found live credentials for services the client still uses.

Ask the outgoing developer one question. "Where are the production secrets stored?" If the answer involves a file in the codebase, you've got remediation work ahead of you. Every key needs to be rotated, meaning canceled and reissued, because you have to assume the old ones are compromised.

This one surprises people. You paid for the app, so you own it, right? Not always.

Read the original contract. Many development agreements grant you a license to use the software while the developer keeps the copyright. That distinction matters enormously. A license means you can run it. Ownership means you can modify it, hand it to another firm, or sell it with your business.

Then check where the code physically lives. If the repository sits in the developer's personal GitHub account, you don't have possession. If the servers are billed to the developer's credit card, you don't have infrastructure control. If the domain is registered under their name, you don't own your own web address.

We've seen all three at once. The client had spent six figures over several years and could not have moved the app anywhere without the original developer's cooperation.

Before you take over, get these transferred into accounts your company controls:

• The source code repository, under a company-owned organization account
• The hosting and cloud accounts, billed to a company card
• The domain registration and DNS control panel
• Any third-party service accounts the app depends on
• Written confirmation of copyright assignment, signed

An app you can't redeploy is an app you can't recover. Test this before you need to.

Ask for a fresh install. Take the code, follow whatever documentation exists, and stand up a working copy on a new server. If a competent developer can't get it running in a day using only the written instructions, the knowledge lives in someone's head and not in your files.

The specific things to verify are the boring ones. Are there database migration scripts, meaning files that build the database structure automatically? Or did someone create tables by hand over the years? Is there a list of exact software versions the app needs? Older apps often depend on a specific version of a language or library, and if nobody wrote it down, finding the right combination becomes archaeology.

Older apps often run on one specific Node version from years earlier with nothing documenting it, and the only way to find out is trial and error across an afternoon. That's a cost you pay whether you budgeted for it or not.

Modern apps are built on other people's code. Hundreds of packages, sometimes thousands. Each one is a small library that handles some task, and each one gets updated over time. Some get abandoned. Some develop security holes that get published publicly.

Run a dependency audit. Most languages have a built-in command for this that lists every known vulnerability in the packages an app uses. The output tells you two things. How many problems exist, and how badly the app has fallen behind.

A handful of low-severity warnings is normal. Every app has those. What should worry you is a long list of critical issues in packages that are five major versions out of date. That pattern means nobody has updated anything in years, and catching up requires touching a lot of code at once.

Also look for abandoned packages. If the app depends on a library whose last update was in 2019 and whose GitHub page has 400 open issues, that's a component nobody will ever fix for you. Eventually you replace it yourself.

Everyone says they have backups. Far fewer have ever tested a restore.

The question isn't "do you back up the database?" The question is "when did you last restore from a backup and confirm the data was complete?" Those are different questions with different answers, and the gap between them is where companies lose data permanently.

Check the retention period too. Nightly backups kept for seven days sound fine until you discover a data corruption problem that started three weeks ago. Now every backup you have contains the corruption. Thirty days is a reasonable floor for most businesses. Longer if you're in a regulated industry.

Find out where backups are stored. Same server as the app doesn't count. Same cloud account as the app barely counts. If someone gets into that account, they can delete both.

Inherited apps carry expenses nobody tracks. Pull every recurring charge tied to the software and put it on one page.

Start with hosting. Then add the paid third-party services, the monitoring tools, the error tracking, the email delivery service, the file storage. Add any per-seat software licenses baked into the app. Add the maintenance retainer if one exists.

Now compare that total to what a replacement would cost. This is where the arithmetic gets useful. If you're paying a maintenance retainer on an app nobody understands, plus hosting on oversized servers nobody has reviewed, plus SaaS subscriptions for features the app half-duplicates, the annual number is often larger than people expect.

We've had clients discover they were paying for two overlapping services because a developer added one and never removed the other. Nobody noticed because the charges were small and monthly. Small and monthly for four years adds up.

The honest comparison looks like this. Add up three years of running the inherited app as-is, including maintenance and cleanup work. Compare that to three years of a rebuilt system you own, including the build. Sometimes the inherited app wins because it works and it's paid for. Sometimes it doesn't, and you'll see it clearly on the page.

A review like this tells you the condition of what you're inheriting. It doesn't tell you everything.

Code review finds structural problems. It won't find every logic bug. An app can pass every check on this list and still calculate sales tax wrong in one edge case that costs you money for years. Only real usage and real data testing catches that.

You also can't fully assess an app you can't run. If the outgoing developer won't grant access to a staging environment or a copy of the production database with sensitive fields removed, your review is limited to reading code. That's better than nothing, but it's a partial picture.

And rebuilding isn't automatically the answer. If the inherited app works, users know it, and the problems are contained, cleaning it up is usually cheaper and less disruptive than starting over. We've told clients to keep apps we personally wouldn't have built that way. Working software has value that clean architecture doesn't override.

The case for a rebuild gets strong when three things stack up together. Nobody can safely change the app, the platform it runs on is past end-of-life, and the business has outgrown what it does. One of those is a maintenance project. All three at once is a replacement.

If you take one thing from this, take the list. Give it to whoever is evaluating the app on your behalf and ask for written answers.

1. Where are production credentials stored, and have any ever been committed to the repository?
2. Who holds copyright to the code, and is there a signed assignment?
3. Are the repository, hosting, domain, and third-party accounts all in company-owned accounts?
4. Can a new developer deploy a working copy using only written documentation?
5. What does a dependency audit report show today?
6. When was a backup last restored and verified?
7. What is the complete annual cost of running this app, line by line?

Seven questions. Any developer who built the app properly can answer all of them in an afternoon. The ones who can't answer are telling you something important.

If you've inherited an app and you're not sure what condition it's in, we'll look at it with you. Black Badger is in Clearwater, and we work with businesses across Pinellas and Hillsborough counties. Book a free strategy session at /contact and we'll go through the list together.