Custom service parts software development
A machine you delivered ten years ago is standing idle today. Whether the right part is on site tomorrow depends on three sets of records that, at most service companies, live separately: which configuration that specific unit has, which article fits it, and whether that article is in stock anywhere. Appfront builds custom software that ties the three together, for machine builders, installation companies and technical service providers.
Parts management starts with the machine, not the warehouse
Spare parts software is the system that keeps the parts supply running for the installations you have delivered over many years: which units are where and in what configuration, which article fits them, which successor replaces a discontinued item, and what needs to be kept in stock. It is the aftersales chain, and it keeps running for years after handover.
Are you on the right page? This is about the spare parts side of service. If your question concerns the wider production process, from costing to planning, see manufacturing software. If it concerns the engineer on site, with work orders and reporting in the field, a field service app is the better fit. If you want a sales channel with a catalogue and customer pricing, without the customer's machine park driving the selection, a B2B e-commerce portal is the shorter route.
The installed base as the foundation
Not a list of machine types, but a register of individual units with serial number, configuration and everything that has changed since handover.
Compatibility as a rule set
What currently sits in a parts catalogue organised by build year, and in the heads of two engineers, becomes a rule set you can check.
Stock on a different standard
A service part earns its place not through turnover rate, but through what happens at the customer who is waiting for it.
Why stock models discard exactly the wrong parts
Trade stock and spare parts look alike until you examine the control logic. In trade, slow-moving stock is waste: every item must circulate, and a low turnover rate is a signal to run down. For spare parts, the value often lies in the item that sits idle for years and is needed exactly once, at the moment a line stops at a customer.
This is built into the tooling. An ABC analysis based on revenue places a critical drive module with one withdrawal every four years in category C, and the next clearance round of obsolete stock removes it. Two years later a machine stands still and the manufacturer quotes a lead time of months.
The right trade-off sets two cost types from different systems against each other. Holding stock costs capital, space and obsolescence. Failing to supply costs production loss at the customer, express freight, a second service visit and escalation under the service agreement. The first cost sits in your general ledger; the second usually appears nowhere.
In practice, that means classifying by criticality rather than by revenue, with a service-level target per class, and forecasting with methods that cope with intermittent demand, such as Croston's method from 1972, which estimates the interval between withdrawals separately from their size.
Does this fit? A question answered per unit
Serial number, build year and configuration
For installations delivered in variants over many years, compatibility is an administration in its own right. A machine type from 2011 has a different drive from the same type in 2016, and the unit that received a retrofit in 2019 differs from both. The parts catalogue entry for the build year describes the configuration as delivered, not as it currently stands.
That is why, in a working system, compatibility attaches to the unit rather than the type. Each serial number records which conversion kits and retrofits have been carried out, and rules refer to that configuration, usually as validity from or up to a serial number range. A wrongly supplied part here rarely costs only the part; it costs a second service visit.
Successors, replacements and the final purchasing round
Suppliers discontinue an item and supply a successor, and that chain must be traceable through the administration. Replacement often only works in one direction: the new sensor fits the place of the old one, while the old one no longer meets requirements on a recent machine.
On top of that comes the end of supply: how much should you still buy for the machines that will run for years to come? That is an arithmetic exercise based on your installed base.
What such a system needs to do in practice
Installed base with history
Each supplied unit with its serial number, location and configuration, plus any modifications that have been carried out.
Compatibility per unit
Rules based on serial number range, configuration and retrofits, so that the back office, the engineer and the portal all give the same answer.
Replacement and succession chains
Recorded per relationship whether a replacement works in both directions, with a justification for the most recent purchase round.
Stock control by criticality
Classification by what happens when a part is missing, with a delivery target for each class.
Ordering portal for your own machine park
The customer selects from the exploded diagram for their exact configuration. Parts that do not fit do not appear.
Parts for the engineer
Van stock as a full location, with consumption recorded when the work order is closed.
Parts are a sales channel, not a by-product
At many service businesses, parts account for a considerable share of margin, yet they are sold through the slowest channel the company has: someone calls the back office and describes the part. That description is rarely unambiguous, so photos and nameplate details get exchanged back and forth.
An ordering portal breaks down once it is tied to the installed base rather than a general catalogue. The customer works from their own machines and only sees what fits that specific unit. That brings in customer-specific prices, purchase order numbers and, for larger customers, ordering from their own procurement system via punchout standards such as OCI or cXML. See also Building a B2B e-commerce portal.
The portal is not separate from field service: whether a part is already in the engineer's van should come from the same source as the customer's order. We work through that interface as part of the field service app.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Standards, item data and integrations
Spare parts management has no certification of its own, but it touches on frameworks that define terminology and documentation obligations. NEN-EN 13306 defines the terms used in maintenance. NEN-EN 13460:2009 covers the documentation that should be supplied with an installation and kept up to date during its operational life; parts lists fall within that scope. Customers working to ISO 55001 translate this into requirements for your documentation.
Two European regulations matter over the longer term. The Machinery Regulation (EU) 2023/1230 replaces the Machinery Directive 2006/42/EC and applies from 20 January 2027, with tighter requirements for technical documentation. The Ecodesign Regulation (EU) 2024/1781, in force since 18 July 2024, works through delegated acts for each product group and sets requirements on repairability, the availability of spare parts and a digital product passport.
On the data side there is often more to gain than on the standards side. In the Dutch installation and technical sector, ETIM is the prevailing classification model for technical products, and 2BA is the article database in which manufacturers and wholesalers share their data. GS1 article numbers (GTINs) help establish that three supplier numbers refer to the same part, a persistent cause of duplicate stock.
When custom development is not the answer
Mature packages do exist here: the spare parts and service modules of SAP S/4HANA Service, Microsoft Dynamics 365 Field Service, IFS or Infor have years of design behind them. For a service business with a manageable range and machines that barely differ by type, such a module is the most sensible choice.
Custom development becomes worthwhile once your compatibility logic outgrows what the package can handle. You'll recognise it by three signs. Your back office keeps a separate spreadsheet of which variant has which part. The portal you have in mind assumes an installed base the package doesn't know about. Or you're stuck waiting on your supplier's roadmap.
Then there's the burden that custom development brings, and it is real. You maintain the item data, the installed base and the compatibility rules yourself: a development partner supplies the model, not the content. That calls for an owner within your organisation and a way of working in which every modification is actually reported back. A system that isn't kept up to date is riskier than no system at all, because people start to trust it. That's why we more often build a layer alongside the ERP than replace it. Feel free to outline your situation.
If you want mechanics and dealers to order parts by clicking on the drawing, look at exploded-view drawing and spare parts ordering software.
If you are dealing with automotive parts that need to fit vehicles according to TecDoc, look at our TecDoc parts matching app.
If you sell exchange parts with a deposit on the old core, and that core must go back to the supplier or be remanufactured, there is our app for registering exchange parts.
If you want to supply printing press parts with priority during downtime, look at our software for printing press parts provisioning.
Signs that custom development is worth considering
- Your machines differ in configuration by serial number
- Your back office maintains its own compatibility lists
- Customers order based on their own machine fleet
- The same part runs under multiple item numbers
- Stocking decisions are currently based on turnover rate
Frequently asked questions about service parts software
For some service companies that is the right choice: packages such as SAP S/4HANA Service, Microsoft Dynamics 365, IFS or Infor have mature item and stock administration. It falls short in two places. A bill of materials per type has no rules by serial number range or by modifications carried out. And an ordering portal based on the customer's machine fleet assumes an installed base that the package doesn't maintain.
By reversing the question: not which type this item belongs to, but which configuration this specific unit now has. Per serial number it is recorded which configuration the machine was delivered with and what has changed since. Compatibility is captured as rules over that configuration, for example valid from a given serial number or only with a specific control system. That distinction between as-delivered and as-maintained is not something a parts catalogue by year of manufacture provides.
Not with turnover rate: an ABC analysis based on revenue will always place a part needed once every four years at the bottom, as a candidate for disposal. Other methods exist for sporadic demand, such as Croston's method from 1972, which estimates the time between two withdrawals separately from their size. More importantly, the target differs per part: for a part that stops a production line you manage for availability, while for a cosmetic defect the customer can wait.
The source code, the database and the documentation are yours, and we record that in writing in advance. We build on mainstream technology and hand over the build environment and the rollout process, so another party could take over. More importantly, what you keep in your own hands is the item data, the installed base and the compatibility rules: they are your business knowledge. A development partner can be replaced; a rule set built up over years cannot simply be swapped out.
Yes, provided you accept that cleaning up that data is the real project and the software is the tool. The same pattern nearly always comes up: one physical part listed under several numbers, an installed base that was maintained until someone stopped, and compatibility knowledge held in the heads of two technicians. That is why we start with the critical top: the machine types that weigh most heavily in your service contracts, small enough to validate manually and large enough to test the model.
That depends on the quality of the installed base behind the portal. If the customer works through a generic catalogue, you merely shift the risk of a wrong choice from your back office to him. If he works from his own machines, with the exploded diagram of his configuration, much of that risk disappears. Where doubt remains, the order goes first as a request to your service department.
Related services
Manufacturing software
For costing, production planning and the bills of materials for your machines. See Building manufacturing software.
Field service app
For the engineer on site: work orders, checklists and logging the parts used. See field service app development.
B2B e-commerce portal
For a business ordering channel with a catalogue and customer prices, without installed-base logic. See Building a B2B e-commerce portal.
Ready to overhaul your parts administration?
Tell us what your machine park looks like, where the compatibility knowledge currently resides and which decisions you make on instinct. We will help you assess whether your current package can handle this or whether a custom layer alongside it makes sense, including if the outcome is that you need to build nothing at all.