Stocky

Chat with the agent, as an example, we are searching for a product, via writing, you could talk to him instead.
Rules of the demo store/account, changeable.
Setting the quantity of a new product for my stock.
The agent working on creating the orders for the demo store/account.
Main page showing the month spending, and some orders to be approved, and the products that are on a low quantity for the store.
Stock reviewed, the agent created the orders with lacking stock.
Orders of the demo account and their status.

About the Project Inspiration Small retailers lose time and money on repetitive restocking decisions: checking stock levels, comparing suppliers, and placing orders under tight cash-flow constraints. We wanted to build Stocky — an AI-assisted operations companion that helps a store owner decide what to reorder, from whom, and within budget, while keeping humans in control of payment approvals. The PayPal AI Hackathon was the perfect opportunity to combine an autonomous agent workflow with a trusted, familiar payment rail (PayPal Sandbox). What we learned

Agent reliability is a product problem, not just a model problem. Clear tool boundaries, explicit spending rules, and deterministic order states matter more than “smart” prompts.
Web and mobile parity takes real engineering. Flutter makes cross-platform UI fast, but browser constraints (CSP, popup blockers, audio autoplay policies, asset loading/CDNs) require platform-specific solutions.
Security must be designed into the demo. Public demos need safe defaults: no auto-login in production builds, secrets only in server/Vercel env vars, and only the public Supabase anon key in the client. How we built it Stocky is a Flutter app (web + mobile) backed by a Fastify (TypeScript) API and Supabase (auth + data). The core flow is:
The assistant reviews inventory and supplier/catalog data.
The agent proposes or creates a restock order that respects the store’s spending policy.
The owner reviews the order and approves payment through PayPal Sandbox.
The app confirms authorization/capture and updates order status. We unified deployment on Vercel: the Flutter web build is served statically, and /api/* requests are rewritten to a Fastify serverless adapter. For web, we built with --no-web-resources-cdn and served local CanvasKit/fonts to avoid external font/CDN fetch issues; UI sounds use a web-safe audio path, while native platforms use SoLoud. To keep purchasing within policy, the agent validates proposed orders against monthly limits. For example, if Sₘ is the amount already spent this month, Bₘ is the monthly budget, and o is the proposed order total, an order is allowed (or flagged for approval) when: o ≤ max(0, Bₘ − Sₘ) Challenges we faced
Web runtime constraints: We hit multiple browser-specific issues — CanvasKit/font CDN boot failures, CSP blocking required resources, popup-blocker behavior on PayPal redirects, and audio playback differences. We solved these with local web assets, tighter CSP rules, and a same-tab navigation flow for PayPal on web.
Cross-platform payment UX: Getting a reliable “approve → open PayPal → return → confirm” flow across web, iOS simulator, and mobile required careful handling of URL retrieval and platform navigation behavior.
Integration/debugging complexity: Coordinating Supabase auth, protected backend routes, agent decisions, and PayPal Sandbox state meant small wiring issues (like a missing use-case registration) could break the end-to-end flow. Structured logs, health checks, and demo reset scripts helped us iterate quickly.
Demo readiness under time pressure: Balancing hackathon speed with safe defaults (no leaked secrets, no production auto-login, clear reviewer instructions) was challenging, but essential for a trustworthy submission.