DEV Community: Ronald Alejandro Azuero Maldonado

🌌 The Equity Pulse: Turning Chaotic Code into an Interactive Constellation of Equality

Ronald Alejandro Azuero Maldonado — Sat, 28 Mar 2026 14:33:18 +0000

This is a submission for the 2026 WeCoded Challenge: Frontend Art

Show us your Art

Art is rarely static, and neither is the pursuit of equity. I wanted to build a living, breathing digital canvas—an experience that requires the user's active participation to find its final form.

I present to you The Equity Pulse.

For the best experience, please turn on your sound, explore the canvas with your mouse, and don't be afraid to grab and drag the nodes once the system is aligned! (If you are on a mobile device, you will also feel haptic feedback as you uncover the artwork).

Sherman95.github.io

Accessibility Note: If you have sensory sensitivities, please use the Sparkles / Accessibility toggle in the top right corner to enable the Reduced Motion mode, which disables the parallax effects and pulsing animations.

Inspiration

When I read the prompt for "Gender Equity in Tech," I didn't want to just draw a shattered glass ceiling. I wanted to build a representation of the system itself. The tech industry often celebrates the myth of the "solitary male genius," while the profound, foundational contributions of women are pushed into the background. I wanted to bring those invisible threads to the forefront.

My inspiration is broken down into four interactive acts within the art piece:

