Juan RamírezLearningES

Full Stack Developer, building with AI

Complete products — frontend, backend, data, payments and the pipeline that ships them.

Juan Ramírez

01Skill2 cases

Real money, real cards, phones with no signal — flows that hold up.

  • Katapult Labs
  • Devsu
01.1 — Katapult LabsSenior Full Stack Developer · 2025 — Now
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

A transaction platform on Stripe: checkout, saved cards, subscriptions, platform fees, payouts and receipts — one flow, built and maintained by me.

AI in the loopTests, debugging and pixel-precise UI, accelerated with AI.

Next.js / NestJS / Stripe / Supabase Postgres / Redis / Design system

checkintenteventspersistCheckoutStripe ElementsNestJS APIcommands · queriesAbuse guardRedis · per deviceStripeintents · subscriptionsConnected accountsfees · payoutsWebhookssignature-verifiedPostgresstate · RPCReceiptsPDF · CSV · S3
01 / 08
  1. Buyers pay inside the product with Stripe Elements.
  2. A NestJS API creates and confirms every PaymentIntent.
  3. Before a card is charged, a Redis guard checks the device.
  4. Stripe handles cards, saved methods and subscriptions.
  5. Connected accounts get their share; the platform keeps its fee.
  6. Signed webhooks report what really happened.
  7. Every transaction state lands in Postgres.
  8. Receipts and exports are generated from that one record.
Fig. 01.1.1 — Checkout, a guarded charge, signed webhooks and one persisted record.

Built

  1. 01Auth
  2. 02Users
  3. 03Checkout
  4. 04Subscriptions
  5. 05Webhooks
  6. 06Payouts
  7. 07Receipts
  8. 08Reports
Fig. 01.1.2 Delivery pipeline — every merge walks the same path to production.

Impact

$100K+

In transactions, hundreds of thousands of dollars

100%

Of the payment flow built and maintained by me

01.2 — DevsuMobile & Frontend Developer · 2024 — 2025
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

Mobile payments for Ecuador's largest digital wallet: QR codes, deep links and offline payments encrypted on the device.

React Native / NestJS / TypeScript / AWS / Design system

no signalWallet appReact NativeQR · deep linkstart a paymentOffline paymentencrypted on deviceBack onlinesyncBackend servicesNestJS · AWSCacheno empty responsesChartsmoney, made visual
01 / 07
  1. A wallet app, often on a weak network.
  2. Pay by scanning a QR code or opening a deep link.
  3. With no signal, the payment is encrypted and kept on the device.
  4. When the network returns, it syncs.
  5. Backend services take over, across a large distributed team.
  6. A cache layer stops empty or invalid responses from reaching the user.
  7. Interactive charts show people where their money goes.
Fig. 01.2.1 — A payment that starts offline and settles once the network is back.

Built

  1. 01QR payments
  2. 02Deep links
  3. 03Offline mode
  4. 04Encryption
  5. 05Charts
  6. 06Service migration
Fig. 01.2.2 Delivery pipeline — every merge walks the same path to production.

Impact

1000s

Of people paying with no connection

#1

Digital wallet in Ecuador

02Skill3 cases

Agents do the typing. I own the architecture, the review and the result.

  • Every project
  • Neura
  • Lucka · Lexio
02.1 — Every projectAI-augmented workflow · 2025 — Now
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

I don't trust AI to write good code. So I built a system that doesn't need trust.

Claude Code / MCP / Agents / Skills / Hooks

planevery editMeeting notesGranolaTicketswritten by ClaudePlanner agentdecisions → questionsClaude Coderules · Figma · codeHooksblock · lint · formatTest plannerJest · CypressAI review4 reviewers + refuterPull requestlive preview
01 / 08
  1. It starts in a meeting. Granola takes the notes.
  2. Claude turns them into tickets.
  3. A planner agent writes the plan. Every decision becomes a question I answer.
  4. Claude codes against one short, strict rules file and the Figma design.
  5. Hooks check every edit. Hardcoded colour, wrong file name, push to main: blocked.
  6. A test planner proposes the edge cases. I pick. Jest and Cypress run them.
  7. Four AI reviewers check the code in parallel. A fifth tries to prove them wrong.
  8. Every pull request ships with a live preview.
Fig. 02.1.1 — From a meeting to a reviewed pull request, with agents doing the typing.

The loop

  1. 01Notes
  2. 02Ticket
  3. 03Plan
  4. 04Code
  5. 05Hooks
  6. 06Tests
  7. 07AI review
  8. 08PR
Fig. 02.1.2 Delivery pipeline — every merge walks the same path to production.

Impact

+200%

Delivery output since AI joined the loop

3 days

To build a complete application

2 wks

To ship a feature scoped at three months

02.2 — NeuraTech Lead · Full Stack (part-time) · 2025
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

Neura, a personal AI assistant built from zero: send a voice note, get emails written and tasks created. Web, mobile and backend, with a team of three.

AI in the loopAI inside the product, and across the build: screens, API integration and UI iteration.

Next.js / React Native / Express / Supabase / Redis / OpenAI / Design system

