SplitLedger

Overview

This started on a trip to Bir Billing. Five of us, four days — bike rentals, food, entry tickets, a hundred small purchases nobody wrote down because we were always halfway to the next thing.

Every night we'd get back to the hotel and try to reconstruct the day. Who paid for the bikes? Was that ₹400 lunch, or petrol? Logging it into Splitwise meant sitting through an ad between every expense — ten seconds, times thirty expenses, times four nights. None of us were buying Pro for one trip a year.

Then at the end, we wanted to see what we'd actually spent on food versus travel. There was no way to do it.

That's when I got curious. Was it just us, or was everyone quietly working around the same things?

I went in with a hunch, not a plan. Before designing anything, I wanted to know whether the friction we'd hit was specific to our trip or common enough to be worth solving.

Discovery

1. 01Find out how people actually track shared expenses — how they add bills, and how they organise them so the record still makes sense weeks later.To find out whether the pattern every app is priced against — logging as you pay — is what anybody actually does.
2. 02Go through the alternatives — the competing apps, and the notes, sheets, and chat threads people use instead — and find where each one breaks down.To find out what the category has already solved, and what people reach for when they skip it entirely.
3. 03Watch what actually happens to a group's tracking over a trip or a month. Does it fall apart? Is every group even trying to reach a final settle-up?To find out whether tracking really does fall apart, or whether that is only the easy thing to assume.
4. 04Find out how groups really pay each other back — over UPI, in cash, or by picking up the next bill instead. Apps assume settling is one clean action. Check whether it is.To find out whether settling is the one clean action every tracker models it as.

Definition

1. 05Identify what goes wrong for each kind of group — trip groups, flatmates, workplace groups, one-off event groups — rather than assuming they all want the same thing.To find out where each group is badly served before deciding what the product owes any of them — a workplace claim and a trip are not the same problem.
2. 06Turn the findings into a ranked list of problems, and say plainly what solving them would look like.To decide what to design and build for, and what would count as having built it.

Before asking anyone anything, I wanted to know what the category had already solved.

Partly to write better questions — you can't ask usefully about entry friction until you've walked the entry flows yourself. But mostly to avoid the most common failure in a project like this: treating a pain as an opportunity without checking whether other apps fixed it years ago. Four apps, audited against the objectives — Splitwise, Settle Up, Splid, and Google Pay's split feature — and beside them a shared note, because Objective 2Go through the alternatives — the competing apps, and the notes, sheets, and chat threads people use instead — and find where each one breaks down. says to audit what people use instead and 38 of 59 use exactly that.

Feature Matrix

Where Each One Breaks Down

The analysis told me what the category had already built. It could not tell me why people behave the way they do around it — whether the cap is why a group gives up halfway through a trip, or whether they would have drifted anyway; whether anyone actually wants the retrospective view that everybody paywalls. So the next thing was to ask, and to word each question carefully enough that it could come back with an answer I did not want. Four of the seven questions below came straight off that feature matrix. The other three came from the trip.

Research Questions

Seven questions. Each one is worded so that a boring or inconvenient answer still fits — if the only possible answer is the one I already expect, it isn’t a question, it’s a conclusion with a question mark on the end.

• Question 1 — What happens between paying for something and it showing up in the group's record?To find out whether the daily cap ever bites. A handful a day is plenty if people log as they pay, and punishing if they log a whole day at once.
• Question 2 — What do people do with a shared record after the spending stops?To find out whether anyone opens it again. Every app charges for the breakdown, which is only worth attacking if people actually want one.
• Question 3 — How does a group's tracking change over the course of a trip or a month?To find out whether tracking survives — without assuming it collapses, or that reaching a final settle-up was ever the goal.
• Question 4 — Who does the tracking work in a group, and how did it end up being them?To find out whether logging is one person's job rather than the group's. A product that assumes everyone logs is built for a group that does not exist.
• Question 5 — How does a balance turn into money that has actually moved?To find out whether settling is one clean action or something that happens outside the app entirely. Every tracker in the audit stops at a checkbox once the money moves outside it, and none of them can settle over UPI.
• Question 6 — What do people use besides these apps, and what makes them reach for it — or never reach for one at all?To find out what the real competitor is. If it turns out to be a note on someone's phone, then the thing to beat is not another tracker.
• Question 7 — What does a wrong number cost a group, beyond the money?To find out what people are actually protecting. The other six ask what people do; none of them ask what it costs when the number is wrong and nobody can explain it.

