Executive summary

This week I finished work on a minimum viable product (MVP) for a manufacturing company that aims to reduce machine downtime and therefore cut losses.

It addresses the following pain point: "We have a machine. Where is all the information about it, and how can we ensure that this knowledge doesn't disappear when employees leave?". According to available statistics, the depreciation rate of fixed assets in the manufacturing industry is about 50% (Russia). This means that these assets require continuous maintenance to extend their service life. Although my personal experience is limited to a single manufacturing company, it confirms that old machines make up a significant share of physical assets and that engineers often struggle to find documentation and accumulated knowledge about how to repair them developed over the years.

The concept is straightforward: every machine gets a QR code. An engineer scans it and instantly receives access to:

  • Technical documentation and service manuals
  • List of breakdowns over the years
  • Who repaired the machine, when it was repaired, and what was done.
Such information should significantly reduce repair time by providing quicker access to documentation and insights into previous failures, as many issues tend to recur.

Tech stack:
Kotlin backend, React/TS web client, mobile web client, Postgres, Docker Compose.

Github repository

Market research

Market capacity

Rosstat reported:

  • The depreciation rate of fixed assets in the manufacturing industry is approximately 50%;
  • Machinery and equipment are depreciated at approximately 50–52%;
  • Approximately 18–20% of machinery and equipment are completely worn out.

The situation with machinery assets in the rest of the world doesn't make a big difference:

The next interesting metric is the number of manufacturing enterprises with sufficiently complex and aging equipment where undocumented knowledge causes downtime, onboarding issues, and dependence on key personnel.

The ballpark formula and estimate are as follows:
Target factories = Manufacturing enterprises × % with multi-machine operations × % suffering from knowledge fragmentation

Competitor analysis

Product Category Examples Problems Solved Weaknesses for This Use Case
Generic Wiki / Documentation Systems Confluence, BookStack, MediaWiki Documentation management, procedures, onboarding, knowledge sharing Not machine-centric; no equipment inventory; no breakdown history; QR workflows must be built manually.
CMMS (Maintenance Systems) openMAINT, MaintainX, UpKeep Work orders, preventive maintenance, asset tracking, maintenance scheduling Optimized for maintenance execution rather than preserving institutional knowledge; documentation is usually secondary.
MES (Manufacturing Execution Systems) OpenMES, IMES Production tracking, work orders, routing, scheduling, shop-floor execution, documentation attached to operations Documentation is process-centric rather than machine-centric; historical repair knowledge and troubleshooting experience are usually not first-class entities.
ERP + MES + QMS Platforms Carbon Production planning, inventory management, quality control, business processes, manufacturing operations Broad enterprise scope increases implementation complexity and deployment cost; preserving repair knowledge is only a small subset of the platform.
Enterprise EAM Platforms IBM Maximo, SAP Asset Management Enterprise asset management, maintenance planning, analytics, integrations Expensive; complex deployment; excessive for many SMEs; long implementation cycles.
File Shares and Network Drives SharePoint, NAS, shared folders Central storage of manuals and drawings No machine context; poor searchability; no repair history; knowledge remains fragmented.
Paper Documentation Binders near machines Immediate local availability Easily outdated; difficult to search; impossible to aggregate organizational knowledge.
Human Memory ("Ask Sergey") Experienced maintenance personnel Tacit knowledge and undocumented troubleshooting experience Single point of failure; knowledge disappears with retirement or employee turnover.
Available open-source solutions
Product Strengths Missing for This Use Case
BookStack Excellent documentation UX, self-hosted, easy deployment No machine model, no breakdown history, no maintenance context.
MediaWiki Extremely flexible, mature ecosystem Requires heavy customization; poor UX for shop-floor engineers.
openMAINT Asset management and maintenance workflows Heavy enterprise orientation; knowledge capture is secondary.
Wiki.js Modern documentation platform Generic wiki only.
OpenMES Modern MES for small manufacturers; production tracking; operational documentation Optimized for production execution rather than preserving machine repair knowledge and maintenance history.
Available commercial solutions
Product Strengths Weaknesses
MaintainX Mobile-first CMMS, QR codes, work orders Primarily maintenance execution rather than organizational knowledge preservation.
UpKeep Strong mobile experience, preventive maintenance Expensive for SMEs; knowledge retention is not its primary value proposition.
IBM Maximo Industry-leading EAM capabilities Very expensive and operationally heavy.
SAP Asset Management Deep integration into the SAP ecosystem Significant implementation and consulting costs.
Carbon ERP + MES + QMS platform covering production, inventory and quality processes Broad business scope; machine knowledge preservation is not the primary focus and may be excessive for SMEs seeking only equipment documentation and repair history.
IMES Designed for job shops and discrete manufacturing; production planning and shop-floor coordination Strong production orientation but limited emphasis on capturing tacit maintenance knowledge accumulated around individual machines over many years.
Capability comparison
Capability Wiki CMMS MES ERP/MES Proposed KMS
Documentation management ✅ ⚠️ ⚠️ ⚠️ ✅
Machine inventory ❌ ✅ ⚠️ ⚠️ ✅
QR access from shop floor ❌ ✅ ⚠️ ⚠️ ✅
Breakdown history ❌ ✅ ⚠️ ⚠️ ✅
Capture of repair know-how ⚠️ ⚠️ ❌ ❌ ✅
Fast deployment ✅ ⚠️ ⚠️ ❌ ✅
Affordable for SMEs ✅ ⚠️ ⚠️ ❌ ✅
Self-hosted open-source option ✅ ⚠️ ⚠️ ❌ ✅

