Andrea Giovanni Muttisoftware engineer and IT consultant, Mantua

I connect machines to the ERP and take software to production

I work on integrations between machines in the field and the systems companies run on. I take projects as a consultant: I start from the process I find, size the solution to it, and stay the person to call when something stops.

What I do

Integration between machines and the ERP

I read the data collected on board the machine and write it into the ERP. The job runs every day without an operator. Every record keeps its source and the result of the write, and the link between machine and ERP stays documented.

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

See the case →

Custom business software, carried through to release

I build the application and take care of the release, with staging environments kept separate from production. Database migrations go in two phases: the reversible part first, the final part only after verification on real data.

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

See the case →

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. The cost of every run stays under control.

This line of work is at its first pilot project.

typescript, anthropic sdk, node, jsonl

See the internal R&D →

Work

01

Vehicle data from the vendor cloud into the ERP

Logistics and transport, fleet of 60 vehicles

problem

Data from the sixty vehicles stayed inside the vendor portal. An operator copied it into the ERP by hand. Nobody else knew the procedure, and no history was kept.

When the workload was high, some days were skipped. Management control saw spikes in fuel consumption and mileage weeks late, too late to dispute anomalies or wrong supplier charges.

what I did

  1. Reconstructing how the platform API works, documented only in part, by watching the traffic of its web portal and checking every assumption with test calls.
  2. Middleware in Python that queries the Kiwisat REST API every day and writes into SQL Server, before handing the data to the TeamSystem Alyante CPM system.
  3. 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.
  4. Six validation rules stop inconsistent data before the write. Eight automated tests cover them.
  5. Delivery 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.
  6. Direct integration through a transactional outbox, where the write and the outbox row share one transaction. A separate dispatcher delivers with an idempotency key.

outcome

In production, it runs on the server and the scheduler the client already had, with no extra paid services. Every run leaves a diagnostic log, an error sends an email notification.

  1. Kiwisatvendor REST API, only partly documented
  2. Middleware Pythondaily, on the client's scheduler; 6 validation rules
  3. SQL ServerMERGE on a composite key: history, no duplicates
  4. CSV file over SFTPatomic rename, exponential retryTransactional outboxdispatcher with idempotency key
  5. TeamSystem Alyante CPMthe client's ERP
Two delivery paths to the ERP: files over SFTP or direct integration. Every run leaves a diagnostic log, an error sends an email.
Before and after
By handAutomated
Frequencydays skipped when the workload was highevery day
Consumption anomaliesseen weeks latedata updated every day
Procedureknown to one persondocumented
Historynonein SQL Server, with source and result of every record
When something stopsnoticed weeks lateremail alert and diagnostic log

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

02

Lifecycle and release of a time and attendance application

Payroll consulting and HR services, cloud service for several companies

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

  1. Staging environments kept separate from production, where every release is tried first.
  2. Automated builds, and a release that always follows the same procedure.
  3. Database migrations in two phases: reversible changes first, final ones only after verification on real data.

outcome

A wrong migration is rolled back in the first phase, before it becomes final, and the release does not depend on who runs it.

typescript, postgresql, docker, ci/cd, git

03

Data recovery and remote diagnosis on multi client installations

Industrial automation and cogeneration, telemetry from energy plants

problem

On cogeneration plants, sampling boards and PLCs collect time series of thermal and electrical telemetry. This data cannot be recreated: if the database is corrupted or the storage fills up, that day's performance data is lost for good and the reporting required for state incentives is no longer valid. 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

  1. On PostgreSQL, across multi client installations, I run the backups and bring the data back online after a fault, checking its integrity when the work is done.
  2. Internal tools developed in Python and Bash that automate the diagnostic checks, from hardware load tests to storage space monitoring.
  3. Diagnosis over SSH and provisioning of virtual machines on bare metal, VMware and DigitalOcean. Network segmented through VLANs and site to site VPNs.

outcome

Fault diagnosis got faster: the tools point to where the work is needed before anyone opens a session. Client data stays recoverable even after a database fault.

linux, postgresql, python, bash, vmware, digitalocean

04

Helpdesk for several companies, with the data separated in the database

Outsourced IT services, freelance project

problem

An IT service provider runs first-level support on behalf of several companies, all on the same portal. Each company must see only its own tickets, and the provider must know which ones are about to miss the agreed times.

what I did

  1. Ticketing portal in Java over JDBC, with no framework. Data separation between companies is handled by PostgreSQL Row Level Security.
  2. SLA monitoring module measuring response time and resolution time.
  3. 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.

java, jdbc, postgresql, row level security

Internal R&D: Agentic HUB

Internal project, developed outside any client engagement. No client runs it in production.

The part I work on is cost control. A shared token ledger measures every run and enforces a cap of $2.00: past that threshold the supervisor stops the workers, so a loop cannot turn into an unexpected bill. In internal tests, a full cycle of analysing and breaking down an average process costs about $0.07.

Agent orchestrator developed in TypeScript directly on the Anthropic SDK, with no intermediate framework.

A supervisor breaks the work down and assigns tasks to workers. State persists to JSONL files and filesystem tools operate inside a sandbox.

Development continues in order to test automation on real processes. Once a project of this kind runs in production at a client, I will document it under work.

typescript, anthropic sdk, node, jsonl

How I work

  1. I understand the process before writing code.
  2. I size the project to the process I find, using the tools the company already has.
  3. I trace a fault back to its cause and fix that.
  4. I pick the boring solution that holds for years.
  5. I keep environments separate, testing stays outside production.
  6. I leave the documentation needed to continue with another supplier.

Profile

languages
TypeScript, Java, Python, C, Bash, T-SQL
frameworks
Next.js, Fastify, Django, JDBC, Streamlit
databases
PostgreSQL, SQL Server, SQLite, Prisma
infrastructure
Linux, Docker, CI/CD, Git, VMware, DigitalOcean, Railway
protocols
REST, OAuth2, OIDC, Microsoft Graph, SFTP

Tell me the context in two lines

Which machines or systems are involved, and what has to happen. I will tell you whether it is work I can take on and how I would set it up.

email
andreamutti002@gmail.com
phone
+39 351 568 0785
linkedin
linkedin.com/in/andreamutti

I work across Lombardy, Veneto and Emilia, and remotely. Based in Mantua.