Short answer
Price is driven by integrations, user roles, anything touching payments or personal data, and how much is still undecided at the start — not by the number of screens. Fix the first deliverable narrowly so the price can be fixed too, and get it into real use in weeks. Watch the process happen before specifying it, because scope agreed with someone who does not do the work is the single largest source of rework. Settle ownership, hosting and post-delivery support in writing before anyone starts.
What actually drives the price
Quotes for custom software look arbitrary from the outside because the visible surface — screens, buttons, reports — is not what costs. Four things are.
| Driver | Why it costs | How to reduce it |
|---|---|---|
| Integrations | Every connected system is an interface you do not control, with its own auth, limits and failure modes — and it can change without warning. | Connect two systems in version one, not five. Add the rest once the first is running. |
| Roles and permissions | Each distinct role multiplies what has to be built and, more expensively, what has to be tested. | Start with one role. Most internal tools need fewer than the org chart suggests. |
| Payments and personal data | Both bring obligations that do not scale down for small projects: storage, access, retention, audit. | Use established providers for payments; hold the minimum personal data the process needs. |
| Undecided scope | Decisions taken during a build are the most expensive kind, because work gets redone around them. | Decide the first process completely. Leave the rest openly undecided rather than vaguely decided. |
Why the first version should embarrass you
In LYVIA’s experience the strongest predictor of a custom software project going well is how narrow the first deliverable is. Narrow enough that describing it feels underwhelming — one process, one role, one integration, in production with real work going through it.
Two reasons, and the second matters more. A narrow scope can be priced honestly, which protects both sides. And real usage produces information that no specification round can: which steps people skip, which exception happens weekly rather than annually, which field nobody fills in. Every subsequent decision is then made against evidence instead of against opinion.
The alternative — build the whole thing, then launch — front-loads every assumption and discovers the wrong ones at the most expensive moment.
Specifying without writing fiction
A complete specification written before anyone has used anything reads well and ages badly. The parts you were most confident about are usually the first to change.
What works instead is asymmetric detail. The first process gets specified precisely: the trigger, each step, what happens on each exception, and what “done” looks like. Everything else is listed as a heading with no detail, explicitly marked as not yet decided. That distinction is worth being pedantic about — a vaguely specified feature gets built to someone’s guess, while an openly undecided one gets a conversation.
A good test for the first deliverable: can you describe it in two sentences, and can you name the person who will use it on day one? If either answer is fuzzy, the scope is not ready to be priced.
The hour that prevents the rework
In LYVIA’s own engagements, most rework traces to the same origin. The person commissioning the tool describes the process as they understand it. That description is sincere and incomplete, because the exceptions live with the people who handle them, and those people were not in the room.
The remedy is unfashionably simple: watch the process happen. Sit with whoever runs it, for a real cycle, and note what they do that is not in the description — the second spreadsheet, the message they send to check something, the case they handle differently on Fridays. Those are the details that break a specification, and they surface in an hour of observation rather than a week of meetings. It is the same discipline as a proper process audit, applied to a build rather than to a choice.
What belongs in the contract
- Ownership of code and configuration, with the right to modify it and to have a third party modify it.
- Hosting under your accounts. Cloud, database, model provider, domain — in your company’s name, with credentials you hold.
- A repository you can access throughout, not delivered as an archive at the end.
- What happens after go-live: who watches, who fixes, response expectations, and the cost. The most commonly omitted clause and the most expensive to negotiate later.
- Documentation as a deliverable, not a favor. Short is fine: what it does, where it runs, what it connects to, how to get in.
- An exit procedure. What is handed over, in what form, within what period.
None of this is adversarial, and a supplier who works this way has already thought about what happens after the engagement — which is itself the signal. The wider version of these criteria is in our buyer’s guide to choosing an AI automation agency.
Life after delivery
Custom software that connects to other software has a maintenance floor above zero, permanently. An interface changes, a certificate expires, a provider deprecates a version, volumes grow past an assumption made quietly during the build.
Plan for three things. Someone who notices — monitoring that reaches a person rather than a log nobody opens. Someone who fixes, internal or contracted, with an agreed response time. And a small recurring budget, because a tool that nobody is funded to maintain degrades until the workaround becomes the process. The infrastructure side of this is covered in our guide to AI infrastructure.
Where AI changed the economics, and where it did not
Writing code is faster than it was, and that is a real change to the cost of a first version. It is a smaller change to the cost of a project than the discourse suggests, because the expensive parts were never the typing.
Specification, integration against systems that resist it, security review, testing across roles, support, and the ongoing cost of keeping the thing alive are all roughly where they were. What has genuinely shifted is the threshold for trying: building a narrow first version to find out whether the idea holds is now cheap enough to do speculatively. Use that. The trap it creates is a prototype that quietly becomes production without ever getting the review it would have had — which is precisely the case for deciding, before you start, whether this should have been bought instead: custom tools versus off the shelf.
Signals a project is going wrong
- Nothing usable exists after several weeks. Not a delay problem — a scope problem.
- Demonstrations instead of access. If you are shown the tool rather than given it, the gap between demonstration and production is being hidden.
- The specification keeps growing during the build. Each addition sounds small and the compounding is not.
- Only one person understands it, on either side. On theirs it is a delivery risk; on yours it is a dependency you created.
- Maintenance has never been discussed. The proposal priced the easy half.
Where a build sits against everything else you might spend the year on is in our AI strategy roadmap.
Frequently asked questions
What drives the cost of custom software?
Four things, and none of them is the number of screens. Integrations with systems you do not control, the number of distinct user roles and what each may see, anything touching payments or personal data, and how much of the specification is still undecided when work starts. A project with one integration and one role costs a fraction of one with five integrations and four roles, even when they look similar in a demonstration — an order of magnitude LYVIA sees across its own engagements, not a published benchmark.
How long does it take?
The pattern from LYVIA's own delivery, rather than a published benchmark, is that a first version doing one process end to end is measured in weeks, not quarters — and if a proposal describes months before anything is usable, the scope is wrong rather than the estimate. What genuinely takes time is not writing the software but getting access to the systems it must connect to, and getting decisions from the people who own the process.
Should we specify everything up front?
Specify the first process completely and the rest loosely. A full specification written before anyone has used anything is an expensive work of fiction: the parts you were most sure about are the ones that change once real work goes through the tool. Fix the scope of the first deliverable tightly so the price can be fixed too, and leave the rest deliberately open.
Who owns the code?
Whatever the contract says, which is why it must say so before work starts. At minimum: the code and configuration are yours, hosted on infrastructure in your name, with credentials you hold and a repository you can hand to someone else. A supplier hosting everything under their own accounts has made leaving expensive whether or not that was the intent — the same test as for any partner, set out in our buyer's guide to choosing an agency.
What happens after delivery?
Something breaks, because software that connects to other software always does — an interface changes, a credential expires, a volume assumption stops holding. Budget for it explicitly rather than discovering it. The arrangement to agree before launch is who watches, who fixes, how fast, and at what cost, because negotiating that during an outage is expensive in every sense.
What is the most common reason these projects go wrong?
Scope agreed with someone who does not do the work. The person who commissions describes the process as they believe it runs, the tool is built to match, and the people who actually run it turn out to handle exceptions nobody mentioned. As a working rule from LYVIA's own engagements rather than a published benchmark, an hour spent watching the process happen prevents more rework than a week of specification meetings.
If you have a process worth building around, the useful first conversation is about how narrow the first version can be — not how complete it should be. Book a call.
