Crisla
Pott

A personal project to prove a concept: a solo PM, using AI tools and cloud infrastructure, can ship a working geospatial product in a short iteration cycle — without a dedicated engineering team.

An interactive demand forecasting map for Bogotá that shows where food delivery orders concentrate across the city, in 30-minute time windows, for the next 3 days. Couriers see where demand is heading before it peaks. The same architecture scales to any city with order history.

Data: 30-day order history (lat/lng, timestamp). Spatial indexing: Uber H3 hexagonal grid at resolution 9 (~0.1 km² per cell). Forecast: Statistical demand profile per hex — fully explainable, no black box. Score: Percentile ranking (1–5) per time window, the same approach used by Uber and DoorDash. Exclusion: AK30 highway corridor removed via buffer geometry — a real operational barrier in Bogotá logistics. Stack: Python · pandas · h3 · shapely · Kepler.gl · AWS S3.

This case looks the simplest of them all, but it was the one that took the most work — and almost none of it is visible on screen. The real effort was the geospatial groundwork: hunting down and stitching together several shapefiles for Bogotá and Colombia, clipping and cleaning the geometries, and defining the city's operational zones by hand so the H3 grid sat on top of a real, coherent map. The demo renders in seconds; getting the geography right took days.

ChatGPT and Claude throughout the pipeline: architecture design, geospatial edge case debugging, Python scripts, scoring methodology validation. Claude Code for refactoring. From concept to live demo in a few weeks of part-time work.

Every hangout has the same fight: whoever plugs in their phone owns the music, and one person's taste floods the whole night. A shared playlist never quite feels like everyone's.

A web app where everyone drops the songs they like — by pasting a public Spotify or YouTube playlist, or just searching, with no login — and the app blends them into a single set with two rules: fairness (nobody monopolizes; equal space per person) and flow (an energy arc that starts calm and builds to the peak of the night, like a DJ). It plays right inside the app — cast to a TV through the clips — or exports to Spotify.

Blend: dedupes shared songs into "anchors", gives every person an equal quota, and orders tracks along an exponential energy arc toward the end-of-night anthems. Vibe: reads each track's mood from Last.fm tags (Spotify retired audio-features). No login at scale: resolves songs and clips by reading public Spotify/YouTube pages directly, bypassing the platforms' account and quota limits — so anyone can contribute and play without signing in. Stack: React · Vite · Supabase Edge Functions · Last.fm · Vercel.

Built end-to-end with Claude Code over a weekend — the blend algorithm, caching, the in-app player, PT/EN i18n, PWA, and deploy. I described the problem and made the product calls; the AI wrote the code while I tested and steered. The hardest part wasn't the code — it was deciding what to cut and designing the experience around what the platforms actually allow.

Delivery platforms in LATAM face a growing threat during driver onboarding: synthetic-identity fraud — AI-generated profile photos reused across multiple fraudulent driver registrations under different documents. Manual fraud review is slow, inconsistent, and doesn't scale. No automated system existed to detect fraud rings across applications.

An end-to-end fraud-detection pipeline covering three layers of defense: document OCR cross-validation to catch inconsistencies between submitted documents; AI-generated image detection to flag synthetic profile photos; and facial-embedding deduplication to surface fraud rings — the same face registered under multiple different identities.

Translated a manual process into automatable rules first — mapped every step the ops fraud-review team did manually, identified which decisions followed consistent logic, and converted those into business rules and risk-scoring thresholds before writing a single line of code.

Modular architecture — each detection layer (OCR, image, face) operates independently, so the system can flag a case based on any single signal or a combination, and each module can be iterated without breaking the others.

Risk scoring output, not binary decisions — the system surfaces a risk score and evidence summary for human review, rather than auto-rejecting applications, keeping a human in the loop for edge cases.

Claude Code as the primary development partner: scaffolding the pipeline architecture, iterating on the OCR validation logic, debugging embedding comparisons, and reviewing the risk-scoring model. This is consistent with my AI-first building approach — AI as co-pilot from architecture to implementation.

Every day, thousands of customers opened support tickets claiming their order never arrived. The support team had no way to determine who was telling the truth — the driver claimed delivery, the customer claimed otherwise. With no evidence system, the default was to compensate the customer to avoid risk. This created two problems: significant monthly costs from unwarranted payouts, and no way to identify patterns of fraud or driver misconduct.

Rather than relying on manual case review, I led the development of a microservice that automatically analyzes the full order lifecycle at the moment a customer opens a ticket. The key insight: the evidence already existed in our systems — geolocation, photos, timestamps, chat history. We just needed to connect it and surface it at the right moment, before a human made a decision.

Prioritized 'order not delivered' over other defect types (damaged product, poor quality) because it had the highest user friction and the richest evidence trail.

Built the diagnosis at ticket-creation time — so the support agent received the evidence before making any decision, not as an afterthought.

Designed the output as a clear recommendation (evidence found / not found) rather than raw data — reducing cognitive load on support agents and standardizing decisions across teams.

Launched first in smaller markets (Uruguay, Peru) as a controlled experiment. Initial results were below expectations, so we refined the model before rolling out to larger markets.

End-to-end problem framing & solution scoping · Alignment with engineering and support teams · Prioritization rationale & rollout sequencing · Experiment design & post-launch iteration.

Beyond cost savings, the system created a consistent, data-driven standard for resolving disputed deliveries — reducing variability across support agents and countries. The evidence was always there. The product problem was surfacing it at the right moment.

During mass events — carnival street parties, protests, large concerts, elections — the ops team had to manually identify which stores fell inside the affected area and close them individually at the right time. This was slow, error-prone, and entirely dependent on someone scanning a map and remembering to act at the exact moment the event started.

A tool that automates the entire process: input a location, define an affected area, and the system identifies and schedules closures automatically. Two modes to match real-world event shapes: radius mode for point-based events (concerts, stadiums) and line mode for linear events (parade routes, marches), each expandable by a custom distance.

Scheduled closures at the exact event time — removing the ops team from having to be present at a specific hour and manually trigger anything.

Built line mode as a second iteration — after seeing that many real-world events (parades, marches) don't fit a simple radius, expanding applicability without adding complexity.

Scaled across all 9 countries once validated — disruptive events (protests, holidays, elections) are a universal operational challenge, not market-specific.

Customers didn't place orders that couldn't be fulfilled. Couriers weren't sent into unsafe areas. Stores weren't overwhelmed trying to serve demand they couldn't meet. The team no longer needed to manually monitor or intervene at the exact moment an event began.