Voltadrop

Inspiration

Almost every app still runs on manual operation — click here, fill this form, check that page, repeat across five more screens for anything non-trivial. That model hasn't changed much in twenty years, and it puts the entire burden of translating intent into action on the user.

VoltaDrop is a small, working test of a different premise: that an app can work intent-first instead. It's built on top of a broader idea I'm developing called Volta — apps that understand what a user means, recall context automatically, and coordinate multiple backend actions at once, the way a nervous system fires several muscles from a single intention rather than requiring one manual step per outcome.

What it does

The scenario: a live, limited-inventory product drop. A user types one sentence:

"Get me my usual size, and let Sarah know it's almost gone."

That one sentence triggers three coordinated backend actions simultaneously:

1. Recall — looks up the user's size from order history
2. Reserve — locks in the item atomically, safely, even under real concurrent demand
3. Notify — pushes a real-time message to a specific other user, live

How I built it

Frontend: React + Vite, deployed on LingoQL. Natural-language input is parsed by Gemini 2.5 Flash into structured intent, then dispatched through an orchestration layer that runs recall first (since reserve depends on the resolved size), then reserve and notify concurrently.

Backend: Sub0 — a 5-model Postgres schema and four ABI resources:

• issue-token — JWT issuance
• recall-last-size — reads order history
• reserve-stock — a single atomic SQL statement (a CTE combining a stock check and write) that prevents overselling under concurrent load with no application-level locking
• notify-user — writes a notification and broadcasts it over Sub0's WebSocket layer to one specific connected user

Challenges I ran into

The core technical challenge was reserve-stock's atomic overselling-prevention query — getting a single SQL statement to safely check and write stock in one operation.

Beyond that, integration surfaced several real platform-level issues: a mismatch between our schema's table names and what Sub0 actually created in Postgres, an incorrect combination of Sub0's tokenize and protected authentication patterns on the same resource, missing type casts on jsonb and integer parameters, and foreign-key ordering in seed data. Each was diagnosed with direct Postgres access and resolved with help from Sub0's support team.

To keep the project demoable throughout that debugging process, I built a fully-functional in-memory fallback that mirrors Sub0's real API shape exactly — including genuine cross-device real-time sync via BroadcastChannel — so the application never stopped working end-to-end, even mid-integration.

What I learned

A lot of this project ended up being about distributed-systems debugging as much as feature-building: diagnosing JWT signature mismatches, schema migration gaps, and type coercion issues against a real, evolving backend platform. I also learned the value of building a resilient fallback early — it meant platform-level blockers never stopped forward progress on the actual product.

What's next for VoltaDrop

VoltaDrop is one narrow, honest proof point for Volta's broader idea. Next steps: expanding intent-parsing to handle multi-step and ambiguous instructions, adding real multi-user auth, and applying the same coordination pattern to a structurally different use case — like a support-ticket or booking flow — to test how well it generalizes beyond product drops.

Built With

• api
• framer
• gemini
• javascript
• jwt
• lingoql
• motion
• postgresql
• react
• sub0
• typescript
• vite
• websocket