dadecasdevSoftware engineer / Bilbao
I connect systems, data and processes.
Software that goes beyond the screen and makes things work.
PYTHON / ERP / INTEGRATIONS
MOVE YOUR CURSOR · EXPLORE THE OBJECT
Selected projects where code meets the reality of a working business.
01 / LIVECONCEPT VISUALOPEN CASE STUDY↗Spain's rail network in real time, on a map and in 3D, built entirely on public data.
Explore the case↗WHAT IT SOLVESBuilt entirely on public data: what can be done without access to internal systems.
An app for EV drivers: find a charger and know whether it is actually free.
Explore the case↗WHAT IT SOLVESDistinguishing a working charger from one that is actually free.
WMS integrated with the ERP for receiving, dispatch, picking and lot- and location-level traceability.
Explore the case↗WHAT IT SOLVESScan, identify, continue. Fewer steps, better traceability.
The best code starts with a good question.
I start by understanding how the business works. Most problems that reach me aren't programming problems: they're processes nobody has translated properly into software, or features requested literally without asking what they were meant to solve.
From analysis to deployment. And beyond: production is where the problems that really matter emerge.
Custom Tryton modules: sales, purchasing, warehouse, production, invoicing. Extending what the ERP already does rather than duplicating it.
Python services around data that matters: coherent models, queries that hold up under volume and APIs other people can consume without pain.
Connecting systems never designed to talk to each other: ERP to online shop, to the tax authority, to third-party APIs and their quota limits.
Getting repetitive work out of the way: migrations, closings, document generation and processes someone still does by hand every week.
Understanding how the business actually works before writing code. The feature being asked for is not always the one that solves the problem.
Serial-port scales, barcode scanners, thermal printers. Software that talks to the machines already on the shop floor.
Custom modules on Tryton 6.x and 7.x: sales, purchasing, invoicing, accounting, products, warehouse, production. Extending standard modules by reading their internals to reuse rather than duplicate.
Warehouse management applications: receiving, dispatch, picking, lots, locations, stock counts and expiry control, with the interface built around the barcode scanner.
Lot-based production control, raw material consumption, weighing via connected scale, in-process inspections and temperature logging, with different configurations per phase and per client.
POS with tables, orders, open tabs and payment; ticket and label printing; and dedicated performance work on the operations repeated most during service.
WooCommerce synchronisation across multilingual stores, TicketBAI e-invoicing and diagnosis of tax authority rejections down to the actual root cause.
CargaTurno: an application for EV drivers, from the data model and official-source integrations through to interface design and release.
Backend — Python · Flask · Tryton · REST APIs · Wizards & workflows · ODT reports
Data — PostgreSQL · SQL · Migrations · Data diagnostics · openpyxl · CSV / Excel
Infrastructure — Docker · Docker Compose · Linux · Bash · SSH · Git / GitLab
Integrations — WooCommerce · TicketBAI · E-invoicing · Third-party APIs · Identifier mapping
Business domain — ERP · SGA / WMS · POS · Production · Logistics · Accounting & tax
Hardware — Serial port · Industrial scales · Barcode scanners · Thermal printers · QZ Tray
Interface — The screens somebody uses eight hours a day. If every entry costs three extra clicks, that price gets paid in full, every single day.
Integrations — Where the system talks to the outside: the online shop, the bank, the tax office, the carrier. Almost always in a format nobody chose.
Business logic — The company's rules written once, in one place, instead of scattered across five screens and a spreadsheet.
Data — PostgreSQL: where the truth actually lives. A bad migration here doesn't show on day one, it shows on closing day.
Hardware — Scales, label printers, POS terminals, chargers. The point where software stops being abstract and starts weighing kilos.
Small changes. Clear decisions. Ownership of the outcome.
How the business works today, and why. Before any screen exists.
What software is already there, what can be reused and what is redundant.
The simplest solution to the real problem, not to the literal request.
Small, maintainable changes that reuse what already exists.
With the rest of the system, with external platforms and with the hardware.
And check it actually works, not just on my machine.
Guided by real usage, which is almost never what was predicted.
Tell me what you need and what is behind it. If I can help, we start there.