The wrong decision compounds fast.
Kristina Golovko
MindDesign
The capability decision model
Ownership
Strategic, internal, long-term
Speed
External, fast, defined scope
Complexity
Requires judgment over time?
Cost
Total cost, not just salary
Every capability decision lives at the intersection of these four dimensions. The right answer changes with stage, context, and what the business is actually optimising for.
Why this matters
The default in most startups is to hire. It feels like ownership. It feels like commitment. But ownership isn't always what the situation requires — and commitment to the wrong structure is expensive.
Building in-house creates speed, control, and institutional knowledge — but it also creates fixed cost, management overhead, and long-term dependency. Outsourcing creates flexibility and access to expertise — but it creates distance, context gaps, and loss of institutional memory.
The right answer isn't philosophical. It's contextual. And it changes as the company changes.
Founder reality
Before deciding, answer these clearly:
Is this capability core to the product or to the business model — or is it supporting infrastructure?
Will this work require iterative judgment developed over 12+ months?
Is the scope defined enough to be handed to an external party with clear deliverables?
What happens if the external party gets this wrong — is the blast radius contained or critical?
Do you have the internal capacity to manage and review external work effectively?
Core, ambiguous, high-blast-radius work belongs in-house. Defined, specialist, time-bound work often doesn't.
The framework
Each path has a natural context. Choosing wrong compounds quickly — correction costs more than the original decision.
Build internally — when the capability is core and requires compounding knowledge
Internal builds are right when the work shapes the product, creates competitive advantage, or requires institutional understanding that only comes from proximity. The cost is time and overhead. The return is ownership and iteration speed.
Hire — when the work is persistent, strategic, and requires judgment over time
Hiring is right when you need ownership plus adaptability over time. A contractor delivers to a brief. An employee develops the judgment to rewrite the brief. When the scope will evolve and the stakes are high — hire.
Outsource — when the scope is defined, the expertise is specialised, and the timeline is bounded
Outsourcing is right for work where external expertise exists, the output can be clearly evaluated, and the engagement has a natural end point. Legal, design systems, data infrastructure, specific engineering capability — these often work well externally.
Don't decide yet — when clarity is missing on scope, ownership or importance
The most underrated option is to wait. Forcing a build/hire/outsource decision before you know what you actually need produces expensive corrections. Clarity is cheap. Reversing a bad structural decision is not.
Common mistakes
01
Outsourcing core product decisions
External teams can build to a spec. They cannot develop the product judgment that comes from customer proximity and iteration. Core product work outsourced too early creates structural dependency that's hard to reclaim.
02
Building what should be bought
Not every internal build creates competitive advantage. Sometimes you're just adding engineering debt to reinvent infrastructure that already exists off the shelf.
03
Hiring for scope that should be contracted
A 6-month project with a defined output is a contractor engagement. Hiring a full-time employee for it adds overhead and creates an awkward offboarding problem.
04
Switching paths without a transition plan
Moving from outsourced to in-house (or vice versa) without a knowledge transfer plan loses institutional context. The transition costs as much as the original decision if it's unmanaged.
Example scenario
A cybersecurity startup, 15 people, Series A. They need to build a customer-facing data analytics layer. The CEO is debating: build internally, hire a data team, or use an external analytics vendor.
The options on the table
Build: 3–4 months of engineering time, full control, but pulls focus from core product.
Hire: Long search, 6+ month ramp, but creates long-term internal capability.
Outsource: Specialist agency, fast delivery, but creates external dependency on a customer-facing feature.
What the framework revealed
The analytics layer was customer-facing but not core to the security product. It was better described as a reporting layer than a product differentiator. The scope was defined. The delivery timeline was bounded.
The decision
Outsourced to a specialist team with a clearly scoped brief. Delivered in 10 weeks. One internal engineer retained context. The core product team stayed focused. At month 12, when the analytics layer became more strategic, the decision was revisited with full clarity on what to bring in-house.
The decision isn't permanent — but it has costs.
Build, hire, and outsource aren't philosophies. They're tools. Use the one that fits the current stage, scope, and strategic importance of the work. And revisit the decision when the context changes.
Continue reading
Hiring for the Stage You're In →