A custom database is rarely priced by the number of tables. The real work sits in how people create, validate, find, change and trust the information—and how safely existing records move into the new system.
This guide avoids universal price bands because they often hide assumptions about workflow, data, integrations, quality and support. A credible budget explains what is included, what remains uncertain and how the first investment will produce evidence.
Begin with the business boundary
Define the users, outcome and smallest end-to-end workflow that must work. List the systems and data it depends on, the operational exceptions that matter and what can wait. This creates an estimable release rather than an open-ended feature list.
- scope, exclusions and acceptance criteria;
- assumptions about data, integrations and client decisions;
- discovery, design, engineering, QA, release and handover;
- third-party, infrastructure and ongoing operating costs; and
- a clear method for resolving uncertainty and change.
The main cost drivers
- Data domains, relationships and validation rules
- User roles, approvals and audit history
- Search, reporting, exports and operational dashboards
- Migration quality, reconciliation and rollback
- Integrations with CRM, ERP, finance or external APIs
- Availability, backup, retention and security requirements
These drivers interact. A small interface can still require substantial work when permissions, migration or external systems are complex. A larger interface may be comparatively predictable when workflow and data are clean.
Common scope patterns
- A focused internal database with a small set of roles and one workflow
- An operational platform combining workflow, reporting and multiple integrations
- A governed data product with migration, complex access and assurance requirements
These patterns are not fixed packages. They help separate a focused first release from the broader operating model that may follow.
How to estimate without false precision
Start with a range while uncertainty is high. Investigate the assumptions capable of changing the estimate materially, then refine the range as workflows, data and integration behaviour become observable.
- Frame the outcome. Define users, success and the release boundary.
- Map scenarios. Include critical exceptions, roles and acceptance evidence.
- Test uncertainty. Validate integrations, data and technically risky assumptions.
- Estimate the whole delivery. Include discovery, design, QA, release and coordination.
- Show assumptions. Separate known scope, exclusions and unresolved risk.
- Include ownership. Make post-launch infrastructure, support and change visible.
Questions to prepare
- Which decisions or workflows depend on this data?
- Who creates, approves, corrects and exports records?
- What existing data must move, and who owns its quality?
- Which systems remain the source of truth?
- What audit, privacy, retention and recovery obligations apply?
Reduce cost by reducing uncertainty and breadth
Protect the one journey that creates business evidence, defer optional flexibility, validate expensive dependencies early and use established services for commodity capabilities where they fit. Cost reduction should remove low-value scope—not testing, security, migration controls or operational readiness.
Need an estimate grounded in your actual workflow?
Share the users, current process, data and integrations. We’ll identify the questions needed to define a credible first release.