splide/build

Built, then run. Not built, then handed over.

Ordering, reporting, warranty, claims, stock visibility and the operational systems no off-the-shelf product quite fits. Splide builds them around the way the business actually works, uses agents where context and judgment help, and remains responsible after launch.

The problem with a finished project

A software project has an end date. A business process does not.

A supplier changes a feed. A browser changes a behaviour. A person leaves with the only explanation of an exception. A new product, claim type or reporting question arrives. None of it was in the original scope because none of it had happened yet.

The system slowly decays, people work around it, and eventually the business pays to replace something that was described as finished.

Splide uses the other shape: build the system, operate it and keep changing it as the business changes.

Where agents genuinely help

Not every system needs AI. A useful business system should know when a rule is enough and when the work depends on context.

Totals, permissions and state transitions remain deterministic. Agents become useful where the system needs to interpret messy input, connect information from different places, retain the reason behind a decision, investigate an exception or coordinate work that does not fit a fixed path.

Adja gives those agents persistent organisational memory. They can carry decisions and corrections forward rather than treating every interaction as a first meeting. The model is a component; the business history remains owned separately.

The point is not to make the interface look intelligent. It is to make the operation more capable without making it less accountable.

What this looks like in practice

A bicycle distributor runs warranty claims, service bookings and courier bookings on a platform Splide built around its real operating process.

The client paid for the system and owns it outright. It is not rented from Splide and it is not held over them.

Splide still runs it. Years after launch, it is hosted, monitored, patched and changed when the business needs it changed. A separate reporting layer runs as a subscription because reporting is used continuously and therefore changes continuously.

The system is theirs. The operating of it is ours. The two are priced separately and honestly.

The operating model

An operations base

The base covers keeping the system alive: hosting, monitoring, backups, dependency and security updates, small breakages and one accountable place to call when something stops.

Development capacity

Agreed capacity each month covers changes to the system and the process around it. Used systems generate change requests. Building that into the relationship is more honest than pretending the system will ever be finished.

Memory that compounds

The people and agents working on the system retain why it was built a particular way, what changed and which assumptions no longer hold. The relationship should become more useful with time, not more dependent on archaeology.

The operations base does not decline as though it were a payment plan for the original build. The fee is for the continuing work of keeping a live system useful.

The clause that matters

The fee buys operations. It never buys permission.

Stopping the fee stops Splide hosting, monitoring and changing the system. It does not stop the client's access to the system or to a single row of its data. The system and the data remain the client's, and nothing is designed to make leaving painful.

An arrangement a client can leave is one they can choose to keep on its merits.

What we do not do

Splide does not sell standalone builds that end in a handover. If the requirement is "deliver the software and disappear", this is the wrong firm.

We also do not agree to build a system we would be unwilling to operate for years. Knowing that we will live with the consequences changes the decisions made at the beginning.

Starting

The first conversation is about the work, not a feature list.

Who does what? Where does information arrive? Which exceptions consume the most judgment? What already exists? Where is the same fact entered twice? What happens when the process fails? Which part should remain a rule, and where would memory or an agent genuinely improve the result?

The initial brief is useful. The operation underneath it is what the system must fit.

Build the system around the business. Keep it useful as the business changes.

Talk about the process