ERP system for a laser engraving business

LaserProdukt does laser engraving to order - some jobs on its own material, some on material supplied by the client, and some on-site at the client’s premises. That is three different ways of billing the same machine, and three different sets of information to collect for every order.

There was no system at all. An order arrived by email and stayed there: the details in a thread, the quote in a reply, a quantity change further down, confirmation in yet another message. To find out where a specific job actually stood, someone had to locate the right thread and read it from the top.

But the biggest time sink was the stockroom. Material stock existed only as the sum of what someone remembered and what they had time to check on the shelf, so once a week someone sat down and counted it all again. That time did not go into handling the next order. The problem was not the missing software as such, but that every answer about the state of the business had to be assembled by hand.

Where we started

With the order’s journey, not with screens. We walked it from the first email enquiry to the moment the money lands in the account, and at every step asked who holds that piece of information and where it actually sits.

Two things came out of it that were not in the original brief:

• An order is not one single process. There are three types - own material, client-supplied material, and on-site service - and they differ in what has to be entered and what gets deducted from stock. One universal form either asks about things that do not apply to a given type, or stays silent about the ones that do.
• The company did not need a full ERP. Invoicing worked elsewhere and was meant to keep working there. What was missing was the part in between: orders, material and money seen at the level of a single job, not an accounting document.

The second observation decided the scope - and what we deliberately did not build.

What we built

A browser panel with the order at its core. The form adapts its fields to the job type, and the quote is calculated from laser time times the rate times quantity, plus material and delivery - or entered manually when the price is agreed some other way. Each order runs through its own status cycle from quote to settlement, and the client’s decision on a quote is recorded separately, because a rejected quote is information too.

Everything else stands around that core: a contact register that feeds document headers, an item catalogue with an engraving rate and laser time per item, multi-line delivery notes with their own numbering and a PDF, and quality-control reports with an editable table of criteria. The dashboard rolls all of it into numbers - orders, revenue, receivables, a breakdown by status, and quote conversion - filterable by date, contact, item and status.

Stock is a result, not a field you edit

Key decision: stock levels cannot be edited directly in this system. They follow from movements - receipts, issues and corrections - and only from those.

You can see it in daily use. An order moving into “in progress” status deducts material from stock on its own, because that is the moment the material actually goes under the laser. The “issued” status only lights up once delivery notes cover the full ordered quantity - nobody ticks it by hand.

An editable stock field looks convenient right up until the first mistake, after which nobody knows anymore whether the error is on the shelf or in the field. A stock level built from movements can always be traced back to what produced it.

What we deliberately did not build

Invoicing (including KSeF, Poland’s mandatory e-invoicing system), a purchase-order warehouse module, and a CRM all stayed out of scope. That was not an oversight or a budget cut: each of those either already works elsewhere in the business, or solves a problem this company does not have at this stage.

The whole thing sits behind two-factor authentication (2FA) and passkeys, with no public registration - accounts are created by an administrator. This is a panel with prices, margins and the client register, so a password alone would not be enough protection.

How the rollout went

Standard, with no plot twists: a stage, a demo, feedback, the next stage. The client looked at a working screen instead of a written description and gave feedback on what he actually saw - with a system made of six parts, that is the only way to catch a missing field before it gets built around.

To be honest: there was no moment here where something had to be rolled back, and we do not have a story from this project about clashing with the team or a wrongly assumed process. We suspect that is a result of the trimmed scope - the part we did not build is exactly where this kind of rollout usually gets stuck in loops.

What changed after launch

To be honest about measurement: the time recovered on stock is the owner’s own pre-launch estimate, not the result of two measurements, because the company was not measuring anything before. The number of new contacts comes straight from the system itself - records added to the register over a month, created along with an order rather than in a separate “add client” step.

The change that does not show up in the numbers is about the questions the owner can now ask. Knowledge of what actually sells and which quotes turn into orders used to be scattered across email threads - it could be reconstructed, but it cost an evening. Now quote conversion is a line on the dashboard, so “is it worth taking jobs like this” stopped being a matter of gut feeling.

What we deliberately left out of scope stays open. If the company ever decides to issue sales documents from the same place, the data is already in one system and one format - but that will be a separate decision, not something we quietly locked in at launch.