---

Build a complete, production-minded website for 1PIECE Sushi & More, a sushi restaurant in Eschweiler, Germany. The website must introduce the restaurant and let customers order delivery online.

The restaurant’s printed menu photos — IMG_1988.jpg, IMG_1989.jpg, and IMG_1990.jpg — are already in the folder where I want you to create the project. Locate and inspect them before creating the application. They are the primary reference for the restaurant identity, menu, prices, ingredients, piece counts, address, opening hours, and delivery terms. Rotate and enlarge the photos as needed. Keep the original files intact, and do not silently guess text that is unreadable.

How to work

Use oh-my-codex and codebase-memory-mcp throughout the project, according to their installed instructions. First inspect the repository, available tools, existing code, and any project instructions. Record important architecture decisions and progress in codebase memory so work can continue across sessions. I will also connect Supabase MCP: use it to inspect the selected Supabase project, create and apply database migrations, configure appropriate policies and server functions, and seed the catalog when access is available. Do not claim that a remote change was applied unless you verified it.

Make the implementation, not just a design, plan, or static mockup. Work in milestones, run the application, check its main flows, fix issues, and finish with a concise report of what works and what still requires credentials or restaurant-owner confirmation.

Product and visual direction

Create a distinctive, modern restaurant site inspired by the supplied printed menu: dark surfaces, confident typography, restrained yellow accents, appetizing food photography, and a clear visual connection to the existing 1PIECE identity. Improve on the flyer’s layout rather than copying it literally. Avoid generic AI-looking gradients, repetitive cards, excessive animation, and stock-looking restaurant copy.

The interface should be German-first, with prices in euros and a polished mobile experience. Include:

A home page explaining the restaurant, highlighting its food, and leading directly to ordering.

A complete, searchable and filterable menu with clear category navigation.

Product detail views or dialogs showing ingredients, allergens where verified, piece count or portion size, price, and a suitable image.

Restaurant information, address, opening and delivery hours, contact details, delivery area and fees.

An accessible cart, delivery checkout, payment flow, order confirmation, order tracking page, and downloadable order document.

Appropriate Impressum and Datenschutz pages with clearly marked fields requiring the owner’s verified legal details. Do not fabricate legal identities or tax numbers.

Use subtle, purposeful motion and make the interface fast, responsive, keyboard accessible, and SEO friendly. Provide meaningful metadata, structured restaurant/product data where appropriate, sitemap, and readable URLs.

The printed flyer contains a dated 25% promotion. Do not automatically publish that expired promotion as a current offer. Similarly, treat printed opening hours, delivery fees and minimum order values as initial data that the restaurant owner must confirm before launch.

Catalog and images

Transcribe the entire legible menu, including its categories, products and prices. The photos show starters, soups, hot dishes, sushi varieties, bowls, combos, extras, drinks and other groups; use the actual menu headings and products rather than a small invented sample. Preserve the distinction between sets of 2, 5, 6, 8 or 10 pieces where the menu provides it.

Write short, useful German descriptions based on the printed ingredient lists. Show piece counts and portion information. Where a weight or count is genuinely missing, you may add a clearly marked estimated placeholder for the prototype, but keep it distinguishable in the data model so it cannot be mistaken for verified restaurant information. Do not invent ingredients, allergens, prices, or claims about food safety. Flag unclear transcription and missing allergen information for owner review.

Find real, commercially usable food photographs online; do not generate product or prepared-food images with AI. Use one coherent photographic style per category, particularly for sashimi. Store licensed assets locally or in Supabase Storage rather than relying on fragile hotlinks, and keep a record of their sources and licenses. Match each photo to the correct kind of food. If an exact product photo is unavailable, use an honestly representative image, keep it easy to replace later, and never imply that it depicts the restaurant’s actual dish. Design the product-image field and storage structure so the owner can replace pictures later without changing the frontend.

The flyer includes anime imagery. Do not download or recreate third-party anime characters or other protected artwork as website assets unless the restaurant confirms it has permission to use them. Build a recognizable visual identity using the restaurant name, colors and original design work.

Architecture and deployment

