Compare
Owned, against bought or rented.
Packaged software is the right purchase for the work every business does the same way. This page says what that work is, what it costs to rent the systems that run the rest, and when buying is still the correct decision.
What packaged software is right for
Buy what is the same for everyone.
A ledger works the same way in a steel mill and a wealth firm. So does payroll. So does statutory reporting. The rules for these are set outside your business, and they change on a timetable you do not control.
Packaged software exists because of this. One product serves many companies, the vendor carries the work of keeping up with the rules, and your accountant already knows how to use it. Renting it is the correct decision, and nobody should rebuild it.
A system built on Phlo does not replace your accounting or payroll software. It sits beside it and records the operation that produces the numbers.
The argument for owning
Every other capability came inside. The software did not.
Enterprises grow by bringing capabilities inside: suppliers, distribution, logistics, maintenance, finance. Each one came inside because control mattered more than convenience.
The software that runs all of it is the exception. It is still bought or rented, including the systems that hold the part of the operation that is yours alone: how a load is received, how an order is quoted, how a batch is traced.
For a long time that was rational. Building your own took a year and an army. That has changed, and so the rent is worth looking at again.
What renting costs
Three costs that do not appear on the invoice.
None of these is a fault in the product. They follow from one product serving many customers.
The roadmap is the vendor's
A product moves in the direction most of its customers need. The feature your plant needs is weighed against every other request. It may arrive next year, in a form built for somebody else, or not at all.
The change waits in a queue
Your process changes when a customer, a regulator or a supplier changes. The system changes after a request, an estimate and a release window. In between, the operation runs on the new process and the software records the old one.
The workarounds accumulate beside it
What the package cannot hold moves outside it: a sheet beside the system, an approval in a group chat. The package keeps the result. The decision that produced it is kept by whoever remembers.
Customising the package can close a small distance. When the distance is the centre of the operation, the customisation becomes a build of its own, inside a product somebody else controls. What the sheet beside the system costs.
Side by side
Nine questions, asked of both.
| Bought or rented | Owned, on Phlo | |
|---|---|---|
| Who decides what is built next | The vendor. Its roadmap serves every customer at once, so your request is one vote among many. | You. What gets built, and when, is your decision. |
| A change to your process | A request, an estimate and a release window. Until then the change lives in a spreadsheet. | A change to your own system, made on a framework that is available to you. |
| Built around | The process most businesses of a type share. | One operation, mapped on site: its steps, its roles, its exceptions. |
| Your units and words | Items, quantities, documents. Anything else goes into a custom field or a remark. | The nouns your floor uses are the records: a trip, a lot, a bale, a household. |
| An exception | Handled outside: a sheet beside the system, an approval in a group chat. | A step with a role, a rule and an event, so it leaves the same record as the normal case. |
| History of a record | Usually the current value, with a log of changes if the module keeps one. | Every action is an event. A correction is added on top of the original, and both remain. |
| Knowledge of how it works | With the vendor and its implementation partner. | Written down as a model of your operation: entities, events, exceptions. It stays with you. |
| Ledger, payroll, statutory reports | Its home ground. The vendor keeps up with the rules when they change. | Usually not rebuilt. Your accounting and payroll software keeps doing this work, and the Phlo system sits beside it. |
| Time to start | A licence can be bought this week. Fitting it to the operation is a project of its own. | Two to five weeks for a first build, starting with a visit to your site. |
The part that is yours
What a product has no place for.
Four cases from systems that run on Phlo today. None is unusual to the people who do the work. Each is the kind of thing a product built for many customers leaves to a remark field.
A trolley at the gate with no contract
A farmer can arrive in the night with a loaded trolley and no purchase order. Each plant publishes an approved rate, and its aggregator holds a standing bargain at that rate. The gate operator attaches it. A standard purchase module expects the order to come first.
Textile house · Textile finishingCloth counted in metres, offcuts weighed in kilograms
Finished cloth is measured in metres. The lowest grades are weighed. Each lot carries its own metres-per-kilogram figure, so a lot adds up in one unit from arrival to dispatch. A stock module with one unit per item cannot hold that.
Engineering group · Spares and consumablesOne part, described differently by every client
A request from a client rarely uses the name the group keeps for a part. Each item carries the descriptions clients have used for it. The system suggests a match for each line, and a person accepts or overrides it.
Wealth firm · Wealth managementA client is a household, not a person
Family members hold the assets, across eleven asset classes. Joint holdings are split by ownership percentage, and everything rolls up to the household.
How they meet
Beside the package, not instead of it.
Owning the systems that run your operation does not mean leaving the package. At the power producer, a purchase invoice is parked in the accountant's review queue when the truck leaves the gate, with the deductions already worked out. The accountant checks it and posts it. For the engineering group's spares unit, the system produces files in the accounting package's own format, and an administrator imports them.
The books stay where they are. What changes is that a figure reaching them can be traced back to the events that produced it.
When buying is the right answer
Often, the package is the answer.
Buy the package, and nothing else, when one of these is true.
- Your process is the standard one. If the product's way of raising an order is close to yours, use it. Bending your process a little costs less than building.
- The function is set by statute. Accounts, payroll and tax filing belong in software whose vendor tracks the law.
- The exceptions are rare. A workaround used twice a year is cheaper as a workaround.
- The process is not yet settled. If the steps still change every week, wait. A system should describe an operation that exists.
Own it when the workarounds have become the operation: when the spreadsheet beside the system is what people open first each morning, and when a change to it matters enough that you would not want to wait for someone else's release.
What owning involves
Two stages, and a decision that stays with you.
Owning starts with one system. In the first stage, Phlo Enterprise Systems, we build it with you: discovery on your floor, a process map, a specification you sign, then the build. A first build takes two to five weeks, because most of it is already written in the framework.
The first build is not a pilot. It is where your operation gets described, and that description is what every later system is built from. In the second stage, Phlo Framework, the framework becomes available to you. Your own engineers build the next system on it, or we carry on. Both stay open.
Get started
Tell us which capability you want to own first.
Describe the process your packaged software does not hold, and the sheet that holds it instead. We will say plainly whether it is worth building.
coffee@jetbro.inWhatsApp +91 90999 62227