PrecisionSense GmbH managed 3,000+ SKUs across four regulated industries using a combination of ERP exports, email threads, and Slack messages. One person spent half their working week just keeping the data coherent. I led the product definition and delivery of a custom PIM system that replaced the entire manual stack.
PrecisionSense GmbH is a fictional industrial sensor manufacturer based in Germany with 8-figure ARR. Their product portfolio spans 600 base products and 3,000+ SKUs, serving four highly regulated sectors: automotive EV battery monitoring, medical diagnostic equipment, renewable energy pitch control systems, and ruggedized aerospace sensors.
In each of these sectors, an incorrect technical specification is not a customer service problem - it is a legal and safety liability. The stakes around data accuracy were unusually high.
PrecisionSense relied on their ERP system for transactional data: pricing, inventory, and orders. But ERP was never designed to carry descriptive technical data, compliance certifications, or marketing assets. The gap between what ERP could store and what customers actually needed had been filled entirely by manual human effort.
Per week spent by one person manually gathering data from ERP, email, and Slack to update product records. 50% of a full-time role.
To identify, extract, and update a single product request - creating a queue backlog that grew faster than it could be cleared.
No audit trail existed for who changed what and when. In medical and aerospace contexts, this was a compliance exposure.
Variants managed in rigid ERP tables that had no concept of parent-child relationships or attribute inheritance.
"The ERP knows what we sell and how much we have. It has no idea what the product actually is, what it does, or whether it is certified for use in a medical device."
The deeper issue was that product data lived in three separate systems that never talked to each other: engineering data in a PLM system, transactional data in the ERP, and commercial data in spreadsheets and email. Every customer-facing output - datasheets, portal listings, catalog entries - required someone to manually reconcile all three. That person had become a critical single point of failure.
Before scoping a custom build, I evaluated three established SaaS PIM platforms. All three failed on requirements that were non-negotiable for PrecisionSense.
I led product definition end-to-end: translating the client's operational pain into a functional spec, making the build-vs-buy decision, defining the technical architecture priorities, scoping each feature against the core use cases, and owning the delivery timeline in partnership with the engineering team.
The architecture philosophy I set from the start was "vanilla first" - minimal external dependencies, prioritizing auditability and long-term maintainability over feature richness. For a lean industrial team with no dedicated software ops function, a system that is easy to understand and secure is more valuable than one that is feature-complete but opaque.
Five core modules, each mapped directly to a specific operational failure in the current state.
| Module | Problem it solved | Key technical decision |
|---|---|---|
| ETL data onboarding | Migrating 3,000+ SKUs from ERP exports and Salesforce CRM without months of manual re-entry | Custom Extract-Transform-Load engine supporting Excel and Salesforce; even with manual cleaning required, migration time dropped from months to days |
| Parent-child data model | Managing 3,000+ variants that share 80% of their attributes with a base product | Attribute inheritance: changes to a parent spec propagate instantly to all child variants, guaranteeing 100% consistency across the SKU tree |
| RBAC and audit trail | No visibility into who changed what; unverified edits to technical specs in regulated industries create legal exposure | Granular view/edit permissions by role, admin approval workflow for core spec changes, and an immutable change log for compliance audits |
| Technical asset management | BOMs, RoHS/REACH certifications, and CAD files living in email chains and Slack - impossible to version or locate reliably | Direct attachment of engineering files to specific SKU variants; always-current link between the physical engineering asset and the digital product record |
| Full data export | Avoiding vendor lock-in and giving the client legal sovereignty over their own product data | Structured .zip export of all data at any time; the client can leave, migrate, or audit without asking permission from a vendor |
Architecture decision worth noting: the system was intentionally built with minimal external library dependencies. This was not a technical constraint - it was a product decision. An 8-figure industrial client with no dedicated software ops team needs a system where a security audit is straightforward and where there is no npm-style dependency chain to maintain. Simplicity was a feature.
From 2-3 minutes per product record to under 15 seconds. Queue backlog cleared within the first week post-launch.
The role that spent 50% of its time on data reconciliation now spends less than 10% on oversight. The rest is reinvested in strategic work.
Every field change is now logged with timestamp, user, and approval status. First compliance audit passed with zero findings on data integrity.
3,000+ SKUs migrated from ERP and Salesforce via the ETL engine. Previous estimate for manual migration was 4-6 months.
Self-hosted, fully exportable, no SaaS licensing. The client owns the system, the data, and the roadmap.
B2B portal, e-commerce feed, print catalog, and structured export now all draw from a single source of truth.
The most important decision on this project was made before any code was written: choosing to build custom rather than configure off-the-shelf. That decision required a structured business case comparing 3-year TCO across options, not just a feature checklist. The custom build was cheaper at scale, more compliant by design, and ultimately more aligned with the client's risk profile than any SaaS alternative.
The "vanilla architecture" principle was also a product decision, not just a technical one. When you are building for a team that has no dedicated software operations function, the ongoing cost of complexity is real and ongoing. A system with fewer dependencies is easier to audit, easier to hand over, and easier to modify two years later when the original engineers are gone. Simplicity has a business value that rarely appears in a feature comparison.
The hardest conversation on this project was telling the client that one of their three top-priority features needed to move to phase two. The compliance approval workflow had scope that would have pushed the initial delivery by six weeks. Cutting it from v1 and shipping the core PIM on time - with a committed roadmap for the approval module - was the right call. The team had the data benefit within their original timeline, and the approval module shipped eight weeks later with better specification because we had real usage data to inform it by then.
The actual UI of the prototype is larger and only simple functions are recreated for the purpose of the case study.