Survey

I ran the survey first, to reach more people quickly and turn the right respondents into interview leads — asking for a call at the end of a 30-second form gets far more yeses than emailing a stranger to ask for one.

What Came Back

• Logging is not a live activity. Two-thirds of adopters recorded expenses at the end of the day or later, or left it to someone else entirely. Only nine of the 42 logged as they paid — which is the behaviour every free tier in Competitor analysis is priced against.
• Most people already have a workaround. Thirty-eight of 59 had kept a shared expense somewhere other than an app — a note, a sheet, a WhatsApp message. Twenty-one of the adopters at Q12Have you ever used something outside an app — notes, sheet, WhatsApp — instead?, plus all seventeen on the branch, for whom it is the only method. That is the competitor, not Settle Up.
• Balances sit open, and it isn’t neglect. Thirty-four had let one sit unsettled for over a month, and eleven said their group never fully settles at all — not because paying up is hard, but because it doesn’t need to happen. Whoever is owed just gets picked up on the next round, so the group evens out in favours rather than in cash. Settling up is not the finish line the apps assume it is — except on a trip, where a fixed end date turns the same balance into something people really do square away before everyone goes home.
• People do want to look back at the record. Twenty-five had gone back to check what a group spent money on after the fact — what the trip cost per person, who paid for the hotel, whether food had blown the budget. The category view that answers the last of those is the thing Splitwise and Settle Up both paywall.
• Fourteen left an email. Six of them became the interviews below.

The Response Summary, Straight From the Form

Once the survey came back, I picked six people to interview — not the most enthusiastic responses, but the ones that spanned the widest range of habits: someone who logs an expense the moment it happens, someone who logs it days later, someone who’d quit a tracking app outright, and two who’d never installed one. That spread mattered more than enthusiasm, because five people who all track instantly would have told me nothing about why anyone else doesn’t.

Sequence (Why Survey and Interviews)

Survey first, to reach a lot of people. Then interviews, to explain the patterns the survey turned up — and the people I interviewed came straight out of Q15Willing to do a 20-minute call?. That order worked because the open-ended part had already happened by itself: I started from a problem I had lived through, so the survey only had to check whether it was just us, and the interviews only had to explain why.

Three of these are the trip. The research did not find them — it checked whether everyone else hit the same three, against 59 survey responses, six interviews, store reviews and the four apps in Competitor analysis. The other three are what it added, and two of them nobody raised without being asked, which is the best argument for having run it. Six, in order of weight — and the order matters more than the list.

• 01

  From the trip

  An ad between every entry

  The loudest thing in the research, by a clear margin. Splitwise caps free entry at a handful a day — its help page says four, testers report anywhere from two to five, and these sessions hit five — with a ~10-second interstitial between them, which is a tax on the one pattern everybody has: logging in a batch at the end of a day. The workaround costs more than the cap does: people merge two or three same-day purchases into one line to stay under it, which quietly corrupts the very ledger the app exists to keep accurate. Thirty expenses over four nights was the trip; nobody was buying Pro for one trip a year.

• 02

  From the trip

  The day gets rebuilt from memory

  Nobody logs as they pay. Two-thirds of adopters record at the end of the day or later, or leave it to someone else, and the reasons vary — the app is slow to open, somebody else handles it, it is easier to do the whole day at once. What they share is a shape: logging competes with whatever you are actually doing, and loses. So the record is reconstructed hours later — was that ₹400 lunch, or petrol — and reconstruction is where it starts going wrong.

