Tech stack & architecture

The server side is Laravel 13 on PHP 8.3, with PostgreSQL as the database. The pages are React 19 components written in TypeScript. Inertia connects the two: a Laravel controller answers with the name of a React page and its data, so there is no separate REST API for the interface and no client-side router to keep in step with the server. The first visit to a page is rendered to HTML on the server by a small Node.js process that runs the same React code; the browser takes over from there.

The look comes from shadcn/ui components on Base UI primitives, styled with Tailwind CSS 4. The Floor is a three.js scene inside the same React application. Queue, cache, and sessions all live in the database. Besides PHP and PostgreSQL, the installation therefore needs only Node.js for that rendering process: no Redis, no WebSocket server, no search engine.

The Shop, the ERP, the WMS, the Handheld, the Floor, this Documentation, and Feedback are one codebase, one deployment, and one database. Each system is a URL prefix with its own layout and sidebar: /shop, /erp, /mobile, /floor, /docs, /feedback, and the WMS on everything else. One login covers them all.

Inside, the business systems are kept apart as if they were separate products. The Demo ERP has its own tables with the prefix erp_, the Demo Carrier and the Demo Supplier have theirs, and the WMS has the rest. The WMS never reads an ERP table and the ERP never reads a WMS table. What one system knows about the other, it has learned from a message over HTTP, exactly as it would between two companies.

That is why the same article exists twice, as ErpArticle and as Article, and why an order number is the only thing an ERP order and a WMS order share. The chapter Backend & interfaces follows such a message.

The first visit to any page returns a complete HTML document: Laravel builds the props, the SSR server renders the React page into markup, and the props travel along so the browser can take over. From then on, Inertia turns every link and form into a background request, receives only the page name and its props as JSON, and swaps the React page in place. The server side looks the same in both cases: a route, middleware, a controller, and a response from Inertia::render(). The chapter Frontend & 3D follows the first visit step by step.

Controllers stay thin. They validate the input, often through a form request class, hand the work to an action, and redirect or render. The action holds the business rule and runs inside one database transaction. After a change, the controller redirects back with a flash message, which the layout shows as a toast.

Every page also receives a small set of shared props from HandleInertiaRequests: the signed-in user, the work counts for the sidebar badges, the number of articles in the Shop cart, and the state of the sidebar.

The repository follows the standard Laravel layout. As of October 2026 it holds about 22,700 lines of PHP in app, 65,200 lines of TypeScript in resources/js (almost a third of them the Floor), and 12,800 lines of tests.

A few rules apply everywhere, and most of them are enforced by a tool rather than by discipline.

1. One time zone: the application, the scheduler, and the PostgreSQL session all run on Europe/Berlin. A time is stored and shown as Berlin wall-clock time and never converted on the way.
2. One home for rules: a controller, a console command, and the virtual crew call the same action, so a pick booked on the Handheld and a pick booked by the crew cannot behave differently.
3. Statuses are enums, never free strings, and their labels are tested.
4. Types everywhere: PHP methods declare parameter and return types and PHPStan checks them at level 7; TypeScript runs in strict mode.
5. No hand-written URLs in React: every link and form uses a route function that Wayfinder generates from the Laravel routes.
6. Formatting is not discussed: Pint formats PHP, Oxfmt formats TypeScript.

Production is a single server managed by Laravel Forge. A deployment builds a new release beside the running one, including the bundle for server-side rendering (npm run build:ssr), runs the migrations, and then switches over, so visitors do not see a gap.

Besides the web application, three background processes keep the Warehouse alive. The scheduler starts php artisan schedule:run every minute; without it, no order is released and the crew stands still. One queue worker (queue:work database --tries=3 --backoff=60) sends the emails for real Shop buyers. Interface messages are not queued: they are sent in the same request and logged.

The third process is the SSR server, started with php artisan inertia:start-ssr: a Node.js process that renders first visits. It listens on port 13714, which the firewall keeps closed to the outside. After each switch-over, the deployment stops it with inertia:stop-ssr, and Forge starts it again from the new release, so it renders with the new code. If it is down, the pages still work; the browser then renders them alone.

Development happens on Laravel Herd with PHP 8.3 and PostgreSQL 17. Locally, the Vite dev server renders first visits itself, so no separate SSR process runs. There is no build server. The quality gate described in Testing & quality runs on the developer machine before every push.