The initial price does not prove the quality of a software project. Reusing components, cutting features or using an existing service can reduce cost sensibly. Problems arise when a quote excludes work someone will still have to do: correcting records, updating dependencies, responding to incidents or moving the system to another supplier.
Before choosing, I separate savings from deferred work. This guide assesses cost over the life of a product. For deliverables and purchasing terms, use the guide to comparing custom software quotes.
How to calculate software total cost of ownership
Choose the same horizon for every option: for example, 24 months from the start of the project. This is a comparison period, not a promised product lifespan. Record when each cost begins, expected usage and who pays. An unknown cost remains an open question; do not enter it as zero.
Period cost = initial investment + recurring expenses + planned changes + internal work + transition or closure. Record the consequences of possible incidents separately as risk scenarios. If they occur, include their cost without counting the same hours or losses twice.
| Category | What to include | How to verify it |
|---|---|---|
| Initial delivery | Discovery, development, migration, testing and training. | Included deliverables, internal tasks and written exclusions. |
| Operations | Hosting, licences, storage, backups, APIs and monitoring. | Billing units, limits and the start date of each service. |
| Maintenance | Fixes, updates and adaptation to external changes. | An owner, coverage, review schedule and separately priced work. |
| Internal work | Manual review, data reconciliation, support and coordination. | Hours observed in a pilot, frequency and an owner. |
| Product changes | Known changes to processes, volume or integrations. | Assumptions for each scenario and who approves spending. |
| Exit or closure | Data export, access transfer, documentation and service shutdown. | A usable export and a tested handover procedure. |
Calculate one scenario at pilot usage and another at the volume the business wants to assess. Use verified current rates, clearly labelled estimates and measured internal effort. Valuing those hours helps compare options, but freeing them does not automatically reduce payroll. I do not apply a universal maintenance percentage or assume that custom development always beats an existing tool.
What you can simplify without deferring the problem
I would first reduce target users, integrations, visual customisation and secondary features. Manual review can be sensible at low volume if someone owns it and has the capacity. The idea-to-MVP guide explains how to narrow the first release to a testable business decision.
For the workflow entering production, make permissions, data recovery and error handling explicit. Their depth depends on the process risk. A demo without live data can have different limits from a system already handling orders; the proposal should identify which one is being delivered.
What included maintenance actually covers
“Maintenance included” is not enough to estimate cost. I would ask for these responsibilities to be separated:
- Corrections: which agreed behaviour is covered, for how long and how the fix is verified.
- Updates: who reviews dependencies and external services, tests changes and schedules deployment.
- Operational support: who receives an alert, during which hours and how the business continues while it is investigated. Response time and resolution time are different commitments.
- Product development: which new features need another estimate and who approves the work.
State coverage limits, third-party usage charges and what happens when prepaid hours run out or an API changes. A subscription does not remove these decisions; it may distribute them between your team and several suppliers.
The Adslyfy case study shows execution records, failures and screenshots used to investigate ad checks. It demonstrates specific operational components, not a price or savings benchmark. The ability to inspect what happened still needs an owner who acts on it.
Example: an internal request-management tool
Imagine a tool that receives requests, assigns an owner and records resolution. This is a hypothetical example. One option leaves assignment to a person; another adds automatic rules, change history and an exception queue. I would not compare their prices as though they delivered the same thing.
During a pilot, I would measure how many requests need review, time spent on each one, errors and who resolves them. Manual effort for the period can be estimated as requests reviewed × minutes per review ÷ 60. To express it as a cost, use a documented internal hourly cost. Keep fixed supervision time separate and avoid counting it again as support.
The manual option may fit when volume is low and the person is available. Automation may justify a later phase when measured workload, delays or errors exceed an agreed limit. The decision depends on process data, not a generic savings promise.
Continuity checks before accepting delivery
- Deploy the agreed version using documented steps and company-controlled accounts.
- Restore a backup in an isolated environment and inspect the recovered records.
- Simulate an external service failure and locate the pending request without losing it or processing it twice.
- Verify that an alert reaches a named person with enough information to act.
- Export the agreed data and open it outside the tool, preserving the required relationships.
- Check that another authorised person can follow the operating procedure and revoke the previous operator's access.
Record what was tested, the result and unresolved limits. Repository access alone does not establish that another team can operate the product. Clarify licences for reused components and the access needed to deploy it.
If the software exists already: repair, maintain or replace
A low-cost purchase that has caused problems does not automatically require a rebuild. I would first inspect the critical workflow, repeated incidents, dependencies and the ability to deploy and restore. The existing Laravel project audit offers a technical starting point for that diagnosis.
Compare remaining costs from today, including migration and parallel operation where necessary. Money already spent does not establish that continuing is better. It also does not justify a rewrite without evidence. A bounded repair, gradual retirement or standard tool may be valid options.
What to prepare for an investment review
Bring the process you need to improve, current volume, manual tasks, connected systems and what each proposal includes. Mark confirmed costs, estimates and unresolved items. I can use that to help scope custom software and SaaS development or review the decision through my technical CTO work.
If you are considering a purchase or recovery project, tell me about the problem and your budget constraints. The first step is identifying the information needed to decide, without sharing credentials or customer records.