Technology Case Interview: Frameworks, Examples, and How to Solve Tech Cases (2026)
Mar 29, 2026
Frameworks · Technology Case Interview, Tech Case Interview, Platform Strategy
Road to Offer
Case Interview Prep Platform
Built by ex-consultants who coached 200+ candidates to MBB and Tier 2 offers. Every article is reviewed against real interview data from thousands of AI practice sessions.
- -Ex-strategy consulting team
- -10,000+ AI practice sessions analyzed
Published Mar 29, 2026
Summary
Technology case interviews cover digital transformation, platform strategy, make-buy-partner decisions, and SaaS profitability. Learn the PPT, ACT, and platform economics frameworks with worked examples.On this page
A technology case interview is a consulting case where the client is a tech company or where the core question involves a technology decision — build vs. buy, digital transformation, platform strategy, AI adoption, or cybersecurity investment. These cases appear at McKinsey Digital, BCG Platinion, Bain's Technology practice, all Big 4 strategy arms, and increasingly at tech companies like Amazon, Google, and Meta that run consulting-style internal strategy interviews. What makes them different from standard cases is the business model: SaaS subscription economics, two-sided platform dynamics, and software development costs require frameworks that go beyond the standard profitability tree.
Technology case interview: A case interview where the client is a technology company (SaaS, platform, hardware) or where the central question requires a technology decision — such as build vs. buy, digital transformation roadmap, platform strategy, or AI adoption. These cases require standard consulting logic plus tech-specific frameworks: PPT for transformation cases, ACT for make/buy/partner decisions, platform economics for marketplace cases, and SaaS unit economics for profitability analysis.
Practice a technology case interview now
Get AI-generated feedback on your structure, SaaS metrics analysis, and synthesis — tailored to tech and platform cases.
Try a free caseThe 5 Types of Technology Case Interviews
Before choosing a framework, identify which type of tech case you're facing. The five types have different analytical priorities, and confusing them is the most common mistake candidates make.
| Case Type | Core Question | Example Firms |
|---|---|---|
| Tech company profitability | Why is our SaaS/platform business losing money, and how do we fix it? | McKinsey Digital, BCG, Bain |
| Digital transformation | How should a traditional company adopt technology to improve operations or compete? | McKinsey Digital, BCG Platinion, Accenture, Deloitte |
| Make vs. buy vs. partner | Should we build this technology capability in-house, license it, or partner? | All MBB, Big 4, BCG Platinion |
| Platform/marketplace strategy | Should we build a two-sided marketplace, and how do we win? | McKinsey Digital, BCG, Amazon (internal) |
| AI/data strategy | How should we invest in AI or data to create competitive advantage? | All MBB, tech companies (Google, Meta) |
| Cybersecurity investment | How do we prioritize our security spend given risk exposure and budget? | Booz Allen, Deloitte, Accenture, KPMG |
Each type maps to a different primary framework — but a single case can span two or more types. A digital transformation case might include both a PPT analysis (type 2) and a make/buy/partner decision (type 3).
Framework 1: PPT for Transformation Cases
The PPT framework — People, Process, Technology — is the standard structure for any case asking how an organization should adopt or implement technology. It was originally developed in the organizational change management literature and is now widely used in consulting engagements at McKinsey, Accenture, and Deloitte (Source: Hacking the Case Interview, 2026).
The key insight: technology implementation fails most often on People and Process, not Technology. According to Bain's 2025 analysis of agentic AI disruption, the companies most at risk are those that deploy new technology without redesigning the processes and workflows around it (Source: Bain & Company, 2025).
PPT Framework for Technology Transformation Cases
Skills gaps, change resistance, training needs, leadership alignment, and organizational structure. Who are the internal champions? Who are the blockers?
Current-state process mapping, process redesign before technology deployment, workflow integration. Technology on broken processes creates digital debt.
System architecture, integration requirements, data quality, vendor selection, and build vs. buy decisions for each capability.
How to Apply PPT in the Case Room
Open your structure with all three layers, then go deep where the interviewer signals. In BCG Platinion cases, Technology often gets the most time. In Accenture and Deloitte cases, People (change management) is frequently the crux. A strong candidate explicitly links all three: "The technology change is straightforward — the risk is that 60% of the workforce lacks digital skills, and the current approval process has 14 steps that the new system can't accommodate without a redesign."
PPT signals in the prompt: Look for words like "adoption," "transformation," "rollout," "implementation," or "change management." These are reliable indicators that PPT is the right framework to lead with.
For cases that go deeper on transformation specifically, see our digital transformation case interview guide, which covers the 5-layer transformation framework in detail.
Framework 2: ACT for Make/Buy/Partner Decisions
The ACT framework — Ability, Cost, Time — structures make/buy/partner decisions. These appear in tech cases when the client needs to acquire or develop a specific technology capability: building an internal software platform, licensing an existing solution, or forming a technology partnership.
ACT Framework for Make/Buy/Partner Decisions
Does the client have (or can they build) the internal capability? Assess engineering talent, technical architecture, data assets, and strategic importance. Build differentiators; buy commodity.
Total cost of ownership over 5 years, not just Year 1. Build: upfront development + ongoing maintenance + opportunity cost. Buy/license: licensing fees + integration + vendor dependency risk. Partner: revenue share + control trade-offs.
What is the competitive window? Build typically takes 24-36 months for enterprise software. Buy/partner can be live in 6-12 months. If the market moves faster than you can build, buy.
Make vs. Buy vs. Partner: When Each Wins
| Decision | Choose When |
|---|---|
| Build (Make) | Capability is a core differentiator; off-the-shelf doesn't fit; talent exists; time horizon is long |
| Buy/License | Commodity capability; faster time-to-market needed; limited engineering talent; vendor market is mature |
| Partner | Strategic alignment with a complementary provider; shared IP development; market testing before full commitment |
The modern answer is usually hybrid: buy commodity infrastructure, build differentiating features on top, integrate via APIs. A traditional bank building a mobile app should license the core banking platform (commodity) and build the personalization layer in-house (differentiator).
Framework 3: Platform Economics for Marketplace Cases
Platform cases ask whether a business should shift to a two-sided or multi-sided model — connecting buyers and sellers, producers and consumers, or providers and users. These are among the most intellectually demanding tech cases because standard profitability frameworks don't capture the dynamics that drive platform value (Source: SignalFire on Networked SaaS, 2025).
The Four Components of Platform Economics
1. Network Effects Direct network effects: users benefit from more same-side participants (e.g., social networks). Indirect network effects: users on one side benefit from growth on the other side (e.g., marketplace — more sellers attract more buyers). Most platforms have indirect effects. Network effects drive an estimated 70% of value creation in the technology sector (Source: SignalFire, 2025).
2. Winner-Take-All Dynamics Strong network effects + high switching costs + data advantages = winner-take-most or winner-take-all markets. In consulting cases, the question is: does this market have the structural conditions for winner-take-all? If competitors can multi-home (users easily use multiple platforms), winner-take-all dynamics are weakened.
3. Cold Start Problem and Launch Strategy Every new platform must solve the cold start problem: how do you attract buyers without sellers, and sellers without buyers? The answer is subsidy: pick the side whose early presence most attracts the other side, and subsidize it (reduce friction, offer incentives, sometimes make it free). Marketplaces like Uber subsidized drivers first. App stores subsidized developers first.
4. Monetization and Take Rate Platform revenue = Gross Merchandise Value (GMV) × Take Rate. Take rates typically run 10-30% for B2C marketplaces (Source: Bain & Company). The key constraint: the take rate must be low enough that participants prefer the platform to bilateral deals, but high enough to cover CAC and infrastructure costs.
Platform case structure to use in the room:
- Define both sides and their value exchange
- Assess network effect type (direct vs. indirect) and strength
- Evaluate cold start strategy — which side to subsidize first
- Model unit economics: CAC per side, take rate, LTV, contribution margin
- Address governance: how to prevent disintermediation (participants cutting out the platform)
For more on this topic, see our growth strategy cases guide which covers platform market entry scenarios.
Worked Example: EV Software Platform — ACT Analysis
A traditional automotive company (call it AutoCo) wants to build its own EV software platform — the operating system, over-the-air update infrastructure, and data layer that runs the vehicle. The alternative is licensing existing technology from a Tier 1 software supplier.
The numbers: Build cost: $800M over 4 years. License cost: $120M/year (5-year minimum, $600M total). After Year 5, build is cheaper by ~$80M/year. Build also creates proprietary IP; license creates vendor dependency.
ACT Analysis:
| Dimension | Build ($800M) | License ($120M/year) |
|---|---|---|
| Ability | AutoCo has 200 software engineers — but EV platform needs 1,200+. Talent gap is significant. | Vendor has 10 years of EV software experience, ISO 26262 certification already complete. |
| Cost (5-year TCO) | $800M development + $160M/year ongoing maintenance = ~$1.6B over 5 years | $600M licensing + $40M/year integration = ~$800M over 5 years |
| Time | 4-5 years to production-ready software. Competitors are launching EV platforms in 18 months. | 12-18 months to integration and launch. Hits the competitive window. |
ACT verdict: License in the near term. The talent gap alone makes the build option high-risk — EV software development requires safety-critical expertise (ISO 26262) that AutoCo doesn't have at scale. The cost advantage of building only materializes after Year 7 when you factor in integration costs. And critically, the 4-year build timeline means AutoCo misses the 2027-2028 EV market window when competitors will be gaining software lock-in with customers.
Nuance to add in the room: This is not "license forever." Recommend licensing now while building internal capability in 2-3 targeted areas (data analytics, personalization) where AutoCo has unique advantages from its existing driver behavior dataset. Structure the license agreement with an exit clause at Year 5 to preserve strategic optionality.
SaaS Metrics You Must Know
When the client is a SaaS or subscription business, the profitability framework must be adapted. Revenue growth, gross margin, and net income are still relevant — but the metrics that actually reveal SaaS business health are unit economics and retention.
| Metric | Formula | Healthy Benchmark | What It Signals |
|---|---|---|---|
| ARR | MRR × 12 | Growing >30% Y/Y (growth stage) | Total annualized subscription revenue base |
| MRR | Sum of all monthly subscription fees | Growing consistently, low volatility | Predictability of revenue |
| CAC | Total sales & marketing spend ÷ new customers | Varies; use payback period as proxy | Cost to acquire one new customer |
| LTV | ARPU × Gross Margin % ÷ Churn Rate | >3× CAC | Lifetime value of one customer |
| LTV/CAC ratio | LTV ÷ CAC | >3:1 (>5:1 for top quartile) | Unit economics health (Source: Wall Street Prep) |
| Churn rate | Customers lost ÷ customers at start of period | <5%/year for enterprise SaaS | Rate of customer loss |
| NRR (Net Revenue Retention) | (Starting MRR + expansion − churn − contraction) ÷ Starting MRR | >100%; top performers >120% | Whether existing customers grow revenue |
| CAC Payback Period | CAC ÷ (ARPU × Gross Margin) | <18 months (strong: <12 months) | Time to recover customer acquisition investment |
The single most important metric for SaaS cases: NRR. An NRR above 100% means revenue from existing customers is growing even before new sales — the business can grow by doing nothing but retaining customers. Public SaaS companies with NRR above 120% command significantly higher revenue multiples (Source: Phoenix Strategy Group, 2025).
In the case room: If you're given a SaaS profitability case, immediately ask for (or state assumptions about) NRR, LTV/CAC, and churn rate. A company with declining NRR has a retention problem — cutting costs won't fix it. A company with strong NRR but high CAC has a payback problem — they're growing but burning cash to do it.
For more on the profitability framework foundation, see our profitability framework guide.
Common Mistakes in Technology Cases
The 4 mistakes that cost candidates in tech cases
1. Applying the standard profitability tree to a SaaS business. Revenue minus costs works for industrial companies. For SaaS, the tree misses NRR, churn, and unit economics. Lead with SaaS-specific metrics.
2. Treating the make/buy decision as purely a cost question. Year 1 cost is the least important factor. Strategic importance of the capability, time-to-market, and talent availability are almost always more decisive.
3. Recommending "become a platform" without checking the structural conditions. Network effects require two distinct sides with a reason to interact. Not every business has this. Vague platform recommendations without analysis of network effect type and cold start strategy look like buzzwords.
4. Ignoring the People and Process layers in transformation cases. 84% of digital transformations fail on adoption, not technology (Source: WWT Research). Jumping straight to technology recommendations without addressing change management is the most common tech case mistake at all experience levels.
Practice tech cases with structured AI feedback
Road to Offer's Guided Mode walks you through platform strategy, SaaS profitability, and make-buy-partner cases with feedback on your framework structure, quantitative reasoning, and synthesis.
Bridge: Related Frameworks and Cases
Technology cases frequently intersect with other case types. Use these guides for the adjacent frameworks you'll need:
- Case Interview Frameworks Complete Guide — The master reference for when to use which framework across all case types
- Digital Transformation Case Interview — Deep dive on the 5-layer transformation framework and build-vs-buy analysis
- Market Entry Framework — Platform launch cases often require a market entry structure for the initial side acquisition strategy
- Profitability Framework — Foundation framework adapted for SaaS and subscription businesses
- Growth Strategy Cases — Platform expansion and network effect growth cases
- Market Sizing Framework — TAM/SAM sizing for AI and SaaS market entry cases
Tech Case Drills
Quiz: Test Your Technology Case Knowledge
Test yourself
Question 1 of 3
QuizA SaaS company has NRR of 92%. What does this signal about the business, and which framework layer does it map to?
See where your tech case performance stands
Take Road to Offer's free readiness assessment — score your framework quality, quantitative reasoning, and synthesis across 7 dimensions. Know your gaps before the interview loop.
Sources
- Hacking the Case Interview — Technology Consulting Case Interview Guide (2026): hackingthecaseinterview.com/pages/technology-consulting-case-interview
- Management Consulted — Technology Case Interview: managementconsulted.com/technology-case-interview
- Wall Street Prep — LTV/CAC Ratio: SaaS Formula + Calculator: wallstreetprep.com/knowledge/ltv-cac-ratio
- Phoenix Strategy Group — LTV:CAC Ratio: SaaS Benchmarks and Insights (2025): phoenixstrategy.group/blog/ltvcac-ratio-saas-benchmarks-and-insights
- Bain & Company — Will Agentic AI Disrupt SaaS? Technology Report 2025: bain.com/insights/will-agentic-ai-disrupt-saas-technology-report-2025
- SignalFire — Why Networked SaaS is the new AI business model (2025): signalfire.com/blog/networked-saas-business-model
- PrepLounge — McKinsey Digital / BCG Platinion: Oil & Gas Upstream Technology Case: preplounge.com/en/management-consulting-cases/interviewer-led/advanced/mckinsey-digital-bcg-platinion-oil-gas-upstream-technology-196
- Hacking the Case Interview — BCG Platinion Case Interview: Complete Prep Guide (2026): hackingthecaseinterview.com/pages/bcg-platinion-case-interview
Sources checked March 29, 2026.
Frequently asked questions
Continue your prep path
Next actions based on this article: one pillar hub, two related guides, and one conversion step.
Related articles
McKinsey 7S Framework: How to Use It in Case Interviews (2026)
Master the McKinsey 7S framework for case interviews. Learn all 7 elements, Hard vs Soft S distinction, when to apply it, and a worked retail example.
Energy Case Interview: Oil & Gas Framework, Worked Example, and Prep Guide (2026)
Energy case interviews require a different cost structure map than standard cases. Master the upstream/midstream/downstream value chain, key metrics, and the transition framework that McKinsey, BCG, and Deloitte actually use.
ESG Case Interview: Dual-Metric Framework, Scope Emissions, and Worked Example (2026)
Master ESG case interviews with the dual-metric recommendation framework, Scope 1/2/3 emissions structure, five common case types, and a fully worked supply chain decarbonization example.