Work
Products built end to end
Each case follows the same path: a real problem, a closed specification, a working product.
Restaurant QR menu, ordering and pay-at-table platform
2026 · Founder · In usability testing, CDMX pilot
- Problem
- Diners in Mexico still wait for the waiter to order and to pay, and splitting the bill is a mess. Restaurants lose table turns and tips.
- What I built
- Diners scan a QR, order and pay from their phone. Each person can run their own tab, or the table can order through the waiter as usual, and both coexist. Staff console, owner dashboard and menu management included.
- Time
- Defined and built in 2 weeks at 2 hours a day, in 10 verified sub-specs.
- Result
- Complete product ready for pilot; now in usability tests with real diners.
StackReact (PWA) · FastAPI · PostgreSQL · Conekta
BrightPath, EdTech SaaS for private schools
2025 – present · Co-founder
- Problem
- Private schools write assessments by hand and have no fast way to check that questions actually match the official curriculum.
- What I built
- A platform where schools create and validate assessments. 965-question bank, 670+ questions auto-classified by competency with the Claude API, and validation against 68 official documents through semantic search (RAG on pgvector). Google and Microsoft sign-in, data isolated per school.
- Time
- Built as a single engineer alongside my main job.
- Result
- Working product with a pedagogical-expert portal; onboarding first schools.
StackNext.js · Supabase (RLS) · pgvector · Claude API
Wapi, WhatsApp + Instagram inbox with an AI agent
2025 · Founder
- Problem
- Small businesses in Mexico sell and support customers over WhatsApp and Instagram, from several phones, with no history and nobody answering at night.
- What I built
- A single inbox for both channels with an AI agent that answers on its own and hands off to a person when needed. Two demo agents (a notary and a recruiter) and a live demo with a real client.
- Time
- Full demo stack built from scratch; this is where I consolidated the spec-driven method I use today.
- Result
- Working demo with a registered WhatsApp Business account.
StackChatwoot · Hono.js · OpenAI · WhatsApp Business API
Navigator, account search for Customer Success teams
2026 · Senior Full-Stack Developer at QuadSci · In development, team project
- Problem
- Customer Success managers at B2B software companies need to find which customers are growing, which are at risk and why, across hundreds of accounts and many months of data.
- What I built
- A search engine where a CSM combines business criteria (growth, feature usage, risk signals), saves searches, compares results across months (which accounts stayed, entered or exited) and exports them. I own the project end to end: architecture, task definition, backend, and integrating the team's frontend work.
- Time
- Delivered in iterations with team code review and weekly live demos to the CEO and product.
- Result
- Core search, month comparison and export working; moving to production.
StackFastAPI · Vue 3 · PostgreSQL · Docker (AWS, GCP, Azure)
Also: Tendero, a turnkey POS kit for micro-businesses on Android tablets (2025, paused) · Cauce, a digital product consultancy, cauce.tech (2024 – present, co-founder) · An analytics dashboard with AI chat and recommendations, 424 automated tests, quadsci.juantoledo.com.mx.
Method
How I work
Spec-driven development with AI coding agents as supervised implementers. The method is what lets one person deliver at team quality.
- 1
Investigate first
Before proposing anything I read the existing code and the real constraints. No assumptions; the report comes before the design.
- 2
Write a closed specification
Each feature becomes a spec with scope, data model, API contract and acceptance criteria. If it isn't in the spec, it isn't built.
- 3
Build in verifiable blocks
I implement with Claude Code in small sub-specs, each one tested and reviewed before the next. The agent writes; I decide and verify.
- 4
Verify and ship
Tests, a hard code review and a real-environment check before every delivery. Then the next block.
Why it matters. The result is predictable: you know what you're getting, when, and it keeps working after I'm done. That's the difference between fast and merely quick.