• 03

  Everyone has to install and sign up

  This one goes back years before the paywall. The organiser drops the app entirely rather than chase four friends to sign up — the only barrier the non-adopter branch names that a product can do anything about; the rest never considered an app at all, which is its own answer. Seventeen of the 59 took that branch, and thirty-eight in all had kept a shared expense in a note, a sheet or a chat thread instead — the workaround is the category's real competitor.

• 04

  Settling happens somewhere else

  Pay by UPI, come back, tick a box. Nobody raised this on their own, and eleven said their group never fully settles at all — and those two facts are really the same fact. It isn't neglect, it's give and take: whoever is owed just gets picked up on the next round, so the group evens out in favours rather than in cash. A trip is the exception, where a fixed end date forces a real settlement. Either way, no tracker in the audit records that kind of settling, so a balance that is completely fine looks, to the app, exactly like one nobody bothered to close.

• 05

  From the trip

  No way to see where the money went

  The question that ended the trip: what did we actually spend on food versus travel. There was no way to answer it. Twenty-five people had gone looking for the same thing after the fact, and on Splitwise the breakdown and the history search both sit behind Pro.

• 06

  The balance nobody can explain

  Quieter in reviews, louder in interviews — and the only pain that is social before it is functional. Debt simplification rewrites who owes whom with no indication it happened, so one person ends up defending a figure they did not compute and cannot show. Nobody settles that argument in the ledger. Twenty-five of 42 message or call whoever added the expense and nineteen ask in the app's comment thread, against six who work it out themselves — which is the tell: the record cannot answer the question it caused.

Definition

Six pains, but not six problems. They collapse into three — and the order matters more than the grouping: you can't fix the second or third problem until the first one is fixed. A ledger nobody finished filling in cannot answer questions, and a group that never came together has nothing to settle.

Three Problems, in Order

What Would Count as Solving It

Targets, not results — there is nothing built yet to measure. Each one is settled by re-running the usability protocol against the finished build and comparing it to the figures Splitwise already posted, so the bar is something observed rather than something chosen.

Definition

Four roles, sorted by what people do rather than who they are. What changes from person to person is who does the work — and the three problems in What to build do not land one to a role. The organiser carries Problem 1 and Problem 2 at once, the hold-out is the half of Problem 1 no screen can reach, and Problem 3 lands on whoever is owed, which on most weekends is nobody in particular. That uneven spread is why the roles are worth naming separately.

The Anti-Persona

Naming the person this is not for is the useful part. It rules out three features that would otherwise look obviously worth building.

Exploration

With the model settled, the questions left were about structure, not looks — and paper answers those faster than a grid does. Twenty-six sketches, and the ones worth showing are the ones that settled an argument: paper is where the shape of the ledger got decided — what a group is, whether someone needs an account before they can owe money, and where a balance comes from. Four of them below; the rest work through the same set screen by screen.

Some Key Screens

Overview

• •One number is a summary, three are a situation — the net position, and what it is made of.
• •Logging starts before you decide to log. Scanned payments wait at the top, already captured.
• •That section hides itself when empty, so it costs nothing on a quiet day.

Add Expense

• •No more form-like look — a sentence, not a form.
• •Two decisions: a name and a number. Five things pre-filled.
• •The split is visible where you type it, not one screen later.

Import from Splitwise

• •Replays expenses and settlements to rebuild balances — the arithmetic comes over, not just the totals.
• •Friends come across too, including people you only split with outside a group. A ledger without its people is a spreadsheet.

Import from Splitwise

• •Opens with the reassurance, not the algorithm — nothing invented, same amounts, fewer payments.
• •The rule is written so you can redo it yourself, not named and left opaque.
• •Every step shows what is left over — the residue is why the next payment looks odd.

