What Should You Do in the First 90 Days of Inheriting an App?

I want to talk about something I think is really important and that people don't understand very well: what to do in the first 90 days of inheriting an app.

A lot of times I hear from people who have just taken on an app they didn't build. Maybe they bought a business and the business came with an application. Maybe they were partnering with somebody, working on it a little with them, and now it's fully on them. Either way, they're now in charge of maintaining it and making sure it runs well, and they don't always know what's going on inside it.

The short answer is four things. Document everything. Use the app yourself as if you were a brand new user. Give your team real time to understand the product before you ask them to change it. And talk to the customers who are already using it. None of these are complicated, but skipping any of them is how a good acquisition turns into an expensive one.

---

Why should you document everything first?

The first thing you should be doing is documenting everything: every workflow, how it works, and how the pieces connect.

This used to be a lot harder. In my opinion it used to take a very long time to go through an app and write down the ins and outs of each part. With AI, a lot of teams are having a much easier time of it. They can run a series of agents in parallel, have each one walk through a workflow, see how they all connect, and come back with a set of documents that explain exactly how the app works.

I've seen teams take that further and put the documentation in a wiki, so it isn't just sitting in the code where only developers can find it. And I've seen teams go a step further than that and use AI to build essentially a workflow book on their own intranet site. This is workflow A, this is workflow B, and here's how workflow A works, with screenshots of the actual app that AI captured and uploaded so people can check that everything looks right. Those teams also tend to find context they weren't expecting, because the process forces them to go back and verify what they thought they knew.

One set of workflow documentation serves every group that has to work with the app, not just the developers.

That documentation helps everyone who touches the app:

• Developers understand why certain code is written a certain way.
• Quality assurance knows exactly how to test things, and probably how to test them better.
• Product, customer support and customer success get a playbook for how the app is supposed to behave.

If you're adopting an app with a lot of users who need support, you want this in place early. Otherwise everyone is confused, everyone is lost, and nobody wants to be in a position where no one knows anything.

Most of the time there's a transition period. It's rarely "here's an app, good luck." If you have one, use it. Talk with the partners or the people who owned the application before you, document what you find, ask questions, go back and forth, and come out of it with a cohesive picture of what the app does. If you need more resources after that, at least you'll know it. When the previous owners aren't available, the app itself becomes the documentation, which is a situation I wrote about in rebuilding when the old app is the documentation.

---

Why should the owner use the app like a brand new user?

The next thing you want to do in the first 90 days is really start playing around with it. And this one is specifically for you, the owner.

You shouldn't be developing in it and you shouldn't be QA-ing it. You should be using it the way a brand new customer would. You need to understand your application. If you don't understand it, how do you plan on selling it to other people?

I can't tell you how many times I've seen someone buy an app on a marketplace like Microns or Acquire.com, expecting it to make them a ton of money, and then start using it and say, "I have no idea what this is doing." By that point it's already bought. You can't return it. The contracts are signed. So your next best option is to get in there, understand what it does, and then decide whether anything needs to change.

More often than not, what people find is that it's a good app. It does something useful for what they want to do, and it just needs a few things to fine-tune it. But you only find that out if you do the work of using it yourself, because that's how you learn what it's good at and what it's bad at.

That's also what tells you what your roadmap should be. I've had teams come to me and say, "We need to fix a lot of tech debt." I've had teams say, "The code is actually good, let's just start on new features." And some just say, "There are a few bugs, can we please fix these bugs?" There's no right answer to what you'll find, and I don't ever expect there to be one. What I can say is that if you do the due diligence, you'll know where you need to go with your mobile app. And if you'd rather have someone go through it with you, that's what our technical audit is for.

---

Why does your team need time to learn the product?

Another thing you should be doing is giving the people who actually work on the app, whether that's quality assurance, product, your Scrum Master or your developers, the time to truly understand what the product is.

I've seen a lot of teams start on an app with absolutely no idea what they're working with. At one point in my career I saw a team building a new mobile app based on an existing web application. They understood more or less what the end goal was. They had deadlines and they knew what features they wanted. But they really didn't understand the product, and when they started building, they had a hard time seeing how everything was supposed to fit together.

Some ramp-up time is normal, and that part isn't the problem. The problem is when nobody gives the team that time at the beginning, or even in the middle. By the end, no one really knows what's going on, and no one can tell you whether the app is going to be successful.

Whether you're building an app, fixing one, or inheriting one like we're talking about here, your team is the group that's going to turn it into a return on your investment. Whether you paid $20,000 or $50,000 for an app, the last thing you want is to crash and burn and lose that money. And if you're a bigger business that paid millions for an application or a whole suite of them, the last thing you want is to burn through another million over the next couple of years because the team never really understood what it bought. Give them the knowledge and the tools early. If you've had a good transition period and documented things along the way, your team will be set up even better than you expect.

---

Why should you talk to the app's existing users?

The last thing I'd ask anyone who just inherited an app to do is reach out to the people already using it.

It's really easy to take over an app and think, "I have an idea of where I want to take this. I have all these new ideas." But there's real research on what happens to customers when a business changes hands. A University of Georgia study of more than 2,000 mergers found that customer satisfaction slipped in the years after a deal, and that most of the merged companies lost value in the long run as those losses outweighed the cost savings. The exceptions were the companies that stayed focused on their customers. Your app probably isn't a public company, but I think the pattern holds: customers get annoyed by decisions they didn't see coming, they leave, and you lose money. In some cases that's fine because of how you want to run things. In others it isn't.

So you want to understand why your customers are using the app in the first place. Hopefully you got some of that from the previous team, but either way, asking the people who use it what they like about it is going to set you up for more success.

Here's an example. Say there was a small feature sitting in the backlog that never got built because the acquisition got in the way. Now you have a whole new roadmap full of bigger features you want to add. The problem is that you don't know yet what your users actually want. That roadmap might be based on what one or two people told you, or one or two clients, while the app has thousands of other users, maybe even over 100,000, who those new features won't help at all. Maybe that small feature in the backlog is what they've been waiting for, maybe it's something else entirely. You won't know until you ask.

Your users are going to give you better information than your own assumptions or the people around you, because they're the ones already there, coming back and using the app. That same thinking applies before you make any big technical change, too, which I got into in should you change tech stacks on a live app.

---

Where this leaves you

At the end of the day the goal is to make money with the app you inherited, so pay attention to what moves that number.

These are general thoughts, and every app is going to be a little different. But I think this is more true than not: if you document it, use it yourself, give your team time to learn it, and talk to your users, you'll have a much better shot at a return in the short term. And if you have bigger plans for it, you'll have a much better understanding of how to make those work in the long term too.