transcriptVoice notemobile appBackend APIExpress · authTranscriptionspeech → textAI intentwhat to do nextEmailwritten and sentTaskscreated and scheduledWeb appreview everything
01 / 07
  1. The person just talks: a voice note from the phone.
  2. One backend receives it, with auth and rate limits.
  3. The audio becomes text.
  4. An AI step decides what was asked for.
  5. Emails get written and sent.
  6. Tasks get created.
  7. A web app shows everything Neura did.
Fig. 02.2.1 — A voice note in, emails and tasks out.

Delivery

  1. 01Idea
  2. 02Scope
  3. 03Design
  4. 04Build
  5. 05Integrate
  6. 06Release
Fig. 02.2.2 Delivery pipeline — every merge walks the same path to production.

Impact

15+

Screens delivered

<3

Months from idea to working app

3

Apps: web, mobile and backend

02.3 — Lucka · LexioSide projects · 2026
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

In Lucka and Lexio, AI writes data the app keeps: expenses from a voice note, lessons from a phrase. One schema, any provider, nothing saved unchecked.

Tauri / Rust / SQLite / whisper.cpp / llama.cpp

textanswerconfirmedVoice or textwhat the user givesWhisperon deviceOne JSON schemastructured outputLocal modelQwen · llama.cppYour own keyOpenAI · Claude · GeminiValidationtyped · testedSQLitethrough Rust
01 / 07
  1. The user speaks or pastes a text.
  2. Speech becomes text on the machine itself.
  3. One JSON schema tells every model exactly what to return.
  4. A local model can answer, with a grammar it cannot break.
  5. Or OpenAI, Anthropic or Gemini, with the user’s own key.
  6. Every answer is validated and mapped to real records in tested code.
  7. Only then is it saved, after the user confirms.
Fig. 02.3.1 — Untrusted model output, turned into rows the app can rely on.

Flow

  1. 01Speak
  2. 02Transcribe
  3. 03Interpret
  4. 04Validate
  5. 05Confirm
  6. 06Save
Fig. 02.3.2 Delivery pipeline — every merge walks the same path to production.

Impact

4

AI providers behind one interface

1

Schema that every provider fills

0

Model answers saved without validation

03Skill2 cases

APIs that serve hundreds of people at once, on SQL, NoSQL and Redis.

  • Katapult Labs · Kuepa · GooDev
  • Kuepa → Katapult Labs
03.1 — Katapult Labs · Kuepa · GooDevFull Stack Developer · 2022 — Now
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

APIs that answer hundreds of people at the same time: relational and non-relational data, webhooks from payment providers, and Redis in front of whatever gets slow.

AI in the loopImplementation plans, backend code and tests drafted with AI, reviewed line by line.

NestJS / Express / PostgreSQL / MySQL / MongoDB / Prisma / TypeORM / Sequelize / Mongoose / Redis

eventsreadwritemissHundreds of usersat the same timeAPINestJS · ExpressWebhookssignature-verifiedRedis cacheanswers from memoryPrisma · TypeORMSequelize · MongooseRelationalPostgres · MySQLNon-relationalMongoDB
01 / 07
  1. Hundreds of people at once, each asking for their own data.
  2. One API answers them all, with auth, roles and rate limits in front.
  3. Providers like Stripe push events by webhook; each one is verified before it counts.
  4. Redis answers the frequent reads from memory, so the database is not asked twice.
  5. Writes go through an ORM: Prisma, TypeORM, Sequelize or Mongoose, or plain SQL, whichever the project calls for.
  6. Data with strict relations lives in Postgres or MySQL.
  7. Documents that change shape live in MongoDB.
Fig. 03.1.1 — Many users at once, one API, a cache in front and the right database behind.

Built

  1. 01Auth & roles
  2. 02REST APIs
  3. 03SQL
  4. 04NoSQL
  5. 05ORMs
  6. 06Webhooks
  7. 07Redis cache
  8. 08Jobs
Fig. 03.1.2 Delivery pipeline — every merge walks the same path to production.

Impact

100s

Of users at the same time, each reading their own data

SQL + NoSQL

Postgres, MySQL and MongoDB, chosen by what the data needs

Webhooks

Payment events, verified before anything is saved

03.2 — Kuepa → Katapult LabsFull Stack Developer · 2022 — Now
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

First to make an edtech platform answer faster. Later, to rate-limit an API and stop card testing before a stolen card is ever charged.

Redis / Node / NestJS / Lua / Stripe

alloweddeclinedtrippedPayment requestwith a device idDevice · IP bucketwho is askingVelocity checkintents per 10 minStripecharge attemptDecline webhookcard fingerprintRedis countersatomic Lua scriptsCircuit breakerblock · retry-after
01 / 07
  1. Every payment request carries a device id.
  2. Each one is bucketed by device and by IP.
  3. Too many payment intents from one device in ten minutes: blocked on the spot.
  4. Otherwise, Stripe tries the card.
  5. Declines come back by webhook, with the card fingerprint.
  6. Redis counts distinct declined cards per bucket, atomically.
  7. Three bad cards on one device trip the breaker. A crowd on shared Wi-Fi never does.
