I connect machines to the ERP and take software to production

Integration between machines and the ERP

I read data from the platform that collects it on board the machine and write it into the ERP, with a job that runs every day without an operator. Every record carries its source, timestamp and result, so the link between machines and ERP stays documented.

python, rest, sftp, t-sql, sql server

Custom business software taken to production

I build the application and follow it to release: separate staging environments, automated builds, database migrations in two phases. The reversible part goes first, the final part only after verification on real data.

typescript, next.js, fastify, postgresql, prisma, docker, ci/cd

Automation and applied AI on one specific process

I take a process done by hand today, break it into verifiable steps and hand it to a program, with the cost of every run recorded and readable.

This line of work is at its first pilot project, the orchestrator described in the Lab section. I state this openly before discussing it with a client.

typescript, anthropic sdk, node, jsonl

yotta core / in production since 2 february 2026 / logistics, six connected vehicles

Vehicle data from the vendor cloud into the ERP

problem

Data from the six vehicles stayed inside the vendor portal. One person copied it into the ERP by hand, was the only one who knew the procedure, and no history was kept.

what I did

• Middleware in Python that reads the Kiwisat REST API every day and writes into the client database.
• MERGE on a composite key, so re-running on the same data creates no duplicates. Daily usage is derived from the difference between cumulative counters.
• Six validation rules stop inconsistent data before the write, with eight automated tests covering them.
• Delivery to the ERP over SFTP, with an atomic rename once the transfer completes and exponential retry. If the transfer does not go through, the CSV stays in the client directory.
• Direct integration through a transactional outbox: the write and the outbox row share one transaction, and a separate dispatcher delivers with an idempotency key.

outcome

In production since 2 February 2026, it runs every day on the server and the scheduler the client already had, with no extra paid services. Every run leaves a diagnostic log, and an error triggers an email notification.

stack

python 3.12, sql server 2019, t-sql, rest, sftp, fernet, pytest

yotta core / since 2025 / enterprise hr saas, time and attendance

Lifecycle and release of a time and attendance application

problem

An application used every day to record attendance needs frequent updates, and every update touches data the client companies have already recorded.

what I did

• Staging environments kept separate from production, with the same release procedure.
• Automated builds and orchestrated releases, always along the same path.
• Database migrations in two phases: reversible changes first, final ones only after verification on real data.

outcome

Production releases follow a repeatable procedure, and a wrong migration is rolled back in the first phase, before it becomes final.

stack

typescript, postgresql, docker, ci/cd, git

anteklab / 2023 to 2025 / professional video surveillance and building automation

Data recovery and remote diagnosis on video surveillance installations

problem

On a video surveillance installation the recordings cannot be recreated: if the database is corrupted or the storage fills up, the lost material does not come back. The installations run on hardware at the client site, on VMware and on remote servers, and a fault has to be isolated remotely.

what I did

• PostgreSQL upkeep across multi client installations: running the backups, restoring the data and verifying integrity at the end of every intervention.
• Internal tools developed in Python and Bash to automate the diagnostic checks: hardware load tests and storage space monitoring.
• Diagnosis over SSH and provisioning of virtual machines on bare metal, VMware and DigitalOcean, with network segmentation through VLANs and site to site VPNs.
• Integration and verification of video surveillance and building automation devices over the ONVIF and RTSP protocols.

outcome

Fault diagnosis got faster: the tools point to where the work is needed before anyone opens a session. Client recordings stay recoverable, and every restore ends with an integrity check.

stack

linux, postgresql, python, bash, vmware, digitalocean, onvif, rtsp

freelance project / multi company helpdesk portal

Helpdesk with per company data separation and SLA monitoring

problem

Several companies share the same support portal. Each company must see only its own tickets, and whoever runs the service must know which ones are about to miss the agreed times.

what I did

• Ticketing portal in Java over JDBC, with no framework, with data separation between companies handled by PostgreSQL Row Level Security.
• SLA monitoring module measuring response time and resolution time.
• Alerts on tickets close to their deadline, ordered by priority.

outcome

Separation between companies lives in the database, so it holds for every query the portal runs. Tickets close to their deadline surface before the time is up.

stack

java, jdbc, postgresql, row level security