How I evaluate build-versus-buy decisions at a 50-person startup

Build-versus-buy decisions at startup scale are not about cost. They are about attention. Engineering attention is the scarcest resource at a 50-person company with an 8-person engineering team. Every system you build is a system you maintain, monitor, upgrade, and debug forever. Every hour spent on commodity infrastructure is an hour not spent on the thing that makes your product different.

After two and a half years of making these decisions at FinanceOps, I have a framework that has served us well. It is not complicated, but it requires honesty about what is actually differentiating and what is not.

Generate a realistic engineering editorial image with monitors, architecture notes, and system artifacts, dark slate and blue palette, 16:9, no text, no clip art, no generic stock office look.

Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “Cross-functional alignment is not a meeting problem. It is an incentive problem..” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.

Editorial supporting image for the section "The Framework" in the article "How I evaluate build-versus-buy decisions at a 50-person startup". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "How I evaluate build-versus-buy decisions at a 50-person startup". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: slate, amber, off-white paper, low-contrast office shadows. Mood: measured, confident, strategic, scarred enough to sound calm while saying hard things. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No staged handshake photos, no smiling meeting stock imagery, no motivational poster energy, no text overlays.

The Framework

Every build-versus-buy decision gets evaluated on two axes:

1. Is this on our critical path? Does this system directly affect the customer experience or our core business operations? If the system goes down, do customers notice?
2. Does building it create differentiation? Will our version be meaningfully better than what we can buy, in ways that customers value?

The intersection of these two axes produces four quadrants:

• Critical path AND differentiating: BUILD. This is your product. Payment reconciliation engine. Transaction matching algorithm. Custom compliance workflow. This is where your engineering talent should focus.
• Critical path but NOT differentiating: BUY, but choose carefully. Authentication. Email delivery. Payment processing gateway. These must be reliable but building them provides no competitive advantage.
• Not critical path AND differentiating: BUILD if cheap, otherwise defer. Internal tools that make your team more efficient. Custom dashboards. Developer experience improvements. These are valuable but should not compete with critical-path work for resources.
• Not critical path and NOT differentiating: BUY the cheapest option. Logging infrastructure. Error tracking. Status pages. Uptime monitoring. There is no reason to build any of these.

Decisions We Got Right

Built: payment reconciliation engine. This is the core of FinanceOps. Our reconciliation algorithm is our competitive advantage. Every optimization, every edge case handler, every performance improvement directly translates to customer value. No third-party reconciliation tool would handle our specific requirements without heavy customization that costs as much as building from scratch.

Bought: authentication via Clerk. Authentication is on our critical path but is not differentiating. We evaluated building our own auth system. The estimate was 6 weeks for basic email/password and another 4 weeks for SSO. Clerk handles both plus MFA, social login, and user management for $300/month. The 10 weeks of engineering time are worth far more than the annual subscription.

Bought: error tracking via Sentry. Not on the critical path, not differentiating. Sentry is $26/month and better than anything we would build. The decision took five minutes.

Decisions We Got Wrong

Built: internal admin dashboard. We spent three weeks building a custom admin dashboard because “off-the-shelf tools do not fit our data model.” Two months later, we realized that Retool or Appsmith would have handled 90% of our needs for $50/month. The remaining 10% could have been custom scripts. The three weeks of engineering time was wasted on commodity work.

Bought then rebuilt: notification system. We started with a third-party notification service. It handled email and Slack notifications well. But as our notification requirements grew, specifically around compliance-required audit notifications with specific delivery guarantees, the third-party service’s retry logic and delivery confirmation did not meet our needs. We rebuilt it in-house after six months. The lesson: commodity services work until your requirements become non-commodity.

The Mistake Most Startups Make

The most common mistake is building commodity infrastructure because it feels productive. Engineers prefer building over configuring. Standing up your own Kafka cluster feels like real engineering. Configuring a managed SQS queue feels like operations work. But the business value is identical, and the maintenance burden is wildly different.

Create a realistic engineering leadership editorial image with a cleaner desk, refined system notes, calmer lighting, 4:3, no cliché teamwork stock imagery.

By the time I wrote this, the lesson was bigger than the tool or incident. The job had become setting defaults a team could trust, then proving those defaults in systems like portfolio, pipeline-sdk, and dotfiles. That is leadership work, not just technical taste.

Building something that a SaaS handles for $50/month is not engineering. It is a misallocation of attention. The job of engineering leadership is to focus finite attention on infinite problems. Every build decision must pass the question: would our customers notice the difference?

At 50 people, you have maybe 8-10 engineers. Each one gets roughly 1,600 productive hours per year. That is 16,000 engineering hours total. Every hour spent building commodity infrastructure is an hour stolen from differentiation. The math is unforgiving. Build what matters. Buy everything else. Be honest about which is which.

The Review Cadence

Build-versus-buy decisions are not permanent. We review them quarterly. Systems we built may have cheaper buy alternatives now. Services we bought may have become critical enough to warrant building in-house. The quarterly review prevents both sunk-cost attachment to internal systems and vendor lock-in complacency with external ones. The question is always the same: is this where our attention should be?

The build versus buy decision at fifty people is different from the same decision at five or five hundred. At fifty, you have enough engineers to build and maintain custom systems but not enough to absorb the opportunity cost of building commodity infrastructure. The evaluation framework we developed weighted three factors: how central the system is to our competitive advantage, how much customization our use case requires, and how mature the available commercial options are. Systems that scored high on all three justified building. Everything else defaulted to buying, with an explicit trigger condition for reconsidering. The framework did not eliminate debate, but it gave the debate structure and prevented decisions from being driven by engineering enthusiasm rather than business reality.