When manufacturers introduce new software, the SI approach is familiar: define the required functions, have a vendor develop them for the customer's environment, then take delivery when the project ends. Because every factory system is different, this is often a natural choice.
But software used every day in production and continuously expanded across processes and equipment is different. If the core is rebuilt separately for every customer, code and operating methods diverge over time, while updates and support become fragmented into project-specific work.
SI may feel safer, but the difference grows after the project ends
For a large enterprise, choosing a small software vendor can feel risky. It needs to know whether the supplier will still exist years later, who will respond when something fails, and whether support will continue after the people in charge change. This is why a large SI vendor can feel relatively comfortable.
That concern is reasonable. But company size alone does not determine long-term operating stability. For software that must be used for years, it also matters whether the same product continues to be maintained and updated.
An SI project is optimized to complete the system within the contracted scope. A product company, in contrast, has to make one piece of software something many customers can keep using. Bug fixes, feature improvements, version management, documentation, and compatibility are not waiting for the next contract; they are ongoing product work.
A product still needs deployment and operating infrastructure
Every factory has different data structures, security policies, MES/APC environments, and equipment connectivity. Product software still requires integration and configuration during the initial installation.
The difference is that product deployment focuses on placing an existing product into the customer's environment and configuring the necessary connections. If the core software is rebuilt for every customer, similar development has to be repeated again at the next process or site.
Being a startup does not make supplier risk disappear. If anything, a smaller vendor has an even greater need to design its product and support model so customers are not dependent on one developer or project team.
That is why on-premise operation, version management, documented configuration and integration procedures, product-level updates, and support matter. Customers need a structure that can keep the installed product stable and move to future versions, rather than one that requires holding on to the people from a single project.
Separate the work that needs SI from the work that needs a product
Amfibian deploys the same product into each customer environment. After the necessary deployment and integration work, product updates and operating support continue.
Pricing is also separated into Software Subscription, Deployment & Integration, and Enterprise Support. Deployment services focus on the work required to use the product in the actual production environment.
If the goal is a one-off system or a customer's unique workflow reproduced exactly, SI may be the better fit. If the goal is to operate the same capability for years and expand it across equipment and lines—as with process control—continuous product maintenance and repeatable deployment become more important.
Amously operates process-control software in this way: deployment work is adapted to the customer environment, while the core software continues to evolve as one product.