The RFC That Stopped a Merger: When Technical Due Diligence Changed Everything

The RFC That Stopped a Merger: When Technical Due Diligence Changed Everything

Sarah Chen had been a Staff Engineer at a mid-sized fintech company for two years when the executive team announced exciting news: they were in talks to acquire a promising startup whose payment processing technology would accelerate their roadmap by 18 months. The deal was valued at $80M, and everyone was excited about the capabilities this would unlock.

As the lead architect for payments infrastructure, Sarah was asked to perform technical due diligence. “It’s mostly a formality,” her VP told her. “The business case is solid. Just make sure there are no obvious red flags.”

The Investigation Begins

Sarah approached the task systematically. She requested access to the startup’s codebase, architecture documentation, and production metrics. Over three weeks, she conducted deep technical reviews, interviewed their engineering team, and analyzed their operational practices.

What she discovered troubled her deeply.

The startup’s impressive demo performance came from aggressive caching and a monolithic architecture that worked well at their current scale of 5,000 transactions per day. Sarah’s company processed 5 million transactions per day. The architectural patterns that worked for the startup would collapse at scale.

More concerning: the startup had accumulated massive technical debt to ship features quickly. Their database schema had no proper indexing strategy, they had zero automated testing, and deployments required manual coordination across teams. Their “microservices architecture” was actually a distributed monolith with tight coupling between services.

The Dilemma

Sarah faced a difficult decision. She could write a diplomatic report highlighting some concerns while downplaying the severity. The business teams wanted this acquisition, and her VP had already told leadership it was a “low-risk technical integration.”

Or she could tell the truth: integrating this acquisition would require a complete rewrite of their core systems, taking 12-18 months and diverting her entire team from roadmap work. The promised 18-month acceleration would actually become a 2-year setback.

The RFC That Changed Everything

Sarah decided to write a detailed RFC (Request for Comments) rather than a simple pass/fail report. She titled it “Technical Integration Analysis: Payment Processing Acquisition” and structured it carefully:

Executive Summary (2 pages):

• Clear recommendation: Do not proceed with acquisition as structured
• Three alternative paths forward with cost/benefit analysis
• Quantified risk assessment with specific metrics

Technical Deep Dive (15 pages):

• Architecture analysis with diagrams comparing current vs. target state
• Scalability projections with load testing data
• Code quality metrics and technical debt quantification
• Integration effort estimates broken down by component

Alternatives Section:

• Option A: Build the functionality internally (12 months, $5M)
• Option B: Acquire but plan for complete rewrite (24 months, $80M + $8M)
• Option C: Hire key engineers from startup, not acquire company (3 months, $2M)

Risk Analysis:

• Detailed scenarios showing what would happen if they proceeded as planned
• Specific production incidents that would likely occur
• Customer impact projections with revenue implications

The Response

Her VP was not happy. “This is going to kill the deal,” he said. “The CEO is already talking about this in board meetings.”

Sarah held firm. “I’d rather kill a bad deal than let a bad deal kill us. If we do this acquisition without understanding the technical reality, we’ll be explaining to the board in 12 months why our payment processing is broken and why we need another $10M to fix it.”

She requested 30 minutes at the next executive team meeting to present her findings.

The Presentation

Sarah’s presentation was a masterclass in technical communication for non-technical audiences:

• She started with the business case everyone was excited about
• She used analogies: “This is like buying a bicycle manufacturer when we need to build a high-speed rail system”
• She showed projected system behavior under load using simple graphs
• She presented concrete alternatives with clear tradeoffs
• She ended with a specific recommendation: Option C - hire their top 3 engineers

The room was silent when she finished. Then the CFO spoke up: “So we’re about to pay $80M for something that will cost us another $8M to make usable, when we could build it ourselves for $5M?”

“Or hire their best people for $2M,” Sarah added.

The Outcome

The acquisition was restructured. Instead of acquiring the company, they made acqui-hire offers to the startup’s three senior engineers and licensed specific patent-pending algorithms. Total cost: $3.5M including licensing fees.

Within 9 months, Sarah’s team, augmented by the new hires, had built a payment processing system that exceeded the original functionality promised by the acquisition. The project came in under budget and integrated seamlessly with existing systems.

The CFO later told Sarah’s VP: “That RFC saved us somewhere between $75M and $100M when you factor in the acquisition cost, integration costs, and opportunity cost of delayed roadmap. That’s the most valuable document anyone at this company has written.”

What Sarah Did Right

1. Systematic Analysis Over Gut Feel Sarah didn’t just raise concerns - she quantified risks, projected outcomes, and provided data. This made her arguments irrefutable.

2. Provided Alternatives, Not Just Problems The RFC didn’t just say “no” - it offered three concrete paths forward with honest cost/benefit analysis. This turned a blocking concern into a constructive strategic discussion.

3. Communicated at Multiple Levels The executive summary worked for C-level readers, while the technical deep-dive satisfied engineering leadership. Everyone got what they needed from one document.

4. Prepared for Organizational Resistance Sarah anticipated pushback and armed herself with data, projections, and clear business impact analysis. She was ready to defend her position with facts, not opinions.

5. Stayed Professional Under Pressure When her VP expressed frustration, Sarah didn’t get defensive. She focused on organizational outcomes: “I’d rather kill a bad deal than let a bad deal kill us.”

6. Followed Through on the Alternative After stopping the acquisition, Sarah took ownership of delivering the promised functionality through the alternative path. She didn’t just identify the problem - she solved it.

Lessons for Staff Engineers

Technical due diligence is strategic work: When you’re asked to evaluate major technical decisions, recognize this as high-leverage work that can save or cost millions. Treat it with appropriate seriousness.

Document everything: Sarah’s RFC became a reference document. Written analysis has far more impact than verbal concerns because it can be shared, reviewed, and referenced over time.

Quantify the unquantifiable: “Poor code quality” is subjective. “Zero automated tests covering 150K lines of code that processes financial transactions” is objective and alarming.

Always provide alternatives: Senior leadership wants decisions, not just analysis. Presenting multiple paths forward with honest tradeoffs makes you a strategic partner, not a naysayer.

Build trust before you need it: Sarah had spent two years building credibility through consistent delivery. When she raised red flags, people listened. Invest in relationships and credibility during normal times.

Be willing to be unpopular: The right technical decision isn’t always the popular one. Staff engineers must be willing to deliver uncomfortable truths backed by rigorous analysis.

Communication is as important as analysis: The best technical analysis is worthless if you can’t communicate it effectively. Sarah’s presentation skills were as critical as her architectural knowledge.

The Career Impact

This incident transformed Sarah’s role at the company. She went from being “the payments architect” to being regularly consulted on M&A technical strategy, vendor evaluations, and architectural decisions across the organization.

Six months later, she was promoted to Principal Engineer with expanded scope covering all technical due diligence and strategic architecture decisions. The RFC that stopped a merger became the template for how the company evaluates all major technical decisions.

As Sarah reflected later: “Staff engineering isn’t just about building systems. It’s about having the judgment to know when not to build them, the analytical skills to prove it, and the courage to say it even when it’s unwelcome. That RFC was the most impactful code I never wrote.”