TL;DR
| Factor | Big Tech | Startup | Agency |
|---|---|---|---|
| Codebase size | 10M+ LOC | 50K-500K LOC | 5K-50K per project |
| Deploy frequency | Weekly/Monthly | Multiple daily | Per milestone |
| Tech debt tolerance | Low | High | Medium |
| Stack freedom | Limited | High | Client-dependent |
| PR review depth | 3-5 reviewers | 1-2 reviewers | Often none |
The Stack Reality
Big Tech locks you into internal tooling.
At Google you write JavaScript but deploy through Blaze. React exists but so does Wiz. Your Node.js knowledge means nothing when everything runs on proprietary infrastructure.
// What you think you'll write at Google
import express from 'express';
// What you actually write
import {Handler} from 'google3/path/to/internal/framework';
Startups let you pick the stack. Sometimes too freely.
{
"dependencies": {
"next": "^14.0.0",
"react": "^18.2.0",
"@tanstack/react-query": "^5.0.0",
"zustand": "^4.4.0",
"tailwindcss": "^3.3.0",
"prisma": "^5.0.0",
"zod": "^3.22.0",
"trpc": "^10.0.0"
}
}
Modern. Clean. Until the next CTO joins and rewrites everything in Rust.
Agencies inherit client chaos.
// Monday project
{ "dependencies": { "next": "14.0.0" } }
// Tuesday project
{ "dependencies": { "jquery": "1.9.1", "backbone": "1.4.0" } }
// Wednesday project
{ "dependencies": { "angular": "1.8.0" } } // Yes, AngularJS. In 2026.
You become a mass polyglot by survival, not by choice.
CI/CD and Deployment Patterns
Big Tech has infrastructure you cannot replicate.
# Simplified Google-scale deployment
deploy:
canary: 0.1%
monitor: 24h
rollout:
- 1%
- 5%
- 25%
- 100%
auto_rollback:
error_rate: > 0.01%
latency_p99: > 200ms
Your feature reaches 1% of 2 billion users. That is 20 million people in "canary."
Startups ship fast and fix in production.
# Typical startup deployment
deploy:
branch: main
trigger: push
environment: production
rollback: "git revert && pray"
No canary. No gradual rollout. Vercel preview links are your staging.
Agencies deploy when the client approves.
Week 1: Code complete
Week 2: Waiting for client feedback
Week 3: "Can we make the logo bigger?"
Week 4: Regression from logo change
Week 5: Deploy at 11pm before launch
Code Review Culture
Big Tech reviews are documents.
// Google-style code review comment
nit: Consider using Optional<T> here instead of null check.
This aligns with go/nullable-guidelines (internal link).
Also see similar pattern in //ads/frontend/utils:null_helpers
Approved with nits.
Average PR: 200-500 lines. Review time: 1-3 days. Reviewers: 2-5.
Startups reviews are survival checks.
// Startup code review
"LGTM ship it"
Average PR: 50-2000 lines. Review time: 30 minutes. Reviewers: whoever is online.
Agencies reviews are optional.
// Agency code review
// What review? Client demo is in 2 hours.
Performance Requirements
The numbers tell the story.
Big Tech performance budgets:
const BUDGET = {
FCP: 1200, // First Contentful Paint (ms)
LCP: 2500, // Largest Contentful Paint (ms)
FID: 100, // First Input Delay (ms)
CLS: 0.1, // Cumulative Layout Shift
TTI: 3500, // Time to Interactive (ms)
bundleSize: 150 // KB (initial JS)
};
// Miss these? No deploy.
Startup performance budgets:
const BUDGET = {
doesItWork: true,
// That's it. Ship it.
};
Agency performance budgets:
const BUDGET = {
clientHappy: true,
lighthouseScore: 60, // "Green is green"
};
Technical Debt Approaches
Big Tech has dedicated teams for debt.
Q1: Feature work
Q2: Feature work
Q3: "Fixit week" - address 10% of logged issues
Q4: Feature work + Q1 planning
Debt gets logged, prioritized, occasionally fixed.
Startups are debt.
// TODO: Refactor this before Series B
// Written during seed round
// Still here at Series D
export const getUserData = async (id) => {
// 400 lines of spaghetti
// 17 edge cases
// 3 race conditions
// "It works, don't touch it"
};
Agencies hand off debt.
// Delivered to client
// Now their problem
// Next project starts Monday
What You Actually Learn
Big Tech teaches:
- Systems design at billion-user scale
- Debugging distributed systems
- Navigating legacy code (millions of lines)
- Performance optimization that matters
- Incident response processes
Startups teach:
- Shipping under pressure
- Full-stack ownership
- Making tradeoffs (speed vs quality)
- Product thinking
- Breaking things and fixing fast
Agencies teach:
- Rapid context switching
- Client communication
- Estimating accurately (or suffering)
- Multiple tech stacks
- Saying "no" diplomatically
Interview Technical Depth
Big Tech asks:
Design a URL shortener that handles 100M daily requests.
Expected: Load balancing, database sharding, caching layers,
consistent hashing, rate limiting, analytics pipeline.
Time: 45 minutes.
Startups ask:
Build a feature in our actual codebase.
Expected: Working code. Tests optional but impressive.
Bonus: Fix a bug you find along the way.
Time: 3-4 hours take-home.
Agencies ask:
Show us your portfolio.
Expected: Pretty things that launched.
Explain client constraints you navigated.
Time: 30 minute conversation.
The Compensation Math
const bigTech = {
base: 180000,
stock: 50000, // Liquid. Vests quarterly.
bonus: 20000,
total: 250000,
variance: 'low'
};
const startup = {
base: 120000,
equity: '0.25%', // Paper value: $25K-$2.5M or $0
bonus: 0,
total: '120K-2.6M',
variance: 'extreme'
};
const agency = {
base: 110000,
equity: 0,
bonus: 5000,
total: 115000,
variance: 'low'
};
Expected value is not actual outcome.
Decision Framework
const chooseCareerPath = (developer) => {
if (developer.yearsExperience < 3) {
return 'bigTech'; // Learn fundamentals at scale
}
if (developer.riskTolerance === 'high' &&
developer.savings > 12 * developer.monthlyExpenses) {
return 'startup'; // You can survive a failure
}
if (developer.wantsVariety &&
developer.clientSkills === 'strong') {
return 'agency'; // Maximize breadth
}
if (developer.hasFamily || developer.hasMortgage) {
return 'bigTech'; // Stability matters
}
return 'startup'; // Default to growth
};
Final Take
There is no objectively better path.
Big Tech optimizes for depth and stability.
Startups optimize for ownership and upside.
Agencies optimize for breadth and variety.
Pick based on your current variables.
Re-evaluate every 2-3 years.
Your optimal path at 25 is not your optimal path at 35.
Top comments (0)