Mouloud Elasri

Problem

Working out what a plant is — and then what is wrong with it — usually means guesswork or scattered forum threads. People want a clear answer: what is this, is it healthy, and what should I do about it, without having to be a botanist.

Solution

PlantPal recognises a plant species from a photo and, in the same flow, diagnoses disease and recommends care. A vision model handles recognition; a reasoning LLM turns the raw classification into botanical detail, care instructions and treatment advice, explained in plain language. It keeps conversation memory, so follow-up questions stay grounded in the same plant and image.

Features

• Plant species recognition from an uploaded image
• Disease detection and diagnosis
• Care and watering recommendations
• Treatment and prevention advice
• Conversational follow-up with conversation memory
• Plant encyclopedia

Architecture

1. Frontend
2. Backend API
3. Vision AI model
4. Reasoning LLM
5. Plant knowledge base
6. Response generation

Tech

• Angular
• Spring Boot
• PostgreSQL
• Docker
• Vision Models
• LLMs
• REST APIs
• Authentication

Challenges

• Combining two very different AI models — a vision classifier and a reasoning LLM — into one coherent answer.
• Keeping the conversation anchored to the actual image and classification rather than letting the LLM drift.

Lessons

• Prompt engineering matters as much as model choice: the product only feels intelligent when the reasoning step is tied to real classifier output and conversation memory.

Future work

• Broaden the species database
• On-device / offline recognition
• Richer care scheduling and reminders

Problem

SFR's WorkFlow Fibre B2B platform was running on aging PHP and an old Spring 1.7 codebase: hard to extend, harder to keep secure, and drifting out of step with the rest of the stack. It also had to stay live for the business throughout any change.

Solution

Led the platform through a staged modernisation — migrating the backend from PHP to Spring Boot and upgrading Spring from 1.7 to 2.7 — while keeping the application in production. REST and SOAP contracts stayed stable so existing integrations kept working, with Kafka carrying messaging between services.

Architecture

1. Angular client
2. REST / SOAP API layer
3. Spring Boot services
4. Kafka event bus
5. Database

Tech

• JEE
• Spring
• Spring Boot
• Angular
• PHP
• Kafka
• REST
• SOAP

Challenges

• Migrating a live B2B platform without breaking existing integrations.
• Preserving legacy PHP and Spring 1.7 behaviour through the cutover while the architecture underneath changed.

Lessons

• Incremental, well-tested migration beats a big-bang rewrite.
• Holding REST/SOAP contracts stable lets the backend change underneath consumers safely.

Future work

• Further decomposition into microservices
• Broader test-automation coverage

Problem

Shipping several small AI-powered products as one engineer means every app re-solves the same problems: AI provider access, cost control, deployment, monitoring, conventions. And LLM APIs bill by usage — one runaway loop in a hobby app can cost real money. The goal: run many small apps without rebuilding infrastructure each time, and without ever letting AI spend go unmetered.

Solution

A personal platform of small single-purpose services, each in its own repository with self-describing metadata, all sharing one version-pinned contracts library. Every AI call flows through a single AI gateway that alone holds the provider keys, which makes cost control architecturally impossible to bypass: a synchronous pre-flight budget check before each call, asynchronous usage events over Kafka after it, and automatic downshift to a free local model when spending nears a ceiling. A control plane owns the app registry and scaffolds new repositories from templates; everything runs local-first on Docker Compose and streams live state over server-sent events to swappable dashboards. The platform is also an experiment in method: each repository is built by an AI coding agent working from a written spec, with decision logs and human review gates — software about running AI, built with AI.

Features

• One AI gateway holding all provider keys
• Budget ceilings with synchronous pre-flight cost checks
• Automatic downshift to local models near a spending ceiling
• Self-describing repositories scaffolded from templates
• Version-pinned shared contracts across every service
• Live platform state streamed over server-sent events

Architecture

1. Apps
2. AI gateway — sole key holder
3. Budget pre-flight
4. AI providers / local models
5. Usage events over Kafka
6. Live state feed
7. Dashboard

Tech

• Java
• Spring Boot
• Angular
• Kafka
• PostgreSQL
• Docker Compose
• Server-Sent Events
• Hexagonal architecture
• AI coding agents

Challenges

• Making cost enforcement impossible to bypass rather than merely discouraged — solved structurally: only the gateway holds provider keys, so there is no path around metering.
• Keeping dozens of small repositories consistent as a solo engineer — solved with a conventions library, repo templates and a compliance validator.
• Evolving shared contracts across many consumers without breakage — solved by publishing them as a pinned, versioned package.

Lessons

• Boundaries enforced by structure beat boundaries enforced by discipline: a rule the filesystem enforces cannot rot.
• Spec-first, agent-built development works when the spec is the source of truth and a human holds the review gate.
• Metering belongs at the choke point, not in every app.

Future work

• Move from local-first to hosted once the first product goes commercial
• More apps on the same platform rails
• A richer live visualization of platform state