How to leverage and frame software developer work experience in taking over a challenging startup acquisition?

We were in a similar situation some years ago: We got a piece of legacy software that generated revenue, had incredibly poor code quality (On Error Resume Next littered all over the codebase), and none of the original developers were available for questions.

There's some sentiment among team members that our team is doomed in a hopeless scenario. We hardly have the expertise that when we take over on call, whoever's on shift feels comfortable handling whatever could happen.

The good news: It's not hopeless. The bad news: It will take a lot of time before you "feel comfortable" handling support requests for it.

Some of the lessons we learned:

• The short-term revenue created by software is mostly independent of the quality of the software. Spaghetti code solving your customers' problems will generate revenue, beautifully-written code that doesn't, won't.
• Obviously, bad code quality makes maintenance a nightmare. It decreases software developer satisfaction, and every small thing (support cases, feature changes, etc.) takes much, much longer than expected. This will get better over time, as you get more familiar with the product. If possible, try to keep fluctuation in your team to a minimum, so that the painfully aquired know-how isn't lost.
• Do not---I repeat: DO NOT---make the mistake of trying to rewrite everything from scratch.

Whole books have been written on how to deal with legacy code: Isolate components, write unit tests, etc. I won't repeat that here.

1. What can I do in the immediate future (as an individual contributor) to benefit myself and the team?

Adjust your expectations.

• Answering a short, simple support question might require a few hours of digging into the code and doing tests. That's OK, and the time is not wasted, because now you are more familiar with the code than before.
• Changes to the code (bugfixes, new features) will take a lot more time than you would expect. In particular, the time it takes will be more unpredictable: A small change might take 5 minutes or 5 days, and you won't be able to tell in advance which one it will be. Make sure the higher-ups understand that.
• Make sure that the office climate is good. Support each other. Working with legacy code is often not fun, so make sure that there are lots of other opportunities for your colleagues to enjoy work. For example, set time aside to rewrite some small(!), particular annoying part of the old application.

2. How can I best frame this work experience? We can barely comprehend the product, algorithms and design choices, etc. and I worry this will hurt my career, being unable to speak deeply on these topics and my work experience besides putting out metaphorical fires and archaelogical work.

Everyone enjoys writing new software from scratch using the newest gadgets and tools. However, what companies often really need are people able to maintain that decades-old legacy application that brings in all the revenue. So knowing how to "put out metaphorical fires and do archaeological work" (and being willing to do that!) are actually skills many companies are looking for.

The workplace problem

The management already made their decision. Which leaves you with a simple choice: take it or leave it.

The technical problem

You have to maintain or rewrite a software that you do not understand. You already study the code and it is hopeless.

Then change the approach: find (i.e., create) the requirements of the software. Or better requirements. Start with the main stakeholders for you: the management. What do they actually want? The exact same behavior? Or just a similar enough behavior? What improvements do they expect compared to what is already implemented?

Once you do that, you might find out that you can completely rewrite the software, and even make it better.

You can also infer requirements through usage and testing. "If I do this, I get that". Write that down, they will be very useful in the future.

Regarding the code, change it step by step. Start with what you understand, and gradually move towards the things that you do not understand so well. You might be able to find tools to reverse engineer the software for you, and present you with valuable information: classes, methods, data structures, call graphs, caller graphs...

Static analysis tools might come in handy to spot bugs or code structures that can be beautified and simplified.

But the most important, start with the requirements.

First, some ideas for what you can do to benefit yourself and the team; I think you could do ANY of these but I would recommend doing ALL (in no particular order):

1. Make sure the current (working-but-dubious) version of the software is well version-controlled, including infrastructure, so that as your team starts to make changes you can always confidently roll back to the current version. Better yet, ensure (before the departing team leaves for good) that you can completely rebuild/redeploy the software, including all its supporting infrastructure, from scratch (i.e., the repo(s)). If this is not feasible today, I would start here.
2. You mention that "lectures on various topics from the departing team aren't particularly effective"—which is understandable. So try this: reverse the flow of information and make all your sessions "reverse KT"-style: document what you think you understand, and present it to the departing team. It might be easier for them to point out what you haven't gotten right, and it might be easier for you to fit those corrections into your working knowledge than listening to standard KT lectures.
3. On that note, record every meeting, every conference call, etc., where KT is occurring. Ideally cover every topic multiple times, from different angles. In my experience, some of this may seem irrelevant until months later when you think, "Didn't they say something about this during one of our KT sessions?" and are thankful you recorded it.
4. Develop the best understanding you can of the original product use case(s) and requirements, and especially the relative importance of those.
5. I agree with others that rewriting everything from scratch is a temptation that often proves less pleasant than first perceived. Regardless, if you do go that route, I would strongly recommend thinking in terms of the strangler pattern: how can you refactor the application so that you can start to migrate its codebase to something more standard/modern/understandable (whatever the case may be) in piecewise fashion?
6. For better or worse, I think this is a great use case for AI. Give an LLM the context and the code (many possible approaches for doing this), either module by module or all at once (or both) and interrogate it to improve your understanding of the code's current state, the purpose of individual modules (if poorly named/commented), what looks most brittle, etc. Other types of code analysis can complement this exercise, of course.
7. In conjunction with some of the points above, figure out what the 'high-value, but highly brittle' parts of the application are, intersecting "What is most likely to break?" (from a technical standpoint) with "What is most likely to cause loss of business?" (from a business standpoint). Invest most of your effort in ensuring there are robust tests for those features and/or portions of the code. Once you have that, you can start to refactor with some confidence.

You might also ask your leaders if the original developers will have ANY availability or be contactable after their end date. If they are truly being laid off, it is likely they won't want to help, anyway, but sometimes people are still open to answering honest questions on the side, especially about an application they personally created.

As for what you do vs. what your team does, I think these points could apply equally to both: you should try doing whichever of these you can, but if you can align your team on them, all the better. Ideally as a team you can understand the seams in the application and split yourselves up so that each of you can focus on individual modules to reduce the overall workload.

Now, as to your second question of 'how can I best frame this work experience', the answer is hinted at in the above paragraph: whatever you identify as solutions to the quandary you're in, by not only taking 'ownership' yourself to try to understand the app, but also (especially) by encouraging/leading your teammates to do the same, you are demonstrating key values employers are usually looking for: initiative, leadership, creativity, etc. When prospective employers ask you to name challenges you've overcome or when you've shown personal leadership, this is an opportunity for you to have a great anecdote to address such questions.