# Build vs buy for internal tools
> Build vs buy for internal tools is the decision between paying for software another company makes and writing your own for the tools your team runs the business with. In practice there are four options, not two.

Build vs buy for internal tools is the decision between paying for software another company makes and writing your own for the tools your team runs the business with: support consoles, back-office screens, approval queues, ops dashboards. It sounds binary, and it is not. Between a finished product and a blank repository sit hosted builders and frameworks, and most companies use several at once. The useful question is which option fits each tool.

## The four real options

**1. Buy a SaaS product.** A finished tool from a vendor: a helpdesk, a payroll system, a CRM.

- You get a working tool on the first day, with support and upgrades you did not write.
- Pricing is often per seat, so the bill follows headcount. Syncing it with your own data is your work.
- Your records live in the vendor's database. Leaving means an export and a migration.
- The vendor decides what changes. You configure what they expose.

**2. Use a hosted low-code builder.** A platform where you assemble screens from components and connect them to your database or API.

- You get screens over existing data quickly, built by people outside the main app's team.
- Pricing is often per builder and per user. Schema changes in your app often mean updating the tools in the platform too.
- The platform reaches your database from outside, with credentials you give it. The tools live in the platform, not in your repository.
- Anyone with a builder seat can change a tool, usually outside code review and tests.

**3. Build on a framework inside your app.** You add an internal-tool framework, such as a [Rails admin panel framework](https://avohq.io/glossary/rails-admin-panel-framework), to the app you already run.

- You get list, detail and form screens, search, filters and permission hooks, and write only what is specific to you.
- The costs are a license if there is one, developer time, and upgrading the framework with the app.
- The data stays in your database and goes through your own models and validations. How locked in you are depends on whether you can drop to plain code where the framework does not fit.
- Developers change it, in the same pull requests as the product.

**4. Build from scratch.** Your developers, and their coding agents, write the controllers, views, search and permission checks themselves.

- You get exactly what you specify, and your developers change it.
- Every fix, upgrade, security review and new screen is your team's work for as long as the tool runs.
- No vendor holds your data. The dependency is on the people who know the code.

## When buying is plainly right

Buy commodity needs: payroll, transactional email, accounting, team chat. The signals:

- Every company needs it in roughly the same way.
- The rules come from outside and change on someone else's schedule, like tax law or email deliverability.
- The vendor's product is the [system of record](https://avohq.io/glossary/system-of-record) for that data, and your team only reads it or links to it.
- Nobody on the team should be on call for it.

A hosted builder beats code when the people changing the tool are not developers and no developer time is free, when the tool is short-lived, or when its data already lives in third-party services.

Build instead when the tool works on your own product data, has to follow validations and permission checks already in your code (a second copy of those rules drifts), is part of how your business is different, or is used by so many people that per-seat pricing grows with every hire.

## Comparing cost over five years

Compare the same cost lines for every option over the same period. The usual mistake is setting one side's first-year subscription against the other's first build and ignoring everything after.

- **Licenses**, and how they scale: per seat, per app or per usage. Model the headcount you expect.
- **First build**: developer time to the first usable version.
- **Maintenance**: upgrades, security patches, bug fixes, new screens as the schema changes.
- **Integration**: keeping a bought tool and your app in sync.
- **Hosting and operations**: where it runs and who is paged when it breaks.
- **Access control**: writing and reviewing permissions, or reviewing a vendor's security.
- **Exit**: export, migration and retraining if you leave later.
- **Not having the tool**: engineers running console sessions for support. Most comparisons forget this line.

Put your own figures against each line. One you cannot estimate still belongs on the list: it shows where the uncertainty is.

## Why "write admin tools from day one" is common advice

- Every product grows a back office behind it: refunds, plan changes, user lookups. It will exist either way. The choice is whether it is planned.
- Without one, engineers become the interface. Each "can you change this for a customer" is a production console session, with no permission check and no record of who changed what.
- It is cheapest while the schema is small. Added late, it is a rewrite against habits nobody wrote down.

Day one does not mean polished. A list, a detail page and the few actions support needs most are enough.

## A worked example

A subscription software company has a small engineering team and a growing support and finance team.

- **Payroll: buy.** The rules change on the government's schedule, and nothing about their payroll is special.
- **Transactional email: buy.** Deliverability is a specialism of its own.
- **Helpdesk inbox: buy**, with each conversation linking to the account screen in their own app.
- **Account lookups, trial extensions, refunds, invoice review: build on a framework inside the app.** These act on the company's own subscriptions, must respect the billing logic already in the code, and the whole support team uses them.
- **A dashboard for a one-quarter data migration: a hosted builder or a script.** It goes away when the migration ends.

No single option won. The same reasoning at a larger size is the [custom ERP](https://avohq.io/glossary/custom-erp) question: whether a company's operational core is bought, built, or bought and extended.

## Building internal tools on Avo

Rails teams who choose the third option for their own data can build their [internal tools on Avo](https://avohq.io/rails-internal-tools). It mounts inside the Rails app they already run and reads their existing models and Pundit policies. Each screen is a short Ruby resource file, reviewed in a pull request, and where a screen needs more, they write plain Rails. Avo is licensed per application, not per seat. Teams with an old admin can [replace it one resource at a time](https://avohq.io/rewrite-your-admin), and the [comparison of Rails admin options and hosted builders](https://avohq.io/avo-alternatives) covers the other choices.

## Frequently asked questions

### When should you build vs buy internal tools?

Buy commodity tools that every company handles the same way, such as payroll or email. Build when the tool works on your own product data, has to follow rules already in your code, or is used by so many people that per-seat pricing keeps growing. Most companies do both, tool by tool.

### Is build vs buy a false choice?

Mostly, yes. There are four options: buy a SaaS product, use a hosted low-code builder, build on a framework inside your own app, or build from scratch. Most companies use more than one.

### How do you compare the five-year cost of building vs buying?

List the same cost lines for every option: licenses and how they scale, first build, maintenance, integration, hosting, access control, leaving, and the cost of not having the tool. Then put your own figures against each.

### Should you write admin tools from day one?

Usually, yes. Every product needs a back office for refunds, plan changes and lookups. Without one, engineers make those changes in a production console. Start small.

### Do coding agents change the build vs buy decision?

They make the first version of a built tool quicker to write. Review, upgrades and new screens are still your team's work, so the cost lines stay the same, and buying commodity tools still makes sense.