Leonardo Chiaramonti

Problem

The product needed new features weekly. A big-bang rewrite would freeze delivery for months; staying on the legacy stack made every feature slower and riskier.

Impact

• ✓A typed, testable codebase the team can actually hire for.
• ✓New listing screens go from days to hours thanks to the generic DataTable and route conventions.
• ✓Zero production downtime during the migration.
• ✓Owned product and delivery solo for a year: roadmap, priorities and releases for 650 stores — a product worth ~€300k/yr on its own.

Approach

• >Rebuilt the application on TanStack Start, React 19, TanStack Router/Query/Table/Form, Zod, shadcn/ui and Tailwind v4 — file-based routing, Suspense loader queries, search params as the single source of truth for pagination, sorting and filters.
• >Designed a generic server-side DataTable and a brand-consistent design system so new CRUD screens are configuration, not code.
• >Kept the legacy app in production during the transition; the same Spring Boot backend serves both, so cutover is per-screen, not per-product.

Problem

One codebase had to ship reliably to iOS and Android across dev, staging and production, with fast fixes in the field and no broken releases.

Impact

• ✓Inspectors get fixes in hours via OTA instead of days via store review.
• ✓Every release is exercised by E2E flows before it reaches a device.
• ✓One team ships three environments and two stores from a single codebase.

Approach

• >Expo SDK 53 + React 19 + React Native 0.79 with expo-router, NativeWind, MMKV, Reanimated and react-hook-form + Zod for offline-tolerant forms.
• >Multi-environment EAS builds (dev / staging / prod) with over-the-air updates for instant hotfixes that skip the store review cycle.
• >Quality gates in CI: 12 GitHub Actions workflows covering lint, type-check, unit tests and Maestro end-to-end flows; Sentry in production.
• >Performance work where it hurts: GridList over FlatList, calendar refactor, BottomSheet flows, keyboard handling.

Problem

Manual temperature logging is error-prone, does not satisfy auditors, and off-the-shelf IoT platforms were expensive, inflexible and impossible to integrate with the HACCP suite.

Impact

• ✓Continuous, automated cold-chain monitoring instead of manual logs.
• ✓Auditor-ready temperature records with alerting on threshold violations.
• ✓One person covered the entire chain: hardware sourcing → backend → Kubernetes release → field installation.

Approach

• >Scouted and selected the temperature probe and the hardware supplier: evaluation of cost, reliability and fit with the compliance requirements.
• >Designed the device management flow in the Java backend: device registration, auto-assignment to the responsible department, client-side grants, mock mode for development.
• >Compliance logic on top of the readings: thresholds, alerts and non-conformity records that feed the existing HACCP flows.
• >Shipped as the iot-compliance release on EKS, observable via OpenTelemetry like every other service.
• >Installed and commissioned the probes physically on site in the stores.

Problem

Deploys were manual and environment drift was constant. Nobody could answer "what exactly is running in prod, and how did it get there?"

Impact

• ✓Owner of ~12 production Kubernetes releases across the cluster.
• ✓A new microservice goes from repo to prod-ready deploy in a day, not a sprint.
• ✓Incidents start from traces and dashboards, not from guesswork.

Approach

• >Terraform multi-account AWS organization: management / audit / dev / staging / prod accounts, centralized CloudTrail, IAM SSO, reusable modules for VPC, RDS, Redis, ECR and EKS.
• >A single reusable eks-release-template Terraform module so every service (auth, payments, copilot, IoT compliance, frontends...) deploys the same way, with External Secrets and the AWS Load Balancer Controller.
• >Typed CI/CD pipelines per artifact class (Java, SPA, microfrontend, Python, DB migration) plus ArgoCD for cluster state.
• >Observability as a default: OpenTelemetry auto-instrumentation on every Java service, traces and dashboards in SigNoz.

Problem

Enterprise AI fails on the boring parts: malformed PDFs, hallucinated fields, cost control, and integration with existing auth and data.

Impact

• ✓Documents that previously required manual data entry become structured records automatically.
• ✓The copilot answers inside the product with tenant-aware context, not in a separate chat tab.
• ✓Development iterates without burning API budget thanks to mock mode.

Approach

• >Copilot: Spring Boot 3 / Java 17 microservice with Spring AI, plus a Next.js 15 + assistant-ui frontend, integrated with the platform’s OAuth identity provider.
• >Digitizer: NestJS + BullMQ pipeline that extracts structured JSON from PDFs with Claude, falling back to multimodal vision when the text layer is unusable; retry/backoff and a zero-cost mock mode for development.
• >Structured outputs validated against schemas — the model proposes, the code disposes.