Exploration

With the brainstorming done, the next step was low-fidelity wireframes for the main flows, and for the problems each one had to solve — the same screens, committed to a grid. Structure before surface — this stage is where the hierarchy of every screen was fixed.

Some Key Flows

FLOW 1

A Layout You Pick, Not a Form

Problem 1 is mostly this flow. Three steps — the first asks the question every other app asks last, and the last is a layout the user chooses.

Search leads, because a year in you have a dozen groups and picking one is a find, not a scroll.

An expense does not need a group. Splitting straight with a person is a path, not a fallback.

A name is enough to add someone. The email is optional, which is what lets a hold-out owe money without an account.

Search sits above the list because a shared flat has five members and a trip has twenty, and only one of those is a scroll.

A member with no account is an ordinary row — muted, but selectable. The hold-out from Personas can owe money without installing anything.

Everyone is included to begin with and the count is stated, so the common case is read rather than assembled.

Amount and note are the only two things this expense actually needs, and both are words in the line.

Payer, split and date come already filled in — the common case is written out rather than left to be assembled.

The per-person shares recompute under the sentence as each word changes, so the split is checked where it is set.

Two Layouts, and the User Picks

Half of Problem 1 is this one screen. The record never gets finished because entry is where it stops — and what stops it is a form. Six labelled fields to read and fill, for an expense that is nearly always the same one. So entry was not designed as a form. It was designed twice, as two layouts that each ask to be read in one pass rather than filled in six: a receipt, where every row already shows its value, against a sentence, where only the words you want to change are targets.

A ticket, not a form. The tear-line separates what the expense is from how it gets divided.

Four rows, each already showing its value. The eye stops at all of them whether or not any needed changing.

Your share and the itemised split print below the rows, so the consequence sits on the same ticket as the inputs.

The instruction is on the screen, because a sentence built out of controls is not a pattern anyone has met before.

Every changeable word is underlined and tappable. Reading the expense and editing it are the same act.

Date and split sit in the sentence rather than behind a default, so a wrong one is read now instead of found later.

	Receipt	Sentence
Reading order	Label left, value right, row by row. The eye stops at every row whether or not it needs to.	One sentence. Only the words you want to change are targets, so a default expense is read in one pass.
The common case	Six fields for an expense that is nearly always “I paid, split equally, today”.	Those three are already the default text. Changing nothing is a complete entry.
A backlog of ten	Sixty field visits, and the moment of abandonment is somewhere in the middle.	Ten sentences, most of them needing two edits — the amount and the label.
Discoverability	Every option is visible, which is the honest advantage and the reason this was hard to reject.	Options are inside the sentence, so nothing announces that “split equally” can be changed.
The live readout	Prints below the rows on the same ticket, and reads as confirmation of what you set.	Sits below a sentence and reads as the consequence of it, recomputing as each word changes.

The sentence is the default, because Task 3You forgot yesterday entirely. Log five expenses from yesterday now. is the case that matters most and the one the sentence wins. The receipt is better for a first expense and worse for the tenth, and the pains arrive in a pile. A layout optimised for the entry you are most likely to abandon beats one optimised for the entry you are most likely to understand.

The receipt stayed anyway, because its advantage is not taste. Nothing about the words split equally announces that they can be tapped, so a first-time user can finish an expense without ever learning anything else was possible. For someone who never gets past that, the sentence is not a faster form — it is a form with hidden fields. So both ship, and neither is imposed: Account carries an Add expense layout switch, and the choice is remembered on the device.

The layouts are shown, not listed. Choosing between two entry screens is a visual comparison, so the screen makes it one.

The neighbours stay in view. You are picking between things you can see rather than committing to a word you have to imagine.

Applying is one tap, and it is reversible. Nobody has to be right about this the first time.

FLOW 2

Entry when the day has piled up

The case the free tier is priced against: ten expenses waiting, logged at the hotel that night rather than as they happened.

