We adopted it to reduce work, and it created more

This is the first of two articles. The second, Why building is exciting now, picks up where this one ends.

lapal lab has built and proposed a range of commercial services, including many in the SaaS model. When several companies share one product, development and operating costs are shared, and every improvement reaches everyone. We still think that value is real.

What happened after adoption was a different story. Getting one product to settle into one company’s work took far more resources than we expected, and more than once we watched one piece of work create the next. A product assumes certain systems and processes, and a company works in its own way. There is always a gap between the two, and that gap is usually filled by people. You adopt something to reduce work, and then you need someone to look after the work it created.

Connected did not mean finished

The first example is ERP integration. An item approved in the SaaS can still be rejected by the ERP, for instance when it falls in an accounting period that has already been closed. Two systems can be connected, and one can refuse what the other considers done. Then someone has to watch where each item stopped, send it again, and compare the two systems to see whether their results agree. Building the integration did not end the work. Watching it and keeping it consistent became new work.

Approvals and permissions went the same way. Approval lines and delegation rules change whenever the organization changes. After a reorganization, departments and positions change, and approval settings must follow. Then the questions start: what happens to requests already in progress, and how far does a delegation reach? Changing the settings did not settle it. Sometimes a person had to decide who would take over which request.

Similar things kept happening elsewhere. Master data such as items and business partners did not match across legacy systems, and had to be cleaned up before anything could be connected. In flows that ran from order to WMS, TMS and ERP, a partial failure, where some steps succeeded and others did not, meant that people had to recover things by hand.

A product cannot absorb every difference

We do not think this is SaaS being wrong. A shared product cannot reflect every industry, domain and vertical one by one. Leaving some differences out is a choice a shared product has to accept, because standardization is what makes it efficient.

The trouble starts when exceptions pile up. If you accept each customer’s exception one at a time, the shared product gets more complicated, and every user pays for that complexity. Some customers also ask, for security reasons, for a dedicated database or separate infrastructure. Managing more things customer by customer adds to the operating burden.

Building everything separately for each customer only moves the burden. It may feel like a perfect fit at first, but someone has to maintain different code for each customer over a long period, and every change adds to the maintenance cost. Going either way, the work never quite went away.

What we kept coming back to

These experiences shifted how we judge adoption. Before asking what is on the feature list, we now ask what new work the adoption will create and who will end up doing it.

So the question we keep holding is this: how do we keep the efficiency of a shared product while supporting the ways companies really differ? We have thought about this persistently for a long time, and lapal lab is still working on it as an organization.

Our team has recently felt that one thing has changed. This kind of work was possible before, but the time and cost it takes have dropped noticeably. We explore what changed, and how, in the next article, Why building is exciting now.