Price follows the work the software has to do.
The size of a custom application is set less by the number of screens than by the number of distinct tasks it has to carry from start to finish. A request that moves through submission, review, assignment, and completion is one workflow. Quoting, scheduling, inspection, and invoicing are four, each with its own rules and people.
Each workflow brings its exceptions with it. Rework, cancellations, partial approvals, and corrections are part of the real task, and they take engineering effort in the same way the main path does. A scope that lists only the ordinary path will be priced low and then grow.
Before asking for a price, write down each task the software must support, who performs it, and what counts as finished. That list is the most useful document you can bring to a first conversation, and it makes proposals from different firms comparable. Include the people who approve, correct, or report on the work, not only those who enter it.
Integrations and existing data carry the most uncertainty.
Connecting to an accounting platform, a CRM, or an industry system can be simple or difficult depending on what that system allows. A documented API with sensible limits is one situation. A system that only exports files on a schedule, or that restricts access under its license terms, is another.
Data migration deserves its own line in any estimate. Years of records rarely arrive clean. Duplicates, inconsistent codes, free-text fields used for three purposes, and missing history all need decisions, and someone on your side has to make them. The estimate should say who cleans the data, how rejected records are handled, and how the result will be checked.
The way to reduce this uncertainty is to inspect it early. Pull a representative export, read the integration documentation, and test access with a real account before the price is set. An estimate built on an inspected system is far more dependable than one built on an assumption about it.
Roles, locations, and devices change the shape of the build.
A tool used by one internal team is a different application from one used by staff, managers, customers, and outside partners. Each role needs its own view of the records, its own permitted actions, and enforcement on the server so a person cannot reach information outside their boundary.
Multiple sites add their own questions. Do locations share customers and inventory, or keep them separate? Do they follow the same approval rules? Does reporting roll up across the business? Each answer is reasonable, but each one affects the data model and the testing. Settle them before the estimate, not during the build.
Where the work happens matters too. Field staff on phones need screens designed for small displays and gloved hands. Crews in basements, warehouses, or rural areas may need the application to work without a connection and synchronize later, which is a substantial requirement that should be named at the start.
Compliance and record-keeping requirements belong in the scope from the start.
Some work carries obligations beyond the workflow itself: audit history for changes, retention rules for records, signed approvals, restricted handling of personal or financial information, or accessibility requirements for customer-facing screens. These shape the architecture and the testing, so they cost less to plan for than to add later.
Name the rules that apply to your business and the evidence you would need to show that they are met. A requirement such as “keep a history of every price change and who made it” is specific enough to estimate. “Make it compliant” is not.
Be careful with sensitive information the work does not require. Every category of data the application stores adds security, retention, and access work. Leaving a field out of the first release is often the simplest way to keep both scope and risk under control. It can be added later, when there is a clear reason to hold it.
Separate the first release from later work, then ask for a written price.
The most reliable way to control cost is to decide what the first release must do and what can wait. Choose one complete task that people can use in production, and keep a written list of later improvements so nothing is lost by deferring it.
A price you can rely on is written against that scope. It should describe the workflows, roles, integrations, data to be migrated, and acceptance criteria, along with the assumptions behind it and how changes will be handled. If a proposal cannot tell you what is included, it cannot tell you what is excluded either.
Baybloom works from this kind of scope: we review the workflow and the systems around it first, put the scope in writing, and set the price before work begins. Whichever partner you choose, ask for the same, and ask how later phases will be estimated when their turn comes.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project