dashboard from tona
collaborative rooms
notion info
Docs panel
Dashboard complete
schedule

Tona

Inspiration

I studied within IPN, Mexico's national polytechnic institute — a demanding academic environment with a heavier, denser workload than most schools outside it. The frustration was never really about not wanting to do the work. It was everything before the work: figuring out what I even needed to do, pasting files into an AI tool, writing a decent prompt, jumping between six tabs just to understand one assignment. Even small tasks — reading what a task was actually asking for — became exhausting. By the time I'd finished untangling the logistics, I'd lost the focus I needed to actually start. Some days I gave up before I began.

One day the idea hit me: what if something just summarized all of it for me? That idea sat with me for a long time — I never had a team to build it with, so it stayed an idea. What finally activated it was this XPRIZE build call itself: the idea had always been there, but the competition is what pushed me to stop waiting for the right conditions and just start building it myself, alone, with more fear than confidence, one piece of logic at a time.

What it does

Tona is a personal academic butler. It quietly keeps track of everything a student tends to forget — enrollment deadlines, forms, surveys, assignments, exams — and surfaces what matters without you having to go looking for it. Instead of a dozen tabs (Classroom, Drive, Gmail, Calendar, Notion), you get one place that already knows what's going on.

If you don't feel like reading, you don't have to — you can talk to it and it talks back. It creates the tasks, drafts and sends the emails, builds the files you need, submits your work when you confirm it, and pulls up exactly what you ask for. The goal is simple: whatever a student needs on their plate, Tona serves it — cutting down the stress of staying organized so there's more energy left for actually learning.

How we built it

Tona runs on a service architecture I largely learned by building it: a React/Vite frontend on Netlify, a FastAPI/Python backend containerized on Railway, Supabase as the data layer, and Gemini 2.5 Flash through Vertex AI on Google Cloud as the decision engine. Working with Railway, Netlify, Supabase, and the Google Cloud console for the first time felt like sitting in a plane cockpit full of switches with no idea which one to press — I had to theorize, test hypotheses, and compare what I built against what already existed in the industry, iterating until it worked.

Functionally, Gemini treats every capability in Tona — creating a task, opening a document, showing a widget, searching an email — as an action it can activate, waiting for the right trigger in the conversation. Each action is backed by its own logic layer of authorized calls to the Google Cloud project's APIs, with WebSocket channels for real-time collaboration and cookie-based session handling to keep every user's data isolated.

Two architectural decisions stand out to me. First, building a component system where Tona doesn't just execute logic — it can also act on the interface itself: intelligently showing, hiding, and rearranging a fixed library of pre-built visual components based on what the conversation calls for, rather than generating new UI on the fly. It's closer to a conductor choosing which existing pieces to bring on screen and in what arrangement than to drawing something new each time. Second, the security and optimization work underneath: blocking unauthorized users from collaborative rooms, rate-limiting requests, and caching the system prompt instead of resending it on every call. Neither of those pieces make headlines, but tightening them taught me more about what "production-ready" actually means than anything else in the build.

Challenges we ran into

The most stressful problem by far was authentication. In an early version, anyone who copied my open dashboard link could access Tona as me — no login required, my data fully exposed. Realizing that pushed me to rebuild the entire session model around httpOnly cookies instead of tokens in the URL. It took days — nights and mornings of "still not working" — before it finally held.

The second was the interface itself. Tona's very first design was a static console of app icons around a spinning globe (see attached screenshots) — nothing like what it is today. Rebuilding it into a system where Tona composes the UI dynamically out of reusable components meant redesigning the entire file structure and logic layer almost from scratch. Just holding the scale of that reorganization in my head was exhausting before I'd written a single new line of code.

The third was Stripe. Validating checkout screens, debugging failed test payments, and getting subscription creation/cancellation to behave correctly across webhooks took days of trial and error I didn't expect going in.

Accomplishments that we're proud of

Starting a project at this scale with no university degree, no formal training, and no prior experience building anything like it was genuinely frightening — there were points where it nearly broke me. I'm proud that I didn't quit, through the hundreds of hours of debugging, rethinking, and rebuilding it took to get here.

The second thing isn't a single moment so much as a string of them: the first real conversation with Tona, the first component it rendered on its own, the math behind the first physics visualization actually working, the first time a multi-turn conversational flow held together without losing context. Each of those small "it's alive" moments still surprises me.

What we learned

I learned that I can carry a project of this size on my own, without giving up, in a short window — I found out about this deadline with only 60 of the original 90 days left, which compressed everything. That taught me more about resilience and determination than anything else, and showed me a logical and systems-building capacity in myself I hadn't tested before.

On the technical side: how to work with and connect real-world APIs, the operational quirks of Railway, Netlify, and Supabase, the full OAuth flow and credential handling, why .env secrets have to be treated seriously, Git workflows under pressure, and how much data volume a real product actually moves. I came out with a much sharper sense of the security work a production system needs — httpOnly cookies being one small piece of a much bigger discipline — and, maybe most importantly, how much a project benefits from being properly designed logically before writing any code, not after.

What's next for Tona

Turning this into a formal company (an SAS) is really just the legal consequence of where I want to take it — the real goal is reaching more students, offering deeper services, and giving Tona a much richer sense of context. Right now it runs on a single context window per session; the next step is vector-based retrieval across sessions, students, tasks, and workflows, so Tona intelligently pulls only the most relevant data into context instead of everything at once — including an elasticity-style relevance layer over files, so it can surface the exact material tied to a topic a student is working on.

I'm already building a beta of study labs and virtual laboratories for foundational subjects (the physics simulations, like the Hooke's Law lab shown in the attached screenshot, are the first of these) aimed at improving performance in topics that aren't conceptually complex but do require solid prior grounding. Beyond that: a "Teams" tier, an emergency-contact/call system for academic urgencies so students aren't left alone with a problem, support for working students, an auto-generated invoicing flow, and PDF-based templates for recurring paperwork like enrollment forms or scholarship applications. Long-term, I want Tona to be a complete butler — down to recommending the best transit route to get to school or work — and to move it off the web and into a full native app, continuously improving from here. No detours, just efficiency.