Use published prices in their proper context
Digizu’s FAQ describes complex website platforms with bookings or custom integrations at £10,000+, compared with a £2,500 starting point for a focused marketing site. The £10,000+ indication is not a promise that every application can be delivered for that budget, and it does not establish a fixed CRM or booking-system price.
For a custom system, an estimate needs a definition of what staff and customers can do, where data comes from and what must happen in unusual cases. If those requirements are unsettled, ask which parts can be priced confidently and which need investigation.
The cost drivers to put in the brief
| Area | A question that changes the work |
|---|---|
| User roles | Can every staff member do the same things, or are approvals and restricted records involved? |
| Business rules | What happens when a booking changes, a price is overridden or a deadline is missed? |
| Data migration | Can existing records be imported cleanly, and who resolves conflicting values? |
| Integrations | Does the external system allow the required reads and writes? |
| Testing | Which mistakes would interrupt operations or require manual repair? |
| Operations | Who monitors failures, updates dependencies and restores backups? |
A booking example: the exception costs matter
Consider two illustrative briefs. One takes a booking request and sends it to a person who checks availability. The other promises immediate confirmation against shared capacity, takes a deposit and lets staff change dates. They may look similar in an early mock-up but have very different responsibilities.
The second brief needs rules for simultaneous requests, abandoned payments, late confirmations, refunds and corrections. Those rules must be tested. Our booking payments guide describes why a successful checkout screen is only part of the work.
Separate a useful first release from later ideas
Choose one complete workflow that produces a worthwhile result. A first release could replace a particular manual handover while leaving existing reporting in place. It should still include the permissions, error handling and support needed to operate safely. Removing recovery controls to meet a budget usually transfers the cost to the team using it.
Put later ideas in a separate list with the reason they matter. A supplier can then explain what the first release needs to leave room for, without building every possible feature immediately. The spreadsheet replacement guide can help decide whether an application is justified at all.
Budget for ownership and change
Ask for separate figures or assumptions for initial discovery, implementation, data preparation, third-party charges, hosting, support and subsequent changes. Include the time your team will spend answering questions and testing the system. A project can be delayed by an unresolved business rule even when the development work is ready.
Agree who owns the source code and accounts, how documentation is delivered and how another developer could take over. Clarify which recurring costs vary with users, messages or transactions. Compare the whole arrangement with a suitable off-the-shelf product, including the work needed to configure and adopt that product.
How long will development take?
There is no reliable application timeline without scope. Ask for milestones tied to evidence: agreed workflow, tested external connection, working end-to-end journey, migrated sample data and user acceptance. An integration investigation may need to happen before a delivery date can be committed.
For Digizu’s bespoke development service, start with the operational problem and a representative record. Do not send private customer data just to obtain an initial estimate; a fictional example with the same fields is usually enough to explain the workflow.
Discuss an application scope
Bring the users, the core workflow and the systems involved. We can discuss a sensible first release and what needs investigating before a quote.