Building Rutiq: Orchestrating the Last Mile with FastAPI, Supabase, Telegram, and Applied AI 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. 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. When designing Rutiq, we made deliberate decisions to adapt to the users' reality, not the other way around. 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. 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. 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. A logistics system demands robustness. These were the main technical challenges we tackled: 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. 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. 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. 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.