How this site was built
ArteyuLabs sells Excel workbooks that work, so the site is built like one. These are the design notes, including the parts that failed.
The concept
The site is the workbook: every page a sheet, every number a live cell, every claim a formula you can inspect.
The previous version referenced a spreadsheet — a formula bar here, sheet tabs there — sitting on a conventional marketing layout. This one tries to be one. The difference shows most in two places: the white cell in the hero that genuinely takes typing, and the inventory sheet that replaced a wall of 48 cards.
Colour
Every pair below was measured against the real composited background, not eyeballed. Anything under 4.5:1 for small text does not ship.
A trap documented from the start: deep gold on cream is only 2.4:1. It still slipped into one small seal, and only the automated audit caught it.
Typography
Two typefaces only. Plus Jakarta Sans for the voice, JetBrains Mono for the data. The rule is simple: if it is a claim or a feeling it is Jakarta; if it is a fact or furniture it is mono. You should be able to squint and know which parts of the page are data.
The audit found twelve of thirteen routes sharing one flat 32px h1. Every route now opens at 49.6px, and only the homepage gets 66.4px.
Motion
Six named behaviours. Any animation that cannot be named as one of them is not allowed. The Malay names are not decoration — they force each movement to explain itself.
The hardest rule: text is never rendered at partial opacity. That holds for the resting state and for every frame of every animation.
That rule came out of a real bug. The old design held ladder rows at 0.25 opacity while waiting for a scroll observer, so body text composited to roughly 1.35:1. It failed the contrast audit, and that was why the accessibility score sat at 96.
The phone
The phone version used to be the desktop reflowed into one column. Measured at 320px: the typeable dashboard fell entirely below the first screen, the labels inside it shrank to 8.3px, and the main menu sat in the top-right corner — the hardest place on a phone for a thumb to reach.
Now the phone follows what Excel on a phone does. The sheet tabs move to the bottom, inside thumb reach. Each chapter carries a name box that sticks to the top, so you always know which part you are reading. The ledger's header row freezes the way freeze panes does — desktop does not even have that. The dashboard moves up: you watch the machine work before you need to scroll.
Performance
Two runtime dependencies: react and react-dom. No Tailwind, no animation library, no WebGL. Those are all fine techniques. The buyer here is just on a mid-range Android phone on 4G, and anyone can look impressive with a GPU and 800KB of JavaScript.
The biggest win was not in JavaScript. The homepage was layout-bound, not script-bound: 1,225ms of style and layout against 259ms of script. Replacing the 48-card grid with an inventory sheet cut the page from 10,646px to under 6,500px and took Speed Index from 4.5s to 3.1s.
All figures measured on 11 Ogos 2026 with mobile Lighthouse against the real build.
What we cut
A guide claiming everything went smoothly is useless. Here is what failed, and why.
A row-number rail down the phone's edge
The A·B·C·D column ruler genuinely does not work on a phone, so the plan was to replace it with row numbers down the left edge. On paper it was already two things doing one job: the sticky name box tells you where you are. And row numbers over paragraphs are not real numbers — they would be invented, which is the one thing we do not do. The rail was never written; the name box stayed.
A swipeable KPI row in the hero
The original plan: the three KPI cells become one row you swipe sideways, the way you scroll columns in Excel on a phone. Before it got written, we saw it would break the only thing the hero exists to show — you type in Jualan and Untung changes. On a swipe rail, Untung would be off-screen at the exact moment it changes. So the KPIs became a column of cells read downward instead. A phone is one column; that is the more literal reading, and it is the one that works.
Clickable sheet tabs in the hero
The STOK and INVOIS tabs were meant to switch mini-panels. That needs sample rows from those sheets, and the repo's data files do not carry them. Inventing rows would break our own rule, so the strip was redrawn as furniture: only DASHBOARD reads as a tab, and the rest sit flat so they read as labels.
A WebGL layer for spectacle
The brief allowed one for capable devices, and it went unused. Every hero moment here is an idea rather than a graphic: the cell computes, the ledger fills, the figures name their source files. None of that needs a GPU. We had budget left over and left it unspent, because adding a heavy effect to prove we could would only be decoration.
Page transitions — nearly missed
BUKA was named in the constitution, ticked off on the checklist, and never actually built. Only the third critique pass caught it. The cost was ten lines of CSS and zero JavaScript.
What is still unfinished
- The phone import test for the Excel files has not been run — stated on every product page rather than hidden.
- Twenty-one of the 25 printable series are still covers only. The Studio page orders them by real status, not by which look best.
- Nineteen of the 20 systems are not open for sale. None can be bought before it can genuinely be delivered.