Five Days to Production: What AI Accelerated, and What It Never Decided
A full sushi delivery platform — 146-dish catalog, Filament admin, online payments, priced delivery districts — went from domain registration to production in 5 days and took its first paid online order on day 10. The specification budgeted 7–11 weeks. Every feature in it was a human decision; AI wrote the code.
Duration
5 days to production (24–29 July 2026); first paid order day 10
Team Size
1
My Role
End-to-end: specification, architecture, backend, storefront, admin panel, infrastructure, CI/CD, catalog data and photography
Executive Summary
The domain sushihouse.kh.ua was registered on 24 July 2026 at 18:13. The first commit landed the same evening at 21:48. The production server — its own isolated system user, not a folder on a shared box — was provisioned at 23:18 that night. The production branch went live on 29 July at 21:51: five days and six hours from buying the domain. The first paid online order, #000015, was placed on 3 August at 14:23, paid through LiqPay sixty seconds later, and delivered at 16:09.
The specification for this project — written before any code — laid out six sprints and estimated 7 to 11 weeks. It shipped to production in five days, with 118 commits and 40 automated test suites. That is roughly a ten-fold compression, and it is the least interesting thing about the project.
The part that matters is what the compression did not touch.
Essentially every feature in this platform — the nested category tree, the per-district delivery pricing, the upsell strip that appears in both the cart and the checkout, the passkey login on the admin panel, the manager-only comment field on orders, the kitchen-clock day boundaries on the dashboard — came from a person who has built and run e-commerce before. The model never proposed the product. It was handed a specific requirement, it implemented it fast, and it frequently improved the implementation of an idea it had been given. It did not originate the idea, and on the handful of occasions it was left to decide something on its own, it chose plausibly and wrongly.
That is the whole argument. AI did not replace the person who knows what a sushi delivery business needs on a Friday night. It replaced the six weeks that person would have spent typing.
Key Metrics
Domain purchase → production launch
Before
7–11 weeks (spec estimate)
After
5 days 6 hours
Domain purchase → first paid online order
Before
7–11 weeks (spec estimate)
After
10 days
Catalog live at launch
Before
0 (chalkboard menu)
After
146 dishes / 21 categories
Dish photography coverage
Before
None (no shoot budget)
After
146 of 146 dishes
Automated test suites at launch
Before
0
After
40
Admin authentication
Before
Password only (typical MVP)
After
Passkeys + audit log + throttle
Online payments
Before
Cash and phone orders only
After
LiqPay, live at launch
Deployment
Before
Manual
After
Push-to-deploy, 2 environments
What Was Built
33 delivered features — every one of them a specified requirement, not a generated suggestion
Storefront
What the customer sees
- Nested catalog — 21 categories (11 root, 10 sub) with products on leaf categories, so opening «Роли» shows the whole sub-tree; counts and filters walk the tree, and deactivating a subcategory removes its products from the parent listing too
- Livewire catalog — filters, search and sort without a page reload, plus a site-wide search overlay and a compact sort dropdown
- Product pages — tabs, rich content, composition, allergens, badges (hit / sale / new / hot / veg / baked) and customer reviews
- Product variants — portion and set sizes priced independently — cart line identity is the product and variant pair, not the product alone
- Cart — a mini-cart flyout that opens automatically when a dish is added, quantity steppers, per-line removal and a free-delivery progress bar
- Upsell — an add-on strip in both the cart and the checkout, with its own photography for 28 add-on products, flagged per product rather than hardcoded
- Checkout — Ukrainian phone mask and validation rule, courier-or-pickup switching, address required only for courier, scheduled delivery slots validated against the kitchen clock, and auto-scroll to the first validation error
- Delivery districts — admin-managed districts priced individually and required at checkout, rather than one flat city-wide fee
- Payments — LiqPay online payment alongside cash, with post-order redirect to the gateway and paid / failed handling
- Order tracking — a status page plus a shareable client link, and a post-delivery feedback and review flow
- Promotions — content-managed campaigns with 9:16 banners and a live countdown timer
- Home hero — an admin-managed banner carousel that falls back to built-in slides so it is never empty
- Working hours — an open / closed state driven by a per-day schedule, which also gates the delivery times a customer can pick
- Localisation — Ukrainian at the root, Russian under /ru, with translatable database content — not just interface strings
- Content pages — Доставка, Оплата, Про нас, Контакти and the legal pages, all editable from the admin
- SEO — robots.txt and sitemap.xml served from the database rather than static files, so staging can de-index itself while production stays open; Schema.org markup and per-page meta
- Polish — self-hosted fonts with a Cyrillic subset, branded 400/403/404/500 pages, cookie and analytics consent, favicon, theme-adaptive payment logo, and a mobile drawer that handles landscape phones without iOS focus zoom
Admin panel
What the kitchen runs the business on
- Passkey login — WebAuthn sign-in for the admin panel, with enrolment on its own page, alongside password auth
- Security page — a login audit log and per-IP throttling, built as a real feature rather than a checkbox
- Order management — full CRUD so staff can enter phone orders, with quick status changes duplicated at the top and bottom of long forms and item thumbnails in the order view
- Authoritative pricing — order totals are never taken from the submitted form — the admin screen and the storefront checkout call the same pricer and rebuild line items server-side
- Manager-only comments — an internal note field on orders that the customer never sees
- Order history — a full audit trail of who changed what and when, including status and payment transitions
- Dashboard — today's orders and pending count, seven-day revenue with sparklines, a fourteen-day chart, latest orders and pending reviews — with days bucketed on the kitchen's clock, not on naive UTC dates
- Analytics — product view tracking and an analytics view added after launch
- Media library — uploads with an editor and crop, a visual thumbnail grid, and the ability to reuse an existing photo instead of re-uploading it
- Translatable editing — one locale switcher per form rather than duplicated fields, across products, categories and pages
- Rich editor — WYSIWYG with an HTML source view for when the editor gets in the way
- Deletion safety — categories, products, orders, districts and users refuse to delete when something depends on them, and the error explains that deactivating is the alternative
- Settings store — site-wide configuration — phone, hours, robots.txt, toggles — as editable settings rather than deploy-time constants
- Toppings — paid add-ons attached at category level and offered on the dishes underneath
- Cross-linking — «На сайт» from the admin and quick-edit links from the storefront, so staff move between the two without hunting for URLs
- Telegram notifications — new-order cards to managers with a tappable phone number and a quick-open admin button, plus paid and failed payment alerts — queued, so an outage can never block an order
The Challenges
Key obstacles that needed to be addressed
A 146-dish menu that existed only as chalk on a board
There was no digital catalog of any kind. The source material was a set of WhatsApp photographs of the restaurant's chalkboard menu and its drinks list — 146 dishes across what turned out to be 21 categories, with prices, portion variants and several items whose prices were ambiguous enough to need confirming with the client.
Business Impact
No online ordering existed at all. Every order came by phone, which caps throughput at however many calls one person can take during the Friday evening peak and loses anyone who will not call.
No photography, no budget for a shoot, no time for one
A food delivery site without dish photography does not convert, and a professional shoot for 146 dishes is weeks of scheduling and a five-figure line item. The catalog initially fell back on one representative image per category and a grey placeholder SVG for everything else.
Business Impact
Launching with placeholder tiles on two thirds of the menu would have made the site look abandoned on day one, which is worse than not launching.
Money, delivery pricing and order handling had to be correct on day one
Unlike a brochure site, this had to take real payments, compute real delivery charges per district, respect the kitchen's working hours, and hand the staff a tool they could actually run a shift on. There is no soft-launch version of charging a customer the wrong amount.
Business Impact
Every pricing or availability bug is either lost revenue or a refund plus an angry phone call, on the same evening it happens.
The specification itself budgeted 7 to 11 weeks
The written spec broke the work into six sprints — foundation, catalog, ordering, promotions, content and SEO, customer accounts — with its own estimates attached. That plan was realistic for a single developer working conventionally.
Business Impact
A restaurant waiting two to three months for an ordering channel is two to three months of peak evenings served entirely by phone.
Our Solutions
How we tackled the challenges and delivered results
Write the specification before writing any code
The project did not start in an editor. It started with a 596-line technical specification covering the stack, the design system, the sitemap, every functional module, the admin resources, SEO requirements, the database tables, localisation and the sprint plan — plus a closing section listing ten open questions to put to the client, from which payment gateway to whether a Russian interface was required.
Implementation
Because the target was unambiguous, the agent was never asked to invent product behaviour. Prompts referenced spec sections directly, and the spec stayed authoritative for the whole build: the project memory file still tells future sessions to read it before making an implementation decision, and warns that the delivery-price table in §5.4 is illustrative and must not be hardcoded because it was never confirmed with the client. Ambiguity is the thing AI converts into confident, wrong output at speed; the specification is what removed it.
Pick the most boring, densest-documented stack available
Laravel 13 with Filament 5, Livewire and Tailwind — the TALL stack. Not chosen for novelty, chosen because it is one of the most thoroughly documented conventional paths in web development, which is precisely what a language model is good at.
Implementation
Filament supplied a production-grade admin panel out of the box, so the effort went into the resources and workflows the business actually needed rather than into rebuilding CRUD. Spatie packages carried media library, sluggable, translatable, activity log and passkeys. The rule of thumb: every hour spent on an exotic dependency is an hour the model spends guessing.
Generate the missing photography, then import it idempotently
The photography gap was closed with AI image generation, driven by a written brief covering all 146 dishes, plus a separate brief for category spread images and one for the 28 cart add-ons.
Implementation
Photos landed in three passes across a single day — 136 dishes, then the final 10 to reach full coverage, then the homepage category tiles — behind an idempotent import command so the operation could be re-run safely. Products carry a spatie media-library cover plus a gallery collection with a WebP thumbnail conversion.
Treat security and correctness as launch scope, not as a later sprint
The parts that quietly decide whether a small-business site is safe were built into the launch, not deferred: how the admin authenticates, where prices are computed, and what the audit trail records.
Implementation
The admin panel got WebAuthn passkey login, a login audit log and per-IP throttling within the first four days. Order pricing is never taken from the submitted form — both the storefront checkout and the admin order screen call the same authoritative pricer to compute subtotal, discount, delivery and total, then rebuild the line items server-side. Order changes are recorded through an activity log. Panel access is gated explicitly rather than by assuming any authenticated user is staff.
Two isolated environments and push-to-deploy from the first week
The project got its own system user on the server, a separate staging domain, and an automated pipeline — before most of the features existed.
Implementation
GitLab CI deploys by branch: pushing test ships to the staging domain, pushing production ships to the live site, with the branch as the only gate. The runner does nothing but open an SSH session; all build steps run server-side. Staging can close itself from search indexing through a database-backed robots.txt while production stays open.
All solutions successfully implemented and deployed
Results & Impact
Measurable outcomes achieved through our solutions
Production launch five days and six hours after the domain was registered
A written plan of six sprints and 7–11 weeks was delivered in under a week, with the ordering flow, admin panel and payments all in the first release rather than staged across months.
First paid online order on day 10 — placed, paid and delivered inside two hours
Order #000015 was created at 14:23 on 3 August, cleared through LiqPay at 14:24, moved through preparing and out-for-delivery, and was marked delivered at 16:09 — the full lifecycle running through the admin the staff had been handed. It carries number fifteen because the preceding entries were demo records seeded during the build so the team had something to practise on; it is the first real one.
The kitchen runs the site itself, with no developer in the loop
Menu, prices, photos, banners, promotions, static pages, delivery districts, working hours, robots.txt and site settings are all editable from the admin panel in Ukrainian, with a Russian locale for the storefront.
40 test suites and a two-environment pipeline present at launch, not retrofitted
Coverage spans checkout, pricing, payment redirect, delivery districts, scheduled delivery, working hours, passkeys, login security, localisation, SEO and even Blade syntax — so the pace never depended on nobody looking.
Essentially every feature was specified by the human, not proposed by the model
The AI contribution was execution speed and occasional improvements to the implementation of a given requirement. Product judgement — what to build, what to price, what to trust, what to log — stayed entirely on the human side, and that is what made the speed usable rather than dangerous.
Project delivered on time and exceeded expectations
Technology Stack
Tools and technologies used to build this solution
Backend
Frontend
Admin / CMS
Security
Payments & Comms
Infrastructure
DevOps
AI tooling
All technologies were carefully selected to ensure optimal performance, scalability, and maintainability