A custom software buyer often asks:
How much will it cost?
How long will it take?
Those are reasonable questions.
The problem is answering them with false precision before the important unknowns are understood.
A project estimated at exactly 1,240 hours from a two-page requirement is not necessarily more rigorous than a range.
It may simply hide uncertainty.
Good estimation makes uncertainty visible and reduces it over time.
Estimate the Known Product, Not the Imagined Product
Start with what is actually defined.
If the requirement says:
Customer portal with payments and reporting
the estimate should not silently assume:
- Five user roles.
- Stripe.
- One currency.
- No migration.
- No mobile app.
- Simple reports.
- No SSO.
Those assumptions materially affect effort.
Write them down.
Actiknow’s custom software development approach uses discovery, architecture and explicit assumptions to make estimates understandable rather than presenting precision that the requirement does not support.
Use Discovery to Reduce the Range
Early estimates should be ranges.
As discovery answers questions, the range narrows.
For example:
Initial concept
$50k–$100k.
After workflows and integrations verified
$65k–$80k.
After design and technical spikes
$70k–$76k.
The exact numbers are illustrative.
The principle is that confidence increases with information.
Break the Project Into Workstreams
Estimate components separately.
Examples:
- Discovery.
- UX/UI.
- Frontend.
- Backend.
- Authentication.
- Admin.
- Integrations.
- Data migration.
- Reporting.
- Notifications.
- Testing.
- DevOps.
- Security.
- Launch.
- Project management.
This makes risk visible.
A simple UI with three difficult integrations is not a simple project.
Estimate User Journeys
Feature lists can hide workflow complexity.
Estimate journeys such as:
- Customer onboarding.
- Order placement.
- Manager approval.
- Technician job completion.
- Invoice generation.
- Admin configuration.
Each journey includes:
- Screens.
- Rules.
- Permissions.
- Errors.
- Notifications.
- Data.
- Integrations.
- Testing.
This produces a more realistic view than counting pages.
Estimate Exceptions
Normal paths are usually easy.
Ask how many exception paths exist.
Examples:
- Payment fails.
- Approval rejected.
- Customer changes request.
- API unavailable.
- Duplicate record.
- File invalid.
- Technician offline.
- User lacks permission.
Exception handling can represent substantial effort.
Estimate Integrations Separately
For each integration, evaluate:
- Documentation quality.
- Authentication.
- Sandbox.
- Endpoints.
- Rate limits.
- Webhooks.
- Data volume.
- Write requirements.
- Error handling.
- Reconciliation.
- Vendor support.
An integration with a mature API may be predictable.
A legacy vendor with partial documentation should carry a larger uncertainty range.
Verify High-Risk APIs
Run technical spikes where uncertainty is expensive.
Examples:
- Can the API return the required historical data?
- Can we create the required object?
- Does OAuth work for multi-tenant customers?
- Can the platform support required webhooks?
- Can the vendor handle expected volume?
A one-day spike can remove weeks of estimation uncertainty.
Estimate Data Migration as a Project
Migration includes:
- Source extraction.
- Profiling.
- Cleaning.
- Mapping.
- Transformation.
- Attachments.
- IDs.
- Duplicates.
- Historical logic.
- Load.
- Reconciliation.
- Cutover.
Do not estimate migration as “import CSV” until the data is inspected.
Estimate Permissions
RBAC adds effort.
Ask:
- How many roles?
- Are permissions configurable?
- Record-level scope?
- Tenant isolation?
- Approval authority?
- Admin overrides?
- Audit?
A simple employee/admin model is different from a complex enterprise entitlement system.
Estimate Non-Functional Requirements
Requirements such as:
- Offline support.
- High availability.
- SSO.
- Audit trail.
- Multi-tenancy.
- Large file upload.
- High concurrency.
- Accessibility.
- Localization.
- Disaster recovery.
can materially change architecture.
Include them explicitly.
Estimate Reporting Properly
“Dashboard” is not one unit.
Clarify:
- Number of reports.
- Metrics.
- Filters.
- Drilldowns.
- Exports.
- Real-time freshness.
- Security.
- Data sources.
- Historical comparisons.
- Embedded BI vs custom charts.
Reporting can be a separate workstream.
Estimate Design Based on Product Type
A back-office internal tool may need efficient functional design.
A consumer-facing product may require:
- Brand system.
- Responsive states.
- Animations.
- Onboarding.
- Empty states.
- Accessibility.
- Extensive usability iteration.
Do not apply one design percentage to every project.
Include Testing
Testing effort includes:
- Functional.
- Integration.
- Permission.
- Regression.
- Browser/device.
- Migration.
- Performance where required.
- Security.
- UAT support.
- Bug fixing.
A project estimate that includes development but not stabilization is incomplete.
Include DevOps and Environments
Plan:
- Development.
- Staging.
- Production.
- CI/CD.
- Secrets.
- Monitoring.
- Logging.
- Backups.
- Domains/certificates.
- Cloud setup.
- Deployment.
Operational readiness takes effort.
Include Project Management
Coordination is work.
Include:
- Planning.
- Client meetings.
- Backlog.
- Change management.
- Risk tracking.
- QA coordination.
- Release management.
- Documentation.
For multi-person teams, this is necessary delivery effort.
Use Three-Point Estimation for Uncertain Items
For a risky feature, consider:
- Optimistic.
- Most likely.
- Pessimistic.
This forces the team to discuss what could make the feature harder.
The final project range can reflect uncertainty instead of pretending every task has one deterministic duration.
Separate Scope Uncertainty From Execution Risk
1. Scope uncertainty
We do not yet know what is required.
2. Execution risk
We know the requirement, but implementation may be difficult.
Examples:
- Unclear approval rules = scope uncertainty.
- Documented API with known low rate limit = execution risk.
They need different mitigation.
Use Assumptions
An estimate should list assumptions.
Examples:
- Client supplies final content.
- One payment gateway.
- English only.
- No offline mode.
- Up to 10,000 monthly active users.
- Existing data supplied in agreed template.
- Third-party APIs available as documented.
- One UAT cycle of defined duration.
When an assumption changes, the estimate can be revisited transparently.
Use Exclusions
State what is not included.
Examples:
- Native mobile apps.
- Legacy hardware integration.
- Data cleansing beyond agreed rules.
- Third-party license fees.
- 24/7 support.
- Content creation.
- Advanced analytics.
Exclusions prevent expectation drift.
Use Contingency Intelligently
A risk buffer is not laziness.
It acknowledges uncertainty.
But avoid one arbitrary 30% added to everything.
Apply more contingency to:
- Unverified integrations.
- Legacy migration.
- Offline sync.
- New technology.
- External approvals.
- Unclear workflows.
Apply less to well-understood repeated patterns.
Separate Estimate From Budget
An engineering estimate predicts effort.
A project budget may also include:
- Contingency.
- Change allowance.
- Licenses.
- Cloud.
- Support.
- Training.
- Travel.
- Internal client effort.
Keep these concepts distinct.
Fixed Price Requires a Scope Boundary
A fixed price can work when:
- Deliverables are clear.
- Assumptions are explicit.
- Acceptance criteria exist.
- Change control exists.
- Unknowns are limited or priced into risk.
Fixed price does not make uncertainty disappear.
Someone absorbs it.
Time and Materials Can Fit Evolving Scope
T&M can be appropriate when:
- Product discovery continues.
- Priorities may change.
- Client wants flexibility.
- Unknown integrations exist.
- Work is iterative.
Governance should still include:
- Budget.
- Sprint plan.
- Burn tracking.
- Priorities.
- Forecast.
T&M should not mean uncontrolled spending.
Consider Paid Discovery for High Uncertainty
If the project cannot be estimated responsibly, estimate discovery first.
Discovery can produce:
- Requirements.
- Wireframes.
- Architecture.
- Integration validation.
- Data assessment.
- Delivery plan.
- Refined estimate.
This is more credible than adding a huge hidden contingency.
Use Milestone Estimates
Instead of one giant commitment, estimate stages.
Example:
- Discovery.
- MVP.
- Integration expansion.
- Migration.
- Production hardening.
This allows decisions as information improves.
Track Estimate vs Actual
After each project, compare:
- Estimated hours.
- Actual hours.
- By workstream.
Analyze variance.
Examples:
- Integrations consistently underestimated.
- QA consistently underestimated.
- Design accurate.
- Migration highly variable.
Historical calibration improves future estimates.
Update the Estimate When Scope Changes
If a client adds:
- New role.
- New integration.
- Offline mode.
- New report suite.
do not silently absorb it.
Assess:
- Effort.
- Timeline.
- Dependencies.
- Risk.
Then update the plan.
Change control protects both sides.
Do Not Penalize Teams for Discovering Reality
A healthy project surfaces unknowns early.
If every newly discovered requirement is treated as estimation failure, teams will hide risk.
Create a process where assumptions can be challenged.
Transparency produces better forecasts.
Communicate Confidence
An estimate should state confidence.
For example:
1. Low confidence
Concept only, major integrations unverified.
2. Medium confidence
Core workflows defined, some technical unknowns.
3. High confidence
Design, acceptance criteria and integrations validated.
This helps executives understand how to use the number.
A Practical Estimation Sequence
- Define business outcome.
- Map users and journeys.
- Prioritize version-one scope.
- Inventory integrations.
- Assess migration.
- Define non-functional requirements.
- Identify high-risk unknowns.
- Run technical spikes where needed.
- Estimate workstreams.
- Add risk-based contingency.
- State assumptions and exclusions.
- Choose commercial model.
- Publish range and confidence.
- Reforecast as discovery continues.
What a Good Estimate Document Contains
A useful estimate includes:
- Scope summary.
- Deliverables.
- Workstreams.
- Effort/cost range.
- Timeline range.
- Team.
- Assumptions.
- Exclusions.
- Dependencies.
- Risks.
- Third-party costs.
- Change process.
- Confidence.
- Next step.
The reader should understand what would cause the number to change.
Frequently Asked Questions
Why are custom software estimates given as ranges?
Because early requirements contain uncertainty. A range communicates that honestly and should narrow as workflows, integrations and architecture are validated.
Can a custom software project have a fixed price?
Yes, when scope, assumptions and acceptance criteria are sufficiently clear and changes are managed explicitly.
How much contingency should a software estimate include?
There is no universal percentage. Contingency should reflect specific risks such as unverified APIs, migration quality, offline sync or unclear workflows.
Why is data migration often underestimated?
Because effort lies in profiling, cleaning, mapping, historical rules, reconciliation and cutover rather than the final import command.
Should discovery be paid?
For complex projects, paid discovery can be a sensible standalone phase because it produces valuable product and architecture decisions and reduces implementation uncertainty.
How often should the estimate be updated?
When material scope, assumptions or risks change, and at planned project checkpoints.
What makes an estimate trustworthy?
Transparent assumptions, decomposed work, validated high-risk areas, historical calibration and clear change control are more useful than false numerical precision.
Conclusion
A good custom software estimate does not pretend uncertainty is gone.
It shows where uncertainty exists and how the team will reduce it.
Break the project into real workstreams.
Estimate workflows and exceptions.
Validate integrations.
Treat migration seriously.
Include testing and operations.
State assumptions and exclusions.
Use ranges until the evidence supports tighter commitments.
If you are budgeting a custom software project and need a defensible scope, architecture and estimate, Actiknow can help run discovery and turn the requirement into a practical delivery plan. Discuss your custom software project with Actiknow.