In-house vs outsource, SaaS vs scratch: how SMBs and startups without a CTO should decide

Here is the answer up front. Decide how to set up your software work in this order:

1. Should we build at all? Could SaaS (a ready-made cloud service you pay for monthly) cover it?
2. If we build, how much can we take off the shelf? Leave things like authentication and payments to ready-made building blocks, and keep what you build yourself narrow (a hybrid).
3. Who builds it? In-house or outsourced. Decide on four axes: core of differentiation, rate of change, in-house expertise and total cost of ownership.
4. Who is accountable for the technical decisions? If you have no CTO (chief technology officer), one option is an external development lead. But some things must never leave the company.

Skip a step and it tends to cost you later. Two mistakes are especially likely to be expensive. One is building from zero something SaaS already does. The other is leaving the repository (where your source code lives) or your cloud account in the vendor's name, and later finding you cannot run your own system.

This article is written for sole proprietors, owners and executives of small and mid-sized companies, and the person put in charge of development at a company that has no CTO. I've written it so you can decide without reading code. The concrete settings for engineers are in a separate section marked "For engineers."

This article is the decision-making installment of the complete guide to commissioning system development. For how costs are estimated, see the article on market rates and estimates.

1. The first branch: build or buy (SaaS vs scratch)

This is the first gate. Before you consider building from scratch (with no off-the-shelf product underneath), check whether something ready-made already solves it.

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, marketing automation, chat, reservations, etc.)
└─ Yes → can an off-the-shelf product meet the requirements?
          ├─ Yes → adopt the SaaS, and extend/integrate only what's missing
          └─ No  → build it yourself (as the hybrid in the next section)

Building from scratch is justified only when both of these hold:

1. It is the core of your differentiation: the part that sets you apart from competitors, the business itself.
2. It has business constraints off-the-shelf products cannot express: a complex commercial flow, industry-specific rules, an unusual way of structuring the data.

A B2B SaaS for lumber distribution that won the METI Minister's Award (I handled it single-handed, from requirements through operations) was the textbook case. A commercial flow chaining many trades — "forestry → market → sawmill → precut → builder → manufacturer" — with different operations and visibility for each trade, plus transactions across companies and the data separation they need. These are all the kind of requirements that off-the-shelf groupware or e-commerce struggles to express, and this part was built from scratch. Building accounting or attendance from scratch, on the other hand — work that is much the same in every company — is almost always a mistake.

Even when you buy, check the contract terms before you choose. For example, whether you can get your own data out when you cancel (vendor lock-in, section 7) is worth confirming before you sign up. The "Model Transaction/Contract for Information Systems" published by Japan's IPA (独立行政法人情報処理推進機構) also includes, alongside the version for custom development, a separate version for using packages and cloud services such as SaaS (the Second Edition supplement).

How to spot a partner you can trust: be wary of anyone who answers "we can build that" to every question. A trustworthy developer can propose not building: "SaaS covers that requirement. This is the only part you should build." It is a proposal that shrinks their own order, which makes it a good signal of whether you can work with them for the long term.

2. The realistic answer is a hybrid — not build-everything or buy-everything

In my view, the realistic answer is usually a hybrid.

• Use ready-made building blocks as much as you can — authentication (Cognito / Auth0 / Clerk), payments (Stripe), email, storage, monitoring. Building these yourself reinvents the wheel and adds security risk.
• Build only the industry-specific logic yourself — the part that is the core of your differentiation, the business itself.

The subscription learning platform for financial-literacy education, which I joined as a core engineer on a team, took exactly this shape. Card payments went to Stripe, while recurring billing by bank transfer, handled outside Stripe (payment deadlines, grace periods, dunning, automatic expiry), was built by the team as its own mechanism matched to the business. Pricing — which mixes direct sales, agencies, NFT-holder perks and users migrating from an outside service — is decided by a single function from six kinds of qualifying input. Both are billing rules specific to this business.

Neither "build everything" nor "buy everything": build only the parts worth building. That is the realistic way to get both cost and quality.

3. The second branch: in-house or outsource — decide on four axes

Once you've decided to build, the next question is who builds it.

TCO (total cost of ownership) means the whole cost of running the system for as long as you use it: not only building it, but maintenance, infrastructure, fees for outside services, your own staff's time, and the cost of migrating away one day.

Decision table: the answer for common situations

The reality for SMBs and startups

In-house development carries ongoing fixed costs: recruiting, salaries, social insurance, training and management time. There is also key-person risk — parts of the system only the person who left understood. If you cannot expect to keep paying for all that, building everything in-house from day one is too early.

For many SMBs the right first answer is moving in-house in stages. First check whether SaaS is enough. Outsource only the differentiating part it cannot cover. Once the business grows and the core features settle, bring the work inside a little at a time.

