Let me state the conclusion first. Before you think about "in-house or outsource," always knock out "should we build it at all (won't SaaS suffice)" first. The most expensive mistake is going out of your way to develop from zero a business function that off-the-shelf SaaS can solve. On top of that, the in-house vs outsource call is made not by gut feel but on the four axes: "core of differentiation, change frequency, specialization, and TCO." This article is a framework for SMB and startup decision-makers to come to be able to make this whole series of calls with their own heads.
This article is the decision-making installment of the complete guide to commissioning system development. For cost details, see the article on market rates and estimates.
1. The first branch: build or buy (SaaS vs scratch)
The first gate of the decision is here. Don't get the order wrong.
Is this feature the core of the business's differentiation?
├─ No → solve it with SaaS / off-the-shelf first
│ (don't build accounting, attendance, CRM, MA, chat, reservations, etc.)
└─ Yes → can off-the-shelf products meet the requirements?
├─ Can → adopt SaaS, and extend/integrate only the missing parts
└─ Cannot → scratch (or the hybrid below)
* when there are complex industry-specific flows or unique business constraints
Scratch development is justified only when it satisfies both of the following two conditions.
- It is the core of the business's differentiation (the part that creates the gap with competitors — your business itself).
- There are business constraints that off-the-shelf products can't express (complex commercial flows, industry-specific logic, a unique data model).
The B2B SaaS for lumber distribution I worked on was the archetype. The multi-stage commercial flow of "forestry → market → sawmill → precut → builder → manufacturer," permissions that differ by industry role, cross-company transactions, and tenant separation — these can't be expressed by off-the-shelf groupware or e-commerce, so scratch was justified. On the other hand, building "the same for every company" operations like accounting or attendance from scratch is almost always a mistake.
How to spot a trustworthy partner: a counterpart who answers "we can build it" no matter what you ask is dangerous. An excellent developer is someone who can propose not building: "that requirement is met by off-the-shelf SaaS. The only part you should build is this." That's a proposal to reduce the order amount themselves, and a sign of long-term trust.
2. The realistic answer is "hybrid" — not build-everything / buy-everything
"SaaS vs scratch" is not an either/or. Many production-quality systems are hybrid. That is,
- Use off-the-shelf foundations to the maximum — auth (Cognito / Auth0 / Clerk), payments (Stripe), email, storage, monitoring. Building these yourself is reinventing the wheel and a security risk too.
- Limit what you build yourself to industry-specific logic only — the part that becomes the core of differentiation, your business itself.
When I built the subscription learning platform for financial-literacy education, this was exactly it. While leaning card payments on Stripe, I implemented the recurring billing by bank transfer that doesn't fit on Stripe (payment deadlines, grace periods, dunning, automatic expiry) as my own state machine matched to the business requirements. Furthermore, the pure function that decisively resolves six billing systems — direct sales, agencies, NFT perks, and external migration — is a core of differentiation that off-the-shelf products absolutely cannot express, so I concentrate development resources here.
Not "build everything" nor "buy everything," but build only the parts worth building. This is the realistic answer that reconciles cost and quality.
3. The second branch: the four axes that decide in-house vs outsource
After you've decided to "build," do you build it in-house or outsource it externally? Judge this on four axes.
| Evaluation axis | In-house favored | Outsource favored |
|---|---|---|
| Core of differentiation? | A core of the business; want to accumulate know-how in-house | Peripheral features, a one-time build |
| Change frequency | Keeps changing frequently (continually grown) | Stable for a while once built |
| Specialization | The relevant skill is in-house / you want to grow it | High specialization needed temporarily |
| TCO (total cost of ownership) | Used long-term, can hire and retain | Want to launch fast and cheap, don't want fixed costs |
Roughly speaking, "a business core that changes frequently and is grown over the long term" leans in-house. "Something where specialization is needed temporarily and you want to launch fast" leans outsource.
But there's a serious reality for SMBs and startups — they can't hire or retain engineers in the first place. In-house carries "hiring cost, labor cost, key-person risk from departures, and management effort." Hiring one engineer as a full-time employee is a fixed cost of several million to over ten million yen a year. If you can't keep paying it, in-house is not an option.
The reality of the decision: for many SMBs, the first right answer is staged in-housing: "first confirm whether SaaS suffices, outsource only the missing differentiating part (or run it end-to-end with one-person × generative AI), and once the business grows and the core features solidify, gradually move to in-house." Full in-house from the start is almost always too early.
4. A third option when you want to build "fast, cheap, no fixed cost"
Traditionally, the outsourcing options were "commission a big SIer at scale" or "commission a multi-person contracting firm." To that has been added a third option: one person (a small team) × generative AI, one-stop from requirements definition through infrastructure and operations.
This is a position that can aim for the "best of both" in-house and outsource.
| Aspect | Big SIer outsource | One person × generative AI | In-house |
|---|---|---|---|
| Launch speed | Slow (lots of coordination) | Fast | Depends on hiring (slow) |
| Cost | High (margins) | Low | Heavy fixed costs |
| Distance to decision-maker | Far (many layers) | Close (direct dialogue) | Close |
| Flexibility (spec changes) | Low (bound by contract) | High | High |
| Large-scale, many-person coordination | Strong | Unsuited | Depends on scale |
One person × generative AI suits new ventures, MVPs, and business systems where speed and cost matter, in cases where you want to turn requirements quickly in direct dialogue with the decision-maker. Conversely, if ultra-large-scale and coordination among many stakeholders is a premise, a big organization's structure fits. "Fast, cheap, flexible" and "a large-scale organization" are a trade-off, and a counterpart who can say so honestly is exactly the one you can trust.
5. Common decision mistakes and how to avoid them
Here are decision mistakes I see repeatedly in the field.
| Common mistake | Why it's wrong | The correct call |
|---|---|---|
| Build everything from scratch | Building even operations that off-the-shelf covers swells cost and maintenance burden | Build only the core of differentiation |
| Settle everything with SaaS | Forcing even the core of differentiation onto off-the-shelf homogenizes you with competitors | Build the core thoroughly via hybrid |
| Too-early in-housing | Takes on hiring/retention cost and key-person risk | Staged in-housing (outsource / one-person × AI first) |
| Choose a vendor on cheapness alone | Non-functional requirements and quality fall out, breaking down in operations | Choose on technical strength × track record and quality gates |
| Neglecting vendor lock-in | Bound to a specific SaaS/language, migration cost jumps | Leave an escape route via standard tech and abstraction boundaries |
The last one, vendor lock-in, is especially overlooked. In implementation too, I localize dependence on a specific vendor by, for example, placing an AI inference engine or a speech-synthesis provider behind the abstraction boundary of "interface → provider → factory," making it swappable with just an environment variable. This is a design decision of ETC (Easy To Change) — "leaving future options open."
FAQ
Q. In-house or outsource — which should I choose?
If it's a core of the business's differentiation that keeps changing frequently and is grown over the long term, lean in-house. If specialization is needed temporarily and you want to launch fast and cheap, lean outsource. But for SMBs and startups, since the cost of hiring and retaining engineers is heavy, it's realistic to launch with outsourcing (or one-person × generative AI) first, and gradually move to in-house once the core features solidify.
Q. How do I tell whether SaaS suffices or I should build from scratch?
Judge on two points: "is it a core of the business's differentiation" and "can off-the-shelf products express the business requirements." General operations like accounting, attendance, and CRM → SaaS; complex industry-specific commercial flows and unique logic → scratch. In many cases the answer is hybrid — using off-the-shelf foundations (auth, payments, etc.) and building only the core of differentiation yourself is optimal.
Q. Wouldn't building everything from scratch be good, since it gives high freedom?
Freedom goes up, but cost and maintenance burden swell. Implementing auth or payments yourself is reinventing the wheel and increases security risk too. Using off-the-shelf for the parts they can solve and concentrating development resources on the core of differentiation lets you build something better, faster, and cheaper in the end.
Q. How does outsourcing to a single developer compare to in-house and big-firm outsourcing?
It's favorable on launch speed, cost, distance to the decision-maker, and flexibility for spec changes. On the other hand, it's unsuited to ultra-large-scale projects needing coordination among many stakeholders. It's the optimal option for new ventures, MVPs, and business systems where speed and cost matter and you want to proceed quickly in direct dialogue.
Summary: don't get the order of the decision wrong
Make the in-house / outsource / SaaS / scratch decision in the following order.
- First knock out "should we build it (won't SaaS suffice)" — avoid the most expensive mistake.
- Scratch only when it's "the core of differentiation" AND "off-the-shelf can't express it" — otherwise, off-the-shelf.
- The realistic answer is hybrid — use off-the-shelf foundations, and build yourself only the industry-specific logic.
- Judge in-house vs outsource on the four axes (core, change frequency, specialization, TCO) — avoid too-early in-housing.
- One person × generative AI is a third option that combines "the flexibility of outsourcing" with "dialogue close to in-house."
"I want to organize how we should decide in our case" — I welcome consultations like that. From drawing the line between what to build and what not to build, to the optimal structure, I design standing on the buyer's side.