We turn a working piece of software written for a single client into a sellable product: separating the core from the client-specific layer, a configuration engine, multi-tenant data isolation, installation and release management, and subscription infrastructure.
Many businesses own a piece of software they commissioned for their own needs and have run for years. Over time it becomes clear that other companies face the same problem and would like to use it too. Two questions follow: will the software work at another company, and is there a revenue model in this? The answer is usually yes — but the road is longer than it looks.
Because software written for a single client is full of that client's assumptions. The tax rate is hard-coded, the workflow is built around that company's approval chain, product codes follow its own scheme, the reports are laid out the way its owner wanted them. None of this is a mistake; as project decisions they were the right ones. As a product, each one is an obstacle. Productisation is the work of picking out these assumptions one by one and making them configurable.
The second and more critical issue is data isolation. In a system where more than one client runs side by side, keeping one client's data invisible to another cannot be left to chance. This is not a matter of a filter in the interface; it has to be solved at the foundation of the architecture. Isolation layers bolted on afterwards are among the most dangerous and most expensive fixes, which is why we address this the moment the productisation decision is made.
There is a legal side to settle before this work begins, and we discuss it in the first meeting: the source code and intellectual property clauses in the existing transfer agreement. If the software was built for one client, whether it can be sold to other clients depends on what that contract says. Starting the technical work before this clause is clarified opens a road that is very expensive to stop later. The same applies to companies that want to productise their own internal software; there too, the contract with the developer must be checked.
Companies with a well-functioning system they had built for their own needs. That system is often valuable because it understands the realities of its industry; the real asset is that knowledge more than the code.
Developers who work project by project and want to move to recurring revenue. This shift is as much a business-model change as a technical one, and the two must be planned together.
Companies that progress by copying and modifying the code for every client. The approach holds up to three or four clients; beyond that, every fix has to be applied separately and maintenance costs spiral out of control.
Businesses that know their own industry inside out and want to turn that knowledge into scalable revenue. Here the technical work is only one part of the commercial picture.
We work out which functions are common to all clients and which belong to a single one. The shared core is preserved; the custom parts become plug-ins or configuration. This separation is the most labour-intensive and most decisive step of productisation.
Hard-coded assumptions are made configurable: rates, workflow steps, field naming, approval chains, report preferences. The goal is never having to change code for a new client; if the code changes with every new client, you still have a project, not a product.
Keeping clients' data separate is built into the foundation of the architecture and tested. Verifying that isolation is run as a separate piece of work; it is the security issue productisation must take most seriously.
We make new-client installation repeatable, and address version numbering, a backwards-compatibility policy and letting clients stay on different releases. Having to update every client at the same time is the quietest obstacle to growth.
Usage metering, plan and limit definitions, subscription management and the billing flow are set up. You define the pricing model; we make sure that model can be measured and billed.
Bringing a new client onto the system, data migration, training and the support flow are designed. In productisation the real bottleneck is usually not the code but how many days of effort each new client takes; until that time shrinks, scale does not grow.
The source code and intellectual property clauses in the existing contract are reviewed, and whether the software can be sold to other clients is clarified. This step comes before the technical work and is carried out together with your lawyer. Projects started before this is settled stop in the most expensive way.
We decide which functions go into the product and which stay out of the first release. Trying to productise the whole of the existing software is a common mistake; a product is the narrowed, sharpened version of the project.
The codebase is split apart and hard-coded assumptions are moved into configuration. This phase runs incrementally; we progress while the existing client keeps working, protected at every step by regression tests.
The multi-tenant structure is built and isolation is put to the test. The real exam is the second client; every friction that surfaces during the first installation shows where the product is not yet configurable and sets the priority list.
Release management, an update policy, and the subscription and support flows are set up. New-client onboarding time is measured and shortened; scalability becomes visible in that number.
That depends on what the contract says and how the relationship was built. Some contracts state that the software belongs exclusively to the client; others allow the core to remain with the developer. We clarify this clause in the first meeting. Renegotiating with the client is also a route that works in practice; cheaper maintenance of a productised system is usually in the client's interest too.
Quoting a single timescale would not be realistic; the deciding factor is how many client-specific assumptions the existing code carries. That is why we start with a scope and condition assessment and price each phase separately. Progressing in stages is also possible: first just enough to carry a second client, then the real product.
Sometimes yes, and we are not afraid to say so. The existing code is valuable for the industry knowledge it carries; but if its architecture is entirely unsuited to multi-tenancy, building on it can cost more than rewriting. We give that verdict at the assessment stage, together with the reasoning. The factor that most often decides it is the data model rather than the code.
Preventing that is solved at the foundation of the architecture and tested separately. It is the issue we take most seriously in productisation; the isolation test is planned as an independent work item. We do not trust filtering approaches bolted on afterwards, because a single forgotten query invalidates the entire guarantee.
You define the model; we build its technical counterpart. How usage will be measured, how plan limits will be enforced, how overage will be handled and how billing will run. Making the commercial decision is not our job, but we will tell you early whether the model is workable.
A codebase with the core and the custom layer separated; a configuration engine; a multi-tenant data architecture with tested isolation; repeatable installation and release management; subscription and usage-metering infrastructure together with a client onboarding flow. Ownership of everything produced, source code included, is one hundred per cent yours.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We make it visible from one place where demand and supply diverge, which supplier is holding to its promised date and where the goods are waiting right now. The aim is not to install a new ERP; it is to gather the off-chain information your current system does not know and tie the planning decision to data.
Details →We bring together in a single chain where a request came from, which quotes were obtained, who approved what, and whether the invoice that arrives matches the order. Procurement runs in the system rather than in people's memories; every step can be read back afterwards along with its reasoning. Your existing ERP stays where it is.
Details →We bring together in one record who the supplier is, when each of its documents expires, how well it kept to its delivery dates last year and which price agreement is in force. The approved supplier list stops being an Excel file. A supplier portal connects to the same structure as an option.
Details →We build a layer that plans the shipment, assigns the vehicle and the route, compares carriers and freight rates, issues the e-waybill and collects proof of delivery from the field. If you run your own fleet, fuel, maintenance and document costs accumulate in the same system; if you work with hauliers, a record is kept of which job went to whom and at what price.
Details →We gather orders from your e-commerce site, marketplaces, the B2B dealer portal, the showroom and the telephone into a single pool. Stock is promised from one source rather than divided up channel by channel; the allocated quantity comes off it, and cancellations and returns come back into it. The aim is not to sell the same item twice, and to see where an order stands from a single screen.
Details →We gather all of a product's attributes, descriptions and translated texts in one centre, and produce the enriched version for each sales channel's own template from there. A field that is missing or breaks a rule is caught before the product goes out to the channel. Product data no longer lives in a file on somebody's desktop.
Details →
