Bespoke software
We compare buying, configuring, integrating and selectively building around one costly workflow. Existing systems stay where they work; a custom layer needs a credible operating-cost case and an accountable owner.
What changed
AI assistance can change engineering effort, but gains depend on the task, team and controls. Compare complete implementation and support costs, not a speed multiplier.
Value is no longer "a better screen". It is a workflow that runs from intake to reporting with people approving the decisions that matter. That has to be built around your process.
Where contract terms assign it, your process logic, data and rules can become an asset you own and improve, with documented export and exit terms.
Side by side
| Seat-based software | Bespoke, owned | |
|---|---|---|
| Fits your process | Standard workflows may fit; configure where practical | The system is built around the real process |
| Cost curve | Depends on licenses, usage and configuration | Build, support, integration and usage costs can vary |
| AI | Vendor capabilities may already meet the need | Agents on the steps that carry your cost |
| Data | Split across tools, exported to spreadsheets | Connect existing records; agree source and access ownership |
| Lock-in | To the vendor's roadmap and pricing | To your own code and documentation |
| Time to value | Setup and adoption depend on workflow fit | Schedule depends on scope, access and acceptance |
Three delivery forms
An API or headless service works inside the systems people already use — a ticket queue, ledger or inbox. No new screen is a deliberate choice, not a universal goal: people still need visible approvals, progress, recovery and evidence where they already work.
A text or voice panel, or an interface generated for the task at hand, inside an existing product. Generated views still need accessible structure, keyboard operation, clear state and a way to correct or stop the task.
Built only when the workflow needs its own records, roles and screens that configuration or integration cannot reasonably provide. Ownership, support and exit terms are agreed before build.
Whichever form fits, human-visible approval, accessibility, progress, recovery and evidence remain requirements.
Run your numbers
Change the inputs to your situation. The formula is shown underneath — nothing is hidden.
Illustrative capacity-inclusive scenario difference, not guaranteed cash savings. All user-entered costs use illustrative USD assumptions, not a DeftSpan quote or rate. Existing = subscriptions + manual capacity. Custom = build + transition + retained subscriptions + run + remaining capacity. Salary cost is not automatically removed; released hours must have a useful purpose. Enter all support, model and integration costs. Adoption timing, growth and tax are not modeled.
Adapting open source
Open source can cover much of a need, but not every solution is fully open source, and source availability does not grant unrestricted rights.
Further reading: Open Source Initiative — The Open Source Definition. Source availability alone is not proof of meeting the definition; this is not legal advice.
How software is paid for
These are models in the market, not offers. We do not list service prices. Future USD proposals follow understanding your needs; scope and terms require agreement. Compare engagement options on the pricing page; no outcome-based price or guarantee is offered.
The illustrative scenario calculator separates cash from capacity; it is not a pricing or savings promise.
Honest limits
Email, payroll, video calls, general ledger. Rent the best tool and move on — nobody wins by rebuilding Gmail.
If the team changes how it works every month, map and settle the process first. Software freezes chaos.
An owned system needs someone accountable for it. If no one will own it, we either provide run support or recommend you don't build.
The journey
01
Agree a diagnostic scope using redacted samples; system access needs separate approval.
02
Compare buy, configure, integrate, selective build or stop; decide what stays human.
03
A bespoke system and agents around your real workflow and data.
04
Agree staffing, support and acceptance before any operating phase.
05
Measure against the baseline agreed in the audit. Compare observed results and costs; no ROI is guaranteed.
What each person receives
User
Needs: A system that matches how the team actually works, not how the vendor imagined it.
Doubt: Custom software sounds slow, risky and hard to maintain.
Proposed deliverables · agreed in scope
Buyer
Needs: A cost case that holds against current seat spend and manual hours.
Doubt: The return will be asserted, not measured.
Proposed deliverables · agreed in scope
Approver
Needs: Something supportable that does not add shadow IT.
Doubt: Another system the IT team will be left holding.
Proposed deliverables · agreed in scope
Affected
Needs: Less re-keying and fewer workarounds.
Doubt: Automation will be imposed without asking them.
Proposed deliverables · agreed in scope
Access is limited to the department in scope and logged.
Initial inquiry: non-sensitive summary only. Later assessment: authorised redacted samples or read-only access. Sandbox and production write access require separate approval, minimisation, access expiry and retention agreement.
Agree revocation, working-copy handling, retention exceptions and confirmation responsibilities before access.
Next step
The opportunity audit maps how work really moves through one department and tells you, in numbers, what to build first — or that you shouldn't.