Act I: The Fragmented Chaos
When you load the canvas, you are greeted with a simple, cinematic question: "Technology changed the world. But who wrote the code?" Upon entering, the canvas is filled with floating, chaotic programming symbols ({, <, /, 0, 1). This represents the raw, historically fragmented state of our industry. Code without human alignment is just chaos.

Act II: The Catalyst (The Click)
Equity does not happen naturally in a state of rest. It requires an active catalyst—a conscious effort. When the user clicks the screen, a glassmorphic shockwave ripples across the void. The chaotic code melts into smooth nodes that mathematically align to form the "=" (Equals) symbol.

Act III: The Constellation of Collaboration
True equity is built on collaboration. Among the purple nodes of the equals sign, there are bright yellow ones. These represent the hidden history of tech. As the user hovers over them, a gamified Gender Equity Index tracks their discovery, revealing the brilliant women and men who built our modern world together—from Margaret Hamilton's Apollo 11 software to Ada Lovelace's first algorithms.
As each story is uncovered, a generative pentatonic chime echoes (via the Web Audio API), and laser-like SVG lines connect the nodes, proving that innovation is a literal constellation of shared human effort.

Act IV: The Climax
When the user discovers all 8 historical collaborations, the system reaches 100% on the Equity Index. The entire equals symbol synchronizes, glowing with an intense cyan light, displaying the final message: "Equity emerges through true collaboration."

My Code

This art piece was built with a Senior-level approach to architecture, performance, and physics.

Sherman95 / wecoded-frontend-art

🌌 The Equity Pulse

A gamified, interactive tech-art experience built for the 2026 WeCoded Challenge (Frontend Art: Gender Equity).

🎨 The Concept

The Equity Pulse represents gender equity not as a static painting, but as an interactive, dynamic system that requires human action to find alignment.

It starts with a cinematic question: "Technology changed the world. But who wrote the code?" Initially, the canvas is filled with chaotic programming symbols ({, <, /, 0, 1), representing the raw, fragmented state of the tech industry. When the user interacts with the system, the chaos melts into glowing nodes that align to form the "=" (equals) symbol.

This piece goes beyond visual art—it's a gamified discovery experience honoring the historical collaborations between men and women that shaped modern technology.

✨ Key Features

Cinematic & Narrative Progression: An evolving story unfolds as you discover nodes, guided…

View on GitHub

The Tech & Engineering Behind the Art:

Core Engine: React 19 and Vite.
Physics & Kinematics: Powered by Framer Motion. I utilized complex spring physics to calculate the trajectory of the 60 particles. The drag and dragSnapToOrigin constraints allow users to physically grab the nodes and stretch them like rubber bands, adding a highly tactile feel to the art.
Generative Audio & Haptics: No external .mp3 files were used. The musical chimes are synthesized in real-time using the native window.AudioContext oscillator. Mobile users experience tactile immersion via navigator.vibrate.
Extreme Optimization: 60 nodes constantly reacting to mouse parallax can destroy browser performance. I engineered the canvas for a buttery-smooth 60fps by wrapping the particles in React.memo, throttling the mouse event listeners with requestAnimationFrame, and utilizing will-change: transform to force GPU hardware acceleration.
Aesthetics: Tailwind CSS v4 handles the deep space background, glowing box-shadows, and the frosted Glassmorphism cards that display the historical text.

Built with passion and late-night coffee by Ronald Azuero.
IT Student (7th Semester) at Universidad Técnica de Machala (UTMACH).
From Piñas, Ecuador 🇪🇨 to the world.

AI Founder OS — Turn Notion into a Multi-Agent Startup Command Center

Ronald Alejandro Azuero Maldonado — Sat, 21 Mar 2026 20:43:13 +0000

This is a submission for the Notion MCP Challenge

What I Built

Every founder has the same dirty little secret: a Notion database called "Startup Ideas" where dreams go to die.

We get an idea. We write it down. But then comes the grueling part: opening 50 browser tabs to research competitors, mapping out feature matrices, digging through SaaS pricing pages, and trying to validate if the idea even makes sense. The paralysis of analysis hits hard. Instead of building, we drown in research.

I built AI Founder OS out of pure frustration. I wanted a system where I could drop a raw, messy idea into my Notion workspace, change a status property to Run, and have an entire team of AI agents do the heavy lifting for me.

Competitive intelligence — grounded on real web search evidence.
Product roadmap — a prioritized feature plan with complexity ratings.
Marketing strategy — channel-specific campaigns and content ideas.
Viability scorecard — a 0–100 mathematical score with risk flags and an executive summary.

Everything writes back autonomously to structured Notion databases. No more "idea graveyards." It's a living, queryable startup command center.

(Plus, it's polyglot: Write your idea in Spanish, French, or Japanese. The system auto-detects the script and returns all AI-generated research in that exact language).

Video Demo

(Agrega aquí el enlace a tu video de demostración en YouTube, Loom, o sube tu video directamente a DEV.to)

Show us the code

Sherman95 / ai-founder-os

AI Founder OS - Notion Run Center Backend (v0.4.0 Agentic Run Audit)

AI Founder OS is a production-ready basic backend that uses Notion as UI + database + memory The system polls a Notion database for startup ideas with Status Run or Queued, executes a multi-agent workflow, and writes outputs into Notion databases:

Competitor Research
Product Roadmap
Marketing Strategy

Competitor research is grounded on real web search evidence (when enabled) and then structured by Gemini The workflow now supports an auditable Run Center model in Notion with optional entities:

Runs
Evidence
Claims
Feature Matrix
Competitor Scorecards

It also writes a startup viability score and executive summary back to the idea.

This release includes MCP support in two directions:

Provider mode switch for Notion access: NOTION_MODE=api|mcp
Founder OS MCP server exposing high-level tools (founder.*)
Human-in-the-loop corrections loop for output rows flagged in Notion
Run operations: Retry, Replay and…

View on GitHub

System Architecture & Flow

To make this work seamlessly without building a custom frontend, I used Notion as both my Database layer and my UI layer.

The System Flow:

Trigger: The system polls the Startup Ideas database for ideas entering the Run state.
Analysis: The Idea Analyzer Agent extracts core concepts and detects the language.
Research: The Market Research Agent executes live web searches (via Tavily) to find competitors and actual market evidence.
Planning: The Product Planner Agent generates an actionable MVP roadmap.
Growth: The Marketing Agent generates GTM campaigns.
Persistence: The notionWrites module idempotently upserts the formatted results into their respective Notion databases.

How I Used Notion MCP

When I started building this, the problem was getting the AI to interact with Notion securely and predictably. AI Founder OS integrates Notion MCP in two directions, turning a simple workspace into a full-stack operating system:

1. As an MCP Consumer

Instead of wrestling with static API keys, the backend consumes the Notion MCP hosted endpoint (NOTION_MODE=mcp) for OAuth-based access. It securely reads the "Startup Ideas" database, discovers properties dynamically, and injects the context directly into the AI pipeline.

2. As an MCP Provider

The Node.js backend exposes its own MCP server (supporting HTTP and stdio transports for VS Code/Claude Desktop clients). This exposes 10 high-level JSON-RPC tools to any MCP environment.

Key tools include:

founder.inspect_schemas: Validates that your Notion databases have the required properties before execution.
founder.run_idea: Executes the 4-agent multi-step pipeline.
founder.claim_idea: Uses Notion properties as a distributed lock to prevent duplicate agent runs.

The Magic: Human-in-the-Loop Corrections

AI hallucinations happen. But because Notion is the UI, fixing them is seamless.
If an agent hallucinates a competitor's feature:

I review the row directly in Notion.
I check the Needs Review checkbox and type my feedback in the Correction Notes property (e.g., "Actually, this competitor only offers this on the Enterprise plan").
I trigger the founder.apply_corrections MCP tool.
The system re-analyzes only that specific row and safely updates Notion.

The "WOW Mode": Absolute Traceability

Any AI can generate text. But an enterprise-grade Command Center needs traceability. By enabling NOTION_UI_WOW_MODE=true, the system creates a forensic audit trail across 5 extra Notion databases:

Runs: Execution logs, durations, and error tracking.
Evidence: Raw web search results (URLs, domains, and AI confidence scores) proving why the AI made a claim.
Claims: Competitor marketing claims cross-referenced with the evidence to output verdicts (supported, unknown, contradicts).
Scorecards: Mathematical viability scoring (0-100) penalizing hidden pricing or lack of traction.

Conclusion

By leveraging Notion MCP, I didn't just build an AI wrapper. I built a resilient, multi-agent operating system that lives entirely where founders already work: inside Notion.

From Burned Sensors to Sunset Algorithms: My Full-Stack IoT Journey with Google Gemini

Ronald Alejandro Azuero Maldonado — Sun, 01 Mar 2026 20:52:39 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

TL;DR: I built (1) an ESP32 + Home Assistant IoT BMI kiosk and (2) a sunset prediction + analytics dashboard for an archaeological viewpoint in Ecuador. Google Gemini helped me across hardware wiring, ESPHome/Home Assistant configuration, and backend architecture.

What I Built with Google Gemini

As an Information Technology university student from Piñas, Ecuador, my true passion lies far beyond writing software on a screen: I am absolutely fascinated by physical hardware. I love getting my hands dirty with jumper wires, microcontrollers, and bringing the physical and digital worlds together.

Throughout my university journey, I haven't just used Google Gemini as an autocomplete tool; I've used it as my Senior DevOps Engineer, Electronics Engineer, and Full-Stack Architect. To demonstrate this, I’m showcasing two of my most complex engineering projects—one rooted in raw hardware, the other in software algorithms—and how I plan to merge them.

Project 1: The Hardware Hub — IoT BMI Diagnostic Station

I built a smart, low-cost, and open-source automated health kiosk that measures weight and height, calculates Body Mass Index (BMI), and logs a historical record for multiple users.

The architecture is highly integrated:

The Hardware Brain: I used an ESP32 development board. Using ESPHome, I configured it to serve a dual purpose. First, it acts as a Bluetooth Low Energy (BLE) proxy to actively scan and intercept weight data from a Xiaomi Mi Smart Scale 2. Second, it reads distance from a JSN-SR04M ultrasonic sensor mounted on the ceiling.
The Logic Engine: The ESP32 streams raw data locally to a Home Assistant OS server. I built custom Jinja2 template sensors to subtract the measured ultrasonic distance from the calibrated ceiling height to get the user's exact height. It then calculates the BMI and classifies the semantic result.
Cloud Storage & UI: The UI is a locked-down Kiosk tablet running a custom Home Assistant dashboard. Every measurement triggers an automated script that uses OAuth credentials to securely push a JSON payload directly into a Google Sheets database.

Project 2: The Software Brain — Yacuviña Sunset Predictor & Analytics

Beyond health tech, I built Algorithm Yacuviña 3.0, a specialized meteorological prediction system and analytics dashboard for a local archaeological viewpoint. It predicts whether visitors will experience a spectacular "Sea of Clouds" or a "Clear Panoramic" sunset.

The Core Algorithm: The backend concurrently fetches data from Open-Meteo, OpenWeather, and AccuWeather. It uses the SunCalc library to pinpoint the exact local sunset time.
The Dual-Scoring Model: It evaluates two distinct scenarios: the Sea of Clouds model (weighting low cloud density and visibility) and the Clear Sunset model (prioritizing total cloud cover and UV index).
The Frontend & Analytics: The client is a React/Vite app with a glassmorphism UI. The backend exposes JWT-protected analytics endpoints to track geo-distribution and unique API hits.

What Role Did Google Gemini Play?

For the BMI Station, Gemini 2.5 Pro was my virtual electrical engineer. In fact, I explicitly cited Gemini as my official "AI Assistant" in the project presentation document and technical paper submitted to my university. It mapped out my physical hardware, explained ESP32 GPIO pinouts, and generated the text prompts I used to render Fritzing-style schematic diagrams.

For Yacuviña, Gemini helped architect my Node.js backend. It guided my JWT rotation logic, helped me design a caching strategy to avoid rate-limiting the weather APIs, and even helped me optimize the frontend CSS.

Transparency / Credits: All system design, scoring logic, backend implementation, dashboards, and integrations were built by me. Weather inputs come from Open-Meteo, OpenWeather, and AccuWeather, and sunset timing is calculated using SunCalc.

Demo

Live Demo: Check out my deployed Yacuviña Sunset Predictor & Analytics Dashboard

Yacuviña Screenshot (add yours here)

IoT BMI Diagnostic Station (screenshots from documentation)

(Note: Since my physical BMI setup is currently disassembled, here are real screenshots and diagrams from my project documentation.)

The BMI Station in Action:

(Here is the physical IoT BMI kiosk scanning and calculating in real-time.)

What I Learned

This journey was a masterclass in the collision between perfect software logic and chaotic physical realities.

Technical Deep Dives

Connecting the ESP32 to the Xiaomi scale wasn't plug-and-play. I had to learn how to turn the ESP32 into a BLE "radar" (a Bluetooth scanner) to sniff out the exact MAC address of the scale amidst the wireless noise.

For Yacuviña, I learned how to handle asynchronous data streams in Node.js using Promise.allSettled, ensuring my dashboard didn't crash if one of the weather APIs timed out.

Unexpected Lessons (The Magic Smoke)

Software forgives; hardware absolutely does not.

Gemini correctly taught me that the JSN-SR04M ultrasonic sensor outputs a 5V signal, which would instantly fry the ESP32's 3.3V GPIO pin. It taught me how to build a voltage divider circuit using two 1kΩ resistors to safely step down the voltage.

However, I was using old, cheap jumper wires that were internally broken. Frustrated by the lack of sensor readings in Home Assistant, I started blindly unplugging and plugging the wires directly into the breadboard. In my haste, I mixed up the positive and negative wires. Kaboom. A puff of magic smoke, and the 5V sensor was dead.

It taught me that while AI can provide perfect pinouts, it cannot fix your faulty cables or save you from a reversed polarity mistake. Measure twice, plug once.

Google Gemini Feedback

Having Gemini 2.5 Pro (and now 3.1 Pro) by my side has been like having a Senior IoT and DevOps Engineer on call 24/7.

What Worked Flawlessly

Gemini is an absolute beast when it comes to infrastructure syntax. Writing the script to authenticate Home Assistant with the Google Cloud OAuth API requires incredibly specific JSON/YAML structures—Gemini generated the exact formatting on the first try.

In the Yacuviña project, it also helped me generate the logic to dynamically switch between the Sea of Clouds and Clear Sky algorithms based on cloud strata percentages.

Where I Ran Into Friction

LLMs often assume errors lie entirely within the code logic, completely missing the physical constraints of the real world.

Before my ultrasonic sensor exploded, my ESP32 was returning null distance values. Gemini kept suggesting software fixes like: "Increase the update_interval," "modify the median filters," "check the firmware buffer size." It took me a fried sensor to realize the code was perfect—my broken jumper wires were the culprit.

I had to learn a completely new way of prompting:

"Assuming the YAML code is 100% correct, what physical hardware, breadboard wiring, or voltage issues could cause this specific sensor reading to fail?"

Once I established strict physical boundaries in my prompts, Gemini transformed from a generic code generator into an outstanding hardware debugger.

Beyond These Projects: My Long-Term AI Co-Pilot

While these two projects are my proudest achievements, the truth is that Gemini has been my co-pilot throughout my entire university degree. Our history together goes way beyond Home Assistant and React.

Gemini was there when I had to configure a 4-node Big Data cluster using Apache Spark, Hadoop, and Jupyter. It helped me survive setting up an Oracle 19c database on Linux, configuring firewalld rules, proxies, and webmail servers. When I went down the rabbit hole of distro-hopping between Linux Mint, CachyOS, and Ubuntu, Gemini helped me rescue my Windows bootloader.

We’ve built point-of-sale systems ("pos-carmita-villegas"), tackled a road alert app for Ecuador deployed on Vercel ("Vialert EC"), and even developed "DevFlow," a custom CLI wrapper for GitHub Copilot CLI. From troubleshooting IPv6 dual-stack RIPng networks in Cisco Packet Tracer to diagnosing the sickest hardware bugs, Gemini hasn't just been an API I call for code snippets—it has been the mentor that taught me how to become a full-stack, DevOps, and IoT engineer.

Looking Forward: Bridging the Gap

My ultimate goal is to merge my hardware passion with my software algorithms. If I win the Raspberry Pi AI Kit in this challenge, my plan is to build a physical edge-computing weather station and deploy it directly at the Yacuviña archaeological viewpoint.

Instead of pulling generic data from web APIs, I will wire real humidity, barometric, and temperature sensors to the Raspberry Pi. I will run Algorithm 3.0 locally on the Pi, utilizing its edge AI capabilities to process hyper-local data in real-time.

If you try the predictor, I’d love your feedback—especially ideas on what sensors or edge features would make the next version even better.

Hardware is hard, and software is complex. But with a soldering iron in one hand, a keyboard in the other, and Google Gemini guiding the architecture, there is no limit to what we can build.

UTMACH Rides -- I Built a Carpooling App So My Classmates Stop Paying $3 for a 10-Minute Ride

Ronald Alejandro Azuero Maldonado — Sat, 28 Feb 2026 19:57:48 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I'm an 8th-semester Information Technology student at the Facultad de Ingenieria Civil, Universidad Tecnica de Machala (UTMACH) in El Oro province, Ecuador. I live in Pinas -- a small town up in the highlands, about 1.5 hours from campus by road. Every single day I make that commute, and so do 14,000+ students spread across 5 campuses and 14 different cantons -- Pasaje, Santa Rosa, Zaruma, El Guabo, Huaquillas, and more.

Here's the problem: there is no public transit system connecting most of these towns to the campuses. Students either:

Pay $2-3 each way for informal taxi/bus rides (on a student budget, that's $20-30/week gone)
Stand on the highway hoping to catch a shared pickup truck
Skip class entirely when they can't afford the ride

But cost isn't even the scariest part. Security is a real, daily concern. Ecuador has been going through one of the worst spikes in violent crime in its history. As CS/IT students, we carry our laptops every single day. Taking public transport or flagging random rides on the highway means you're a visible target -- alone, with expensive gear, on a predictable route. Students at UTMACH have been robbed. This isn't hypothetical. It's why some of us travel in groups or avoid certain bus routes altogether.

That's why riding with people you can verify are from your own university matters so much. It's not just convenience -- it's a layer of safety. And that's the core reason UTMACH Rides only allows @utmachala.edu.ec emails: if you're in the app, you're a verified UTMACH student. You know the person you're riding with is your classmate, not a stranger.

Carpooling already happens organically -- students coordinate via chaotic WhatsApp groups where messages get buried in minutes. There's no structure, no way to search by route or time, and no way to verify that the person offering a ride is actually a UTMACH student.

I built UTMACH Rides to fix all of that.

What I Built

UTMACH Rides is a mobile-first PWA (Progressive Web App) that lets verified UTMACH students publish, find, request, and review shared rides between the 14 cantons of El Oro and the 5 university campuses.

Key flows

Sign up with your @utmachala.edu.ec email -- this is the only way in. No institutional email, no access. Every user is a real, verified UTMACH student.
2-step onboarding -- After email verification, a guided form collects: full name, Ecuadorian cedula (validated with the official modulo-10 algorithm), faculty (5 UTMACH faculties), career (40+ programs), and WhatsApp number. Duplicate cedula detection prevents multi-accounting.
Publish a ride -- Pick a direction (going to campus or heading home), select your campus, your canton, departure time, available seats, and a price contribution ($0-$50). The bidirectional flow automatically handles origin/destination based on your selection.
Find a ride -- The feed shows all active rides with future departure times, filterable by:
- Direction: Ir a la U (going to campus) / Volver (heading home)
- Specific campus (Matriz, 10 de Agosto, El Cambio, Arenillas, Pinas)
- Canton of origin/destination

Each trip card shows driver name, rating, total completed trips (InDrive-style), vehicle info, price, and available seats.

"Me apunto" trip request system -- Passengers tap "Me apunto" (I'm in) to request a seat. The driver sees all requests with passenger info (name, career, rating) and has 3 actions for each pending request:
- WhatsApp -- verify with a pre-filled message: "Puedes confirmar que si vas?" (before accepting)
- Accept -- confirms the seat, decrements availability
- Reject -- declines the request

After accepting, the driver gets a different WhatsApp link for coordination: "Acepte tu solicitud, coordinamos punto de encuentro?". Drivers can also revoke an accepted passenger if plans change (seat is re-incremented). A red badge on the trip card shows how many pending requests are waiting.

Passenger self-service -- Passengers can cancel their own request at any time. If they were already accepted, canceling returns the seat to the pool. No more being stuck waiting.
Mutual rating system -- After a trip is completed, both driver and passenger can rate each other with 1-5 stars (Malo / Regular / Bien / Muy bien / Excelente) plus an optional comment. Ratings are bidirectional: the driver rates each accepted passenger, and each passenger rates the driver. A database trigger auto-computes average ratings. Duplicate rating detection prevents abuse.
Auto-cleanup on completion -- When the driver marks a trip as completed or cancelled, all remaining pending requests are automatically rejected. No ghost requests lingering.
Manage your vehicles -- Add, edit, delete vehicles with brand, model, color, and plate. Can't delete a vehicle that has active trips.
Edit or cancel trips -- Inline editing with validation. Mark trips as completed when you arrive.

What makes it different from generic carpooling apps

Feature	Why it matters
Institutional email gate	`@utmachala.edu.ec` only -- safety through verified identity
Cedula verification	Ecuadorian ID validated with modulo-10 algorithm, duplicate detection
Academic profile	Faculty + career displayed on requests -- you know who's riding with you
Real geography	14 actual cantons of El Oro + 5 real UTMACH campuses with addresses
"Me apunto" request flow	Verify via WhatsApp first, then accept -- no blind seat assignments
Mutual ratings	Both driver and passenger rate each other, InDrive-style trust building
WhatsApp-native	Pre-filled messages for both verification and coordination phases
Bidirectional routing	"To campus" vs "heading home" automatically swaps origin/destination
USD amounts	Ecuador uses US dollars; students share $0.50-$2.00 for gas
Security by design	Server-side middleware, CSP headers, input validation, cookie-based auth

Demo

Video Walkthrough

Full demo: signup -> onboarding (cedula + faculty) -> dashboard -> filter rides -> "Me apunto" -> driver accepts via WhatsApp -> rate after trip -> profile stats.

User Flow

@utmachala.edu.ec signup
        |
        v
  Email verification
        |
        v
  2-step onboarding
  [Name + Cedula] -> [Faculty + Career + WhatsApp]
        |
        v
   +----+----+
   |         |
   v         v
 DRIVER    PASSENGER
   |         |
   v         v
Publish    Browse feed
 ride      (filter by direction/campus/canton)
   |         |
   v         v
Receive    Tap "Me apunto"
requests       |
   |           v
   +-----<-----+
   |
   v
3 actions per request:
  [WhatsApp: verify] [Accept] [Reject]
        |
        v
   Accepted? -> WhatsApp: coordinate pickup
        |
        v
   Trip happens
        |
        v
   Driver marks "Completado"
   (pending requests auto-rejected)
        |
        v
   Mutual rating
   Driver <-> Passenger (1-5 stars + comment)
        |
        v
   Stats updated (avg rating, total trips)

Live App

https://utmach-rides.vercel.app

Demo credentials (pre-seeded account for judges):
| | |
|---|---|
| Email | demo@utmachala.edu.ec |
| Password | DemoRides2026! |

The demo account has a complete profile (cedula, career, faculty), a vehicle, and sample trips pre-loaded. You can publish trips, request seats on other trips, rate passengers, manage vehicles, and test the full flow.

Screenshots

Landing page -- institutional email gate with glass morphism UI:

Dashboard -- trip feed with direction and campus filters:

New trip -- bidirectional campus/canton selector with smart validation:

Trip card -- driver info, rating, trip count, vehicle, price, seats, and "Me apunto" button:

Profile -- 3-column stats (trips/rating/published), academic info, vehicle editor, trip history:

Onboarding -- 2-step form: cedula + name, then faculty/career + WhatsApp:

Code

Sherman95 / UTMACH-RIDES

UTMACH Rides

University carpooling platform for 14,000+ students at Universidad Tecnica de Machala (UTMACH) in El Oro, Ecuador.

Students share rides between 14 cantons of El Oro province and 5 UTMACH campuses, with identity verification, trip requests, WhatsApp coordination, and mutual ratings. Only @utmachala.edu.ec emails allowed.

Live: utmach-rides.vercel.app

Tech Stack

Layer	Technology	Version
Framework	Next.js (App Router, Turbopack)	16.1.6
UI Library	React	19.2.3
Language	TypeScript (strict mode)	5.x
Styling	Tailwind CSS v4 + PostCSS	4.x
Auth & Database	Supabase (Auth + PostgreSQL + RLS)	2.98.0
SSR Auth	@supabase/ssr (cookie-based sessions)	0.8.0
Icons	lucide-react	0.575.0
Animations	canvas-confetti (dynamic import)	1.9.4
Deployment	Vercel (auto-deploy on push)

Features

Identity & Onboarding

Institutional email gate -- only @utmachala.edu.ec can register
2-step onboarding -- Step 1: full name + cedula (Ecuadorian ID validated with modulo-10 algorithm, duplicate detection). Step 2: faculty (5 UTMACH faculties) + career (40+ programs) + WhatsApp number
Middleware-enforced completeness --…

View on GitHub

Project structure

app/
  (main)/                  # Protected routes (middleware-guarded)
    dashboard/             # Trip feed + stats + filters
    profile/               # User info + vehicles + trip history + passenger trips
    rides/new/             # Publish a ride form
  auth/callback/           # Email verification handler
  onboarding/              # 2-step profile setup (cedula, faculty, career)
components/
  trips/
    TripFeed.tsx           # Main feed with direction/campus/canton filters
    TripCard.tsx           # Individual card with driver stats + "Me apunto"
    TripRequestButton.tsx  # Passenger: request/cancel seat
    TripRequests.tsx       # Driver: manage requests (verify/accept/reject/revoke)
    RateButton.tsx         # 5-star inline rating with optional comment
    CompletedPassengers.tsx # Driver rates passengers after trip
    MyPassengerTrips.tsx   # Passenger trip history with status badges
    MyTrips.tsx            # Driver's published trips with edit/complete/cancel
  vehicles/
    VehicleManager.tsx     # Inline CRUD for vehicles
lib/
  auth-context.tsx         # AuthProvider + useAuth() hook
  supabase.ts              # Typed browser client (cookie-based)
  supabase-middleware.ts   # Server client for middleware
  constants.ts             # Cantons, campuses, faculties, careers, validators
middleware.ts              # Server-side route protection + profile completeness
types/database.ts          # Full Database generic for Supabase (6 tables)

How I Built It

Stack

Layer	Tech
Framework	Next.js 16.1.6 (App Router + Turbopack)
UI	React 19 + Tailwind CSS v4 + lucide-react icons
Auth & DB	Supabase (Auth + PostgreSQL + Row Level Security)
SSR Auth	@supabase/ssr -- cookie-based sessions shared between browser and middleware
PWA	Web manifest + dynamic icon generation via OG `ImageResponse`
Effects	canvas-confetti (dynamically imported on trip creation)
Deployment	Vercel (auto-deploy on push)

Architecture decisions

Cookie-based auth, not localStorage. The browser client uses createBrowserClient from @supabase/ssr so auth tokens live in cookies. The server middleware uses createServerClient reading those same cookies. This means the middleware validates sessions server-side with getUser() (which hits Supabase's auth server) instead of the deprecated getSession() (which only reads the cached JWT and can be spoofed).

Server-side route protection via middleware. Protected routes (/dashboard, /profile, /rides) redirect to / if no valid session exists. The landing page redirects authenticated users to /dashboard or /onboarding depending on profile completeness (name + cedula + career + faculty + WhatsApp). All validated server-side before a single React component renders.

AuthProvider + useAuth() hook. A React context wraps the entire app. It calls getUser() on mount, listens to onAuthStateChange for login/logout/token refresh events, and exposes user, profile, loading, and refreshProfile(). Every component consumes auth state from this single source -- no more scattered getSession() calls duplicated across files.

Typed Supabase client. The Database generic type maps every table's Row, Insert, and Update shapes across 6 tables (users, vehicles, trips, bookings, trip_requests, ratings). This gives full autocomplete and compile-time type-checking on every .from('trips').update({...}) call. Had to use type aliases instead of interface because TypeScript interfaces don't produce implicit index signatures, which breaks Supabase's internal extends Record<string, unknown> constraint resolution.

Ecuadorian cedula validation. The onboarding form validates cedula numbers using Ecuador's official modulo-10 algorithm -- checking province code (01-24), computing the verification digit with alternating multipliers (2,1,2,1...), and rejecting invalid numbers client-side. Combined with server-side duplicate detection.

Trip request lifecycle. The "Me apunto" system implements a full state machine: none -> pending -> accepted/rejected, with the driver controlling transitions. Seat counts are managed atomically on accept (decrement) and revoke/cancel (re-increment). Drivers verify passengers via WhatsApp before accepting. Auto-rejection of pending requests on trip completion prevents orphaned state.

Bidirectional rating with DB triggers. Both driver and passenger rate each other after trip completion. A PostgreSQL trigger (update_user_rating) auto-computes average_rating and total_ratings on the users table whenever a new rating is inserted. A separate trigger (update_user_trips) increments total_trips when a trip is marked as completed.

Security headers on every response. next.config.ts injects Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy (disabling camera, microphone, geolocation access).

Input validation everywhere. Cedula validated with modulo-10. WhatsApp numbers validated with /^(09\d{8}|\+?593\d{9})$/ (Ecuadorian mobile format). Names validated as 2+ words, letters only, 3-100 chars. Prices capped at $50. Origin != destination enforced. Departure must be in the future. Rating comments capped at 200 chars.

Error boundaries on every route. Each route segment under (main)/ has its own error.tsx (with a retry button and console error logging) and loading.tsx (shimmer skeletons that match the actual page layout). Component-level data fetches are all wrapped in try/catch with fetchError state and retry UI.

Lazy loading for non-critical components. Vehicle manager, trip history, and passenger trips on the profile page are loaded via next/dynamic so the initial JS bundle stays lean. Trip cards use React.memo to avoid re-renders. Confetti is dynamically imported only on successful trip creation.

Database schema (Supabase PostgreSQL)

users               vehicles         trips                trip_requests       ratings
├── id (uuid)       ├── id (uuid)    ├── id (uuid)        ├── id (uuid)       ├── id (uuid)
├── email           ├── driver_id ->  ├── driver_id ->      ├── trip_id ->       ├── trip_id ->
├── full_name       ├── brand        ├── vehicle_id ->     ├── passenger_id ->  ├── from_user_id ->
├── cedula          ├── model        ├── origin            ├── status           ├── to_user_id ->
├── carrera         ├── color        ├── destination       │   (pending/        ├── score (1-5)
├── facultad        └── plate        ├── departure_time    │    accepted/       ├── comment
├── whatsapp                         ├── seats_available   │    rejected)       └── created_at
├── average_rating                   ├── price_contribution└── created_at
├── total_ratings                    └── status
├── total_trips                          (active/completed/cancelled)
└── created_at

All 6 tables protected with Row Level Security policies. Users can only read/update their own profile, manage their own vehicles, create/edit/cancel their own trips. Passengers can create/read/delete their own trip requests. Drivers can read/update requests for their trips. All users can read active trips (the public feed) and read ratings.

What I'd add next

Push notifications when someone requests your ride
Real-time feed via Supabase Realtime subscriptions (live trip updates without refresh)
Route map -- static SVG of El Oro showing active canton-to-campus routes
Recurring trips -- "Every Mon/Wed at 7am" instead of creating each one manually
Admin dashboard with usage analytics and trip heatmaps
RLS migration files committed to the repo (currently policies live only in Supabase dashboard)

Built with real frustration from standing on the Panamericana highway at 6 AM, laptop in my backpack, hoping someone from Pinas has an empty seat heading to campus. The app is in Spanish because that's what my community speaks, but the codebase and documentation are fully in English.

8th semester, Information Technology -- Facultad de Ingenieria Civil, UTMACH.
El Oro, Ecuador -- 2026.

Silent Triage: The Zero-Chat War Room Protocol (Algolia Agent Studio Challenge)

Ronald Alejandro Azuero Maldonado — Sun, 08 Feb 2026 04:02:26 +0000

"Downtime costs an average of $9,000 per minute. In a 3 AM production crisis, you don't need a conversation. You need a deterministic decision."

💡 The Inspiration: Beyond the Chatbot

Every SRE knows the "Alert Fatigue." When a P0 incident hits, every second counts. Traditional AI assistants are too conversational—they waste time with greetings and "How can I help you today?".

I built Silent Triage to implement the Zero-Chat Protocol: a high-speed, RAG-driven interface that turns raw, messy logs into actionable fixes without the small talk.

🛡️ What is Silent Triage?

Silent Triage is a specialized Incident Response agent that acts as a digital first responder.

✅ Analyzes messy logs: Paste raw stack traces or alerts directly.

✅ Classifies Severity: Automatically detects if an issue is P0 (Critical) or P3 (Minor).

✅ Retrieves Ground Truth: Uses Algolia to search for past incident resolutions.

✅ Prescribes Action: Delivers a structured JSON-based remediation plan.

🎥 Watch the 90-second Demo

See how the agent identifies a Database Connection Timeout and suggests a fix based on historical data.

🧩 Technical Architecture: The "Ground Truth" Engine

The system is built on a high-performance RAG (Retrieval-Augmented Generation) stack using Algolia Agent Studio.

1️⃣ The Memory: Algolia Search Index

I populated an Algolia index named incident_history with structured data from past production failures. This ensures the agent's logic is grounded in reality, not hallucinations.

The Knowledge Base (incident_history.json):

[
  {
    "objectID": "inc-001",
    "title": "Database Connection Timeout - Production",
    "description": "Error: SequelizeConnectionError: connect ETIMEDOUT. The database cluster is not responding to heartbeat checks.",
    "severity": "P0",
    "cause": "Database connection pool exhausted due to unclosed connections.",
    "action": "Restart the primary database node and increase the max_connections limit in RDS.",
    "tags": ["database", "timeout", "critical", "backend"]
  },
  {
    "objectID": "inc-002",
    "title": "Slow Page Loads - Frontend Assets",
    "description": "Users reporting 5+ seconds to load the dashboard. Static assets (JS/CSS) are taking too long to download.",
    "severity": "P2",
    "cause": "CDN cache invalidation failed after the last deploy.",
    "action": "Purge CloudFront cache and verify S3 bucket permissions.",
    "tags": ["frontend", "performance", "cdn"]
  },
  {
    "objectID": "inc-003",
    "title": "Failed User Registration - API 500",
    "description": "POST /api/v1/register returning 500 Internal Server Error. Log: null pointer exception at UserService.java:45.",
    "severity": "P1",
    "cause": "Missing validation for null email addresses in the legacy registration flow.",
    "action": "Rollback to the previous stable build (v1.2.4) and add null-check in the UserService.",
    "tags": ["api", "java", "500-error", "auth"]
  },
  {
    "objectID": "inc-004",
    "title": "Broken Images in Product Catalog",
    "description": "Images not rendering in the mobile app. Getting 403 Forbidden when fetching from the media server.",
    "severity": "P3",
    "cause": "Expired SSL certificate on the media subdomain.",
    "action": "Renew the Let's Encrypt certificate via Certbot.",
    "tags": ["images", "ssl", "minor"]
  }
]

2️⃣ The Brain: Algolia Agent Studio

I used Agent Studio to orchestrate the intelligence layer. By connecting the incident_history index as a Search Tool, the agent "researches" historical data before formulating a response.

Agent Configuration & System Prompt:

Role: Professional SRE & DevOps Incident Triage Expert.
Objective: Analyze the user's error/incident report, SEARCH the 'incident_history' index for context, and provide a structured JSON decision.

Context: You have access to a database of past incidents via the Algolia Search Tool. Use it to find similar patterns.

Instructions:
1. Analyze the user's input.
2. Search the index for similar past issues.
3. Classify severity and recommend actions based on search results.
4. Output ONLY valid JSON. Do not use Markdown formatting.

🛠️ The "Silent" Protocol: Structured Output

To maintain the "Zero-Chat" standard, I engineered a strict JSON schema. This allows the frontend to render the solution in a tactical HUD (Heads-Up Display) immediately.

Response Schema:

{
  "severity": "P0" | "P1" | "P2" | "P3",
  "probable_cause": "Brief technical explanation (max 1 sentence)",
  "recommended_action": "Concrete steps to fix or mitigate",
  "related_incident_ids": ["List of objectIDs found"],
  "confidence_score": Number (0-100),
  "language": "es" | "en"
}

🏗️ Frontend Architecture: React + Custom Hooks

The UI is built with React following a clean architecture pattern:

src/
├── components/     # Reusable UI components
├── hooks/          # Custom React hooks for state management
├── services/       # API integration layer (Algolia Agent Studio)
└── utils/          # Helper functions and parsers

Key technical decisions:

✅ Custom hooks for agent communication

✅ Service layer abstraction for API calls

✅ Component-based architecture for maintainability

✅ Dark theme optimized for high-stress environments

🚀 Why This Wins: Reliability Over Hallucination

Most AI agents "guess" when they encounter an error. Silent Triage is different. By grounding the model with Algolia's Search Tool, the agent retrieves actual historical context.

✅ Tactical HUD: A React-based interface designed for dark "War Room" environments.

✅ Telemetry Extraction: Automatically identifies IPs and endpoints from raw text.

✅ Confidence Score: Transparent scoring based on how well the input matches historical records.

📋 Post-Incident Automation

Beyond triage, Silent Triage automates the post-mortem workflow:

One-Click PDF Report Generation

After analyzing an incident, the system generates a professional PDF Audit Report using jspdf:

✅ Incident Summary: Severity, timestamp, and confidence score

✅ Root Cause Analysis: Grounded in historical data

✅ Recommended Actions: Step-by-step remediation plan

✅ Related Incidents: References to past similar cases

This eliminates the manual copy-paste process that wastes critical minutes during P0 events.

Jira-Ready Format

The analysis can be exported in Jira/Textile syntax, allowing instant ticket creation:

h2. [P0] Database Connection Timeout - Production

*Probable Cause:* Database connection pool exhausted due to unclosed connections.

*Recommended Action:* 
# Restart the primary database node
# Increase max_connections limit in RDS
# Review connection pooling configuration

*Related Incidents:* INC-001
*Confidence:* 92%

This bridges the gap between AI-powered triage and enterprise ticketing systems.

🔗 Project Links

🌐 Live Demo: silent-triage-hackathon.vercel.app

💻 Source Code: GitHub Repository

👤 Developed by Sherman95 for the Algolia Agent Studio Challenge.