When to Build an Internal Tool vs Buying SaaS
Cost, data ownership, workflow fit, and maintenance: a clear framework for when a custom internal web app beats stacking more SaaS seats.
I watched a 12-person ops team spend $4,800 a year on three SaaS products that still forced a 40-minute Friday export ritual. When your team should build an internal tool instead of buying another SaaS is when the workflow tax outruns the seat tax, and your data never fits the vendor's defaults.
That number stuck with me because it was not dramatic. It was ordinary. Three tools, reasonable prices, clean demos. The pain showed up in the seams: handoffs between systems, fields that did not exist, and people who became human glue. If you are a technical founder or lead on a small team, this is the decision you keep postponing until another annual renewal lands in your inbox.
At Pylonworks we build custom websites and web apps for clients, and we also run autonomous AI agents in production. The build-vs-buy call for internal tools shows up in almost every scoping call. The teams that get it right treat it as a cost and ownership problem, not a taste test between shiny UIs.
When does stacking SaaS stop making sense?
Stacking SaaS stops making sense when you pay for seats, then still pay people to work around the product. A rough rule I use: if two or more people spend more than 3 hours per week on export, re-entry, or "status theater" to keep systems aligned, you are already funding a shadow internal tool. You just fund it with salaries instead of engineering.
I see the same pattern across small teams of 8 to 40 people. The first SaaS tools are pure leverage. CRM, billing, support inbox, project board. The fifth and sixth tools are where the stack starts to tax you. You buy another connector. You approve another admin seat. You accept another 14-day free trial because "it might replace the spreadsheet." Six months later the spreadsheet is still there, and so is the subscription.
Community threads on build vs buy keep circling the same split: SaaS wins on speed and standard workflows; custom wins when control, data shape, and process fit matter more than launch day polish. That framing showed up again in a July 2026 discussion on custom AI development versus SaaS AI tools. The technology changes. The tradeoff does not.
Use these triggers as a stop-and-check list:
- You need a field, state machine, or approval path the vendor will not ship in the next two quarters.
- You move the same record across 3+ tools with manual copy or brittle Zapier-style glue.
- Seat pricing scales with headcount while value is concentrated in a few power users.
- Compliance or client contracts require your data to live in a system you control.
- The "workaround" has a name, a champion, and a calendar invite.
If two of those are true, start pricing a thin internal app before you renew the next annual plan.
How much does a custom internal tool really cost?
A focused internal web app for a small team usually lands between $8,000 and $40,000 to design and ship, depending on auth, roles, integrations, and how picky the UI needs to be. The range that surprises people is not the build. It is the five-year math (see how we price web development projects).
Here is a concrete comparison I run with founders. Assume 15 users and a 3-year horizon.
| Cost line | Buy another SaaS | Build a thin internal tool |
|---|---|---|
| Year 1 software / build | $6,000–$18,000 (seats + add-ons) | $12,000–$35,000 (design + build) |
| Years 2–3 software | $12,000–$36,000 | $0–$3,000 (hosting, auth, monitoring) |
| Integration / glue | $1,500–$6,000 | Often smaller if you design the data model once |
| People time (workaround tax) | $8,000–$25,000 (part-time ops drag) | $2,000–$8,000 (reviews + training) |
| Exit / switch cost | High if data is trapped | You own the schema and exports |
| 3-year total (typical mid case) | $30,000–$70,000 | $18,000–$50,000 |
Those bands are not universal. A $12/user tool with clean APIs can stay cheaper forever. A $49/user tool with mandatory higher tiers, audit logs sold as add-ons, and a 10% annual uplift can cross a custom build faster than your finance lead expects.
I budget maintenance at 15–20% of the initial build cost per year if the tool is real production software. That covers dependency updates, small feature requests, and the occasional auth or hosting change. If you cannot fund that line, do not build. A half-abandoned internal tool is worse than an annoying SaaS bill.
The real cost of SaaS is rarely the invoice line. It is the hours you spend teaching people a workflow the product was not designed to hold.
One aside on metering: drafting a post like this on a production agent stack is cheap in tokens and expensive in judgment. The useful part is the decision tree, not the prose. Keep the same ratio when you scope software for your own team.
What about data ownership and workflow fit?
Data ownership is the right to query, export, delete, and reshape records without filing a ticket with a vendor success manager. Workflow fit is whether the software encodes your states, roles, and edge cases, or forces you into theirs.
SaaS is excellent when your process is standard. Invoicing with tax rules, email support queues, password reset flows. Buy those. You will not out-build a mature product team on generic problems, and you should not try.
Custom internal tools win when your process is the product of how you operate. Examples I have seen pay back:
- A client intake board that maps exactly to how sales hands off to delivery, with SLA clocks and revision caps baked in.
- An ops console that joins inventory, contractor status, and invoice readiness in one screen instead of four tabs.
- A permissions model where contractors see one project slice and staff see the whole book of work.
If you need AI in the loop later (summaries, routing, draft replies), ownership matters more, not less. SaaS AI features are fast to turn on. They are also where retention policies, training defaults, and export limits get fuzzy. Teams arguing about custom AI versus SaaS AI tools are really arguing about who controls the pipeline when the demo ends and the data volume starts. That is the same ownership question in a louder outfit.
A practical test: write the three reports your team needs every Monday. If two of them require CSV exports and a VLOOKUP ritual, your system of record is still a spreadsheet wearing a SaaS costume.
How do you maintain an internal tool without drowning?
Maintenance is why smart teams still buy. You avoid drowning by shipping the smallest useful system, not a platform fantasy.
An internal tool is a web app your team uses to run a specific workflow. Scope it to one painful path. Ship auth, the core records, the two or three actions people take daily, and clean exports. Defer the reporting suite, the mobile app, and the "nice to have" admin settings that nobody will open for six months.
Operational habits that keep costs sane:
- One product owner inside your company. Not a committee. Someone who can say no to feature drift.
- A weekly 30-minute triage. Bugs first, then one small improvement. Cap scope hard.
- Hosted managed services for auth, database, and file storage when you can. You want leverage, not a second full-time job.
- Versioned integrations. When you connect Stripe, Slack, or your CRM, isolate the adapter so a vendor API change does not rewrite your core models.
- An explicit kill criteria. If usage drops below a threshold or a better SaaS appears that truly fits, plan a sunset instead of nostalgia.
A lightweight decision config I keep in repos looks like this:
workflow: client_onboarding
users: 12
saas_annual_cost_usd: 7200
workaround_hours_per_week: 6
hourly_loaded_cost_usd: 65
must_own_data: true
vendor_roadmap_fit: low
build_budget_usd: 18000
maintenance_budget_usd_per_year: 3000
decision: build_if_payback_under_18_months
Run the payback math every quarter for the first year. If the workaround hours do not fall by at least half after launch, you built the wrong surface.
When should a small team still buy SaaS?
A small team should still buy SaaS when the problem is generic, the vendor's model matches yours, and switching costs are low. Buy for email, calendar, basic accounting, commodity CRM stages, and anything where compliance is the product (payroll, some security tooling).
Also buy when your team cannot staff maintenance. A $200/month tool with a responsive vendor is cheaper than a $0/month internal app that only one engineer understands, and that engineer just quit. "We own the code" is a liability if nobody will open the repo.
I still scan Hacker News for internal-tool threads because the comments are full of people who built too much. The consistent regret is not "we paid for SaaS." It is "we built a platform for a workflow that changed in three months." Prefer a boring CRUD app with sharp edges over an agent-powered dashboard you will not maintain.
If you are mid-decision and want a second set of eyes on scope, budgets, and delivery risk, the process we use for client web apps at Pylonworks is the same process I would apply to an internal tool: nail the workflow, cap the first release, price maintenance up front, and refuse feature theater (see scope, budgets, and delivery risk).
What is a sane build-vs-buy checklist?
A sane checklist is a short scored list you can finish in 20 minutes with one operator and one technical lead. Score each item 0 (favors buy) or 1 (favors build).
- Process is unique or a competitive advantage.
- Data must live under our access control and export policy.
- Current workaround exceeds 3 hours/week across the team.
- Seat and add-on pricing will grow faster than headcount value.
- Vendor roadmap will not cover the gap in 6 months.
- We can fund 15–20% annual maintenance.
- We can name a single product owner.
- Success is measurable (time saved, error rate, cycle time).
Score 0–2: buy or stay. 3–5: run a 2-week design spike and price both options. 6–8: build a thin internal web app with a fixed first milestone.
Do not let the spike turn into a rebuild of your whole stack. The first release should remove one painful ritual. If Friday's export dies, you won.
Closing: change one number this week
Pick the SaaS product your team complains about most. Write down annual spend, weekly workaround hours, and whether you own clean exports. If annual seat cost plus loaded workaround time exceeds a thin custom build with maintenance over 18 months, stop adding seats and start scoping the internal tool. That single calculation beats another free trial.
FAQ
How long should an internal tool take to ship?
A useful first version should ship in 4 to 10 weeks for a focused workflow with standard auth and one or two integrations. If the plan is longer than a quarter before anyone can use it daily, the scope is too wide. Cut features until a real user can complete the main job in production.
When is no-code the right middle path?
No-code is right when the workflow is simple, the data volume is modest, and you need something this month. It fails when you need complex permissions, audit trails, multi-step state machines, or heavy integration logic. Treat no-code as a prototype budget with a known migration cost, not as free infrastructure (see No-code).
What is the biggest mistake teams make after they decide to build?
They expand scope to "while we are in there." The first release grows from one workflow into a mini ERP. Keep the contract brutal: one job, measured outcomes, scheduled maintenance, and a product owner with veto power. Custom software only beats SaaS when you refuse to rebuild SaaS by accident.
Tired of re-keying the same data between tools? Pylonworks builds custom automation and internal tools for businesses without a developer, on a fixed quote you approve up front. Tell us what's eating your time