The 
Congratulations! Your company just got acquired. The deal is signed, the press release is drafted, and everyone is celebrating. But somewhere in the back of your mind, a quieter thought is forming: what happens to the app?
In my role as Software Delivery Manager, I help teams navigate the technical side of this kind of transition. And what I can tell you from watching this play out over the years is that the technical story of an acquisition doesn't get told in the boardroom. It gets told in the weeks and months after, when new owners start asking questions and the answers either build confidence or break it.
The first six months are chaos. That's normal.
Everyone is trying to find their footing. Your team is fielding questions from people who've never used your product. Your new parent company has its own tools, its own processes, its own opinions about how software should be built and run. There are org chart changes, Slack renames, and new logins to juggle. There's a lot going on at once, and I don't think there's an integration playbook anywhere that completely prepares everyone for this part.
What we've seen here is that the teams that come out of this phase in the best shape aren't the ones who shipped the most during the transition. They're the ones who showed up prepared, with documentation, a clear-eyed view of their technical landscape, and a credible plan for what comes next.
The teams that struggle are usually the ones who were caught off guard by what their new owners found.
The surprises that kill trust
If there's one pattern we see repeat across acquisitions, it's this: the technical surprises that damage trust aren't usually catastrophic bugs or architectural disasters. They're the things that you knew about and just never wrote down.
The hidden cost inventory. Your Rails app likely touches dozens of services: AWS infrastructure, error monitoring tools, background job processors, third-party APIs, payment gateways, and email delivery platforms. You know what these are. Your new parent company doesn't. When their finance team starts mapping vendor contracts and finds a $12,000/month AWS bill that wasn't in the acquisition due diligence, it doesn't matter whether the spend was justified. What matters is that it was a surprise. Surprises after a deal closes feel like concealment, even when they weren't.
The latent vulnerabilities. Every codebase has them. Gems that haven't been updated in three years. A dependency with a known CVE that was triaged as "low severity" and never made it onto the sprint. An admin endpoint with weaker auth than everything else. Before the acquisition, these felt like manageable technical debt. After it, they're your new owners' liability, and their security team will find them. The question is whether you're the one who surfaces them first, or whether they are.
The undocumented everything. How does your deployment pipeline work? Who has production access? What happens when the background job queue backs up? These answers probably exist inside the heads of two or three people on your team. That's fine when everyone is there. It's a problem when people start leaving... and after an acquisition, they always do.
This is your app's second act
Most acquirers arrive with a mental model already forming. They've read the due diligence, they've seen the revenue numbers, and somewhere in the back of their minds, they're already wondering whether the engineering team will recommend a rewrite.
We've watched this play out enough times to know how the story goes. Teams that greet new owners with a clear picture of their system (what's solid, what needs attention, where the real risks are) tend to find their acquirers' requests surprisingly reasonable. Teams that get caught flat-footed tend to confirm whatever concerns were already forming.
Your app has years of production behind it. Real usage, real pressure, real decisions baked into the architecture. That history is worth something. The next 90 days are about making sure the people who now own it can actually see that.
What to actually do in the first 90 days
First things first...
Inventory all of your services
Make a complete map of every external service your application touches. Include the cost, the purpose, the contract owner, and what breaks if it goes away. This doesn't need to be elegant. A spreadsheet is fine. The goal is to give your new parent company visibility before they have to ask.
This includes AWS costs broken down by service, monitoring tools (Datadog, Honeybadger, Rollbar, New Relic, whatever you use), background job infrastructure, email delivery, third-party API subscriptions, and any services running on individual credit cards or personal accounts. Yes, those too.
Get your security house in order
Your new parent company almost certainly has higher security standards than you did when you were an independent team. That's not a criticism. It's just math: a larger organization has more to protect and more compliance obligations.
Don't wait for their security team to hand you a list of findings. Get there first.
- Run a dependency audit.
- Update gems with known vulnerabilities.
- Review who has production access and revoke what shouldn't be there.
- Check for any credentials that have ended up in version control.
- Document what you find and what you're doing about it.
Walking in with a findings list and a remediation roadmap changes the dynamic entirely. It signals that you know your system, and that you're already moving.
Build documentation while you still have the knowledge
The people who know your system best are still on your team right now. That's your window. Capture the things that live in their heads: how the deployment pipeline works, what the most fragile parts of the system are, how to handle common failure modes, what the original reasoning was behind architectural decisions that might look odd to a newcomer.
We're not aiming for perfection in the beginning. Start with the things that would be hardest for a new person to figure out on their own.
Resist pressure to ship big features
There will be pressure, internal, external, from people trying to demonstrate momentum, to ship things during this period. Be deliberate about resisting it. The first 90 days after an acquisition are not the time to introduce significant new complexity into your system.
Your Rails app needs stability right now, not velocity. New owners are watching how you operate, and a clean, stable system that they can understand is worth more than a feature they didn't ask for.
Show your work
The most important thing we can tell you is that transparency is your best asset in this period.
People understand that software isn't perfect, and new owners generally don't expect to acquire a codebase without issues. What they don't like is finding out about problems that should have been disclosed, whether those were costs, security gaps, or architectural decisions.
Remember the roadmap we mentioned earlier? It should include a pretty comprehensive look at: here's what we have, here's what we know needs work, here's how we're thinking about addressing it. That builds more trust than six months of radio silence followed by a polished presentation.
We've seen this work. Clients who came into their post-acquisition integration with a clear technical inventory and a security-first posture found their new owners to be reasonable, collaborative partners. The framing mattered: we know our system, we know where it needs attention, and we have a plan.
Where Planet Argon fits in
We've been doing this for over two decades. We've seen clients get acquired by private equity firms, by Fortune 500 companies, by fast-growing competitors. What we've learned is that the most valuable thing an outside partner can provide during a transition isn't new features. It's continuity. And that's often when we come in.
If your Rails company has been acquired, or if you can see it coming, we'd like to talk.