One number is a summary. Three are a situation — the net, and what it is made of.

Scanned payments queue here already captured. Filing one is a tap, not re-entry — the step people fail.

Expenses with no group live in the ledger too, so nothing waits on a group being made first.

The date is a word in the sentence, not a silent today. A backlog is entered days after it happened, by definition.

Two edits per expense — the amount and the label. Ten of them is twenty taps, not sixty field visits.

Shares always sum to the total exactly, so a stack entered in one sitting never has to be reconciled afterwards.

What the Readout Is For

Under the entry, a line per person recomputes as you edit. It exists because a balance here is computed from the expenses rather than stored: if a number is derived, the cheapest place to prove it is trustworthy is the moment it changes. The alternative — enter, save, then go and look — separates the edit from its consequence by a screen, which is where “wait, why do I owe that?” comes from.

What the Entry Asks For Is Per Group

A trip splits food, travel and tickets; a flat splits rent, groceries and the internet bill — an entry tuned for one reads as friction on the other. Which fields it exposes, what counts as a category, and which of them defaults to split equally are set per group rather than fixed in the model. Nobody in five sessions was asked to customise anything, so this is a design decision rather than a finding. It stays because deriving balances makes it cheap: a field’s label is never baked into a stored number, so exposing the choice costs a settings screen and not a change to the model underneath.

FLOW 3

Joining Without Installing

Problem 1's other half. A member has to be able to owe money before they have an account, or the organiser ends up logging for everyone.

A name is enough. Everything below it is optional.

People already in your ledger are one tap, whether or not they ever signed up.

Add anyway, no email. This is the line the whole flow exists for — the hold-out becomes a member owing real money, with no account.

A link that can be copied anywhere, because the invite has to travel on WhatsApp — which is where the group already is.

Picking a known friend is the second path, not the first: most invites go to people the app has never seen.

Sending changes nothing in the ledger. The member is already in it; this only offers them an account.

What you are joining is shown before you commit — how big it is, how much history it has, and who asked.

Joining claims a member who already exists, so nothing anyone entered has to be typed again.

Declining is on the screen as a real choice, and the group’s ledger is unaffected either way.

A Member Before an Account

The other half of Problem 1: a group that never fully comes together. Two ways in, and neither asks the group to start over — a member can be in the ledger without an account, and an existing Splitwise group can arrive with its history intact. Both are above. What is left is the group that has neither.

A name is the only required field. Everything else about a group can arrive after it exists.

People can be added now or later, and the screen says so — waiting on replies is what stops a group being made at all.

A group of one is legal, and is labelled rather than treated as a mistake. The organiser starts before anyone has agreed to anything.

FLOW 4

Explaining the Number

Problem 2. The number has to be defensible by the person showing it, not just correct.

Every row carries what was paid and what was owed, so the net can be re-derived by hand.

Each transfer names the rule that produced it rather than asserting a figure — which is exactly what debt simplification does not do.

The full working is one tap away, not a paid feature.

Problem 2, and it is a social problem before a functional one. Somebody has to defend the number — usually the organiser, usually to a friend, usually without having computed it themselves. So every balance can be unpacked into the expenses that made it.

Simplify Debts, and Why It Is Visible Here

Pain points, ranked put confusion over debt simplification last of the six, and it is the only pain that is social before it is functional: users do not know whether simplification is on, who turned it on, or why they are suddenly owed nothing. The failure is not the algorithm, it is that the algorithm is silent. Deriving a balance rather than storing it is what lets this be fixed cheaply — because nothing is stored, the original and the simplified view are both derivable, so the app can show the transfer it is proposing alongside the debts it replaces instead of quietly rewriting them.

Task 7Find out why you owe what you owe. Show me what makes up that number. exists for this specifically, and it came out of interviews where two participants independently described needing to justify a number to someone else. That is the behaviour these screens are for: showing what a balance is made of, to whoever is asking.

