Try what we build
Four pieces of working software and one agent run, one for each kind of work we take on. They run in your browser on made-up data, so press anything, including the parts that go wrong. None of it is a client's system.
Web and commerce platformsFictional data
A storefront you can edit while you shop
A small shop on a headless setup. Filter it, fill the cart, then slow the connection to a phone on a bad signal and see what stays usable. On the content side, change a product and publish it: the change goes through its own small release, and only that product updates.
What this shows
- The cart answers instantly and saves in the background, so a slow network costs a spinner, not a lost order.
- Content lives in a model editors can change without a developer.
- A published change ships through a pipeline with checks, not by hand.
- Low stock
Filter, add to the cart, then switch the connection.
Mobile and connected productsFictional data
A courier app that keeps working offline
One app, drawn as iOS or Android from the same code. Complete deliveries, then take the phone offline and keep going. When the connection returns the queue syncs in order, and one job shows what happens when the office changed it while you were away.
What this shows
- Work done offline is queued on the device and never lost.
- A conflict with the server is resolved by a rule you can read, not silently overwritten.
- The cold box in the van reports in, and the app says when it is out of range.
Today's deliveries
- J-1041Galle Road, Kollupitiya09:00 to 10:00 · 2 parcels
- J-1042Duplication Road10:00 to 11:00 · 1 parcel
- J-1043Havelock Town11:00 to 12:00 · Chilled box
- J-1044Rajagiriya12:00 to 13:00 · 3 parcels
Everything is synced
What the server received
Nothing yet. Mark a delivery.
Mark a delivery, go offline, mark two more, then come back online.
Enterprise operationsFictional data
An operations console with roles and an audit trail
Stock and purchase orders for a distributor. Switch between a clerk, a supervisor and finance, and the same screen allows different things. Try a write-off as the clerk: it goes to a supervisor instead of happening. Every action lands in the audit trail with who did it and what changed.
What this shows
- Permissions are part of the workflow, not a hidden menu.
- Anything above a limit becomes an approval, with the reason visible.
- The audit trail records the before and after, so nobody has to reconstruct a Tuesday.
- Items below minimum
- 1
- Waiting for approval
- 1
- Payments to release
- $5,200
Stock
| Item | On hand | Minimum | Actions |
|---|---|---|---|
| Black tea 250 gTEA-250 | 420 | 150 | |
| Glazed cupCUP-ASH | 36Below minimum | 60 | |
| Stoneware teapotPOT-STN | 12 | 10 | |
| Tasting setBOX-TST | 88 | 40 |
Purchase orders
| Order | Supplier | Amount | Status | Action |
|---|---|---|---|---|
| PO-2208 | Hill estate | $1,840 | Submitted | |
| PO-2209 | Kiln workshop | $5,200 | Approved | |
| PO-2210 | Packaging mill | $640 | Draft |
Approvals
0Nothing waiting.
Audit trail
No actions yet today.
Write off stock as the clerk, then switch to the supervisor.
Data and cloud deliveryFictional data
A data pipeline that fails safely
Three sources feed a warehouse and a dashboard. Run it clean, then break it: rename a spreadsheet column, make the payments API time out, send duplicate orders. Watch the checks hold the bad batch back while the rest still loads, and the dashboard say how fresh its numbers are.
What this shows
- Quality checks run before the warehouse, so bad data is held, not published.
- A flaky source is retried with backoff instead of failing the whole run.
- Monitoring is attached from day one, and the dashboard shows its own freshness.
- Orders databaseNot run
- Payments APINot run
- Stock spreadsheetNot run
- IngestNot run
- Quality checksNot run
- TransformNot run
- WarehouseNot run
- DashboardNot run
Dashboard dataAs of 06:00, last night's run
Monitoring
Run the pipeline to see what it reports.
Pick a fault or two, then run it.
AI and automationFictional data
Agents that stay inside their permissions
Pick a request and watch the run: the router chooses agents, retrieval returns passages with the document each came from, and the third request is refused at the gate because the drafting agent is not allowed to send mail.
What this shows
- Every agent has a job description and a boundary it cannot cross.
- Answers carry their source, so they can be checked.
- Each run writes a log a person can read.
What the service includesRun the queue yourselfChoose what the model reads
agent playground
Pick a request below. It runs here.
A support system, running. Each request wakes the agents it needs, touches only what it is allowed to touch, and writes down what it did. The third one is refused.
Task: What are our termination rights on the supplier agreement?
run log
- Pick a request above. The run is drawn on the left and written here as it happens.
Want one of these on your own data?
Each demo is a small version of a real engagement. Send a paragraph about what is not working, and we will tell you which of these it is closest to and what it would take.