ERP & Business Systems
ERP fails when it copies a catalogue of modules instead of the company’s actual process. I model lots, pallets, invoices, roles and reports as they exist on the floor.
FRIGO SYS and AnyWare ERP were built that way: warehouse and multi-vertical operations, not a spreadsheet with a UI.
FRIGO SYS is a cold-storage ERP built as a native Tauri desktop app rather than a web dashboard, because the warehouse floor does not always have a dependable connection, and a native app with a Rust core runs without a browser tab open. Every inbound and outbound movement is recorded against a specific lot, with packaging, pallet count, tare and net weight captured the same way the paper slips worked before — the data model reflects the physical process instead of forcing the process to fit a generic product table.
AnyWare ERP is the multi-vertical version of the same idea: a modular Laravel and React platform with a shared data layer, so a sale updates inventory and accounting in the same transaction instead of needing a separate sync step, and each business activates only the modules its operations actually need — sales, inventory, HR, accounting, reporting.
Reports are generated from the same recorded movements that drove the operational screens, not rebuilt separately at month-end. That is the difference between a report that takes seconds because the data was already structured for it, and one that takes days because someone has to reconstruct it from spreadsheets first.
Business problems
- ERP that copies a catalogue of generic modules instead of modeling lots, pallets, invoices and roles as they exist on the warehouse floor.
- Stock and billing tracked in spreadsheets that drift from reality the moment two people edit them at once, with no lot-level traceability.
- A previous ERP rollout that forced the business to work around software built for a different kind of company.
- A generic ERP module for 'inventory' that has no concept of a lot, a temperature zone or a pallet, so the warehouse team works around it with a parallel spreadsheet anyway.
- Role permissions bolted on after the fact, so a warehouse operator can accidentally edit a client's invoice because nobody modeled who should be able to touch what.
- No way to reprint or reconstruct a historical document — an old invoice, an old slip — because the system only ever showed the current state, not a history.
Development process
- Model the real entities first — a lot, a pallet, a client's stock — before any of it becomes a screen or a report.
- Laravel and React for multi-vertical operations, or a native Tauri and Rust desktop app when the floor does not have a dependable connection.
- Wire billing and reporting to the same recorded movements that drive the operational screens, so a report is a query, not a reconstruction.
- Define roles around what a person actually does on the floor — receiving, picking, invoicing — not around generic admin/user labels that do not map to the job.
- Test the data model against a real week of the business's actual movements before building the rest of the screens, so the entities are proven, not assumed.
- Model currency and location as first-class fields on every relevant record from the start, if the business operates in more than one, instead of retrofitting it later.
- Keep every generated document — invoice, slip, report — retrievable exactly as it was issued, so a historical record can be reprinted or audited months later.
What you get
- Stock accuracy that reflects what is actually in the warehouse, because every movement is recorded against a specific lot instead of a generic total.
- Billing generated in seconds from recorded movements instead of rebuilt by hand at month-end.
- A system that matches how the business actually operates, the way FRIGO SYS and AnyWare ERP do for their operators.
- Permissions that match who should actually touch what, instead of everyone having admin access because nobody modeled roles properly.
- A system proven against a real week of operations before the rest was built, so the foundation does not need to be redone later.
- Multi-currency or multi-location operations handled natively instead of patched with parallel spreadsheets doing manual conversion.
- Any historical document reprintable exactly as issued, months or years later, for an audit or a client dispute.
Selected projects
FAQ
Do you implement Odoo or SAP?
I build custom systems when off-the-shelf ERP does not match the workflow. I can also integrate around existing tools via APIs.