Describe the first useful outcome
Choose a person and a task. For example, a field officer submits a visit report, a supervisor requests a correction, and the approved record appears in a monthly export. This gives a development team something concrete to scope and demonstrate.
For a startup MVP, identify what early use should teach you. Include the main customer journey and the admin tools needed to support it. A first release can be small while still handling errors and protecting account boundaries.
Identify the work behind each screen
An approval button raises questions: who can press it, what must be complete, can a decision be reversed, and who receives a notification? Existing data and external systems add their own requirements. Record these rules before treating estimates as comparable.
- User roles, permissions, and account boundaries
- Normal steps, returned work, and other exceptions
- Data imports, cleanup, and migration checks
- External APIs and failure handling
- Reporting definitions and export formats
- Deployment, support access, and monitoring
Understand the main cost drivers
The visible interface is only one part of a custom application. Two projects with the same number of screens can require very different work when one has a single internal role and the other has customer accounts, approvals, imports, and an external payment or messaging service.
| Scope area | Questions to answer | Why it affects effort |
|---|---|---|
| Workflow and roles | Who creates, reviews, approves, corrects, and exports? | Each role and exception adds rules, states, and tests. |
| Data | What exists, how clean is it, and what must migrate? | Mapping, cleanup, trial imports, and reconciliation require separate work. |
| Integrations | Which external systems are required, and what happens when they fail? | API limits, authentication, retries, and vendor dependencies must be handled. |
| Operations | Who supports users, monitors the system, and deploys changes? | Admin tools, logs, alerts, documentation, and support shape the release. |
Make assumptions visible in the quote
Ask each team to state what is included, what is excluded, and what information is still needed. Specify who provides content and data, how many review rounds are planned, and how changes to the agreed scope are handled.
Recurring costs deserve their own line: hosting, external services, and ongoing support are different from the initial build. An AI feature may also introduce usage-based costs and evaluation work. Avoid comparing only the headline development amount.
Agree how you will accept the release
Use representative records and realistic scenarios to check the system. Define the expected result for the main workflow, an invalid submission, and a failed integration. Decide who signs off and what handover material is required.
Kabeli estimates custom software and MVP development after reviewing these requirements. Bring a sample form, current spreadsheet, or prototype, along with your priorities and constraints. We can use those to define the first release and a delivery plan.
Choose a commercial model that fits the uncertainty
A fixed price is easiest to compare when the workflow and acceptance criteria are already clear. If important rules or integration behavior still need discovery, forcing a precise fixed scope can hide assumptions rather than remove uncertainty. A short discovery or a phased estimate may be more honest.
For an evolving product, agree how priorities are selected, how often working software is reviewed, and how spending is reported. For a defined internal system, milestone pricing may be suitable. In either case, connect payments to understandable deliverables and keep ownership, third-party costs, and termination handover in writing.