What Actually Determines the Cost of Custom Business Software?

1. The number of workflows

Screens are visible.

Workflows are where much of the complexity lives.

Consider an order system.

A simple version might be:

Another business may require:

Both could be described as an “ordering system.”

They are not equivalent projects.

2. Business rules

Custom software becomes more complex as the number of conditional rules increases.

For example:

• different customers receive different prices;
• certain employees require approval;
• some products can only ship from particular locations;
• tax rules vary;
• inventory may be shared across facilities;
• certain actions depend on previous actions.

These rules are often precisely why a business wants custom software.

They also require careful design and testing.

3. User roles

A system used by one internal employee is different from one serving:

• administrators;
• salespeople;
• managers;
• warehouse employees;
• accounting;
• customers;
• suppliers.

Each may require different:

• permissions;
• screens;
• data;
• actions;
• notifications;
• security controls.

The number of accounts matters less than the number of different ways people need to interact with the system.

4. Integrations

Businesses rarely operate in isolation.

A custom system may need to communicate with:

• accounting software;
• payment processors;
• email providers;
• shipping services;
• inventory systems;
• CRMs;
• databases;
• or other internal applications.

An integration with a clean, well-documented API may be relatively straightforward.

Another system may have limited integration capabilities and require substantially more work.

That is why “connect it to our existing software” needs technical review before it can be priced responsibly.

5. Data migration

Building the new system is one task.

Moving years of existing business information into it can be another.

Questions include:

• Where does current data live?
• Is it consistent?
• Are fields standardized?
• Are there duplicates?
• Does historical information need to be preserved?
• Can the old platform export it?

Clean structured data can simplify migration considerably.

Messy historical data can turn migration into its own project.

6. Customer-facing functionality

An internal application can sometimes optimize heavily for employee efficiency.

A customer portal requires additional attention to:

• onboarding;
• authentication;
• usability;
• mobile behavior;
• accessibility;
• error handling;
• account recovery;
• security;
• and presentation.

The expectations are different because the user cannot simply ask the employee sitting next to them how something works.

7. Reliability requirements

Not every system carries the same consequences when something goes wrong.

A small internal reporting tool and a mission-critical ordering platform should not necessarily be engineered identically.

Reliability requirements influence:

• infrastructure;
• testing;
• backups;
• monitoring;
• security;
• redundancy;
• deployment processes;
• and support.

This is one reason Proton does not accept every custom project automatically.

The technical and operational responsibility needs to match our ability to deliver it properly.

8. How much needs to exist on day one?

This is where scope can often be improved considerably.

A business might initially describe 25 features.

After examining the problem, perhaps eight are necessary for the first version.

Building the eight important things well can often be more useful than launching 25 partially considered features.

We generally prefer:

rather than:

Imagine everything → build everything → discover what employees actually needed later

9. Future expansion

Planning for expansion does not mean building future features today.

It means avoiding decisions that make obvious future requirements unnecessarily expensive.

If a business already knows it intends to:

• add locations;
• add customer accounts;
• integrate inventory;
• expand into e-commerce;
• or introduce additional user roles,

that context should influence the architecture.

Think of it like constructing a building.

You do not need to build the fifth floor today.

But if there is a reasonable chance that a fifth floor will eventually exist, the foundation should not make it impossible.

Why Proton uses custom-scoped pricing

This is why Proton's custom business systems are individually scoped.

We first need to understand:

• what the business is trying to improve;
• what currently happens;
• what the first version genuinely needs;
• what must integrate with it;
• and what responsibilities the system will carry.

Only then does pricing become meaningful.

Website starting prices and how custom systems are scoped are on the pricing page. If the requirement is already clear enough to describe, contact Proton.

The same question of fit is covered in custom software versus off-the-shelf software: cost only makes sense after the requirement is clear.

Custom does not automatically mean enormous

There is also a misconception that every custom system must be a massive project.

It does not.

A focused internal system solving one expensive operational problem can be relatively contained.

Custom simply means the solution is shaped around the requirement rather than predetermined by an existing product.

The best scope is not the largest one.

It is the smallest one that solves the right problem properly.