Product 04 · The order visibility platform
Atlas
Know it's late
before it's late.
A projection is never presented as a fact.
The problem
Five functions watched
the same rug. Nobody saw it.
A handmade rug is a manufacturing project. It is designed, dyed, mapped to a loom in a village weaving house, woven for weeks, finished, checked, packed and shipped across the world. The customer plans around one date. The business isn't really selling the rug. It's selling a promise about the rug.
Sales, production, back office, logistics and a second brand all needed to know where an order was and whether it would ship on time. The answer lived in the ERP, and reached everyone else by phone call, by email every morning, and in a weekly report that arrived with blank cells and wrong dates.
There was a tracking page. It sent the entire ERP dataset, about 145MB, to every one of its 124 users' browsers on every login. Its shared passwords were readable in the page's own source code. Its access rules had a fail-open bug: a user it didn't recognise saw every order in the company. And it could only report that an order was late once the date had already passed.
None of that could be patched, because all of it came from the architecture. So Atlas kept what the old page proved people needed and replaced everything underneath it.
Screen 01
Every order, on one page.
Only the ones you should see.
Production, sales and back office all open this same screen. Each person sees a different slice of it.
- What this is
- Late and Delayed are separate tabs, because they mean different things. Delayed is a fact: the ex-factory date has passed. Late is a projection: today plus this stage's standard lands past that date.
- Why it exists
- Production asked for it in almost those words: “flag it as Late, not delayed.” Merging the two would have been tidier, and it would have told a customer something had happened when it only might.
- Business outcome
- On the day it shipped, 706 orders were on track by date and off pace by stage. The old tool showed every one of them as fine.
- What this is
- A summary that follows the filters: pieces, split by status, across the whole filtered set.
- Why it exists
- The list is paginated on the server, so adding up the rows on screen would be wrong for any filter bigger than one page. The totals are computed in the database, mirroring the filter logic branch for branch. The unfiltered total matched a direct count exactly before it went live.
- Business outcome
- Production stopped exporting to a spreadsheet just to add numbers up. It's shown only to production, and not to admins either. That was the request, and it was confirmed twice.
- What this is
- Days in the current stage against that stage's standard, worked out per order from its quality, size, construction and priority.
- Why it exists
- The standards are the business's own, taken from production's edits to their reference sheet, including an exact knot rate for each of 44 qualities. Stages are a table, not code: 134 raw ERP status strings map to 10 stages, so a new status is one row, not a redeploy.
- Business outcome
- When a walkthrough found “At Branch” being judged against the Loom standard, splitting it out was a data change. It now holds 376 orders.
- What this is
- The person to chase for this order, with their email one click away.
- Why it exists
- The ERP has a field for it, but it's blank on most real orders. So Atlas works it out live from a routing matrix: service zone × priority × knotted or tufted, plus two universal overrides. Automatic chasing was deliberately left off until production confirms the rules once more.
- Business outcome
- “Who do I call about this?” used to be a question. Now it's a column.
Screen 02
One rug, from loom
to courier.
The screen that ends the phone call where production says “that's not right, I only just received it.”
- Dispatched
- 30 Aug 2026
- Sales shipment
- SSH-26-018842
- Courier
- BLUE DART EXPRESS LIMITED
- Tracking no.
- 77410286135 Track ↗
- E-way bill
- 3510 8842 9917
- Original ex-factory
- 14 Aug 2026
- Revised ex-factory
- 01 Sep 2026
- Late vs original
- — · stops once dispatched
- Follow-up
- S. Verma ⧉
- What this is
- Every stage this rug has been through, with the date it entered each one.
- Why it exists
- Each duration is worked out from the next entry, never saved as a number that can drift out of step. On an order's first sync, one entry is backfilled from the ERP's own pending-days counter, so reporting didn't have to wait weeks for the first real stage change.
- Business outcome
- The argument moves from “it's late” to “it spent 49 days at Loom.” Both sides can point at a stage. More than 4.4 million stage entries sit behind this view.
- What this is
- A real Dispatched stage. The ERP report Atlas reads doesn't have one.
- Why it exists
- A salesperson said one purchase order had 21 rugs. Atlas said 12, and the salesperson was right. It turned out that a dispatched rug simply disappears from the main ERP report, with no status recorded anywhere. The fact exists only in two different reports, so Atlas now reads those as well.
- Business outcome
- One customer dispute became dispatch dates for 6,074 orders. Both sources keep only a rolling window of history, so these fields are written once and never cleared. An old record ageing out of a report never undoes a dispatch.
- What this is
- A courier, resolved to its full name from the ERP's own code, and a tracking link.
- Why it exists
- The link only appears for the three couriers with a confirmed public tracking page. A real tracking number from a small regional transporter shows as plain text, never as a link that goes nowhere.
- Business outcome
- 1,006 orders carry a courier number today. Most shipments are domestic transfers with no public tracking at all, and the screen says so rather than pretending.
- What this is
- Lateness measured against the original ex-factory date, not the revised one. It's blank here because this rug has shipped.
- Why it exists
- Production revises the ex-factory date on their own schedule, so it moves. The original date never changes, which makes it the one number that honestly answers “how late was this against what we first promised?” The count stops once an order is done, because “today minus a fixed date” would otherwise keep growing forever.
- Business outcome
- A late order can't quietly become on time just because its date was moved.
Screen 03
You see nothing. Until you
say who you are.
The old tool showed everything to anyone it didn't recognise. This screen is the reverse, and it's what makes the reverse workable.
requested by N. Sharma DeclineApprove
- What this is
- Access is denied by default. A new account starts with zero visible orders and is sent straight here.
- Why it exists
- In the old tool, a typo or a new starter meant seeing every order in the company. In Atlas the database enforces the rules itself, not the browser. It starts from nothing and adds only what each grant allows. No screen can write to the orders table. The ERP sync is the only thing that can.
- Business outcome
- The failure mode flipped from “sees everything” to “sees nothing yet.” That's the safe direction to fail in.
- What this is
- People claim their own salesperson and customer codes, with no approval step.
- Why it exists
- Deny-by-default only works if claiming access is effortless. If every new user needed an admin, the tool would have died of tickets. The data isn't confidential between salespeople, so the approval step would have protected nothing. Each claim can only ever write to the caller's own account.
- Business outcome
- People are productive on day one without an admin: 43 salesperson codes and 238 customer codes claimed so far.
- What this is
- Joining a department records where you sit. It doesn't decide what you see.
- Why it exists
- Three real situations need three kinds of access. Production and management see everything. Salespeople see what they claim. The second brand's department brings a preset list of customer codes, and adding a code to it applies instantly to every member.
- Business outcome
- A whole brand was onboarded by editing one list, not every person in it.
- What this is
- People can ask for any of 180 ERP fields, one at a time, and an admin approves it.
- Why it exists
- All 180 fields were checked against the live ERP, and a change adding them all was written, then deliberately never run. The instruction was “no extra load on the database, only what someone actually asks for.” Approving records the decision; adding the field is still a deliberate step, because one click shouldn't reshape a live sync.
- Business outcome
- 45 fields sync today, up from the old feed's 34. The rest are one request away.
What changed
Answers got faster
than the phone.
The brief said it plainly: the goal was never new features. It was information flow. Most of the value comes from that alone.
Before · everything, to everyone
145MB
sent to every browser, on every login
A shared password printed in the page source. Filtering done in the browser, over data the browser already held in full. An unknown user saw the whole company.
After · one page, only yours
9.6ms
to serve it, with access checked in the database
Personal accounts. Filtering, paging and access control all happen on the server. An unrecognised user sees nothing until they claim their own codes.
The first real page load hit a database timeout. After one policy rewrite, it came back in 9.6 milliseconds.
| Before | After | |
|---|---|---|
| Signing in | Shared passwords, visible in page source | A personal account, with reset and change password |
| Data sent per login | ~120,000 rows · ~145MB | One server-filtered page |
| What an unknown user sees | Every order in the company | Nothing, until they claim their codes |
| When lateness shows up | After the date has passed | Projected stage by stage: 706 caught early on day one |
| First real page load | Database statement timeout | 9.6ms |
| Filter lists on each page load | Up to 33 sequential round trips | One query each |
| Dispatch visibility | The rug vanished from the feed | 6,074 dispatch dates · 1,006 courier numbers |
| Fields available | 34 | 45 synced, 180 requestable |
| Freshness | A public feed lagging the ERP | Read from the ERP database every 30 minutes |
In one walkthrough, production and back office agreed to trust Atlas's stage over each other's word.
No mandate made that happen. Both sides could finally point at the same stage, so they did. It's worth more than any usage number, and it raises the bar for everything underneath.
Try it
The day the old tool
would have found out.
Six orders, forty days. The old tool compares today with the due date. Atlas adds one rule, written down exactly as production said it: if today plus this stage's standard lands past the date, it's Late.
Late versus delayed
Drag the day, or press play. The orders are illustrative. The rule is the real one.
Old tool · flagged now
0Atlas · flagged now
0Architecture, for the people who ask
The ERP stays the source of truth; Atlas is its readable mirror. Every 30 minutes a job on a server inside the office network reads 45 columns from a 225-column ERP report, maps each raw status to a stage, and upserts into Postgres in batches. A stage entry is added only when an order's stage actually changes. Two follow-up passes add dispatch and courier facts from reports the main one doesn't contain. The ERP isn't reachable from the internet, so the job runs on the one machine that can reach it.
The job began as a serverless function. It hit the platform's compute ceiling, was rewritten to stream, and failed again twice at almost the same second. That repeatability was the tell: a fixed ceiling, not an inefficiency. So it moved to a plain script under cron, and has run on schedule since.
Access control lives in the database as row-level security, denied by default. Every write goes through a server function that re-checks permission itself. The rule that decides whether an order is Late exists in the browser, the alert job and the database. Before the Late tab was switched on, a script re-implemented it independently and compared every real order: zero mismatches across 13,739. Getting there took four fixes, including a date-boundary bug no code review would have caught. The tab stayed visibly disabled until it passed.
No AI decides anything here, on purpose. People make promises to customers about these dates. A standard that production wrote down can be checked and argued with. A model's estimate can't. AI was used heavily to build Atlas, including the scripts that verify it, but none runs inside it.
The ERP had to be measured before it could be trusted. The feed ignored its own filter parameters. The report is a snapshot rebuilt about every two hours, and querying it mid-rebuild fails outright. The “refreshable” upstream view turned out to be older than the snapshot. None of this was documented anywhere, and all of it now is.
The largest open problem is written down, not hidden. The ERP's item number was assumed to be unique per order line, and it isn't: one value covers up to 404 separate lines. A 79-line read-only diagnostic proved it, and the fix was escalated as a decision instead of quietly patching the symptom.
Next product
Weft
More conversations. Not more people.