Start with one recurring problem
Write down who does the work, what starts it, what tools they use and where delays or errors arise. A distributor might need one reliable order status across sales and dispatch. A retailer might need to trace stock transfers between outlets. These are clearer starting points than “we need an app”.
Record a baseline before changing the process: time spent preparing a report, unresolved orders at closing, or stock differences found during a count. Compare the same measure after rollout. Treat any improvement as something to measure in your business.
Decide whether a custom build is necessary
Check whether an improved spreadsheet, existing software or an integration can solve the problem. A custom build deserves consideration when important rules, approvals or connections cannot be handled adequately by the available tools. Include subscription, setup, migration and ongoing support when comparing options.
Read our guide to replacing spreadsheets.
Separate the first release from later ideas
Choose the smallest complete workflow that a real user can finish. An order tracker might include creating an order, assigning a status, restricting edits and exporting an open-order report. Forecasting and a mobile app can remain later decisions. Include exceptions such as cancellations, duplicate entries and interrupted internet access in the discussion.
What affects custom software cost?
There is no reliable price without a scope. Cost depends on the work needed and the conditions under which the system must operate. Ask each developer to explain these items explicitly:
- Workflows, user roles and approval rules.
- Data quality, migration volume and historical records.
- Connections to accounting, payment or other systems.
- Reporting, devices, performance and access requirements.
- Testing, training, deployment, hosting and support.
Compare what each proposal includes, its assumptions, recurring charges and the process for pricing changes. A lower headline price may cover a different amount of work.
Write checks that define “finished”
The following is an illustrative checklist for an order tracker, not a claim about a delivered client project:
| Requirement | Check before acceptance |
|---|---|
| Order entry | A user can save an order with its required details and a unique reference. |
| Staff permissions | A sales user cannot perform an edit reserved for the manager. |
| Status history | The team can see who changed an order status and when. |
| Open-order report | The export matches a known sample of open orders and agreed totals. |
Agree ownership and support in writing
Clarify ownership or licensing of code, repository access, control of domains and hosting accounts, data export and third-party subscriptions. Agree backup responsibilities, restore checks, staff training and what happens if you change suppliers. Define the warranty period, support hours and how future changes will be handled.
Prepare for the first discussion
Bring a process sketch, anonymised sample records, current tools, expected users, your main constraints and one measurable outcome. You do not need to share passwords or confidential customer records to explain the problem.
Use the project brief planner to turn these answers into text you can copy, download or choose to share. For a relevant example of our own work, read the WOOL O WOOL family-business case study.
Discuss your workflow with iFactory India
We build custom business software, e-commerce websites and billing and inventory systems. A first discussion can help clarify the problem and the next step; implementation scope and pricing are agreed separately.