Existing solutions tend to optimize one of three concerns: documentation management, maintenance execution, or production execution. Small and medium manufacturers frequently need something simpler: a machine-centric knowledge repository that can be deployed quickly, accessed directly from the shop floor via QR codes, and preserve historical maintenance knowledge that would otherwise remain locked inside individual engineers' heads.

Potential market fit

The strongest signal of market fit is not the absence of competitors, but rather the fragmentation of partial solutions. Existing systems typically solve adjacent problems: documentation (wikis), maintenance execution (CMMS), production tracking (MES), or enterprise asset management (EAM). However, none of them treats the machine itself as the central knowledge entity that accumulates operational history over time.

In practice, most manufacturing companies operate in a hybrid state:

  • formal maintenance systems exist but are underused or partially implemented;
  • documentation is stored in shared folders or paper binders;
  • critical knowledge remains in the heads of a small number of technicians;
  • production and maintenance systems are disconnected.

This creates a consistent operational gap: information exists, but it is not accessible in the context where it is needed (at the machine, during failure, under time pressure).

The proposed system is positioned to fill this gap by unifying three layers:

  • static knowledge (manuals, procedures, documentation),
  • historical operational knowledge (breakdowns, repairs, patterns),
  • contextual access layer (QR-based retrieval directly at the machine).

This combination is particularly relevant in environments with:

  • heterogeneous equipment fleets (different generations and vendors),
  • limited digital integration between systems,
  • high dependency on experienced technicians,
  • cost-sensitive production where downtime is still expensive but not digitized away.

From a geographic perspective, these conditions are not confined to a single region. They are common across Eastern Europe, parts of Western Europe (notably SME manufacturing sectors), the United States industrial mid-market, and rapidly industrializing economies in Asia.

The most promising segment is not the most advanced factories, but rather the “in-between” segment: companies that are large enough to suffer from knowledge fragmentation, but too small or too fragmented to justify heavy enterprise systems such as SAP or IBM Maximo.

In this sense, the product does not compete directly with MES or ERP systems. Instead, it operates as a lightweight layer above them — or alongside them — focused exclusively on preserving and operationalizing machine-level knowledge.

A practical indicator of product-market fit would be the moment when maintenance teams stop asking:

“Where is the manual for this machine?”

and instead begin asking:

“What has historically been done when this machine failed in this way?”

That shift represents a transition from documentation-centric behavior to knowledge-centric behavior, which is the core value proposition of the system.

