Your Rails App Just Got Acquired. Now What? -- Planet Argon Blog

The 2026 Ruby on Rails Community Survey is open. Add your voice!

Article<br>Strategy

Your Rails App Just Got Acquired. Now What?

Reading time: ~ 5 minutes

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...