A startup I advised spent four months building a custom CRM because the founder decided Salesforce was “too complex” and HubSpot was “too limited.” Their custom CRM did about 20% of what HubSpot does, had bugs that took weeks to fix, and cost €15,000 in development time.
They could have used HubSpot’s free tier and launched four months earlier. The “limitations” they’d identified were features they didn’t actually need for the first 100 customers. They’d built a worse version of something that already existed, and the opportunity cost of those four months was devastating.
The build-vs-buy decision is one of the most consequential choices an early-stage founder makes, and most founders get it wrong by defaulting to “build.” The bias toward building is understandable — founders are builders by nature. But in the early stage, building infrastructure that isn’t your core product is almost always the wrong call.
The Decision Framework
Here’s the simple test I apply to every build-vs-buy decision:
Is this your core product? If the thing you’re considering building IS the product you sell to customers, build it. If it’s infrastructure that supports your product (CRM, email, analytics, invoicing, scheduling), buy it.
Does a tool exist that covers 70%+ of your needs? If yes, use the tool. The 30% it doesn’t cover is almost certainly not worth building custom for, at least not yet. Workaround the gaps manually.
Is the cost of the tool less than the cost of building? Calculate the real cost of building: developer time (or your time) × hourly rate × estimated hours. Then add 3x for underestimation (everyone underestimates development time by at least 3x). Compare that to the annual cost of the tool.
Will you need to maintain what you build? Custom-built tools require ongoing maintenance — bug fixes, updates, security patches. Tools you buy include maintenance in the subscription. Factor maintenance into the total cost of ownership.
If the tool exists, covers most of your needs, costs less than building, and removes maintenance burden, the answer is buy. In my experience, this is the answer about 90% of the time for early-stage businesses.
The 10% where building makes sense: your core product (obviously), truly unique workflow requirements that no tool addresses, and situations where the tool’s pricing becomes more expensive than custom development at your scale (which rarely happens before €50K+ monthly revenue).
The “Good Enough” Principle
Most founders reject existing tools because they’re not perfect. “But it doesn’t do exactly what I need” is the refrain.
Here’s the reality: your own custom-built tool won’t do exactly what you need either. You’ll discover new requirements as you use it. You’ll find bugs. You’ll want features you didn’t anticipate. The only difference is that when an off-the-shelf tool doesn’t do what you need, you submit a feature request. When your custom tool doesn’t do what you need, you spend another week building.
“Good enough” is the correct bar for non-core tools. Your CRM needs to be good enough to track customers. Your email tool needs to be good enough to send emails. Your analytics need to be good enough to show basic metrics.
None of these need to be perfect because none of these are your product. Your customers never see your CRM. They never interact with your analytics dashboard. They don’t care whether your invoicing is custom-built or comes from Stripe.
The only place where “good enough” is not good enough is your actual product — the thing customers pay for. That deserves every ounce of your building energy. Everything else is a distraction from the work that matters.
The Hidden Costs of Building
When founders calculate the cost of building, they consistently miss three categories of expense.
Hidden cost 1: Opportunity cost.
The four months spent building a custom CRM is four months not spent on customer acquisition, product development, or market validation. What would those four months have been worth if spent on the core business?
For the startup I mentioned earlier, those four months likely cost them their first-mover advantage in a niche market. A competitor entered during that time and captured the early adopters. The CRM wasn’t the product — it was infrastructure. But it consumed the same time and energy that should have gone to the product.
Hidden cost 2: Maintenance burden.
Custom tools break. They need updating when dependencies change. They need security patches. They need documentation so other team members can understand them. This ongoing maintenance typically costs 20-30% of the original development cost per year. Every year. Forever.
Hidden cost 3: Decision fatigue.
Every custom tool requires ongoing decisions. What to improve next. How to handle edge cases. Whether to add features. These decisions consume cognitive bandwidth that should be spent on your core business. When you buy a tool, someone else makes those decisions for you. That cognitive space becomes available for the work that actually matters.
The Build-vs-Buy Matrix for Common Needs
Here’s my recommendation for the most common tools early-stage businesses need:
| Need | Buy | Build Only If |
|---|---|---|
| Website | Carrd, Webflow, Squarespace | Your product IS a website/platform |
| Email marketing | ConvertKit, Mailchimp | Never (at early stage) |
| CRM | HubSpot free, Notion | Never (at early stage) |
| Payment processing | Stripe, Paddle | Never (at early stage) |
| Scheduling | Calendly, Cal.com | Never (at early stage) |
| Analytics | Plausible, Google Analytics | Only if analytics IS your product |
| Customer support | Intercom, Crisp, email | Never (at early stage) |
| Project management | Notion, Linear, Trello | Never (at early stage) |
| Invoicing | Stripe, FreshBooks | Never (at early stage) |
| Form/survey | Tally, Typeform | Never (at early stage) |
Notice how many items say “never at early stage.” That’s not lazy — it’s strategic. Every hour spent building infrastructure is an hour stolen from building your product. And your product is the only thing that generates revenue.
When Building Is the Right Call
Let me be fair to the “build” side. There are legitimate reasons to build custom tools.
Reason 1: Your product requires a unique capability.
If your product needs to do something no existing tool supports — a specific data processing pipeline, a unique user interaction pattern, a novel integration — you need to build that specific capability. But build only that capability. Use off-the-shelf tools for everything around it.
Reason 2: Tool costs exceed custom development costs at your scale.
Some tools become expensive at scale. If you’re sending 100,000 emails a month, a custom email sender might be cheaper than Mailchimp’s Enterprise tier. But this calculation only makes sense at significant scale — rarely relevant for early-stage businesses.
Reason 3: Data privacy requirements.
If you’re handling sensitive data (healthcare, finance) and existing tools don’t meet your compliance requirements, custom development may be necessary. Verify this with a lawyer, not with assumptions — most major tools have compliance certifications.
Reason 4: The tool becomes part of your competitive advantage.
If your customer acquisition process is so unique and effective that it’s a competitive moat, building custom tools to support that process might be justified. But be honest about whether it’s truly unique or whether you just think it is because you haven’t looked at existing solutions hard enough.
In all four cases, the “build” decision should be made reluctantly, with clear justification, and with a plan for long-term maintenance. Building should be a last resort for non-core tools, not the default.
The Tool Audit: Cleaning Up What You Have
Most founders over-tool just as easily as they over-build. They sign up for tools, use them for a week, and forget about them while the subscription keeps charging.
Every quarter, I run a tool audit:
- List every tool you pay for (check your credit card statements)
- For each tool, answer: “Did I use this in the last 30 days?”
- If no, cancel it
- If yes, ask: “Could I do this with a tool I’m already using?”
- If yes, consolidate
I typically find 2-3 tools per quarter that I’m paying for but not using. The financial savings are modest (€20-50/month usually), but the cognitive savings of having fewer tools to manage are significant.
The goal is the minimum effective toolset — the fewest tools that cover all your real needs. Like subtracting features from a product, subtracting tools from your stack makes everything simpler and more manageable.
Key Takeaways
- If it’s not your core product, buy it. Building infrastructure that isn’t your product wastes time that should go to the thing customers pay for.
- A tool that covers 70% of your needs is good enough. Workaround the remaining 30% manually. Don’t build custom to cover edge cases.
- Calculate the full cost of building: development time (× 3 for underestimation), ongoing maintenance (20-30% per year), opportunity cost, and decision fatigue.
- Build custom tools only when your product requires unique capabilities, tool costs exceed development costs at scale, compliance demands it, or it’s a genuine competitive advantage.
- Audit your tool stack quarterly. Cancel what you’re not using. Consolidate where possible. Aim for the minimum effective toolset.