Outsourcing has its own key-person risk, though. If only the vendor knows where the code lives and how things are configured, you face the same problem as when an employee leaves. That is why the fourth question matters: who is accountable for the technical decisions.

4. With no CTO: what you can hand to an external development lead, and what you must never let go

When a company with no CTO or development lead outsources, the same problems keep appearing: "we can't tell whether this quote is reasonable," "they explained the technology choice, but we can't judge it," and "if the person who built it leaves, nobody can touch it." An external development lead fills that gap. The titles vary — technical advisor, fractional CTO — but the role is the same: someone outside the company who takes on the technical decisions. A monthly technical advisor provides decisions and advice. A fractional CTO, in the sense used in this article, also takes on the hands-on development work, such as design, implementation and building the cloud environment.

Some things you can hand to an external development lead, and some must stay with the company.

Why decisions stay with the company

The Agile Development Edition of IPA's model contract calls the role responsible for a product's direction and content the product owner (PO). It has the user company appoint the PO and provide, in a timely way, the information and decisions the development team needs. The vendor, as the expert, advises on the backlog (the list of what is still to be built) and explains the product's technical risks.

Handing technical decisions to an external lead does not change that split. The external lead lays out the options and the reasons; the company decides what comes first, what it will pay, and what counts as done. Hand those over too, and an outsider ends up guessing what should be built — the root of "this isn't what we asked for."

Why account ownership stays with the company

Account ownership is the item most often overlooked, and the hardest to win back later.

• Repository: GitHub's documentation says organization owners have complete administrative access to the organization, and recommends keeping that role limited, but to no fewer than two people. People from outside can join as "outside collaborators," with access to only the repositories they need.
• Cloud: when you create an AWS account, it starts with a "root user" that has complete access to every resource in the account. AWS recommends using, for the root user, an email address managed by your business that forwards to a group of people — so that if AWS needs to reach the account owner, a reply is less likely to be delayed, even when individuals are on vacation, out sick, or have left the business.
• Copyright: under Japan's Copyright Act, the author is "the person who creates a work." For a program an employee writes in the course of their duties at the company's initiative, the company is the author unless a contract or work rules say otherwise (Article 15(2)). Work by an outside development firm or freelancer often falls outside that rule, so making it the company's means providing for a transfer of copyright in the contract (Article 61(1)). And if a transfer contract does not specifically mention the rights in Article 27 (rights of translation, adaptation, etc.) and Article 28 (the original author's rights in the use of a derivative work), those rights are presumed to remain with the party that transferred the copyright (Article 61(2)). For software you will keep modifying, that is not a detail to miss. Have a lawyer or other professional check the contract wording where needed.

Four things to require from any external development lead

Whoever you hire, confirm these four before you sign.

1. The repository and cloud are created in your company's name from day one. The outside person works with access you grant. When the engagement ends, you remove that access and recreate any keys they touched (API keys, passwords and the like).
2. Handover documents are part of the deliverables: a README, an architecture diagram, an environment-variable list and a runbook.
3. The infrastructure is managed as code (IaC). Defined in Terraform or similar, another engineer can rebuild the same environment.
4. The main business flows have automated tests and CI. With CI (a system that runs the tests automatically on every change), another engineer can change the code safely.

I do all four as standard. The repository and cloud are set up in the client's name from day one, and I work with collaborator access. Handover documents are a standard deliverable at no extra cost. An NDA can be signed before our first commercial discussion, and copyright in the deliverables belongs to the client as a rule. But the point here is not "hire me and you'll be safe." It is this: whoever you hire, make these four conditions, and your business is less likely to stall if that person disappears.

For engineers: concrete ownership and access settings

If anyone in the company has some technical background, ask them to check these settings.

• GitHub: create a company Organization with at least two Owners from inside the company. Give the external lead or vendor access as outside collaborators (or members), only to the repositories they need.
• If the repository sits in the vendor's personal account: transfer it to the company Organization. The person transferring needs administrator access to the repository and, in addition, permission to create repositories in the target Organization. If the vendor is an outside collaborator (someone who is not a member of the Organization), check before the transfer whether they have that permission; if not, prepare for it, for example by making them a member for the duration of the transfer and allowing them to create repositories (whether members may create repositories is an Organization setting). Issues, pull requests and the wiki move with it, and links to the old location redirect to the new one automatically. However, if a new repository or fork is later created at the old location, those redirects are permanently deleted.
• AWS: use a business-managed group address for the root user's email and set up MFA (multi-factor authentication). Don't use the root user for everyday work; create a separate administrative user. For everyone, outside people included, use IAM roles for a single account, or IAM Identity Center if you manage several accounts through AWS Organizations, and grant only the permissions needed through temporary credentials.
• Domains and outside services: hold the domain registration and the contracts for outside services — payments, email delivery, monitoring — in the company's name and under a company email address.