Spend, Not Just Balance

The charts answer a different question from the balance breakdown: not what do I owe, but where did the money go — by category, per group. Task 6Find out how much the group has spent on food so far. tested it directly, and zero of five could do it, at 18 taps. It belongs with this flow because it answers the same problem from the other side: a group that can defend a number should also be able to ask it a question, not only account for it after the fact.

The total sits inside the chart, so the summary and its breakdown are one object rather than a figure to trust and a picture beside it.

By member, because the question at the end of a trip is who spent what — not which category won.

By month as well, for the ledgers that have no end date the way a trip does.

Who paid, and what it did to you, in one line above the arithmetic that produced it.

The split is listed per person rather than named by a rule, so a share can be checked without knowing what “equally” resolved to.

Who added it, and when. Most arguments about an expense turn out to be arguments about who entered it.

FLOW 5

Settling Up

Problem 3. Every tracker in the audit stops at a checkbox once the money moves outside it; this is the flow that does not.

Settle up sits beside the balance it clears, at the top of the group.

Balances are per person and derived on demand, so there is no stored total that can disagree with the expenses below.

Settled is a state, not a deletion — the history stays where it is.

The rows are the fewest transfers that clear the group, offered as a suggestion rather than applied to the ledger behind you.

The amount is editable and pre-filled to the full figure. Part-payments happen, and refusing to record them is what sends the group back to chat.

Paying and recording are one action, not a checkbox ticked after the money moved somewhere else.

Problem 3, and the one thing no tracker in Competitor analysis does. Paying and recording are one action, over UPI — for the balances that get paid off in cash at all. Most do not: whoever is owed gets picked up on the next round instead, and give and take, not a checkbox, is what settles it.

What Happens When the Payment Fails

The interesting half of paying and recording in one action. It is only an improvement if a failed payment leaves the ledger correct — otherwise the app has invented a debt that was never settled, which is worse than the checkbox it replaced. So the write is conditional on the payment, never optimistic, and a partial settlement stays a partial settlement rather than rounding itself away. Holding money as an integer count of paise is what makes that expressible: a half-settled balance is exact rather than nearly right.

Where this stops. UPI is India-only, which is the whole bet. The gap is narrower than “nobody does UPI”, though: Competitor analysis scores Google Pay a yes on UPI-native settlement and then files it under “moves money, keeps no record”. What no audited product does is settle over UPI and keep the ledger, and that narrower gap is what made it Problem 3. It is also a ceiling — the same product outside India loses its one structural advantage and becomes another tracker with a good expense editor.

The Personal Ledger Inside the Group One

Non-group expenses are the same ledger with no group attached — a coffee that was never anyone else’s business, tracked the same way as a split dinner rather than living in a second app. Nothing in the survey, the interviews, or the audit asked for this directly; it exists because a member who opens the app only to check a shared balance still has spending of their own, and a separate app for that spending is the install-and-sign-up tax Pain points, ranked put third — aimed at yourself this time.

One figure for the whole relationship, because what you owe a person is not divided up by where it happened.

Groups are a breakdown here rather than the top level. It is the same ledger, read along the other axis.

Direct expenses sit beside group ones. Splitting a coffee with somebody is not a lesser kind of debt.

Groupless spending gets a total of its own, so it is a place in the app rather than a residue of one.

People first, because a debt with no group is still a debt with a person.

Part-settled is a state these expenses can hold too — nothing here is a cut-down version of the group case.

“No group” is stated rather than left blank — the same detail view, with one field different.

Deleting a settlement says what it will do to the balances, because that is the consequence nobody can see.

Partial settlement is carried as a state rather than rounded away, so the outstanding half stays visible.

Undoing a Delete

Activity is the record of what changed — and the gap it exposes is that “what changed” includes deletions nobody meant to make. A ledger several people write to has exactly one failure worse than a wrong number: a missing one, gone before anyone else notices it is missing.

