How much it costs to build a custom web system in 2026

The short answer

A custom web system is software built for one specific process in a company, with its own database, users with distinct roles and integration with what the company already uses; it pays off when the spreadsheet or the off-the-shelf SaaS costs more in rework than the software would. Price is not a rate card, it is scope. What pushes the cost up is not the number of screens: it is ERP integration, fine-grained per-user permissions, an audit trail and who maintains everything after go-live. A fixed quote without discovery is a guess dressed up as a contract, and a guess turns into a change order. Below are the variables that make up the price, the operating costs with public, dated prices, and how to ask for proposals you can actually compare.

1. Why there is no rate card for a custom system

Whoever asks for a quote wants a number. Whoever delivers needs to know what is inside it. The same request ("a system to track orders") can turn into three projects with very different costs:

• A screen that lists orders from an imported spreadsheet, two users, everyone on the same login.
• The same tracking with four departments, each seeing only its own, with a history of who changed what.
• The same tracking pulling stock from the ERP in near real time, with the tax invoice triggered at the end of the flow.

The first is a CRUD with authentication. The third involves a reprocessing queue, third-party errors, reconciliation and on-call support. No rate card tells the three apart, because the difference is not in the interface: it is in what happens when the system on the other side responds with an error. Whoever publishes a fixed rate card is selling a small scope and charging for the rest through change orders, or padding the price to cover the unknown.

The questions that change the price more than the design

Five answers move the price before any estimate: how many people use it and how many different roles exist; which systems the software needs to read from or feed (ERP, e-commerce, bank, a live spreadsheet); whether someone will later need to prove who made each change; whether the process carries a tax or legal obligation; and who looks after the system in the month after delivery.

"Three people, no systems, no history, no invoices, you look after it" is a different quote from "forty people in five departments, integrates with the ERP, mandatory audit trail, issues invoices, my IT team takes over afterwards".

2. The four items that push the cost up the most

ERP integration

Integration is not "connecting the API". It is living with someone else's API. The Bling documentation is explicit about the ceiling: "3 requests per second" and "120,000 requests per day", with the limit applying to the whole account, not per endpoint. When you exceed it, the response is HTTP 429, and 600 requests in 10 seconds can block the source IP for 10 minutes.

That changes the architecture. A sync job that loops over a thousand products breaks on the first day of real operation. What works requires a queue, backoff, idempotency and a record of what has already been processed. Add the filter rules: queries with an interval longer than one year return 400, which forces you to paginate by date windows in any historical load. Each of these restrictions is code nobody sees on screen and that shows up in the price. A quote that treats integration as "1 day" has not read the documentation.

Multi-user access with real permissions

"Multi-user" is sold as a login with a password. What costs money is granularity: who sees which row.

PostgreSQL solves part of this in the database, with Row Level Security. The official documentation describes the consequence of turning the feature on: "If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified". Security becomes explicit, policy by policy, command by command: safer and more work. The same documentation warns that referential integrity checks, such as unique and foreign keys, always bypass row security, which calls for careful modeling so information does not leak through an indirect channel.

Outsourcing identity takes the cost out of the code and puts it in the monthly bill. On Clerk, custom roles and RoleSets are not in the base plan: they depend on the B2B Authentication add-on, US$ 100 per month (US$ 85 billed annually), read on 23/09/2026.

Audit trail

Auditing is the difference between "the order changed value" and "user so-and-so changed the value at 14:32 on the 12th, from X to Y, from this IP". That means a history table, immutability of old rows, a retention policy and a screen to query it without opening the database. When personal data is involved, it stops being a preference. Brazil's LGPD states, in art. 37, that "the controller and the processor must keep records of the personal data processing operations they carry out", and art. 6, VII, requires technical and administrative measures to protect against unauthorized access.

On platforms, auditing lives in the higher tier. On Supabase, Platform Audit Logs only come from the Team plan (US$ 599 per month), with 7 days of log retention on Pro. On Clerk, Admin Logs come with Business (US$ 300 per month), with 30 days. Both read on 23/09/2026. If the requirement is to prove something two years from now, no default retention will do: the trail needs to live in your own database.

Maintenance after go-live

Go-live does not end the cost, it starts the recurring one. Dependencies get updated, certificates expire, the ERP API changes its contract, volume grows, someone enters wrong data and wants a rollback. It is the item most often left out of quotes and the one that causes the most friction six months later. The question is not "is there support", it is "what is included, for how long, and what starts being billed".

3. Ranges by type of system, presented as scope

The three types below cover most requests. The columns are not prices: they are the variables that set the price.

The internal dashboard is the only one of the three where the biggest uncertainty lies in your process, not in outside systems. In the other two, a good part of the effort is defensive, written for the day the API on the other side returns an error. The "worth it or wasteful" criterion is the same one that appears in headless WordPress.

4. The cost that keeps arriving: infrastructure and services

The development price is an event. The operating cost is a subscription. Keep the two apart, because the sum of small monthly fees surprises people more than the project price. The figures below come from official pages read on 23/09/2026 and work as a floor for a small or medium system.

