Photo: free stock photography (Unsplash licence) — see imprint
Where types earn their keep
At the boundaries: what comes out of the ERP, what goes into the payment provider, what the shop sends you. A wrong shape at a boundary is the bug that silently charges the wrong VAT rate for a month. Types catch it at compile time.
`any` is a decision, not an accident
A codebase with `any` sprinkled through it has all the ceremony of TypeScript and none of the safety. Turn on strict mode from day one — retrofitting it into a 40,000-line project is a project of its own.
Validate at runtime anyway
TypeScript disappears at runtime. The ERP that promised you a number will one day send you the string "12,50". Parse and validate external input with a schema validator — types are a design tool, not a guard.
The real payoff comes in year two
Types pay back when someone who did not write the code has to change it under time pressure. That is the whole business case, and it is a good one.
- Strict mode from line one.
- Types at compile time, validation at runtime.
- The payoff is maintenance, not fewer bugs today.
Frequently asked questions
For code that touches money, yes — but not for the reason it is usually sold. Types do not prevent bugs in general. They prevent a specific class of bug at the boundaries, where a wrong shape from the ERP silently charges the wrong VAT rate for a month. If your project is a two-week script, skip it. If someone maintains it in year two, do not.
No, and believing they do is the expensive mistake. TypeScript disappears at runtime — the ERP that promised you a number will one day send a string with a comma in it, and your types will have no opinion about that whatsoever. Parse and validate every external input with a schema validator. Types are a design tool, not a guard.
You can, and it becomes a project of its own. Retrofitting strict mode into a large codebase is not an afternoon — it is weeks of decisions that produce no visible feature. Switching strict on from day one costs almost nothing. If you are already deep in JavaScript, convert the boundaries first: the ERP payloads, the payment calls, the shop responses.
It is a decision, so make it one consciously. A codebase with 'any' sprinkled through it has all the ceremony of TypeScript and none of the safety — you pay for the build step and the annotations and get nothing back. Used deliberately in one place, with a comment saying why, it is fine. Used to get past a compiler error, it is a lie you will find later.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer