Forem: Jorge Eduardo Vazquez Trujillo

From Product Backlog to Production: My Journey through the DataArt Agentic Development Hackathon

Jorge Eduardo Vazquez Trujillo — Tue, 21 Apr 2026 16:55:53 +0000

The "Product Manager" in the Machine

As a Product Manager, my day-to-day usually involves roadmap alignment, user interviews, and prioritization. However, in my "off-hours," I’ve become obsessed with the potential of Agentic Development. I’ve spent months building small functional solutions for my own workflow and helping colleagues automate their business processes.

When the DataArt Agentic Development Hackathon was announced, I saw it as the ultimate test. Could I take my hobbyist experimentation and apply it to a high-stakes, time-sensitive competitive environment?

The answer lay not in how well I could code, but in how well I could orchestrate.

The Vision: A Modern "El Chat"

The prompt for the hackathon was clear: Create a functional chat server. Immediately, my mind went back to the early days of the internet—specifically to a site called elchat.com. For many of us in Latin America, it was a "rusty" but beloved digital plaza where you could connect with anyone, anywhere.

My goal wasn't just to build a server; it was to build a modern, agent-driven version of that nostalgic experience. But as a PM, I didn't reach for a compiler first. I reached for my User Stories.

Phase 1: Hiring my "Senior Business Analyst" (Gemini)

To succeed in a 48-hour sprint—especially while living in Central Time and balancing a different schedule than my international peers—I needed a solid foundation.

I started by crafting a highly specific Profile Prompt for Gemini. I didn't just ask it for ideas; I commanded it to act as a Senior Business Analyst. We entered an intensive back-and-forth dialogue:

Refining the core features.
Identifying potential edge cases.
Breaking down the roadmap into a lean, 2-day "hackathon" sprint.

By the end of the session, I had a professional-grade Product Backlog. I knew exactly what the agents needed to build before a single line of code was generated.

Phase 2: Spec Driven Development (SDD)

Once I opened VSCode, I committed to a Spec Driven Development approach.

For a Product-oriented person, SDD is a game changer. It shifts the focus from the "boring" mechanics of writing syntax to the high-level strategy of defining requirements. It felt like I was managing a development team that never slept. I provided the specs; the AI provided the delivery. This allowed me to stay focused on prioritization—ensuring that the most critical features were built first.

Phase 3: Building the "Agentic Squad"

One of the most exciting parts of this hackathon was the requirement for Dockerization. Every solution had to be packaged in a Docker container with zero external dependencies. This meant the architecture had to be tight, portable, and self-contained.

To manage this, I didn't just use one AI. I built a squad:

The Developer Agent: Handled the core logic and feature implementation.
The Backend Tester: A specialized agent focused on API reliability and server-side stability.
The Frontend Tester: Ensuring the UI was responsive and user-friendly.

The "Frustrating" Reality of Agentic Work

I’ll be honest: there were moments of deep frustration. Even though I’m not a professional developer, I had a burning urge to get in there and manually "touch the code."

However, the "Agentic" philosophy requires a different kind of discipline. I realized that my value wasn't in fixing a typo in a CSS file; my value was in refining the prompt, adjusting the spec, and ensuring the testers were catching the right bugs.

The Takeaway: The Human in the Loop

At the end of the hackathon, I walked away with a functional, containerized chat server and a profound realization.

Even when AI takes over 90% of the development work, the 10% that remains—the decision-making, the strategy, and the vision—is more critical than ever. An AI can write a function, but it cannot decide why that function matters to the user. All the decisions behind the code must come from a human with the experience to know what "good" looks like.

Final Credits
A huge thank you to DataArt for the opportunity to push the boundaries of what "development" means in 2024. To my fellow participants: thumbs up for the incredible work and the shared late nights.

🔗 Explore the Project

Curious about how it turned out? You can find the full repository, including the Docker setup and the agent-generated logic, right here:

https://github.com/jorgevaztdev/ChatServer

Building Rutiq: Orchestrating the Last Mile with FastAPI, Supabase, Telegram, and Applied AI

Jorge Eduardo Vazquez Trujillo — Sat, 18 Apr 2026 03:49:36 +0000

Last-mile logistics is often a silent chaos. If you look closely at the operations of many retail or shipping companies, you'll see a reality built on "trench tech": copy-pasted Excel sheets, WhatsApp groups saturated with voice notes, delivery photos lost in chat histories, and zero real-time traceability.

The "before" of a standard operation involves low visibility, constant friction between dispatchers and couriers, and a very high margin of error. To solve this, Rutiq was born—a last-mile operations platform designed to connect operators (shippers and admins), stores, and couriers in real-time.

More than just a dashboard, Rutiq was built as an exercise in applied AI engineering for real-world logistical operations. The thesis here isn't to "just add a chatbot," but to use automation and Large Language Models (LLMs) strictly where they reduce friction, minimize errors, and shorten response times within an auditable workflow.

Below, we break down the architecture, product decisions, and technical challenges behind this production-ready MVP.

🏗️ High-Level Stack and Architecture

To build a fast, secure, and easy-to-iterate platform, we opted for a modern stack that clearly separates responsibilities:

Frontend (Admin & Shipper Portals): Built with Next.js (TypeScript) and deployed on Vercel with continuous integration from GitHub. This gives us a typed, fast, and easily distributed frontend.
Backend: Developed in FastAPI, leveraging its speed and native support for asynchronous programming. Persistence is handled via SQLAlchemy async.
Database & Auth: PostgreSQL hosted on Supabase (using its connection pooler and SSL). We leverage Supabase Auth for issuing JWTs and Supabase Storage for delivery evidence (photos), protected by tenant-based RLS (Row Level Security) policies.
Courier Interface: An operational bot on Telegram connected via webhooks.
On-Premise Deployment (Optional): The backend is containerized to run on Docker Compose, using Cloudflare Tunnels to expose webhooks securely without dealing with complex network configurations on proprietary servers.

🧠 Product Decisions: Pragmatism Over Hype

When designing Rutiq, we made deliberate decisions to adapt to the users' reality, not the other way around.

1. Why Telegram Instead of a Mobile App?

Developing, maintaining, and getting couriers to download a native app adds massive friction to the onboarding process. Telegram allows us to use an interface users already know. Through a structured bot, couriers can view their order list, get details (address, neighborhood, cross streets), execute delivery workflows, register payments (cash, bank transfer), and upload photos as evidence or report issues. All without leaving their messaging app.

2. Embracing Excel Instead of Banning It

The shipper lives in Excel. Forcing a company to abruptly change its management tools is a losing battle. Rutiq includes a bulk import engine from Excel that maps columns, validates data, deduplicates, and enables review workflows. Excel remains the entry point, but Rutiq transforms it into structured data.

3. Applied (and Measurable) AI

We didn't want a generic conversational chatbot. We integrated Anthropic (Claude) as a data enrichment layer.

The Use Case: When an Excel file is imported with incomplete addresses or missing postal codes, the AI infers and normalizes the information based on text context (neighborhood, street, municipality).
Control: For AI to be viable in a B2B model, we implemented an audit table (ai_usage) that tracks costs and token usage for every request, ensuring profitability and transparency.

⚙️ Development and Architecture Challenges

A logistics system demands robustness. These were the main technical challenges we tackled:

True Multi-Tenant Architecture

Rutiq is designed to serve multiple operations without mixing data. The database design revolves around an omnipresent tenant_id. All FastAPI queries and Supabase Storage policies are strictly filtered by this identifier, ensuring one operator never has access to another's routes or billing.

The State Machine and Auditing

A last-mile order is never static. We developed a rigorous state machine (Pending ➔ Assigned ➔ En Route ➔ Attempts ➔ Issue / Delivered). To avoid the classic "who moved what" problem, we implemented an events table (order_events). Every state transition generates an immutable record, creating a perfect auditable timeline for resolving logistics disputes.

Edge Security

With public webhooks receiving critical data, security couldn't be an afterthought:

Protected Webhooks: The Telegram integration requires a Secret Token in the headers, strictly validated by FastAPI to prevent forged requests.
Defense in Depth: CORS is restricted exclusively to frontend domains, rate limiting is applied to sensitive routes (like logins or bulk assignments), and there is a strict zero auth bypass rule in production environments.

🚀 Key Takeaways for the Community

Building Rutiq left us with valuable lessons for any team evaluating this stack (Supabase + FastAPI + Next.js):

FastAPI and Supabase are a high-performance duo: The development speed of FastAPI combined with Supabase's managed services (especially Auth and Storage) allows you to spin up serious MVPs in weeks, not months.
AI should solve boring problems: Using LLMs to clean and enrich messy databases (like poorly formatted Excel files) brings immense and immediate business value—far more than a generic virtual assistant.
Telegram is an underrated UI: For field operations workflows (couriers, technicians, inspectors), Telegram bots with inline keyboards and webhooks are a powerful, cheap, and frictionless alternative to dedicated mobile apps.

Rutiq proves that innovation in logistics doesn't always require inventing a new paradigm. Sometimes, it's about structuring existing chaos, choosing the right tools, and applying artificial intelligence exactly where humans lose the most time.