Built, then run. Not built, then handed over.
Ordering. Reporting. Warranty and claims. Stock visibility. The systems a business actually runs on, that no off-the-shelf product quite fits, because the way you work is not the way the product assumed.
Those get built as projects, and that is where it goes wrong.
The problem with a finished project
A build has an end date. On that date the system becomes yours, which sounds like the good outcome and is usually the expensive one.
Because now it needs somebody. Something changes at a supplier and a feed breaks. A browser update changes a behaviour. Somebody leaves and takes the only understanding of it with them. A dependency needs patching. None of that was in the scope, because none of it had happened yet.
So the system quietly decays, everyone works around it, and eighteen months later the business is quoting for a replacement. The replacement will be built by someone else, as a project, with an end date.
The other shape
Splide builds the system and then runs it, priced per system, with no end date and no handover event.
An operations base that covers keeping it alive: hosting, monitoring, backups, dependency and security updates, the small breakages, and being the person who answers when it stops.
Development capacity, in days per month, for the changes the business actually asks for. Systems that are used get change requests. Building that into the arrangement is more honest than pretending a system is ever finished, and it means an improvement is a conversation rather than a quote.
The base does not decline over time. It is not a payment plan for the build, and there is no point at which it has been paid off and the system is on its own again. You are paying for it to keep working, which is a thing that never stops being needed.
The clause that matters
This is the part worth reading twice, because it is the part that makes the arrangement safe to enter.
The fee buys operations. It never buys permission.
Stopping the fee stops us keeping the system alive. It does not stop your access to the system. It does not stop your access to a single row of your data. The system is yours, the data is yours, and nothing is architected to make leaving painful.
That is deliberate, and it is not generosity. An arrangement you can leave is one you can also stay in on the merits. If the only reason a client is still paying is that leaving would cost them their own data, the work stopped being good some time ago and everyone involved knows it.
What we do not do
We do not sell builds on their own. If what you want is a system delivered and handed over, we are the wrong firm, and it is better for both of us to find that out in the first conversation.
We also do not take on a system we would not be prepared to run for years. That constrains what we agree to build, on purpose.
Starting
A conversation about the process the system would serve, not about features. Most of these projects are shaped by how the work actually happens, which is never what the initial brief describes.