Every founder eventually faces the same set of decisions: should we build this feature or use an existing tool? Should we hire an engineer to do this or buy a software subscription? Should we build our own CRM or use HubSpot?
These are not just product decisions. They are resource allocation decisions with compound effects. The wrong call made repeatedly in the first year can eat your budget, slow your team, or lock you into a technical approach you cannot afford to change.
Here is a framework that makes these decisions systematic.
The core question: competitive advantage
The primary filter for build vs. buy is whether the capability in question is a source of competitive advantage.
If yes, you should almost always build. If no, you should almost always buy.
A project management company should build its own project management features. It should not build its own email infrastructure. A company whose competitive advantage is a proprietary AI model should build that model. It should not build its own video conferencing tool for customer calls.
This sounds obvious. But founders routinely build things that are not differentiators because building feels productive and buying feels like giving up control.
When to buy (use a tool or SaaS subscription)
Use an existing tool when:
The problem is solved. Email sending, payment processing, analytics, video calls, document signing: these are solved problems with excellent tools. Building your own version does not make your product better. It makes your team smaller for the same output.
The build cost is high relative to the subscription cost. Building a payment processing system costs $200,000+ and takes six months to make production-ready. Stripe costs 2.9% plus 30 cents per transaction. There is no scenario where building makes sense.
The maintenance burden would be ongoing. Every piece of software you build is software you have to maintain. Every dependency, every integration, every custom component requires ongoing attention. Tools you buy are maintained by the vendor.
Speed matters more than perfect fit. Getting something working in a week using an existing tool is often worth more than getting a perfect custom version working in two months.
When to build
Build custom software when:
The capability is your core product. If you are selling project management software, the project management features are your product. You build those, no matter how good the existing tools are.
Existing tools cannot meet your requirements. Sometimes the specific combination of features, data model, or integration requirements cannot be achieved with existing tools without more customisation than a fresh build would require.
You have proven the need with a manual or off-the-shelf solution first. The best time to build a custom version of something is after you have proven that the manual or tool-based version has specific, consistent limitations. This is the opposite of what most founders do.
The economics make sense at scale. Some tools become expensive at scale. If your current tool costs $5,000 per month at your current volume and would cost $50,000 per month at your target volume, building may make sense. But run the numbers carefully.
The hiring vs. tools version of this decision
The same framework applies when deciding whether to hire someone or buy a tool to solve a problem.
Hire when:
- The task requires ongoing judgment and adaptation that software cannot provide
- The work is complex enough that a person can do it better than any available tool
- The role is strategic enough that you need a thinking human, not a workflow
- You are building a capability that will compound over time (customer relationships, brand voice, technical depth)
Use a tool when:
- The task is repetitive and rule-based
- A good tool exists that covers 90% of your use cases
- The volume of work does not justify a full-time person yet
- The capability is not a long-term competitive advantage
A common mistake: hiring a developer to maintain infrastructure that could be handled by managed services (AWS, Vercel, Supabase). Another: hiring a social media manager when a scheduling tool and two hours of your own time would achieve similar results at this stage.
The staffing middle ground: augmentation
Between "hire a full-time employee" and "use a tool" is a third option that founders often overlook: staff augmentation. This means bringing in skilled people on a flexible basis, without the overhead of full-time employment.
Staff augmentation works particularly well when:
- You need a specific skill for a defined period
- The work is project-based with a clear start and end
- You need to scale capacity quickly without the delay of a hiring process
- Budget is constrained and a full-time salary is not justifiable yet
An offshore staff augmentation model can give you senior-level skills at half the local market cost, making the build-vs-tool maths different than it would be with expensive local hires.
A decision hierarchy
When facing a new capability need, work through this in order:
- Does an excellent existing tool solve this problem at acceptable cost? If yes, use it.
- Can this be done manually by an existing team member for the first three to six months? If yes, do that and learn before building.
- Does this capability constitute a competitive advantage or core product feature? If yes, build it.
- Is the build a one-time investment or ongoing maintenance burden? Account for the total cost of ownership, not just the initial build.
- Can this be delivered by a short-term augmented team rather than a full-time hire? If yes, start there.
The most expensive decisions
The decisions that cost founders the most are usually:
Building infrastructure prematurely. Custom authentication systems, custom databases, custom DevOps pipelines in the early stages are almost always waste. Managed services exist for these things.
Hiring people before proving the need. Hiring a head of marketing before you have a product worth marketing. Hiring a customer success team before you have customers.
Over-engineering the first version. The architecture that can handle 10 million users costs significantly more than the architecture that can handle 10,000. If you have zero customers, build for 10,000.
Our custom software development team works with founders to scope the right build for the right stage. Before you decide what to build and what to buy, get an honest assessment of what makes sense for where you are now.