Not measured, and not a ranked pain — none of the six interviews described losing an expense, because nobody had used a version of this product long enough to lose one. It is in the design on the same reasoning as a derived balance: a deletion is marked and held rather than removed from the ledger outright, so recovering one is showing a row that was already there, not reconstructing a number that got recomputed without it.

Every row names who did it, in which group, and when. A shared ledger is auditable or it is argued over.

Undo lives on the event itself, so reversing something does not first mean finding where it was done.

Even a deleted group is an entry that can be restored. Nothing that touched the money is silently gone.

The deleted expense is still a row in the feed. Restoring starts from the record of the deletion, not from a bin kept somewhere else.

The dialog names the expense rather than asking about “this item”, so answering it does not depend on remembering which row was tapped.

One confirm and it is back in the balances. Nothing is rebuilt — the row was held, so this only stops it being deleted.

FLOW 6

Leaving Splitwise

The leaver's on-ramp. They already rejected the category once; their history is the only thing keeping them where they are.

Non-users arrive as ghosts, so a group comes across whole even when only one person moved.

Balances are reconstructed by replaying the expenses, not copied across as totals.

Friends come too, including people you only ever split with outside a group.

Everything is ticked to start with, so the default is a complete move and not a decision.

Any group can be left behind. Leaving an app is easier when it is not all or nothing.

Friends and non-group expenses come across too — the parts kept outside groups are the ones people forget they will lose.

Why the Import Exists

Read the feature matrix down the Splitwise column and it scores one clear win, a persistent group ledger, which Settle Up and Splid both match. Nothing Splitwise does is unavailable elsewhere. Why it leads anyway is an inference and not a finding — the audit never measured installed base — but the likeliest answer is the history already sitting in it, and if that is right the barrier is switching cost rather than capability. An import is the cheapest possible attack on that, and it is why the flow gets its own screens rather than a settings toggle.

The dependency this accepts. The import is built on Splitwise’s own API, so it can be withdrawn by the company it competes with. Worth building anyway — the value is highest early, when switching cost is the whole objection — but a feature that depends on a competitor’s goodwill is not something to build a defence on.

The one screen where the product waits on somebody else's server, so it is drawn as a wait rather than hidden behind one.

It names what is happening: the handshake is with the leaver's own Splitwise account, not a new one.

Both failure states are drawn, because the only dependency on a competitor is also the only step that can fail for reasons this product cannot fix.

One line, and it names the thing being replaced. Whoever reaches this screen was convinced by the app, not by this page.

Two ways in and no password. An account is for syncing across devices, not for permission to use the ledger.

A magic link exists because the whole product is designed around people who will not install or sign up on request.

Foundation

With the wireframes tested and the structure settled, the next thing was not another screen — it was the vocabulary every screen would be built from. Colour, type, radius, spacing and the component masters, defined once and bound to code.

One thing the file admits about itself, and it is worth repeating here rather than leaving on a plate nobody zooms into: the app declares Manrope but only three components actually consume fontFamily, so the shipped build still renders in the platform default. The ramp is real and the tokens are bound; the wiring is not finished. A system page that showed only what works would be a brochure.

What the argument above turned into. The screens are built out of the system in the section before this one — every colour, every radius and every component on them is a token rather than a decision made twice.

The Rest of the Set

Eight of the twenty-six screens, picked for what they settle rather than for variety — the four above carry the features, these carry the arguments. Not all twenty-six, because a gallery that shows everything is a file browser: what is left out is the states and the empty views, which matter to build and not to read.

Light and Dark

The design system holds twenty-three colours, each with a light and a dark value on the same name. That is the claim; this is the check. Every one of the twenty-six screens has a dark twin, and none of them is a second design — the same components resolve the same tokens against the other mode. Four pairs here, picked for the surfaces hardest to carry across: the gradient banner, the form surfaces, and the plain lists that have nowhere to hide.