Finally, the adoption curve is likely to follow a bottom-up pattern. Initial usage is driven by a single workshop, production line, or maintenance team. Once the value of reduced downtime and faster troubleshooting becomes visible, the system can expand horizontally across the factory and vertically across multiple sites.

How much to charge for this product to stay attractive for the customer?

Knowledge management systems are somewhat unusual products because they are difficult to evaluate in isolation. Customers do not buy documentation, QR codes, or a searchable wiki. They buy fewer hours of stopped production, less dependence on individual experts, and faster recovery when something eventually breaks.

Therefore, pricing should not be benchmarked against generic wiki software such as Confluence or SharePoint. It should be benchmarked against the financial impact of equipment downtime.

A simple ROI model can be expressed as: 

            Annual benefit =
                downtime reduction
            + reduced time spent searching for information
            + faster onboarding of engineers
            + avoided losses from knowledge leaving the company

Consider a small factory:

  • 100 machines;
  • 6 maintenance technicians;
  • 15 significant breakdowns per year;
  • 2 hours saved per incident;
  • Downtime cost: €2,000 per hour.

Downtime savings alone are: 

            15 × 2 × €2,000 = €60,000 per year

If the system also saves engineers twenty minutes per day previously spent searching for manuals, drawings, and historical repair information, the labour savings can easily exceed another €10,000–15,000 annually.

Even conservative assumptions quickly produce annual benefits in the range of €50,000–100,000 for a medium-sized factory.

As a rule of thumb, industrial software remains an easy purchasing decision when its annual cost is below 10% of the measurable value it creates.

This leads to an interesting conclusion. Although the product itself is technically simple, its value proposition is not. A system that saves a factory €50,000 per year should not be sold for €200 simply because it is "only a documentation system".

A more reasonable pricing strategy might look as follows:

Customer profile Typical savings Suggested annual price
Small workshop (10–30 machines) €5k–20k €500–2k
Medium factory (30–200 machines) €20k–100k €2k–10k
Large plant (200+ machines) €100k+ €10k–30k+

Regional purchasing power should also be taken into account.

Market Indicative annual price range
Russia and Eastern Europe €500–5,000
Western Europe €2,000–15,000
United States €3,000–20,000

The pricing model should probably scale with the customer's complexity: number of machines, number of users, or number of production sites. Such metrics are easy to understand and correlate reasonably well with the value generated by the system.

The product is better described as a form of insurance against knowledge loss and expensive production downtime. If a factory believes the system can prevent even a single serious incident per year, paying several thousand euros annually becomes a rational business decision.

Architecture

High-Level Flow:

User (operator/technician on shop floor) → opens Web Client (React/TS) on mobile/desktop.

Presses Scan → uses device camera (rear preferred) to read QR/Barcode on equipment.

Frontend calls Backend → GET /api/v1/machine/barcode/{barcode}.

Backend returns machine data or redirects to /machines/{id}.

Machine Card shows: documentation, maintenance history, solutions to past issues, attachments (PDFs, videos, schemas).

Deployment View (Docker Compose)

  • Services:
    • web / web-prod → React frontend (port 3000)
    • server → Kotlin Spring Boot backend (port 8080 + Swagger)
    • database → PostgreSQL
  • Profiles: prod and dev
  • All self-hosted, easy one-command deploy.

Strengths

  • Mobile-first with strong Android/Chrome focus.
  • Simple, maintainable stack.
  • QR-driven navigation = core differentiator for shop-floor use.

Market entry strategy

This section describes a rough vision of how the product is expected to enter the market and evolve from early validation to scalable sales.

Phase 1 — Validation

  • Landing page with clear product positioning and use cases
  • Public GitHub repository (transparency + trust for technical buyers)
  • 1–3 pilot factories for real-world testing
  • Manual outreach to maintenance engineers and plant managers
  • No or minimal paid advertising

Goal: validate that the system is actually used in real workflows and that a full usage loop exists (scan → find knowledge → solve problem → repeat usage).