5. Which companies a single external development lead suits, and which it doesn't

Outside help broadly comes in three forms: a large systems integrator, a development company with a team, and a single external development lead. I offer the last, with this approach: build fast with AI, and keep a human accountable for production quality. I use generative AI for the speed of writing code, run automated tests, linting (automated checks on how code is written) and vulnerability scans in CI, and a human reviews the work and makes the call to ship it. You have one point of contact, and the work stays with you in a form another engineer can pick up.

"Employee salaries" means the fixed cost you carry every month by employing people. When you go outside, an ongoing contract, such as a monthly technical advisor, is still a fee you pay every month.

Companies it suits

• You have no engineers, or very few, and want to launch an MVP (a first product with the minimum features), a SaaS product or an internal business system
• The owner or business lead can talk directly and decide priorities on the spot
• You want help deciding what to build — and what not to build — from the start

Companies and projects it doesn't suit

• Large programmes spanning many departments or partner companies, where coordination itself is most of the work
• Systems that need a rota of people on call, including nights and weekends. My monthly technical advisory does not include standing by for incidents either
• Work that needs several development streams running in parallel, where headcount itself is the requirement
• Companies that cannot put someone in charge of priorities and acceptance criteria (the PO role). Handing everything over fails whoever you hire

The most common worry about relying on one person is "what if they become unavailable?" The answer is not a promise that someone else will step in. It is using the four conditions in section 4 to run the work in a state another engineer can pick up. What is in your company's name from day one is the repository and the cloud; handover documents, IaC, and automated tests with CI are conditions of delivery.

6. Start small: begin with advice on the decisions

You don't need a large contract to bring in an external development lead. Even if nobody can build, you can start with a small unit such as a PoC (a small trial that checks feasibility before full development). The prices are the same as on the pricing page (excluding tax).

Whether advice is enough or you need development too comes down to one question: does someone in the company (or a vendor you already have) build the software? If so, a technical advisor making the calls is enough. If not, commission work by deliverable — a PoC, an MVP, or a project — so the cost and the definition of done are clear. On fixed-scope work, defects found within 3 months of acceptance are fixed free of charge (contractual non-conformity liability).

The difference between a technical advisor and a fractional CTO, and how an engagement runs from first call to handover, is on the fractional CTO / external development lead page.

Taking over or rebuilding an existing system has no set price, because the cost depends heavily on the state of the code. What moves the estimate, and what to prepare so the quote comes back faster and more accurately, is covered in the article on preparing a handover.

The sensible first step is a spot consultation to look at the code and environment. Depending on the state of the code, a tech-debt assessment (3–5 business days) comes first. Then you decide between partial changes and a rebuild by comparing cost and risk.

7. Common decision mistakes and how to avoid them

A prototype built with AI is a legitimate starting point

With generative AI, an owner or a project lead can now build a working prototype themselves. A prototype is a legitimate starting point: it shows what you want more precisely than words do. But working is not the same as not breaking in production, and shipping the prototype as it is would be risky. In most cases you can reinforce (harden) the parts that tend to break instead of rebuilding, but whether to fix it, partly rebuild it or rebuild it is decided on signs you can check. The decision table is in the article on taking AI-generated code to production.

Compare total cost, not the up-front price

When you compare vendors or setups, look beyond the initial price: include maintenance, infrastructure, fees for outside services, your own staff's time, and the cost of migrating away one day. Some of these never appear on a quote.

Checklist: before you commission anything

• We checked whether SaaS or an off-the-shelf product already covers the feature
• We narrowed what we build ourselves to the core of our differentiation
• We decided in-house vs outsource on the four axes (core of differentiation, rate of change, expertise, TCO)
• We named someone inside the company to decide priorities, budget and acceptance criteria
• The repository, cloud and domain are in our company's name, with at least two owners inside the company
• Handover documents, IaC, and automated tests with CI are conditions of delivery
• We have a list of the access to remove and the keys to recreate when an outside person leaves
• The contract states who owns the copyright (including the Article 27 and 28 rights) and covers confidentiality
• We compared total cost, not the up-front price

Summary: get the order of decisions right

1. First, check whether you should build at all (does SaaS cover it?) — this avoids a mistake that is especially likely to be expensive.
2. Build from scratch only what is "the core of your differentiation" AND "inexpressible off the shelf" — the realistic answer is a hybrid.
3. Decide in-house vs outsource on the four axes — and avoid moving in-house too early.
4. With no CTO, you can hand the technical decisions to an external development lead — but keep business priorities, budget, the final call, and the ownership of and access to your accounts.
5. Start small — for advice, a spot consultation or a monthly advisor; if nobody can build, a PoC or MVP.