When to build custom software instead of buying

Buy by default. Build only when the workflow itself is the differentiator, or when every off-the-shelf tool forces a shape your team cannot live with. And when you do build, build one slice rather than a platform.

Buy when the job is standard

Invoicing, email, CRM for a simple pipeline, authentication as a commodity. Paying a vendor is cheaper than owning the failure modes. Custom software here is usually a vanity rewrite.

The test is whether a customer would ever notice. Nobody chose you because of how your invoices are generated. If the job is identical at ten thousand other companies, someone has already built it better than a two-week sprint will.

Buying is also the right answer when the requirement is still moving. A subscription you can cancel is a cheap way to learn what you actually need. Several of the best build decisions start as a year on a tool that taught you exactly which part does not fit.

Build when the workflow is the product

If customers pay you because of how approvals, data, or operations run, that path should not sit in five tools glued with Zapier and a spreadsheet. You will spend the rest of the year teaching people a workaround.

An owned system is worth it when:

• The objects are yours (jobs, lots, mandates, properties, research sessions)
• More than one role has to act on the same record
• Reporting has to be true, not exported
• You need to keep the data when a vendor raises prices or shuts a plan

Xntral is what that looks like in practice. Users, patients, locations and functions are the operation's own records, and recurring scheduling runs against them. Generic scheduling software can hold appointments, but it will not hold those records with those relationships, which is the part the business actually runs on.

Adey Studio is the other version of the same reasoning. Creative teams already own tools for storage, generation and review, and Adey integrates with eight of them rather than replacing them. What was missing was the connective workflow across the gaps, so that is what got built.

Signs you have outgrown the tool

Buy-versus-build rarely arrives as a strategic question. It arrives as symptoms:

• A spreadsheet has become the real system of record, and the tool is where you retype it
• Onboarding a new team member requires explaining a workaround before the work
• Two people have different numbers for the same question, and both are technically right
• The automation between tools breaks quietly, and someone checks it manually every morning
• You are paying per seat for people who use one screen
• The answer to "can we change that?" is permanently no

One symptom means live with it. Three or four in the same workflow means the tool is now a tax.

Count the real cost of both options

Compare honestly, and include the parts that are easy to leave out.

Buying costs the subscription, the per-seat growth as you hire, the integration work to connect it to everything else, the manual steps nobody logs, and the migration you will eventually pay for anyway.

Building costs the sprint, the hosting, and the maintenance you own from day one. That last item is real. Custom software needs someone who can change it. If nobody in the business can, or nobody is retained to, you have swapped a subscription for a liability.

Most decisions are less about total cost than about which cost you would rather own.

Build a slice, not a platform

Custom does not mean large. It means specific. A 14-day sprint can replace the painful middle of a process and still leave Stripe and Gmail where they are.

That is usually the right first move: build the one step no vendor does well, and keep buying the boring surroundings. A build that starts by replacing your email, your payments and your CRM has already lost the plot.

If you cannot name the slice, you are not ready to build. You are ready for another discovery pass. How to scope a first SaaS system in 14 days is the method for naming it.

Ownership is the exit

The point of custom is not "we use TypeScript". It is that you can run, extend and host the thing without a licence sitting between you and your own records. If a build does not end in source, access and docs, you bought a different kind of subscription.

Ask for the specifics before the work starts:

• The repository lives under your account
• The hosting and database accounts are in your name, with your billing
• Environment variables and third-party keys are documented and handed over
• A written note covers the data model and the parts most likely to change next

A quick decision test

Answer these about the workflow in question:

• Would a customer notice if this ran differently? If no, buy.
• Do the records belong to you rather than a vendor's schema? If yes, lean build.
• Do two or more roles touch the same record? If yes, lean build.
• Can you describe the slice in one sentence? If no, run discovery, not a build.
• Will someone own the code after handover? If no, buy.

If that lands on build, the shape of the work is a scoped sprint, either as custom software development or, when the users are your own team, internal tools and dashboards. If it lands on buy, you just saved a quarter.