Two readings come out of this. The server is the smallest item on the list when the system is internal and the volume is modest: one VPS handles the application, the database and the queue for the same kind of dashboard the current spreadsheet supports. Providers such as Hostinger, Hetzner, DigitalOcean and Contabo operate in this range, and choosing between them changes the budget less than the decision to outsource or not.

The other: compliance add-ons cost more than the server. PITR on Supabase (US$ 100/month) and custom roles on Clerk (US$ 100/month) together exceed any VPS in the table. That is the price of not writing those things yourself. The mistake is finding this out after signing off on the scope.

Where to save without creating debt

Legitimate savings in a low-volume internal system: run the application and the database on the same VPS until the volume justifies splitting them, with backups off the server, and use the stack's own authentication when there is no corporate SSO and no role hierarchy. Savings that charge interest: cutting the audit trail (rebuilding history that was never recorded is impossible, not expensive) and cutting error monitoring, because without it the one who discovers the failure is the user.

5. Why a fixed quote without discovery turns into a change order

A fixed price requires a fixed scope, and a fixed scope requires knowing the process. If nobody has looked at the current spreadsheet, the number in the contract is a bet. What discovery finds and the request does not say:

• Exception rules that live in one person's head ("this customer always has a different deadline").
• Spreadsheet columns with three meanings depending on the row.
• A second file nobody mentioned that feeds the first one.
• A manual report someone builds every Friday that is the real reason for the request.
• Dirty historical data that has to be migrated before any screen can work.

Each of these items, discovered after signing, becomes an uncomfortable conversation: either the developer absorbs it and works for free, or asks for a change order and the client feels the price changed.

A discovery plan that could fit in a week

Five deliverables, without turning into a consulting project: a map of the process from trigger to result, with who does each step; an inventory of the systems with each API's documentation checked, request limits included; a roles matrix (who sees, who edits, who approves); what needs an audit trail and for how long; and the phase 1 scope with an explicit cut of what is left for later. At that point the quote stops being a guess, and the client ends up with something useful even if they hire someone else.

6. Phased scope, not cut scope

A phase is not delivering less: it is delivering in order of value. Phase 1 is the smallest slice that replaces the spreadsheet in the main process. A common path for an internal dashboard that grows:

• Phase 1: records and the main flow, minimal roles and change history already being recorded.
• Phase 2: reports and exports that are done by hand today.
• Phase 3: ERP integration, starting with reads before writes.
• Phase 4: automation of whatever became repetitive once the process became visible.

The audit trail is in phase 1 because it is the only part that cannot be added retroactively with the same value. The integration is kept separate for another reason: it is the item most likely to get blocked by an external cause (a credential the accountant does not have, an app waiting for approval, a request limit that changes the design). Putting it on the critical path of the first delivery is inviting a third-party blocker.

7. How to ask for quotes you can compare

A vague request produces three proposals that cannot be compared, because each one assumed a different scope. What to include:

• The process from start to finish, with the trigger and the expected result.
• How many people use it and how many distinct roles exist.
• The systems that need to be read from or fed, with name and subscribed plan.
• Whether there is an audit requirement and for how long the history stays available.
• Whether there is a tax obligation in the flow, and who maintains the system afterwards.
• The current volume as a number, even if approximate (orders per month, records, concurrent users).

What to demand from every proposal:

• A split between development cost and monthly operating cost.
• Which third-party services are included and how much each one costs per month, with a link to the pricing page.
• What is out of scope, in writing, and who keeps the code.
• What happens when a third-party API changes.

A proposal that does not separate development from operation is hiding recurring cost. A proposal that does not list what was left out of scope will argue about it later, under pressure.

A single price without any of these answers is not a quote: it is risk baked into a number.

Frequently asked questions

Why nobody gives me a price over the phone

Because the price depends on what has not been asked yet. The number of screens is what varies least between two projects that look the same; what varies is integration, permissions, auditing and maintenance. A number given before those answers is a shot in the dark, and a high guess protects whoever made it while a low guess ends in a change order. Answering the five questions in section 1 is the fastest way to a figure.

Is it cheaper to adapt an off-the-shelf SaaS

Often yes, and that should be the first hypothesis you test. Off-the-shelf SaaS loses when the process has a rule the tool does not accept, when the per-user cost grows faster than the operation, or when the data needs to live alongside the rest of the company to become reports. The test is to list the rules of your process and mark which ones the SaaS covers without workarounds.

What happens if I want to switch developers later

That is settled in the contract, not in the technology. Three clauses are enough: the code is yours and lives in a repository in your name; the service credentials are in accounts you own; and there is minimal documentation of the deploy and the environment variables. Without them, switching suppliers costs almost a restart, and that is when the low price of the original proposal charges its interest.

Conclusion

The price of a custom system is built by adding up scope variables, not by looking up a rate card. The four that weigh the most are ERP integration, per-user permissions, auditing and maintenance after go-live, and none of them shows up in the screen design. Operating cost is separate from development cost, has public and dated prices, and needs to be written into the proposal. A fixed quote without discovery is a bet, and a bet on software gets paid in change orders.

If you want a number instead of a range, send to oailton.dev/en/contato which process needs to leave the spreadsheet and how many people use it, with the different roles that exist among them. With that plus the list of systems that need to talk to each other, it is possible to design a phased scope and price it on something countable.