The lab

TimberWorks sells wood. Raw logs and planks, stairs, fences and doors, ready-to-build kits like the Watchtower or the Tea House: a specialist's catalog for builders, architects and project creators, not another generic marketplace.

None of it exists.TimberWorks is the lab's fiction, a company invented so that everything around it can be real. With no actual business behind the shop there is no NDA, no anonymized screenshot, no customer to protect: the storefront can run in public, break in public, and be studied in public.

And it does run. Every few minutes, a simulated customer opens the store in a real browser, compares a Barrel and a Chest, buys or abandons; the company answers with the signals every retailer knows: traffic, orders, abandoned carts. The rest of this page is the tour: the catalog, the system at the core, the pressure that tests it, and the flows that answer it. (Why run a lab this way? The manifesto makes the case.)

The catalog is loosely inspired by a well-known block-based construction universe, and the wink is deliberate.

The first reason is neutrality. A shop selling oak logs, Barrels and Watchtower Kits resembles no existing business, so nothing on this site ever leaks from a real one.

The second is scale. That universe offers more than 8,000 items, in families running from raw wood to ready-to-build kits, with variants and relationships: enough structure to make search, classification and analytics interesting from day one.

And the honest funnel, today: thousands of items possible, a few dozen seeded, one uncontested best-seller. The Chest is the shop's idiomatic item; for a while, nearly every completed order was one. Not a bug to hide: exactly the kind of accidental behavior the lab exists to make visible.

Inside the dashed boundary sits a classic enterprise stack, made of existing components: PrestaShop, MariaDB, Matomo, Nginx. The heart of the map is, quite literally, the production stack of an e-commerce company. That is what the lab is after, and what makes it rich: architectural questions get asked against software that enterprises actually run. Grey turns solid, in the order the roadmap below sets.

The boxes outside the boundary are a different job. Customers, suppliers, payment providers and carriers do not belong to the enterprise, so the lab has to simulate them. And the realism of that generation decides how far the simulation can go: believable customers and believable suppliers are what separate a living laboratory from a demo.

Demand follows the clock. Traffic is shaped by five composable dials: a base rate, a day-of-week rhythm, an hour-of-day curve, seasonal campaigns (Black Friday, Christmas), and a little noise. The dials multiply, then a Poisson draw decides how many customers arrive this tick: a quiet Tuesday at 2 a.m. and a Black Friday evening come from the same five numbers.

Each arrival is a customer, not just a request: new or returning, carrying a website-agnostic intent (browse, buy one product, buy a basket). A translation step turns intents into concrete journeys on PrestaShop today, on another platform someday. The state machine is designed to grow: search, sign-in, payment retries, abandonment at every step of the funnel.

The machinery is open source: archipellabs-runtime, on PyPI. A scheduler emits arrivals into a Redis stream; pools of workers drive real browsers through the store. When a customer orders a Chest, that order exists three times: a browser session, rows in MariaDB, events in Matomo.

Put enough simulated customers on a shop and a problem shows up on its own: the stock runs out, and the Chests go first. A real company has staff for that; someone reorders, updates the catalog, processes the returns. TimberWorks has business flows instead. The first one is landing now: a simulated supplier (OakHeart Forestry, say) publishes its catalog, an ordering agent watches stock levels and decides when to place a purchase order, and the goods arrive only after a lead time, like real goods do.

Pressure is only half of the simulation. The lab also simulates the business itself: workflows, activity, tasks. Business rules first: explicit, debuggable, boring on purpose. Then AI agents that work the way an employee does. Either way, the company operates itself, and every operation leaves a trace in the system.

The objective is double: build a simulator with genuinely complex behavior, and get hands-on with the repetitive tasks of real employees, the ones AI can orchestrate. Simulating a business workflow today is the same skill as automating one in a real information system.