Build vs Buy
Two Expensive Mistakes
A logistics company spent three months building a custom shipment tracking dashboard. Their operations director led the project, working with an AI coding assistant to create exactly what they needed. The tool tracked their specific metrics, integrated with their unique processes, and displayed information the way their team wanted.
Six weeks after launch, someone discovered that their existing logistics software had a dashboard feature that did 90% of what they’d built. It had been there all along—just unused. The custom build wasn’t wasted, but it had been unnecessary. They could have spent those three months on something else.
Across town, a consulting firm bought an expensive project management platform. All their competitors used it, so it seemed like the safe choice. Two years later, they’d implemented perhaps 15% of the features. Their actual workflow didn’t match the tool’s assumptions. They spent more time working around the software than working with it. The license fees accumulated while the frustration grew.
Both organizations made build vs buy mistakes—in opposite directions. The logistics company built when buying would have worked. The consulting firm bought when building (or buying something simpler) would have fit better.
Now that you’ve learned to build with vibe coding, you need a framework for deciding when building makes sense and when buying is the better choice. This chapter provides that framework.
The Real Question
The question isn’t “Can I build this?” With AI assistance, you can build far more than you could before. The question is “Should I build this?”
The Default Should Be Buy
Commercial software represents years of development, testing, and refinement. Professional teams have solved problems you’ll encounter. They’ve handled security concerns, edge cases, and scaling issues. They provide support documentation and ongoing updates.
For most common needs, someone has already built a good solution. Reinventing that work through vibe coding wastes your time and produces inferior results. If a $50/month subscription solves your problem, that’s almost certainly better than spending twenty hours building something yourself.
The exception is when your needs don’t match what exists. When commercial tools assume workflows you don’t follow, require features you don’t need, or miss capabilities you require—then building becomes attractive.
The Case for Building
Building makes sense when:
Your requirements are genuinely specific. Not “I want it my way” but “commercial tools literally don’t do what I need.” If 80% of a commercial tool’s features don’t apply to your use case, you’re paying for complexity you don’t benefit from.
The scale doesn’t justify commercial pricing. Enterprise tools are priced for enterprise use. If you need something simple for yourself or a small team, commercial pricing may not make sense. Your time building has value, but so does your budget.
You need integration that isn’t supported. Commercial tools integrate with popular services. If your workflow involves less common tools or internal systems, commercial options may not connect.
You’re building capability, not just tools. Sometimes the learning from building matters as much as the tool itself. Building teaches you what’s possible, and that knowledge improves your technology decisions.
The Decision Matrix
Three factors determine whether to build or buy: requirement specificity, scale and criticality, and maintenance burden.
Requirement Specificity
How closely do your needs match what commercial tools offer?
Generic needs favor buying. If your requirements sound like what most people need—CRM, project management, email marketing—commercial tools have been optimized for exactly these use cases. You benefit from their investment in solving common problems.
Specific needs favor building. If you find yourself saying “I only need this one part” or “I need it to work differently,” your requirements may be too specific for general-purpose tools. Building gives you exactly what you need without the overhead of features you’ll never use.
How specific is “specific”? If you’d ignore more than 70-80% of a commercial tool’s features, your needs are probably specific enough to consider building. If you’d use 50% or more, buying likely makes sense even if the fit isn’t perfect.
Scale and Criticality
How many people will use this, and how important is reliability?
High scale, mission-critical systems favor buying. When many people depend on a tool and downtime has significant consequences, professional development and support matter. Vibe-coded tools are appropriate for personal use, not production systems.
Low scale, personal or small team use favors building. When you’re the primary user, rough edges are acceptable. You understand the tool’s limitations because you built it. Reliability requirements are lower because impact of failure is limited.
The middle ground requires judgment. A tool used by your team of five falls between these extremes. Consider: What happens when it breaks? How quickly must it be fixed? Can you handle that responsibility?
Maintenance Burden
How much ongoing attention will this require?
Stable requirements favor building. If what you need today is what you’ll need in two years, a vibe-coded solution can work indefinitely with minimal maintenance. Build it, verify it works, use it.
Evolving requirements favor buying. Commercial tools update to handle new standards, changed regulations, and shifting best practices. If your domain changes frequently, letting commercial vendors handle that evolution saves you maintenance burden.
External integrations favor buying. When your tool connects to external services via APIs, those APIs change. Commercial tools handle API updates as part of their service. With custom builds, you’re responsible for keeping up.
The Four Quadrants
Combining these factors:
Generic needs + High scale → Buy. Almost no exceptions. Let professionals build and maintain critical infrastructure.
Generic needs + Low scale → Buy. Unless there’s literally no free or cheap option, commercial tools will serve you better than building.
Specific needs + High scale → Build professionally. This isn’t vibe coding territory. Hire developers or engage professional services.
Specific needs + Low scale → Build (vibe coding sweet spot). Personal tools for specific needs are ideal vibe coding projects.
The Evaluation Process
Before deciding, gather information systematically.
Evaluating Build Feasibility
For any potential build project, assess:
Technical complexity. Does this require simple data manipulation, or does it need sophisticated algorithms? Vibe coding handles the former well but struggles with the latter.
Integration requirements. How many external systems must this connect to? Each integration adds complexity and ongoing maintenance burden.
Your available time. Building takes hours. Do you have those hours? Will you have maintenance time ongoing?
Your domain expertise. Can you verify correctness? If you can’t tell when the tool produces wrong results, you can’t build it safely.
Evaluating Buy Options
For any potential purchase, assess:
Feature fit. List your five most important requirements. Does the tool meet them without workarounds?
Pricing model. Is the pricing sustainable? What happens if pricing increases?
Integration capabilities. Does it connect to your other tools? How difficult is setup?
Exit strategy. If you need to leave, can you export your data? How difficult would switching be?
Spend an hour on this evaluation before committing. The hour is almost always worth it.
Hybrid Approaches
Build vs buy isn’t always either/or. Hybrid approaches often provide the best outcomes.
Buy the Platform, Build the Customization
Use commercial tools for core functionality. Build only the customizations that make them fit your needs.
Example: Use a standard CRM for contact management and deal tracking. Build a custom reporting tool that pulls CRM data and formats it for your specific needs. The CRM handles the complex, critical functions. Your custom tool handles only the specific formatting you need.
This approach gets professional reliability for the important parts while allowing customization where it matters.
Build the Prototype, Buy the Production
Use vibe coding to prove a concept works. Once you understand what you actually need, evaluate whether commercial tools can provide it.
Example: Build a simple dashboard to track the metrics you think matter. Use it for a few months. Discover which metrics you actually look at. Then evaluate BI tools with clear requirements instead of guessing what you need.
Building first clarifies requirements that would otherwise be unclear. That clarity leads to better buying decisions.
Build the Glue
Use commercial tools for each distinct capability. Build only the integration layer that connects them.
Example: Use separate tools for email, scheduling, and task management. Build a simple automation that connects them—when certain emails arrive, create tasks and block calendar time.
This limits custom code to connections while leveraging commercial tools for the complex work.
Choosing Your Hybrid Strategy
The best hybrid approach depends on your situation:
If commercial tools mostly fit but miss specific needs, buy the platform and build customizations. Most of the work is done for you.
If you’re uncertain what you need, build a prototype first. Learning from actual use clarifies requirements for better buying decisions.
If you need multiple specialized tools, buy each tool and build the connections. Integration is simpler than replicating core functionality.
Decision Triggers
Build vs buy isn’t a permanent decision. Circumstances change, and so should your choices.
Triggers to Reconsider Building
Your built tool may need to become a bought tool when:
- Maintenance burden exceeds 2-3 hours weekly
- Security or reliability concerns emerge that you can’t address
- The tool needs to expand beyond you or your small team
- Requirements have evolved significantly from original design
Don’t let sunk cost fallacy trap you in a build decision that no longer makes sense.
Triggers to Reconsider Buying
Your bought tool may need to become a built (or different bought) tool when:
- You consistently use less than 30% of features
- Time fighting the tool exceeds time using it productively
- Workarounds outnumber straightforward uses
- Pricing has increased without proportional value increase
Don’t let familiarity trap you in a buy decision that no longer serves you.
The Annual Review
Every tool—built or bought—deserves periodic review. What made sense two years ago may not make sense now. Your needs changed. The market changed. Your skills changed.
Schedule an annual “tool audit.” For each significant tool: Is this still the right approach? Have alternatives emerged? Has maintenance burden grown unacceptable? Has value delivered declined?
Learning From Mistakes
Both build and buy decisions can go wrong. Learning from mistakes prevents repeat errors.
When Build Decisions Fail
Common patterns in failed build projects:
Scope grew beyond original vision. What started as a simple tool accumulated features until maintenance became unsustainable. The fix: Define clear boundaries before starting and resist expansion.
The builder left without documentation. The person who understood the tool moved on. No one else could maintain it. The fix: Document as you build, even for personal tools. Future you will thank present you.
Requirements evolved faster than the tool. The problem the tool solved changed, but updating the tool couldn’t keep pace. The fix: Recognize when requirements are too dynamic for custom builds.
When Buy Decisions Fail
Common patterns in failed buy decisions:
Chose based on features, not fit. The tool had impressive capabilities that turned out to be irrelevant. The actual workflow didn’t match. The fix: Evaluate fit to your specific workflow, not feature count.
Assumed integration would work. The sales materials promised seamless integration. Reality was much harder. The fix: Test integrations before committing, not after.
Ignored total cost. Subscription seemed affordable until training, customization, and workaround time were added. The fix: Calculate true cost, not just license fees.
Learning from these patterns—whether from your own experience or others’—improves future decisions.
Common Objections
“But I already built it—switching would waste that investment.”
Sunk cost fallacy. The time spent building is gone regardless of what you do next. The relevant question is: what’s the best path forward? If buying now would serve you better, the previous build doesn’t change that calculation.
“The commercial tool is too expensive.”
Compare honestly. Your time has value. If building takes twenty hours and your time is worth $100/hour, that’s $2,000—plus ongoing maintenance. A $100/month subscription may actually be cheaper.
“I don’t have time to evaluate commercial options.”
Evaluation time is an investment. Spending two hours evaluating tools could save twenty hours of building. Or the evaluation might confirm that building is the right choice—but with confidence rather than assumption.
“My needs are unique—no commercial tool does what I need.”
This is sometimes true and often an assumption. Before building, spend an hour searching. You might find tools you didn’t know existed. You might find that your needs are less unique than you thought.
“I want full control over my data and tools.”
Valid concern, but consider the trade-off. Full control comes with full responsibility—for security, for backups, for updates. Commercial tools handle these burdens. The control you gain must be worth the responsibility you accept.
Your Monday Morning Action Item
This week, audit one tool in your workflow:
Step 1: Choose a tool. Pick something you use regularly—built or bought.
Step 2: Calculate true cost. For built tools: estimate hours spent on maintenance. For bought tools: add license cost, learning time, and workaround time.
Step 3: Evaluate fit. For built tools: is maintenance sustainable? For bought tools: what percentage of features do you actually use?
Step 4: Consider alternatives. Spend fifteen minutes searching for alternatives you might not know about.
Step 5: Make a decision. Is the current approach still right? Should you consider switching?
This simple audit, repeated periodically, prevents both build and buy decisions from calcifying into habits that no longer serve you. The goal isn’t perfection—it’s conscious choice rather than default continuation. Every tool should earn its place in your workflow, whether you built it yourself or purchased it from someone else.