Choose a maintainable stack suited to an SEO-friendly storefront. My preferred direction is Next.js + TypeScript for the frontend, with Supabase Postgres, Storage, Realtime where useful, and Edge Functions for data and secure server operations. Inspect the existing repository before replacing any stack already in use.

I intend to use Supabase for the backend. Do not assume Supabase hosts the public Next.js storefront. Prepare the frontend for a suitable separate host, and document exactly which parts run there and which parts run on Supabase. If a deployment account or domain is not connected, complete the code and deployment configuration and state precisely what is needed to go live.

Create versioned SQL migrations and a reproducible catalog seed, even when also applying changes through Supabase MCP. Design tables for categories, products, product images, orders, order-item snapshots, payment attempts, delivery settings, promo codes and redemptions, and order-status history as needed. Use sensible constraints, indexes, access policies and data retention settings.

The public catalog may be readable without login. Customers should be able to order as guests. Protect orders and personal data with server-side operations and restrictive RLS; a public client must not be able to read other customers’ orders or change prices, payments or statuses.

Ordering and checkout

Implement the full customer flow:

Browse products by category and search.

Add products to a persistent cart and adjust quantities.

Enter delivery address, contact details and optional order note.

Validate the delivery address or eligible area against the restaurant’s configurable delivery rules. Show minimum order value and delivery fee before payment.

Apply a promo code with server-side validation. Seed 2026 as a clearly marked test promotion, with its discount value and activation configurable in the database. Use a reasonable temporary discount for the development environment; do not silently enable a test discount in production.

Review an itemized order with subtotal, discount, delivery fee and final amount.

Pay by card or PayPal.

Receive an order confirmation and a private link to track the order.

Download or print an order summary. Generate a legally labelled invoice or tax receipt only after the owner has supplied and verified all required business and tax details; otherwise label the document as an order confirmation.

Calculate every price, discount, fee and final amount on the server from current catalog data. Store an immutable snapshot of ordered items and amounts. Handle retries and duplicate requests safely so customers cannot create duplicate paid orders by refreshing.

Use a hosted or provider-managed checkout; never collect or store raw card data. Prefer one coherent Stripe integration for card and PayPal if the connected German merchant account supports both. Verify actual account eligibility before presenting PayPal as live. If that is unavailable, implement PayPal through its official checkout flow with the same server-side verification standard. Keep all credentials in server-side secrets.

A redirect to a “success” URL is not proof of payment. Verify signed provider webhooks, make processing idempotent, reconcile payment records, and only mark an order paid when the provider confirms it. Handle declined payments, cancellation, refunds and duplicate webhook delivery. Provide sandbox/test-mode instructions and a working local test flow when merchant credentials are unavailable; do not simulate a successful live payment.

Order tracking and operations

After a successful order, show a private tracking page with the order number, item summary, payment state and a clear status timeline, for example: received, accepted, preparing, ready for delivery, out for delivery, delivered, or cancelled. Use live updates where practical, with a polling fallback. Never expose customer details through a guessable order number: use a sufficiently strong private tracking token or an equivalent secure approach, rate-limit access, and avoid leaking personal details.

Build the data model and protected server operations needed to change order statuses. Do not build an admin dashboard yet. For now, document a safe, limited way for authorized staff to view orders and update statuses through Supabase or a protected operational interface. Customers must never be able to modify these states.

Quality and handoff

Test the important paths: catalog loading, category navigation, cart persistence, delivery rules, promo calculation, server-side price checks, failed and successful test payments, webhook retries, private tracking, status changes, and order-document generation. Check both desktop and mobile layouts. Do not add superficial tests that merely duplicate implementation details.

At the end, provide:

A concise summary of what was built and where it runs.

The route list and main customer flow.

Database migration and seed instructions, plus what Supabase MCP actually applied.

Exact environment variables and steps needed to enable live card and PayPal payments.

A list of menu entries, images, business details, allergens, delivery rules, and tax details that still need owner confirmation.

The test commands run, their results, and any remaining blockers.

If you encounter an unclear detail, make a documented, reversible implementation choice and continue. Ask me only when an answer is essential to complete a live integration or would otherwise cause an irreversible change.