I had never written a line of Svelte before. The idea was simple: build a tablet-friendly order manager that lets waiters tap tables on a floor plan, add items, track orders in real time, and generate receipts. No paper tickets, no kitchen printer middleware for the POC.

The twist? I would use Windsurf, an AI-first code editor I had only played with briefly, and record the entire session without cuts. Two hours later I had a working application. Not polished, but complete enough to click through every flow on an iPad.

The observation that pushed me to start was familiar to any solo builder: the friction of learning a new framework often kills side projects before they begin. Documentation, boilerplate, component architecture decisions, state management patterns — each one adds mental overhead. I wanted to test whether modern AI coding tools could collapse that overhead enough to ship a vertical slice in one evening.

What I actually built

The app presents an interactive SVG floor plan exported from Figma. Tapping a table opens an order sheet. Items are added from a persistent menu. Orders show status changes that would normally update a kitchen display. Completed orders move to history with running totals. A receipt view generates clean PDFs via browser print-to-PDF.

I chose Svelte because I had been reading about its compile-time reactivity and wanted to feel the difference myself. Vite handled the dev server and build. No backend — all state lived in memory, which kept scope tight.

Restaurant floor plan interface showing tables and order panel

The image above shows the main screen: tables on the left, active order on the right, category tabs at the bottom. Everything runs smoothly on iPad Safari.

Starting from zero knowledge

I began by asking Windsurf to create a new Vite + Svelte project with TypeScript. Within minutes I had a running dev server. The AI suggested a clean folder structure and basic routing using the built-in SvelteKit patterns even though I stayed with plain Svelte for simplicity.

My workflow was deliberately repetitive: describe the next component in plain English, review the generated code, ask for adjustments, test immediately. When the AI produced something that didn't match my mental model, I pasted the error or unexpected behavior back into the chat and continued the conversation.

This back-and-forth felt closer to pair programming than traditional copy-paste prompting. The AI remembered context across files because Windsurf maintains project-wide awareness. I never had to explain the data model twice.

The floor plan was the first real test. I had prepared an SVG with named groups for each table. I asked the AI to parse the SVG, turn each table into a clickable component, and maintain selection state. The first version used DOM events directly on the SVG elements. It worked instantly.

State management came next. I described the shape of an Order object — table number, items with quantities and modifiers, timestamp, status. The AI generated a writable store that any component could subscribe to. Because Svelte stores are so lightweight, I avoided the architectural debates that usually slow me down in React.

Design decisions shaped by speed

I made several pragmatic choices that I would defend in a real product context.

First, I kept all data client-side. For a POC this removes networking complexity and lets me focus on interaction. In production I would add a lightweight backend, but the current version already demonstrates value to a restaurant owner.

Second, I used the browser's native print functionality for receipts instead of a PDF library. This decision cut hours of integration work. The printed layout is styled with CSS media queries so it looks clean whether saved as PDF or sent to an AirPrint printer.

Third, I accepted some duplication in the UI code. The AI offered to abstract repeated patterns into components, but I deliberately kept a few inline sections because the total file count stayed small. With only a few hundred lines of code, clarity mattered more than DRY perfection.

The order history view taught me something about user expectations. Waiters don't just need a list — they need quick totals and the ability to reopen an order. I asked the AI to implement a modal that loads previous orders into the active state. The resulting flow felt natural when I tested it on the iPad.

Order history screen with totals and reopen actions

What the process revealed about AI-assisted development

The most surprising part was how little time I spent on syntax. Svelte's template syntax is concise, but I never had to memorize the exact directives. The AI produced correct {#if}, {#each}, and event bindings on the first try. My corrections were almost always about desired behavior, not framework quirks.

I also noticed that the AI is excellent at generating consistent styling when you give it a single source of truth. I described a color palette and button hierarchy once, then referenced that description in every subsequent prompt. The resulting UI feels coherent even though I never opened a design tool during the session.

Debugging followed an interesting pattern. When something didn't work, I would describe the observed behavior rather than my guess about the cause. The AI often identified the real issue faster than I could have. In one case it spotted that I was mutating a store value directly instead of using the update function — a mistake I make in every new framework.

The two-hour video (https://youtu.be/bdRU1sW3SKU) captures the real rhythm: long periods of thinking and describing, short bursts of code review, occasional live testing on the iPad. The final GitHub repo (https://github.com/mronceray/OrderManager) contains the exact state at the end of the session with almost no manual cleanup.

Principles I took away

Three observations now shape how I approach new projects.

First, the bottleneck has shifted from typing code to specifying intent clearly. My ability to describe the desired UX in precise, incremental steps mattered more than framework knowledge. This suggests that product thinking becomes an even stronger competitive advantage when AI handles implementation details.

Second, starting small and staying in memory removes artificial complexity. Many side projects die because builders try to make them production-ready too early. By accepting temporary limitations I shipped something testable the same evening.

Third, recording the session forced transparency. I couldn't hide the moments when the AI produced suboptimal code or when I changed direction. That transparency is valuable for other developers evaluating these tools. The mistakes are as instructive as the wins.

I would approach one part differently next time. Early on I let the AI create a large component that mixed UI and business logic. Splitting it earlier would have made later changes cleaner. The AI was happy to refactor, but I paid a small tax for the initial monolithic choice.

Who should try this approach

Solo founders and product leaders who want to validate an idea in a new domain should consider this workflow. The combination of a simple framework like Svelte and a capable AI coding partner lowers the activation energy dramatically.

Restaurant operators who have struggled with clunky POS tablets might look at the live demo and see immediate value. The floor plan interaction alone solves a real pain point I observed in multiple establishments.

Most importantly, developers who feel overwhelmed by the pace of new tools now have a practical path to experiment. You don't need weeks of learning. You need a clear use case, a focused scope, and the willingness to think out loud with an AI pair programmer.

The repo is public. The video is unedited. The result is imperfect but functional. That, to me, is the point. Shipping beats perfection when you're exploring both a new framework and a new way of building.

If you're sitting on an idea that requires a UI you don't yet know how to build, try the same experiment. Choose a stack you've been curious about, open an AI editor, and give yourself one evening. The worst outcome is a few hours of learning. The best outcome is a working prototype that changes how you think about velocity.

I now start every new exploration with this pattern. The speed at which ideas become testable reality has permanently changed.