I had never written a line of Svelte before this. The target: a tablet-friendly order manager where a waiter taps tables on a floor plan, adds items, tracks orders live, and generates receipts, no paper tickets, no kitchen printer middleware for this pass. I built it with Windsurf, an AI-first code editor I'd only briefly touched, recording the full session without cuts. Two hours later, a working application, not polished, but complete enough to click through every flow on an iPad.
The actual question I was testing
Learning a new framework is usually what kills a side project before it starts, documentation, boilerplate, component architecture decisions, each one adding overhead before anything ships. I wanted to know whether AI-assisted development could collapse that overhead enough to ship a real vertical slice in one sitting.
What got built
An interactive SVG floor plan, exported straight from Figma. Tapping a table opens an order sheet, items add from a persistent menu, status changes reflect what would normally update a kitchen display, and completed orders move to history with running totals. A receipt view generates clean PDFs through the browser's native print function. Svelte specifically because I wanted to feel its compile-time reactivity firsthand; Vite handled dev server and build; no backend, all state in memory, which kept the scope tight enough to finish in one evening.
How the session actually worked
The workflow was repetitive by design: describe the next component in plain English, review the generated code, request adjustments, test immediately on the iPad. When output didn't match my mental model, I pasted the error or the unexpected behavior back into the conversation and kept going. This felt closer to pair programming than prompt-and-paste; Windsurf held project-wide context, so I never had to re-explain the data model across files.
The floor plan was the real test. Starting from an SVG with named groups per table, I asked the editor to parse it, turn each group into a clickable component, and manage selection state. The first version worked on the first pass. State management came next: I described the shape of an Order object, table number, items, quantities, modifiers, timestamp, status, and got back a writable Svelte store any component could subscribe to, light enough to avoid the architecture debates that usually slow this down in React.
Choices made for speed, that I'd still defend
Keeping all data client-side removed networking complexity entirely and let the session focus on interaction; a real deployment would need a lightweight backend, but the POC already demonstrates value to a restaurant owner as-is. Using the browser's native print for receipts instead of a PDF library cut hours of integration work, with CSS media queries keeping the printed layout clean whether saved as PDF or sent to an AirPrint printer. And I accepted some intentional duplication in the UI rather than abstracting a few repeated patterns; with only a few hundred lines total, clarity mattered more than strict DRY discipline.
What surprised me about the process itself
Almost no time went to syntax. Svelte's templating is concise, but I never had to memorize its directives; {#if}, {#each}, and event bindings came back correct on the first try, and my corrections were almost always about desired behavior, not framework quirks. Debugging followed a clear pattern too: describing observed behavior rather than guessing at causes got to the real issue faster than my own guesswork would have. In one case, the editor caught that I was mutating a store value directly instead of using its update function, a mistake I make in every new framework I touch.
the repo and the repo capture the actual state at the end, with almost no manual cleanup afterward.
What this changes about starting new projects
The bottleneck has visibly shifted from typing code to specifying intent precisely; how clearly I could describe the desired behavior mattered more than my Svelte knowledge, which suggests product thinking becomes a stronger advantage, not a weaker one, as AI absorbs more of the implementation. Staying in memory and accepting temporary limitations also mattered: most side projects die from being pushed toward production-readiness too early, and shipping something testable the same evening avoided that entirely.
One thing I'd do differently: early on I let the editor generate a large component mixing UI and business logic together. Splitting it sooner would have made later changes cleaner; the refactor itself was easy, but I paid a small tax for the initial shortcut.
If you're sitting on an idea that needs a UI in a stack you haven't used yet, this is a workable path: pick the stack, open an AI-assisted editor, and give it one evening. Worst case, a few hours of learning. Best case, a working prototype that changes how fast you think ideas can become real.