Type: Full-stack · AI product engineer
Barcelona · remote · EU
Available[ 22 · self-taught ]
Full-Stack AI
Product Engineer ✦
From idea to production >>>>>>
Build · govern · ship
I build AI products end to end — from idea to production — and understand their governance, not just their code.
Most AI roles don't ask for a degree. They ask for a real portfolio. This is mine.
AI-2026-ALS
Active
Products
05
shipped
In production
03
or App Store
Degrees
00
self-taught
Work — click any project to open it
Problem
A property manager fields calls all day about the same incidents — a leak, a stuck lift, a noise complaint — and each one interrupts whatever they were doing. Answering well costs time they don't have; not answering costs clients.
Approach
- A voice agent that picks up, understands the incident through natural conversation (not a "press 1" tree), and decides what to do with it.
- Automatic triage: it classifies urgency and incident type from what was said on the call, with no human in the happy path.
- It files the ticket already structured (property, type, urgency, summary) into the management system — ready for the manager to just decide, not transcribe.
Technical decisions
Conversation, not a phone tree
The challenge wasn't "make it talk", it was making the call resolve just as well whether the caller describes the problem in any order, at any level of detail — structured field extraction has to survive a real conversation, not a script.
No human intervention as the goal, not an option
The system is built so the happy path (clear, non-urgent incident) never touches anyone on the team — a human steps in only on the exception, not on every call.
Result
In production, handling real property-manager calls with no human intervention on the happy path.
Stack
How it works, live
CALLER
Hi, there's a water leak in the garage, dripping from the ceiling…
AGENT
Do you know which floor the water is coming from?
CALLER
The first floor, I think — it's coming down fast.
Property
Muntaner 88 · Garage -1
Type
Water leak
Urgency
High
Summary
Water from 1st floor into the garage. Needs shut-off + plumber.
Problem
A Meta Ads manager reviews dozens of ads a week and decides by hand which to scale, pause, hold or refresh — a judgment that repeats, is measurable, and eats time that should go to strategy, not staring at tables.
Approach
- OAuth connection to the Meta Ads API: the client authorizes read-only access to their ad accounts, without sharing credentials.
- Layer 1 — rules & heuristics: each ad is ranked against concrete thresholds (CPA, frequency, CTR, spend) and given a badge — Scale, Pause, Hold or Refresh. Deterministic and explainable: the reason for each badge can be pointed to.
- Layer 2 — Claude (Sonnet) via API reasons OVER the already-ranked data, not in its place: it writes the natural-language insight that explains the pattern behind the numbers, with the ranking already done by rules.
- Make.com fires the pipeline and delivers a weekly report by email — zero manual work between "the week closes" and "the client has it in their inbox".
Technical decisions
Two-layer architecture, on purpose
The business ranking (which ad gets scaled) comes from rules and thresholds, not an LLM — it's the part that has to be deterministic, auditable and cheap to run on every ad. The LLM is reserved for what it does better than a rule: explaining the pattern in words, not deciding the class.
Python backend, Make.com orchestration
The business logic (Meta API calls, ranking, insight generation) lives in Python; Make.com orchestrates the weekly trigger and delivery — separating "what it computes" from "when it fires" meant changing the reporting cadence never touched a line of logic.
Result
Automatic weekly report by email, zero manual work, in production with real clients.
Stack
How it works, live
The broad carousel is flagged Pause: frequency already at 4.3 explains the blown CPA — it's saturating the same audience. Rotate creative before reactivating. Retargeting can take scale: high CTR, low frequency.
Deterministic ranking
Weekly report · auto
Problem
Running an amateur league (padel, 7-a-side, whatever) by hand is a WhatsApp group, a spreadsheet and someone collecting cash. Rostry turns it into a real app, with payments built in and without the organizer being the one who holds the money.
Approach
- Flutter + Riverpod for the app, with a repository pattern (RostryRepository) defining a single abstract interface — one real implementation today, but the data layer never couples directly to the widget tree.
- Firebase as the backend (data, auth).
- Stripe Connect with destination charges: money goes straight to the league organizer's account, with a 5% platform fee withheld automatically on each charge — no manual money movement, no separate invoicing for the organizer.
Technical decisions
Destination charges, not own-collect + manual split
With destination charges, Stripe moves the money straight to the organizer and withholds Rostry's fee in the same charge — it avoids the platform holding third-party money as its own, with all the regulatory weight that implies.
Repository interface from day one
Even with only one real RostryRepository implementation today, the abstract interface was there from the start — cheap to define, and it keeps the app logic from coupling to Firebase if the backend ever changes.
The review process as part of the work
Build 7 approved: six iterations before parts got rejected or change-requested (in-app payment guidelines, metadata, account flows) — the app in production is also the app that survived Apple's real review.
Result
Approved on the App Store at build 7, with real payments between players already working.
Stack
How it works, live
League payment
$40.00
player → app
Organizer
95%$38.00
own account · direct
Rostry
5%$2.00
platform fee
The money never sits in a Rostry account: Stripe pays the organizer directly and withholds the fee in the same charge. Less regulatory weight, zero manual split.
Real-time booking SaaS for padel clubs.
Social padel app — videos, squads, community.
Every line above is real — in production or on the App Store.
Built solo, end to end
Currently building · technical cofounder
Aithority
EU AI Act compliance — as technical cofounder
Not just another product: it's the other half of the profile. Building with AI isn't enough if you don't also understand its regulatory and governance implications — and that's exactly what Aithority forces you to master.
Problem
A company using AI in HR, credit or biometrics has to comply with the AI Act: inventory every system, classify its risk and document it. Today they do it by hand, in spreadsheets, without knowing what applies or what's missing.
Approach
- A real classification engine: feed in a system's description and out comes its risk under Annex III and the concrete obligations that apply, with the reasoning — not a black box.
- Automatic inventory discovery: connect Microsoft 365 over OAuth (admin consent, read-only) and detect the AI tools the organization has already authorized.
- Art. 11 documentation and a dated evidence log, so the audit file composes itself and never describes a stale state.
The dashboard · how it looks
AI systems
6
inventoried
High risk
3
open files
Undocumented
4
pending
Evidence
14
attached
CV screening
HR
Credit scoring
Credit
Identity verification
Biometrics
Support assistant
Support
Deadline readiness
The engine · how it reasons
System
CV SCREENING
HR · Workday
Scope
ART. 3(1)
definition of AI
Role
ART. 3(4)
uses the system
Classification
HIGH RISK
Employment
Technical decisions
Detecting isn't classifying
Discovery fills the inventory, but doesn't decide the risk: "Notion AI" showing up doesn't say whether it's high-risk — that depends on use. Selling "fully automatic classification" would be the overpromise you get caught on in two questions.
No third-party tokens stored
The Microsoft Graph flow requests an app-only token on each sync instead of persisting it — less surface to protect, and consent is read-only over the directory.
Result
Own backend (classification engine + API) and dashboard in production. The startup has its first paying client and a place in Lanzadera.
Stack
What I build with
Toolkit
Full-stack · AI-native
Languages
Frameworks
AI
Data & infra
Integrations
Craft