Industrial lifting-equipment configuration platform

Context

Requests start with a customer need in Sales. When a request needs technical resolution, engineering, technical and operations staff work out the configuration: the required capacity, the geometry and the compatible components.

Problem

Before the platform, that technical work depended partly on spreadsheet calculators, technical tables and catalogs, engineering references and manual validation. Some product families had their own spreadsheet calculators.

The platform was built to digitalize and centralize technical configuration, calculation and validation: depend less on spreadsheets and manual checks, reduce errors and the time needed to reach a technical configuration, and keep the engineering rules in one reusable internal system.

Constraints

• Engineering owns correctness. Domain specialists own the formulas, assumptions and technical rules, and validate them.
• Rules derive from published lifting-equipment standards.
• Operational data changes. Product, availability and cost-related data live in the company’s ERP and change over time.
• Commercial work belongs elsewhere. Price, margins, discounts, taxes and the customer quotation belong to the commercial system (CRM).

My responsibility

I was the primary implementer of the application, working with commercial, engineering and operations stakeholders.

• Analyzed existing spreadsheet calculators (their inputs, outputs, formulas and dependencies) and other technical artifacts to translate the domain rules into application logic.
• Designed and implemented the architecture: a React and TypeScript frontend, a REST API, a Python and FastAPI backend, and PostgreSQL.
• Built the backend, the API contracts and the frontend configuration workflow.
• Implemented the calculation engine, server-side validation and the component-compatibility and selection logic.
• Designed persistence for saved technical configurations.
• Worked on the platform side of the integrations with the company’s ERP and CRM.
• Wrote automated tests, set up Docker, and maintain and evolve the application.

I implement the engineering rules in software. I did not design the engineering formulas: specialists own them and validate their correctness.

Architecture

1. client
   • Configuration workflowReact, TypeScript
2. REST
   FastAPI application

   • Calculation engine
   • Validation
   • Component selection
   • Persistence
   • Integrations
3. data
   • storePostgreSQLdomain data, saved configurations

outside the platform

• externalCompany ERPproduct, availability and cost-related data → platform
• externalCRMplatform → technical configuration data

The backend is the single authoritative place for calculation, validation and engineering rules. The frontend consumes that logic instead of reimplementing it. PostgreSQL stores domain data and saved configurations. The ERP and the CRM sit outside the platform: it consumes product, availability and cost-related data from the ERP and passes technical configuration data into the commercial workflow.

Correctness model

The platform produces two kinds of answer, and they behave differently.

1. input
   • Technical inputs
2. deterministic
   • Engineering calculationvalidated rules
3. result
   • Valid technical candidates
4. filtered by current data
   • externalCatalog and availabilitychanges over time
5. output
   • Current component recommendation

• The engineering result is deterministic: the same technical inputs and the same rules give the same result.
• The component recommendation also uses the current catalog and availability. The same inputs can lead to a different recommendation later if stock or the catalog changed.

That difference is intended. The calculation stays stable, and the recommendation reflects what can actually be used now.

Validation runs in two places. The frontend validates for usability; the backend enforces the rules, so a request that bypasses the UI still has to meet them.

Engineering decisions

Centralize spreadsheet-derived rules in backend code

Problem

Engineering logic lived partly in spreadsheet calculators and technical artifacts, with manual validation.

Choice

Analyze the calculators' inputs, outputs, formulas and dependencies, and implement the rules as reusable domain logic in the backend.

Why

The goal was one owned implementation of the rules, not a web version of a spreadsheet screen. Extending the spreadsheets would have kept the dependency the project set out to reduce.

Trade-off

A rule change now needs software work, validation and a deployment. Engineering cannot edit the rules directly.

Make the backend authoritative for calculation and validation

Problem

Rules this important could not depend on frontend state or be implemented twice.

Choice

Calculation, validation and the authoritative rules live in the FastAPI backend. The frontend validates for usability; the backend enforces.

Why

One place executes the engineering logic, so the interface and the backend cannot drift apart, and requests that skip the UI still meet the constraints.

Trade-off

More responsibility sits in the backend, and new engineering behavior needs API work before the interface can use it.

Separate the deterministic calculation from changing operational data

Problem

Calculations need to be reproducible, but availability, catalog and cost-related data change over time.

Choice

Keep the calculation deterministic with respect to technical inputs and rules, and let a separate recommendation step use current operational data.

Why

A correct calculation should not change because stock changed, but a recommendation still has to be usable today.

Trade-off

The same inputs can lead to a different recommendation later. That is accepted on purpose.

Persist technical configurations

Problem

People need to save a technical configuration and come back to it, while the data around it keeps changing.

Choice

Store the configuration and its calculated result instead of recomputing it from current data every time.

Why

Recomputing a saved configuration against today's data could silently change its result or recommendation.

Trade-off

More data-model complexity, and a saved result can differ from what current data would produce. That divergence is partly the point.

Keep the engineering platform separate from the CRM

Problem

The platform had started to touch commercial concepts, but technical configuration and the commercial quotation are different responsibilities.

Choice

The platform owns technical correctness. The CRM owns the customer, price, margins, discounts, taxes and the quotation. The boundary was agreed with stakeholders; I implemented it and keep it in the architecture.

Why

The engineering application does not turn into the commercial system of record, and each system keeps a clear job.

Trade-off

The systems need integration and coordination, and data has to cross the boundary.

Correctness and validation

Correctness is shared between the people who own the rules and the software that runs them.

• Engineering specialists validate formulas, assumptions and expected results.
• I implement the rules, encode the validation, compare results with reference calculators and known cases where they exist, and protect the behavior with automated tests.

Reference calculators and known cases were used to validate implementation behavior. The automated tests cover calculation and domain behavior, validation rules, regression cases and API behavior.

Saved configurations

Saved configurations keep the technical result, so earlier work can be referenced without depending only on the current catalog, availability, cost context, component status or rules, all of which can change. Making the exact rule and catalog context behind each result explicit is one of the changes I would make today.

How the system and its boundaries evolved

The application started as a technical calculator and configurator. Saved configurations and a richer technical workflow came next. Later it began to use operational data from the company’s ERP and to pass technical data into the commercial workflow.

Early development explored commercial-facing features. As the system grew, its scope settled on technical work, and the boundaries became explicit:

This platform

Technical configuration, calculations, compatibility and validation, saved configurations, technical documents and the technical side of integrations.

CRM

Customer, selling price, margins, discounts, taxes and the authoritative quotation.

ERP

Enterprise, product, inventory and cost data. The platform consumes it and does not replace it.

Outcomes

The platform is used internally as part of the technical and commercial workflow.

• Engineering rules that lived partly in spreadsheets now run from one backend implementation.
• Repeated validation and component-compatibility checks are automated.
• Technical configurations are saved and can be referenced later.
• Component selection can take current availability into account.
• Technical configuration data continues into the commercial workflow without the platform becoming the CRM or ERP.

These outcomes are qualitative. No measurements are published for this system.

What I would change today

1. Explicit rule and catalog versioning. Saved configurations keep the technical result, but I would record more clearly which rule set and catalog context produced it, so historical results are easier to reason about. Full event sourcing would add complexity that is probably not justified here.
2. A stronger reference-case regression suite. More golden fixtures from validated cases and, where they fit, property-based tests for invariants. For this kind of software, confidence in domain behavior matters more than a coverage percentage.
3. Formal, observable integration contracts. Once the platform talked to the CRM and ERP, integration failures became a different class of problem from calculation errors. Clearer data contracts, better failure visibility and contract tests would address that.

I would do these before making the rules editable by non-developers. For engineering logic, governance, validation and versioning come first.