Custom web app vs off-the-shelf software: when to build

Buy off-the-shelf software when your process looks like most other companies' processes and the tool fits at least 80% of it without workarounds. Build a custom web app when the process is what makes you different, when you are paying for several tools glued together with spreadsheets, or when your customers need to see data that lives in your ERP or CRM. Most growing businesses end up with both: standard software for standard work, and a small custom layer where the standard tools stop.

The rest of this guide covers how to tell which side of that line you are on, what each option really costs over three years, and the middle ground that many buyers skip.

What is the difference between custom and off-the-shelf software?

Off-the-shelf software (also called SaaS or packaged software) is built once by a vendor and rented to thousands of companies. You configure it, you do not change its code. Examples are QuickBooks Online for accounting, HubSpot or GoHighLevel for CRM, and Odoo for ERP.

A custom web app is built for one company's workflow. It runs in the browser, it is usually written in a mainstream stack such as React or Next.js on the front end with Node.js and PostgreSQL behind it, and the company that paid for it owns the code. It can still talk to your off-the-shelf tools through their APIs.

Between the two sit low-code builders such as Retool, where you assemble screens on top of your own data. They are faster than writing everything from scratch, but you still rent the platform and pay per user. Retool's Team plan, for example, is listed at $10 per builder and $5 per internal user per month on annual billing, and features such as portals and embedded apps sit in the higher Business tier.

When does off-the-shelf software win?

Packaged software is the right answer more often than agencies like to admit. It wins when:

• The process is regulated or standardized, like payroll, tax, general ledger or payment processing. A vendor with thousands of customers keeps up with rule changes better than a custom app can.
• You need it working this month. A SaaS tool can be live in days. A custom app takes weeks at best.
• Your team is small and nobody will own a custom system after launch.
• The vendor's way of working is close to yours, and the gaps can be closed with configuration, a few automations or a small change to how you work.

A useful test: write down your ten most frequent tasks in the area you are looking at. If a trial account handles eight or more of them as-is, buy it. Adjusting a few habits is cheaper than building and maintaining software.

When should you build a custom web app?

Custom development earns its cost in a narrower set of situations, and in our experience they show up in a predictable way.

The process is your competitive edge

If the way you quote, schedule, price or deliver is the reason customers pick you, forcing it into a generic tool flattens it. A custom quoting engine for a manufacturer with unusual pricing rules is a classic example.

You are paying for a stack of tools held together by spreadsheets

Three subscriptions, two Zapier zaps and a shared spreadsheet that one person understands is a custom system already. It is just a fragile one. Replacing the glue with a single app that reads and writes to your main systems is often cheaper over three years.

Customers or partners need a window into your data

Order status, documents, project progress, stock availability or service history that lives in your ERP or CRM is a frequent reason to build. Off-the-shelf portals exist, but they usually show the vendor's view of the data, not yours. We cover this case in detail in how to build a customer portal connected to your ERP or CRM.

Per-user pricing is becoming the biggest line in the budget

Seat-based pricing is fine for ten staff. It hurts when you want to give access to 400 customers, 60 subcontractors or a seasonal workforce. A custom app has hosting costs, not seat costs.

Custom vs off-the-shelf: side-by-side comparison

Factor	Off-the-shelf (SaaS)	Low-code builder	Custom web app
Time to first use	Days	1 to 4 weeks	4 weeks to several months
Upfront cost	Low (setup and configuration)	Low to medium	Highest (fixed build fee)
Ongoing cost	Per user, per month, rises with headcount	Per builder and per user, plus platform tier	Hosting and a support plan, mostly flat
Fit to your process	You adapt to the tool	Good for internal screens	Built around your process
Customer-facing use	Limited to what the vendor offers	Often a higher tier or extra pricing	Full control of branding and access
Ownership	You rent it	You rent the platform	You own the code and data
Upgrades	Vendor ships them, sometimes unwanted	Vendor ships the platform	You decide when and what
Main risk	Vendor price rises or product changes	Platform lock-in	Scope creep and maintenance

How do you compare the real cost over three years?

Comparing a SaaS subscription with a build quote is misleading because one is monthly and the other is mostly upfront. Put both on a 36-month view.

For off-the-shelf software, add up: subscription per user times expected headcount in year three (not today), implementation or setup fees, paid add-ons you will need within a year, the integration tools that connect it to everything else, and staff time spent on workarounds. That last one is easy to ignore and is often the largest.

For a custom app, add up: the build cost, hosting (often tens of dollars a month for a small internal tool, more for customer-facing apps with heavy traffic), third-party services such as authentication or email, and a monthly support plan for fixes and small changes. Our breakdown of how much a custom web app costs gives typical ranges for each type of project.

When the three-year totals land close to each other, pick off-the-shelf. You get vendor support and lower risk. Build only when custom is clearly cheaper over time or when the fit problem is costing you customers.

What is the hybrid approach, and why does it usually win?

The most common pattern in the projects we scope is not "replace everything." It is: keep the ERP, CRM and accounting tool you already pay for, and build a thin custom layer on top for the one or two jobs they do badly.

Typical examples:

• A customer portal that reads orders, invoices and delivery status from Odoo through its external API, with your branding and your rules about who sees what.
• An internal dashboard that combines CRM pipeline data with ERP margins, so managers stop exporting to Excel every Monday.
• A quoting or configuration tool that writes finished quotes back into the ERP as sales orders.
• A booking or intake form that creates contacts and opportunities in GoHighLevel through its API.

This keeps the boring, well-tested parts (accounting, inventory, payments) in software that thousands of companies use, and puts custom code only where it pays off. It also limits the size of what you need to maintain. Before building, check what the platform already does: Odoo, for example, ships a standard portal where customers can view and pay orders and invoices, manage payment methods and update addresses. If that covers your need, a custom app is unnecessary.

One technical note: an integration is only as stable as the API behind it. Odoo's documentation says its older XML-RPC and JSON-RPC endpoints are deprecated in favor of the External JSON-2 API introduced in Odoo 19, and that external API access on Odoo Online requires the Custom plan. Factor details like these into the decision before you commit.

Questions to answer before you decide

1. Which ten tasks matter most, and how many does the best off-the-shelf option handle without workarounds?
2. How many people will need access in three years, including customers, partners and contractors?
3. Where does the data that matters live today, and does that system have a documented API on your plan?
4. Who will own the software after launch: an internal person, or a support plan with the builder?
5. What happens if the vendor doubles its price or retires the feature you rely on?
6. Can the first version be small enough to ship in six to ten weeks?

If you cannot answer the last question with a yes, the scope is probably too big. Split it into phases, ship the most painful piece first, and decide on the rest with real usage data.

How we approach build-or-buy at Dymaxel

We build custom web apps in React, Next.js, TypeScript, Node.js and PostgreSQL, and we also implement Odoo and GoHighLevel. That means we have no reason to push a build when configuration will do. The first conversation is a free 45-minute consultation where we look at the process and the existing tools. If we recommend building, you get a written fixed-price scope for each phase, weekly demos during the build and testing on your real data before launch. You own the code, the accounts and the data from day one. Read more about our custom web app development work.

If you are weighing a SaaS tool against a custom build right now, book a free 45-minute consultation. Bring the list of tasks and the tools you use today, and we will tell you plainly which option fits, even when the answer is "do not build anything yet."