Phase 2 — Proof of value

  • Derive at least one concrete case study from a pilot factory
  • Refine positioning based on real feedback from technicians and managers
  • Improve onboarding and first-time setup experience
  • Introduce first paying customers, even at small scale

Goal: confirm willingness to pay and validate that the product is perceived as economically valuable, not just “useful software”.

Phase 3 — Early scaling

  • Targeted advertising to specific industrial niches (not broad marketing)
  • Outbound outreach via LinkedIn and industry networks
  • Initial reseller or sales partners, but only after messaging is stable and proven

Goal: establish a repeatable acquisition channel that can consistently generate new customers without relying on founder-led sales alone.

Phase 4 — Sales expansion

  • Hire regional sales representatives
  • Expand into EU and US industrial markets
  • Build localized sales and onboarding processes

Goal: transition from founder-driven distribution to a structured sales organization capable of scaling across regions and industries.

Pricing model

Right now open source version (free) and custom extension by customer demand (paid) are available right now. SaaS option and technical support are possible as one of the offerings in future.

The product follows a hybrid distribution model combining open-source self-hosting with a potential paid SaaS offering and optional enterprise services. This structure is designed to maximize adoption in early stages while enabling sustainable monetization in environments where reliability, integration, and operational support are critical.

1. Open-source (self-hosted) model

  • Free and open-source core product
  • Full access to source code and deployment configuration
  • Self-hosted deployment on customer infrastructure (on-premise or private cloud)
  • No licensing fees or vendor lock-in
  • Community-driven or internal support responsibility

This model is intended to enable fast adoption and low-friction evaluation in real production environments. It is particularly suitable for companies with internal IT capacity and a preference for infrastructure control.

The open-source version includes the core functionality: machine registry, QR-based access to documentation, and basic maintenance history tracking.

2. SaaS (managed platform) model

  • Fully hosted and managed deployment
  • Automated updates, monitoring, and backups
  • Operational support and maintenance included
  • Secure access management and system administration

The SaaS version is not only a hosting alternative, but an operational layer designed for production environments where uptime, simplicity, and reduced internal IT burden are critical.

In addition to the core features, the SaaS platform may include capabilities that are difficult to replicate in self-hosted deployments, such as:

  • Multi-site synchronization across factories
  • Centralized administration of distributed equipment fleets
  • Audit logs and operational traceability
  • Advanced backup and disaster recovery mechanisms

Pricing is based on operational scale (number of machines, users, or sites) and level of service.

3. Enterprise support and integration services

  • Onboarding and guided deployment in production environments
  • Integration with existing MES, ERP, or CMMS systems
  • Data migration from legacy documentation systems
  • Technical support tailored to operational requirements

This layer addresses the reality of industrial environments where adoption often depends not only on software, but on successful integration into existing processes and infrastructure.

4. Customisation and extension model

The platform is designed to be extensible to accommodate specific workflows, machine types, and organizational needs. Customisation typically includes:

  • Custom feature development on top of the core system
  • Specialized UI/UX adaptations for shop-floor usage
  • Integration with proprietary systems or internal tools
  • Private extensions maintained for individual customers

Customisation is handled on a project basis and is priced individually depending on scope, complexity, and long-term maintenance requirements.

5. Product evolution perspective

The pricing structure reflects an expected evolution of the product over time.

In early stages, value is primarily delivered through ease of adoption and transparency via the open-source core. As deployments mature, value shifts toward operational reliability, integration depth, and cross-site coordination.

In later stages, the product is expected to evolve from a documentation and access layer into a machine-centric operational knowledge system, where higher-value capabilities such as pattern recognition, recurring failure analysis, and decision support become increasingly important.

This progression allows the product to remain accessible for small deployments while gradually increasing monetization potential as organizational dependency on the system grows.

Summary

  • Open-source core ensures fast adoption and trust-building
  • SaaS monetizes operational convenience and reliability
  • Enterprise services cover integration and deployment complexity
  • Customisation enables adaptation to real-world industrial variability

The model is intentionally designed to start as an accessible tool and evolve into a critical operational layer in manufacturing environments where knowledge retention and downtime reduction have direct financial impact.