Fig. 03.2.1 — A two-layer circuit breaker that counts declines, not traffic.

Over the years

  1. 01Response cache
  2. 02Rate limiting
  3. 03Throttler storage
  4. 04Velocity cap
  5. 05Card-testing breaker
Fig. 03.2.2 Delivery pipeline — every merge walks the same path to production.

Impact

Faster

Frequent reads served from memory instead of the database

Fair use

Rate limits shared by every server, so no one can flood the API

Fraud

Stolen cards blocked before they are ever charged

04Skill1 case

Every rule checked three times before anything reaches production.

  • Katapult Labs · Lucka
04.1 — Katapult Labs · LuckaFull Stack Developer · 2025 — Now
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

Every rule runs when the agent writes, when I commit and when CI merges. Desktop apps go further: real macOS and Windows builds are launched before each release.

AI in the loopThe same rules guard humans and agents. Neither can skip them.

GitHub Actions / Husky / Jest / Cypress / Supabase CLI / Vercel

deploypromoteOn writeClaude hooksOn commitHusky · lint-stagedOn mergelint · types · JestMigrationsapplied to a fresh DBPreviewVercel, per PRCypressagainst the previewEnvironments3, one database each
01 / 07
  1. On write: Claude hooks block what the rules forbid and lint every edit.
  2. On commit: Husky and lint-staged run the same rules again.
  3. On merge: CI runs lint, types and unit tests.
  4. Every migration is applied to a fresh local database before it can ship.
  5. Each pull request gets its own Vercel preview.
  6. Cypress tests the real preview in a browser.
  7. Migrations roll out one environment at a time: feedback, staging, main.
Fig. 04.1.1 — Three guardrail layers, a preview per pull request and migrations per environment.

Delivery

  1. 01Write
  2. 02Commit
  3. 03CI
  4. 04Migrations
  5. 05Preview
  6. 06Cypress
  7. 07Staging
  8. 08Production
Fig. 04.1.2 Delivery pipeline — every merge walks the same path to production.

Impact

Checkout

One-time and recurring payments, run end to end in a real browser on every PR

Roles

Who can see and do what, checked by unit tests on every PR

Migrations

Every database change applied to a fresh database before it ships

05Skill1 case

Smaller deploys, a smaller bill, teams that ship on their own.

  • Kuepa Edutech
05.1 — Kuepa EdutechFull Stack Developer · 2022 — 2024
  • Frontend
  • Mobile
  • Backend
  • Database
  • Integrations
  • CI/CD
  • AI

Proposed and built a Module Federation architecture for an education platform, then kept it fast: real-time updates, jobs, legacy clean-up and unit tests.

React / Module Federation / Node / Socket.io / AWS / Design system

manifestliveUsersstudents · advisorsApp shellhost · routingAWSremoteEntry.jsDashboardsremoteLeads & reportsremotePaymentsremoteNode APISocket.io · jobs
01 / 07
  1. Students and advisors, one entry point.
  2. A thin shell owns routing and loads the rest.
  3. Remotes are fetched at runtime from AWS.
  4. Dashboards ship on their own.
  5. Leads and reports ship on their own.
  6. Payments ship on their own.
  7. A Node backend pushes live updates over Socket.io and runs the jobs.
Fig. 05.1.1 — A thin shell loading independently deployed remotes, with a live backend behind.

Built

  1. 01Proposal
  2. 02Shell
  3. 03Remotes
  4. 04Real-time
  5. 05Jobs
  6. 06Unit tests
Fig. 05.1.2 Delivery pipeline — every merge walks the same path to production.

Impact

~50%

Smaller deployments

~30%

Lower AWS bill

2+

Years on the platform

8 rolesWhere the work happened

  1. 01Katapult LabsSenior Full Stack DeveloperPayments, API and CI/CD, end to end2025 — Now
  2. 02NeuraTech Lead · Full Stack (part-time)An AI assistant from zero2025
  3. 03DevsuMobile & Frontend DeveloperOffline payments for a national wallet2024 — 25
  4. 04GooDevFull Stack DeveloperMySQL architecture and payment gateways2023 — 24
  5. 05Kuepa EdutechFull Stack DeveloperMicro-frontends, real-time and Redis2022 — 24
  6. 06IndependentWeb development tutorTaught web development and helped students land jobs2022 — 23
  7. 07AKE labFrontend DeveloperDrag-and-drop interfaces, Node and Oracle on AWS2021 — 22
  8. 08Editorial H&GFrontend DeveloperReact and Redux interfaces2021
4 projectsBuilt on my own time

1 CourseNotes, not lessons

Courses I’ve taken, explained the way I understood them, with something to try for every idea.

All learning →
Get in touchEnd of portfolio

Open to remote Full Stack and AI-augmented developer roles. I work in English every day: stand-ups, planning, code reviews and client meetings.

rjuandavid1002@gmail.com
© 2026 Juan RamírezSet in Inter Tight & JetBrains MonoBuilt with Next.js & GSAP