Athanor: what we built when nobody updated the Monday.com board

Our Monday.com board only worked if somebody kept the status column up to date, and nobody ever did. We built our own instead, over 29 working days spread across a summer. It now reads the bank, the diary, the inbox and the proposals out for signature. It also plans a week of training and the food to go with it.

Every screenshot on this page uses invented sample data. The real thing carries our bank balance and our clients, so it does not get photographed.

The outcome

Athanor is the studio dashboard. It answers one question: what is the state of the business today. It answers it in a written sentence rather than a wall of tiles. Behind that sit the task board, a client directory, the money, the diary, the inbox, the proposals out for signature and the week ahead. It runs on two deployed instances, one for each of us, and it also plans a training week and the food to go with it.

Click to enlarge

The challenge

The honest version of why the Monday board failed is that it asked us for maintenance and gave nothing back until we provided it. A status column is only useful once every row is current, and a two person studio in the middle of a delivery week does not stop to mark things In Progress. So the board drifted, then it lied, then we ignored it.

Answer what the state of Alchemy is today in one screen, and make sure nothing slips silently.

That is the line we wrote at the top of the product notes, and it set the rule for everything after it. A tool you have to feed is a tool you will abandon. The dashboard had to arrive already knowing.

Our approach

Make the software do the typing. Almost nothing on the dashboard is entered by hand. The money comes from the bank and the accounts, the diary and the inbox come from Google, the proposals come from the tool we send them with. What is left for a human is a single capture box at the top for the thing you just thought of, which is the only kind of input anybody reliably gives a system.

Click to enlarge

Say how old every reading is. Every card names its source and how stale it is, and an old one steps its figures back rather than presenting them as current. This is the rule the whole thing hangs on. A dashboard that shows a number without saying when it was true is worse than no dashboard, because you will act on it.

Click to enlarge

Colour one thing only. There is a single accent in the entire interface and it means one thing: on the clock. Nothing is coloured for decoration, and money is never coloured at all. The rule we wrote for ourselves is to colour the age, never the amount, because a large invoice is not a problem and a small one that is 60 days late is.

Keep the keys out of the app. Athanor holds no Google or accounting credentials. The syncs are run by Claude Code, which already holds those connections, and it posts into a single endpoint that deduplicates on the source and its own record id. So the app can be small and dumb about authentication, and losing it loses nothing.

Click to enlarge

Two people, two instances, one bridge. Jess runs her own copy with her own database. Neither instance can read the other's tasks directly. A task is handed over by one server calling the other, and it leaves the sender's board when it lands on the receiver's. The money and the calendar go to both.

Two dependencies. The whole application depends on two npm packages. The database is the one built into Node, so there is nothing to compile, which matters because this machine has no native build tools. Even the ZIP reader for the health exports is about a hundred lines of our own code on top of Node's zlib rather than another dependency. It runs on a 256MB machine in London and costs almost nothing.

The part that plans the week

This began as a personal indulgence and turned into the most interesting thing in the app. Athanor writes a training week, adapts it to what the body actually did, and then plans seven days of food and a shopping list to match.

Let the week read the body, not the calendar. Workout, heart rate, sleep and variability data comes out of Apple Health as export archives that land in a synced folder. Rowing and bike pieces come from the Concept2 logbook over its API, and since a change made in September they arrive by webhook within seconds of the handle being put down rather than waiting for the weekly run.

Rules propose, guardrails dispose. Seven rules read the week, and only the first one that matches fires. Resting heart rate 5 beats above its own 28 day baseline, heart rate variability 15 per cent below it, sleep under 6 hours, or adherence under 50 per cent: any one of those forces an easier week. Adherence between 50 and 80 per cent holds the volume where it is instead of trying to catch up. More than 30 per cent of easy running above 140 beats per minute, two weeks running, turns the next long run into a time based effort with walking allowed.

Then come the guardrails, which no rule can cross. Running volume never grows by more than 10 per cent. Never more than two hard erg sessions in a week. Race week cannot be touched for any reason at all, including a red flag.

The guardrail that taught us the most was the volume cap. It originally measured growth against the previous week, so one disrupted week dragged the ceiling down and kept it down for most of the block. It now measures against the best of the last four weeks, which is the difference between a limit and a ratchet.

Count honestly or do not count. Adherence ignores walks, because walking most days would otherwise score a perfect week in a week with no training in it. Where a figure cannot be derived from real data, the app records it as missing and names it in the report. It never estimates to fill a gap, which is the staleness rule again, pointed at a different subject.

Feed the day the training asks for. Every day in the plan carries a load, and the load changes the shape of the food as well as the amount. On a rest day the pre and post training slots disappear, breakfast grows, dinner shrinks, and a protein top up goes in at the end. Calories come down, protein holds. The menu is drawn from a library of 38 recipes, each written so it can be cooked from cold without a decision.

Click to enlarge

Click to enlarge

Finish the job at the shop. The plan turns into an aisle ordered shopping list with prices, on its own installable phone app so it can be ticked off in the supermarket. It works to a budget with a reference figure and a ceiling, and it will not cross the ceiling without saying so.

Click to enlarge

What it does for Alchemy

The thing we set out to build, a better board, turned out to be the least important part. In August we retired the clients, projects and finance sections we had carefully built in July, because once the dashboard existed nobody opened them. That is the honest outcome: we replaced a tool nobody updated with a tool nobody has to, and the parts that still needed feeding got deleted.

What is left is a screen that tells us what is late, what is owed, what is unsigned and what is happening today, without either of us maintaining it. It also plans the training and buys the food. Two dependencies, and one rule: never show a number without saying when it was true. That rule is the part we would take into any client project.

Credits

• Client: Alchemy, internal
• Studio: Alchemy
• Built: 2 July to 8 September 2026, across 29 working days and 122 commits
• Build: Node, Express, SQLite through Node's built in driver, deployed on Fly.io in London
• Typefaces: Mackinac for the things the eye should land on, Satoshi for everything else
• Data sources: bank, accounts, calendar, mail, proposals, Apple Health and the Concept2 logbook
• Status: private and password protected, so there is nothing to link to