Laravel development for Eindhoven technology and manufacturing

Eindhoven builds things with options, and the interesting part is that most combinations of those options do not exist.

A machine with twelve option groups has a very large number of theoretical configurations and a much smaller number of buildable ones. The high-temperature variant excludes a particular seal. The extended axis requires the larger controller. One sensor choice implies a different cable than the default. Those constraints live in the engineering team's knowledge, in a document, and in the memory of whoever has been there longest - and a configurator that does not hold them will sell something the factory cannot make.

An Eindhoven configurator is a constraint problem

The common implementation is a list of option groups with validation at the end, and it fails in the worst order.

Somebody chooses twelve options, submits, and is told the combination is invalid - without being told which choice to change. They try again. The real cost is not the error, it is that the configurator has stopped being usable as a tool for thinking and has become a form to be defeated.

What works evaluates the rules as each selection is made, so incompatible options are visibly unavailable with a reason rather than silently rejected afterwards. The rules themselves are data - requires, excludes, implies, with a note explaining each - rather than conditionals in code, because the people who know them are not the people who deploy.

The extraction of those rules is most of the project. Turning "we never do that with the high-temperature variant" into a stored rule with a reason takes time with the engineers who know, and it is worth testing against historical orders to find the constraints nobody remembers mentioning.

The Eindhoven configuration is stored in Laravel, not derived

The second decision has a ten-year horizon, which is roughly how long Eindhoven equipment stays in service.

A unit sold in 2019 was built to a configuration defined under a catalogue, part numbers and rules that have all since changed. A service engineer standing in front of that machine in 2026 needs to know what is in it - and that is only answerable if the configuration was stored as resolved at the time, with a reference to the definition version that produced it.

Reconstructing it from the current catalogue gives the configuration the machine would have if it were sold today, which is a different machine. This is the same discipline as versioned pricing and effective-dated reference data, and in capital equipment it has a direct consequence in spare parts and service contracts.

Quotes have to be reproducible

A quote holds a configuration and a price, and both of their definitions will move.

So the quote stores the resolved configuration, the price per line, and the versions of the option definitions and the price list it was calculated from. Reproducing the quote loads those versions rather than the current ones.

Without that, a customer holding a printed quote from March and a salesperson looking at the system in June see different numbers, and there is no way to establish which is right. Money and dates are the decisions you cannot undo covers the arithmetic; the versioning is what makes the arithmetic reproducible.

An Eindhoven serial number has to answer for itself in 2036

A machine is shipped. A decade later a service engineer stands in front of it and needs to know what it is - which options it was built with, which firmware it left with, which part number fits the assembly in question.

That requires an as-built record per unit, not a reference to the product it was ordered as. The order said what was wanted; the as-built says what was fitted, including the substitution made on the line because a component was unavailable that week. Those differ more often than anybody expects, and the difference is exactly what the engineer needs ten years later.

Parts supersede, which is the detail that makes a naive implementation useless. The component in the original build is no longer available and has been replaced twice, so the question is not "what part is in this machine" but "what part do I order now for this machine". That is a supersession chain with effective dates, and following it to a currently orderable part is the actual query. Where a supersession is conditional - the replacement fits only in combination with another change - that condition has to be expressible rather than left in a note.

Firmware and configuration belong in the as-built too. A unit updated in the field is no longer in the state it shipped in, and service history is therefore part of the same record rather than a separate system that has to be cross-referenced by serial number.

Laravel engineering changes with a Eindhoven effective date

A change order says a design changes. The useful question is which units it affects and from when, and those are two separate decisions that the application has to carry.

Some changes apply to new production only. Some apply to units in the field and generate a service campaign. Some apply retroactively to in-flight orders that have been configured but not yet built, which is the awkward middle case, because a customer has a confirmed quote against a configuration that no longer exists. Whether that order is rebuilt against the new revision or allowed to complete against the old one is a commercial decision - and the system has to be able to do either, which means a configuration is pinned to a revision rather than resolved live.

Revision levels sit on each component and on each document, and a bill of materials references revisions rather than parts in the abstract. Otherwise a drawing update silently changes what a six-month-old quote described, and nobody can tell whether the unit built last month was built to revision C or D.

Effective dates make the whole thing queryable in the one direction that matters during a problem - given this date and this configuration, what was the correct design. Storing the change order with its effective date, its affected revisions and its disposition for in-flight work answers that in a query instead of a conversation with whoever has been there longest.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - Dutch invoicing and e-invoicing, payment methods, the accessibility statement - is on the Netherlands market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in euros by bank transfer, with no Turkish VAT under the export-of-services exemption.