What Developers Should Know Before Building Software for Factories

Manufacturing software looks simple from the outside.

There are products, orders, inventory, suppliers, machines, customers, and invoices. At first glance, it may seem like a standard business application with a few extra fields.

But once you start building software for real factory operations, you quickly realize that manufacturing is one of the most complex domains a developer can work with.

A factory is not only a place where items are stored and sold. It is a system of dependencies, transformations, constraints, exceptions, and decisions that happen every day.

This article shares a few practical lessons developers should consider when designing software for manufacturing environments.

1. Inventory is not just a number

In many systems, inventory is treated as a simple quantity:

Product A = 100 units

In manufacturing, that is rarely enough.

The system may need to know:

• Where the item is stored.
• Whether it is available, reserved, blocked, or under inspection.
• Which batch or lot it belongs to.
• Whether it has an expiration date.
• Whether it is raw material, work in progress, or finished goods.
• Whether it can be consumed by production.
• Whether it can be sold or shipped.

A more realistic inventory model may need to consider movements instead of just current balances.

For example:

InventoryBalance = Sum(InventoryMovements)

This approach helps preserve traceability and makes it easier to audit what happened over time.

In a factory, the current balance matters. But the history behind that balance matters too.

2. Units of measure can become a hidden source of bugs

Manufacturing systems often deal with different units of measure.

A company may buy material in kilograms, consume it in grams, store it in boxes, and sell the finished product in units.

That means the system needs clear rules for conversion.

A simple mistake in unit conversion can create serious operational problems. It may cause the system to overestimate available stock, generate wrong purchase suggestions, or calculate product costs incorrectly.

Developers should avoid spreading conversion logic across the codebase. Unit conversion should be centralized, tested, and explicit.

For example:

1 box = 12 units
1 kg = 1000 g
1 meter = 100 cm

The challenge is not only storing these conversions. The challenge is knowing when each conversion should be applied.

3. A Bill of Materials is more than a list of components

The Bill of Materials, often called BOM, is one of the most important structures in manufacturing software.

At a basic level, it defines what is needed to produce something:

Finished Product
- Component A
- Component B
- Component C

But in real operations, a BOM can include:

• Component quantities.
• Units of measure.
• Alternative components.
• Optional components.
• Scrap rates.
• Versions.
• Cost allocation rules.
• Production steps.
• Routing information.

This makes the BOM a central part of the system.

It connects engineering, purchasing, inventory, production, costing, and quality.

If the BOM is wrong, the production plan may be wrong. If the production plan is wrong, purchases may be wrong. If purchases are wrong, customer deadlines may be affected.

For developers, this is a good reminder: sometimes a “simple table” is actually the heart of the business logic.

4. Production planning is a dependency problem

Production planning is not just about choosing what to produce.

The system needs to answer questions like:

• What customer orders need to be delivered?
• What products need to be manufactured?
• What materials are available?
• What materials need to be purchased?
• Which machines are available?
• Which operations must happen first?
• How long does each operation take?
• What happens if a supplier is late?
• What happens if a machine stops?

This turns production planning into a dependency problem.

A finished product depends on components. Components depend on suppliers or previous production steps. Production depends on machines, people, time, and capacity.

The ideal plan is useful, but the real value of the software is helping the team react when the plan changes.

And in manufacturing, the plan changes often.

5. Statuses need strong rules

Many business systems use statuses such as:

Draft
Approved
Completed
Canceled

Manufacturing systems often require more detailed status transitions.

For example, a production order may go through stages such as:

Planned
Released
In progress
Partially completed
Completed
Canceled

But not every transition should be allowed.

A completed production order should not always be editable. A canceled order should not consume materials. An order in progress may require different permissions than a planned order.

This means status transitions should not be treated as random field updates.

They should be part of the domain rules.

A good approach is to define allowed transitions clearly:

Planned -> Released
Released -> In progress
In progress -> Completed
Released -> Canceled

This reduces inconsistent data and makes the system easier to maintain.

6. Traceability is a product feature and a compliance requirement

In many factories, traceability is essential.

The company may need to know:

• Which raw material lot was used in a finished product.
• Which supplier delivered a specific batch.
• Which production order generated an item.
• Which customer received a specific lot.
• Which quality inspection approved or rejected the product.

This is especially important in industries where quality, safety, compliance, or recalls matter.

From a technical perspective, traceability requires careful event modeling.

Every relevant operation should leave a reliable record.

That includes purchases, inventory movements, production consumption, production outputs, inspections, shipments, and adjustments.

Traceability is not something that can be easily added at the end. It needs to be considered early in the architecture.

7. Costing is deeply connected to operations

Product cost is not just a financial calculation.

In manufacturing, cost may depend on:

• Raw materials.
• Labor.
• Machine time.
• Production losses.
• Overhead.
• Outsourced operations.
• Inventory valuation rules.

That means cost calculation depends on operational data.

If the system does not correctly capture material consumption, production time, and process losses, the cost calculation will also be unreliable.

For developers, this is an important lesson: financial outputs are often only as accurate as the operational data behind them.

8. Integrations are not optional

Factories rarely use only one system.

A manufacturing ERP may need to integrate with:

• E-commerce platforms.
• Tax systems.
• Financial tools.
• BI platforms.
• Shop floor systems.
• Barcode collectors.
• Supplier portals.
• CRM tools.
• Accounting systems.

Integrations need to be reliable because they often connect critical workflows.

A failed integration can delay invoicing, duplicate data, interrupt production, or create inconsistent information between departments.

When building integrations for manufacturing, developers should think carefully about:

• Idempotency.
• Retries.
• Logs.
• Error visibility.
• Data validation.
• Manual correction flows.

The goal is not only to send data. The goal is to make the integration operationally safe.

9. The user may not be sitting at a desk

Manufacturing software is used by different people in different environments.

Some users work in offices. Others work in warehouses, production areas, receiving docks, quality labs, or shop floors.

This affects product design.

A shop floor user may need a simple screen with large buttons. A warehouse user may need barcode support. A manager may need dashboards and alerts. A finance user may need detailed reports.

The same system may need to support very different experiences.

Good manufacturing software respects the context in which each user works.

10. ERP systems become the operational backbone

Because manufacturing connects so many areas, companies often rely on ERP systems to centralize their operations.

For manufacturers, an ERP needs to go beyond administrative control. It should connect sales, purchasing, inventory, production, quality, costs, finance, and reporting.

That is why specialized solutions such as Nomus Industrial ERP focus on the specific needs of small and medium-sized manufacturers.

The goal is not just to digitize forms. The goal is to help factories manage processes, reduce uncertainty, improve visibility, and make better decisions with reliable data.

Final thoughts

Manufacturing software is challenging because it brings software engineering close to the physical world.

A wrong quantity is not just a database error. It may represent missing material on the shop floor.

A wrong cost is not just a report issue. It may affect pricing and profitability.

A wrong production status is not just a UI problem. It may confuse planning, purchasing, inventory, and delivery.

For developers, manufacturing is a valuable domain because it forces us to think deeply about data consistency, business rules, architecture, integrations, and real-world constraints.

Factories are complex systems.

Good software does not remove that complexity.

It makes the complexity easier to understand, manage, and improve.