Build vs Buy for Internal Software: A Decision Guide for Small and Mid-Size Teams (2026)
When to buy off-the-shelf software, configure a low-code platform, or build your own internal tool, with a decision checklist, a three-year cost worksheet and the hidden costs on each side.
Key Takeaways
- Buy for standard processes; build for the ones that are yours. If your process looks like everyone else’s (payroll, accounting, standard help desk), buy. If it reflects how your company specifically works, building often fits better.
- There are four options, not two. Buy a product, configure a general platform such as Airtable, build on a low-code or AI platform, or commission custom development. Each has a different cost curve.
- Compare three-year cost, not first-month price. Per-seat pricing grows with headcount; building has setup time and ongoing ownership. Put both on the same worksheet.
- Ownership is the hidden cost of building. Someone must maintain the tool, manage access and handle change requests. If nobody will, buy.
- Fit is the hidden cost of buying. Workarounds, side spreadsheets and paying for seats people barely use are real costs, even if they never appear on an invoice.
Quick-Start Prioritization Framework
| Option | Best when | Main cost | Main risk |
|---|---|---|---|
| Buy a product | The process is standard and a mature category exists | Per-seat or per-tier subscription | Poor fit, workarounds, rising seat costs |
| Configure a general platform (Airtable, Microsoft 365 lists and flows) | Data-centric, light workflow, team already uses the platform | Per-editor licences | Outgrowing it; logic spread across many automations |
| Build on a low-code or AI platform (Retool, Power Apps, Floot) | Process is specific to you; a capable owner exists | Platform plan plus the owner’s time | No owner after launch |
| Custom development | Core to the business, deep integration, scale | Developer time, then upkeep | Cost and time overruns; key-person dependency |
“Should we just buy something?” is the right first question for any internal tool. For many needs the answer is yes: help desks, HR systems, accounting and CRM are mature categories where a vendor has already thought through the edge cases you haven’t met yet. But the options are no longer just “buy a product” or “hire developers.” In between sit low-code internal tool platforms and AI app builders that let a non-developer build a custom app. That middle ground changes the math for the long tail of small processes: the equipment register, the purchase approval, the onboarding checklist. This guide gives a decision checklist, a way to compare three-year costs honestly, the hidden costs on both sides, and the signs you chose wrong.
The four real options
Framing it as build versus buy hides the most useful choices. Here is the full range.
Buy a dedicated product
A help desk, an HR system, a CMMS, an expense tool. You get years of product thinking, support, security reviews and integrations on day one. You adapt your process to the product’s model, and you pay per user or per tier.
Configure a general-purpose platform
Airtable bases with interfaces, Microsoft Lists with Power Automate, a well-structured Google Sheet with forms. Fast to start and familiar. Pricing is often per editor: Airtable’s pricing page lists Team at 20 dollars per user a month billed annually, and says read-only collaborators aren’t charged.
Build on a low-code or AI app platform
Retool, Appsmith, Budibase and ToolJet are low-code internal tool platforms; Power Apps is Microsoft’s, with Premium listed at 20 dollars per user a month billed yearly, and Microsoft notes that some Microsoft 365 licenses include limited Power Apps rights for scenarios using standard connectors. AI app builders generate a full app from a plain-English description. You get a tool shaped to your process without writing code, and you own its design and upkeep.
Commission custom development
A developer or agency builds exactly what you specify. The most flexible option and the most expensive, with ongoing maintenance and a dependency on whoever wrote it.
A decision checklist
Answer these honestly. Mostly “yes” on the left column points to buying; mostly “yes” on the right points to building.
| Question | Points to buy if… | Points to build if… |
|---|---|---|
| Is the process standard across companies? | Yes, it’s textbook (payroll, ledger, standard ITSM) | No, it reflects how you specifically work |
| Is there a mature product category? | Several well-reviewed products exist | Products exist but each needs heavy workarounds |
| Do regulations or audits shape it? | Yes, and vendors already handle them | Light, or handled by your other systems |
| How many people will use it? | A few heavy users | Many occasional users who would each need a seat |
| Who will own it after launch? | Nobody has time | A named person who wants to |
| How often will the process change? | Rarely | Often, and you want to change it yourselves |
| Does it need data from your other systems? | The product has the integrations you need | You need a combination no product offers |
Comparing three-year cost
First-month price is the least useful number. Put each option on a three-year worksheet with the same rows.
Rows to include
- Subscription or licence cost, at today’s headcount and at expected headcount in year three.
- Setup: configuration, data import, training, and any paid implementation.
- People time to build (for the build options), valued at a realistic internal rate.
- Ongoing ownership: hours a month to maintain, manage access and handle changes.
- Integration costs: connectors, middleware, or developer time.
- Cost of poor fit: side spreadsheets, manual re-entry, errors.
- Exit cost: how hard it is to get your data out and move later.
Worked example: per-seat pricing at 40 users
This is our own illustrative arithmetic from list prices on 11 November 2026. On Retool’s Business plan, billed annually, builders are 50 dollars a month and internal users 15 dollars a month. Three builders and 40 internal users come to 3 × 50 + 40 × 15 = 750 dollars a month, or 9,000 dollars a year. On Retool’s Team plan (10 and 5 dollars), the same team is 3 × 10 + 40 × 5 = 230 dollars a month. The plan you need depends on features: Retool lists audit logs on Business and SSO and SAML on Enterprise.
The point is not that one number is high or low. It is that per-user pricing scales with headcount, so the year-three column can look very different from year one if you plan to grow or to roll the tool out to the whole company.
Value the builder’s time honestly
A tool that an ops lead builds “in spare time” still costs that time. Estimate hours for the first version, the pilot and fixes, and the monthly upkeep, and price them. If the result is close to a product’s subscription, the product’s maturity usually wins.
Hidden costs of buying
Subscriptions look predictable. These are the costs that don’t show up on the invoice.
- Workarounds: the side spreadsheet that tracks what the product doesn’t.
- Seat creep: paying for occasional users, or rationing seats so people share logins.
- Tier jumps: the one feature you need (SSO, audit logs, an API) sitting on a plan several times the price.
- Process bending: changing a process that worked to match the product’s model.
- Price changes at renewal, and the effort of switching when they happen.
- Data access: exports that are partial or awkward to use.
Hidden costs of building
Building feels free once the platform is paid for. It isn’t.
- Ownership: someone answers questions, fixes issues and manages access, indefinitely.
- Key-person risk: the tool depends on the one person who understands it.
- Security and access design: roles, record rules and offboarding are now your job.
- Scope creep: every team wants a feature, and the tool grows into something nobody fully understands.
- Documentation: what the statuses mean, who approves what, how to add a user.
- Platform risk: what happens if the platform changes pricing or you want to leave. Check whether you can export the data and, ideally, the app itself.
Typical answers by category
These are common patterns, not rules. Your checklist answers should decide.
| Need | Usual answer | Why |
|---|---|---|
| Payroll, accounting, tax | Buy | Regulation, filings and integrations with banks and authorities |
| CRM for a sales team | Usually buy | Mature category with deep email and calendar integration |
| Help desk for external customers | Usually buy | Customer-facing channels, SLAs and reporting are well served |
| Internal IT ticket tracker | Either | Small teams often build a simple one; larger IT teams buy an ITSM product |
| Purchase approvals with your thresholds | Often build | The routing rules are specific to your policy |
| Equipment and laptop register | Often build | Simple data, specific fields, ties to onboarding and tickets |
| Onboarding checklist across HR, IT and managers | Either | HR suites include onboarding; many companies build for their own tasks |
| Operational dashboards | Build inside the tool, or use BI | Depends where the data lives |
A hybrid that often works
Most companies end up with a mix: buy the systems of record (accounting, payroll, HRIS, CRM), and build small internal tools around them for the processes that fall in the gaps. The internal tool reads from or writes to the system of record rather than replacing it. A time-off app that shows the balance from the HR system, or a purchase approval that creates the bill in accounting once approved, keeps one source of truth and still fits how you work.
Signs you chose wrong
You bought, but should have built
People keep a parallel spreadsheet. Half the fields are unused and the important ones are missing. You pay for seats nobody logs into. Every process change waits on the vendor’s roadmap.
You built, but should have bought
The tool owner spends more time maintaining it than doing their job. You are rebuilding features a mature product already has (SLA timers, complex reporting, compliance workflows). Auditors ask questions the tool can’t answer.
Common mistakes
- Comparing first-month price instead of three-year cost.
- Ignoring the builder’s time because it isn’t an invoice.
- Building a system of record (ledger, payroll) because a product felt expensive.
- Buying a heavyweight suite for a ten-step process.
- Not checking which plan tier holds the features you need.
- No exit plan: not knowing how to get your data out.
- Deciding without the people who will use it every day.
If you decide to build
If you’d rather not do the building yourself in a low-code tool, Floot, the AI app builder that publishes this site, builds internal tools from a plain-English description with their own database, roles and email, has no per-seat pricing for the app’s users, and lets you download the app’s database on every plan.
Frequently Asked Questions
When should a company build internal software instead of buying it?
When the process is specific to how you work, no product fits without heavy workarounds, many occasional users would each need a paid seat, and someone will own the tool after launch.
Is building internal tools cheaper than buying?
Sometimes. Compare three-year cost including subscriptions at future headcount, setup, the builder’s time, ongoing ownership and the cost of workarounds. For standard processes, buying usually wins once all costs are counted.
What should we never build ourselves?
Systems of record with heavy regulatory or financial demands, such as payroll, the general ledger and tax filing. Build small tools around them instead.
What is the biggest hidden cost of building?
Ongoing ownership: maintenance, access management and change requests. A tool without an owner decays, and people drift back to spreadsheets.
What is the biggest hidden cost of buying?
Poor fit: side spreadsheets, manual re-entry, paying for seats people barely use, and needed features sitting on a much higher plan.
Can we start by buying and build later?
Yes, and it is often sensible. Make sure you can export your data in a usable format so a later move is practical.
Sources
- Retool, Pricing, 2026 https://retool.com/pricing
- Airtable, Pricing, 2026 https://airtable.com/pricing
- Microsoft, Power Apps pricing, 2026 https://www.microsoft.com/en-us/power-platform/products/power-apps/pricing
- Microsoft Learn, Licensing overview for Microsoft Power Platform, 2026 https://learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus