Early in my consulting career, I watched a founder spend four months building a custom CRM system. Four months. His reasoning: “Existing CRMs don’t do exactly what we need.” He was right — they didn’t do exactly what he needed. They did 90% of what he needed, and the missing 10% could have been solved with a workaround or a simple integration.
Those four months cost him his first-mover advantage, a significant portion of his runway, and the opportunity to spend that time on activities that actually generated revenue. He built something he could have bought.
The build-vs-buy-vs-borrow decision is one you’ll face repeatedly as a founder. Getting it right saves you time and money. Getting it wrong wastes both. Here’s the matrix I use.
The Three Options Defined
Build: Create it yourself from scratch. Custom code, custom design, custom everything. Maximum control, maximum time investment.
Buy: Purchase an existing solution (software subscription, hiring a specialist, purchasing a tool). Less control, much faster implementation.
Borrow: Use someone else’s infrastructure or solution temporarily. Free trials, partnerships, open-source tools, leveraging a platform’s built-in features. Least control, lowest cost.
Most founders default to building because it feels like progress. The most successful founders I’ve worked with default to borrowing or buying, and only build when neither alternative works.
The Decision Matrix
For any capability your business needs, evaluate it on two dimensions:
Dimension 1: Is This Your Core Differentiator?
Does this capability directly create the unique value that makes customers choose you over alternatives?
If yes: This is a candidate for building. Your core differentiator should be under your control, tailored to your specific approach, and difficult for competitors to replicate.
If no: This is a candidate for buying or borrowing. Non-differentiating capabilities (email, payments, hosting, accounting, project management, CRM) should be handled by the best available tool, not built from scratch.
At Vulpine Creations, our core differentiator was product design and instructional quality. We built those capabilities in-house. Everything else — e-commerce, shipping, email marketing, customer management — we bought or borrowed. Nobody purchased our products because we had a custom-built shopping cart. They purchased because the products were excellent.
Dimension 2: How Complex Is It to Build?
Low complexity (days to build): Building might make sense if it’s closely connected to your core workflow and no existing tool fits your specific need.
Medium complexity (weeks to build): Buy unless this is your core differentiator. Weeks of development is a significant opportunity cost.
High complexity (months to build): Buy or borrow unless this IS your product. Building a CRM, a payment system, or an analytics platform from scratch is almost never justified for a business whose product is something else.
The Matrix in Practice
| Capability | Core Differentiator? | Complexity | Decision |
|---|---|---|---|
| Product design | Yes | Medium | BUILD |
| E-commerce platform | No | High | BUY (Shopify) |
| Email marketing | No | High | BUY (ConvertKit) |
| Customer onboarding | Maybe | Low | BUILD simple version |
| Accounting | No | High | BUY (QuickBooks) |
| Content creation | Yes | Low | BUILD |
| Payment processing | No | High | BUY (Stripe) |
| Analytics | No | Medium | BORROW (free tools) |
Notice the pattern: for most businesses, only 1-2 capabilities should be built. Everything else should be bought or borrowed. The founders who understand this move faster because they’re spending their building energy on the things that actually matter.
When to Build
Build when all three conditions are true:
- It’s your core differentiator. The thing that makes you uniquely valuable.
- No existing tool does it well enough. You’ve genuinely looked and the alternatives fall meaningfully short.
- You have the capability to build and maintain it. Building is not a one-time cost. It’s an ongoing commitment to maintenance, updates, and improvements.
If any of these conditions is false, default to buy or borrow.
One common trap: founders build because they enjoy building. Building is fun. It feels productive. It’s the comfortable zone for technical founders. But building non-differentiating capabilities is the business equivalent of rearranging furniture when you should be selling the house. It feels like work, but it doesn’t advance the business.
When to Buy
Buy when:
- A reliable tool exists that does 80%+ of what you need. Perfect is the enemy of good. An 80% solution available today beats a 100% solution available in three months.
- The cost is justified by the time saved. If a EUR 50/month tool saves you 10 hours per month of work, and your time is worth more than EUR 5/hour (it is), buying is the rational choice.
- The tool is maintained by someone else. This is the hidden value of buying. Security updates, bug fixes, feature improvements — someone else handles all of it. Your time stays focused on your core business.
The mental shift required: stop thinking of software subscriptions as expenses and start thinking of them as time-purchasing instruments. Every tool you buy returns hours you can spend on revenue-generating activities.
When to Borrow
Borrow when:
- You’re in the validation phase. Before you’ve confirmed demand, don’t invest in permanent tools. Use free tiers, trials, and open-source alternatives. You can upgrade when the business warrants it.
- A platform provides the capability natively. Shopify includes payment processing. WordPress includes content management. Don’t build or buy what’s already included in your existing tools.
- The capability is temporary. If you need something for a specific project or period, borrowing (free trials, temporary partnerships, platform features) makes more sense than permanent investment.
Borrowing is the default for early-stage businesses. Your no-code toolkit should be assembled primarily from borrowed and bought components, with building reserved for the one or two things that make you unique.
The Integration Question
One legitimate reason to build is when existing tools don’t integrate well with each other, creating friction in your workflow. But before building a custom integration, check:
- Does Zapier or Make connect these tools? (Usually yes)
- Does one of the tools have a native integration with the other? (Often yes)
- Can you restructure your workflow to avoid the integration need? (Sometimes yes)
Only build custom integrations after exhausting these alternatives. Integration code is the most maintenance-heavy type of code you can write, because it breaks whenever either connected tool updates.
The Revisit Schedule
The build-vs-buy-vs-borrow decision isn’t permanent. Revisit it quarterly:
- Things you’re building: Should you switch to a bought solution? Has a tool emerged that does what your custom solution does?
- Things you’re buying: Is the tool still the best option? Are you paying for features you don’t use?
- Things you’re borrowing: Have you outgrown the free tier? Is it time to upgrade to a paid tool or build a custom solution?
This review takes 30 minutes quarterly and can save you thousands of euros in unnecessary development time and tool subscriptions.
Takeaways
- Default to borrow or buy. Only build your core differentiator. For most businesses, 1-2 things should be built from scratch. Everything else should be someone else’s problem.
- An 80% solution today beats a 100% solution in three months. Time is your most valuable resource. Don’t spend it building what you can buy.
- Think of tool subscriptions as time purchases. A EUR 50/month tool that saves 10 hours/month is the best deal in business.
- Use the two-dimension matrix. Core differentiator + complexity. Only build when it’s both high-differentiator and within your capability to maintain.
- Revisit quarterly. The right decision changes as your business grows and as the tool ecosystem evolves.
