Software should earn its keep
A demo shows you the first time you use something. Real work is the hundredth. Almost every decision that determines whether a tool is worth keeping is invisible in the first and decisive in the hundredth.
That gap has a name in our heads: demo-ware. Software that earns attention without earning its keep.
What the demo structurally cannot show
The problem with optimising for demonstrations is not that demos are dishonest. Most are not. It is that the format selects, and it selects against exactly the properties that make a tool survivable.
Demos reward breadth, novelty and visual fluency. They punish depth, consistency, and the invisible competence of something that works without announcing that it worked. A live demonstration never shows what happens when a task is long, or ambiguous, or half-finished at the end of a day and picked up cold on Monday. It never shows the second time you use a feature, let alone the twentieth. It never shows the case where the input was messy, because nobody demos with messy input.
So the selection pressure runs the wrong way. Features that look impressive in a screen recording get built. Features that would let you finish a real task on a difficult Tuesday afternoon end up in the settings menu, or nowhere.
The gap between output and finished
Producing output is not the hard part any more. Finishing is.
A tool can produce a draft. Finishing the draft means it is accurate, attributed, scoped correctly, and in a form a colleague can act on without asking you three questions first. A tool can surface a data point. Finishing the analysis means the point sits in context, the contradictions are visible rather than averaged away, and the conclusion holds up when someone pushes on it.
This is where most AI tooling stops. It gets you to a promising state and hands you a half-built thing, and the last mile — the part that is tedious, specific, and entirely yours — is where the majority of the actual effort still lives. The tool's contribution is genuinely impressive. It is also front-loaded, and the work is back-loaded, and those two facts together explain why so many people describe these tools as remarkable and use them for nothing important.
We think about that last mile more than anything else. Not out of pessimism about what the technology can do, but because a tool that helps you close the gap is categorically more useful than one that opens it with a flourish and leaves.
The metric we tried and threw out
The obvious way to hold yourself to this is to measure it, so we tried to.
We tried counting task completion. Did the session end with something the user kept? It is the right question and the measurement is close to useless, because the signal is unattributable in both directions. A session that ends without a saved artefact might be a failure, or might be someone who got the one number they came for and left satisfied. A session that ends with a saved artefact might be success, or might be someone saving a half-finished thing to fix later somewhere else. We were reading the tea leaves of our own product and calling it evidence.
We tried satisfaction prompts. Ask the user. This fails differently and worse: the people who answer are the delighted and the furious, the great mass of mild disappointment never responds at all, and mild disappointment is the entire phenomenon this note is about. Nobody files a complaint about a tool that was fine.
What we settled on is cruder and holds up better: would we hand this output to someone who did not know it was generated? It is a judgement, not a metric. It does not aggregate, it does not go on a dashboard, and it cannot be gamed by improving a number. We have not found anything better, and we are suspicious of anyone who claims to have.
Reliability does not photograph well
There is a class of properties that make software trustworthy and essentially never appear in a launch: consistent formatting across a hundred uses. Citations that land on the right sentence. Behaviour on the fiftieth run that matches the fifth. Output you can pass on without a disclaimer attached.
None of these are interesting to write about. None of them produce a reaction in a room. They are the entire difference between a tool someone uses every day and a tool someone uses once, admires, and puts down.
So when we decide what to build and what to leave out, the question is a version of the same one: does this help someone finish something? Not "does this expand what askFinz can claim to do", and not "does this make the product look more sophisticated". Does it help you close the tab, confident the work is done?
Where this principle bites us
"Does it help someone finish" is conservative, and conservatism has a cost. The question is very good at rejecting things and quite bad at proposing them. Held too strictly it would have blocked most genuinely new capability, because a new capability rarely helps anyone finish anything on day one — it helps once there is a workflow around it, and the workflow cannot exist first. We have almost certainly said no to things we should have explored, and the failure mode of this note's philosophy is a tool that is dependable and slightly behind.
Boring is a real product risk. A tool that invests everything in the hundredth use is, by construction, underwhelming on the first — and the first is when people decide. We are not going to pretend that is a comfortable position or that we have solved it. It is a bet that the population who stay is worth more than the population who look.
What we would do differently
We would have looked at the hundredth run before we polished the first.
Everything about how software gets built pushes attention to the beginning: the first screen, the first session, the empty state, the onboarding. Those are the parts that get reviewed, screenshotted and iterated. The behaviour of a workspace that has been in continuous use for months — accumulated material, half-finished threads, things named badly in a hurry, the specific mess of a tool that is actually being used — is the condition almost every real user is in, and it is the condition we looked at last, because it is the hardest to simulate and the least rewarding to demo.
If we were starting again we would build the messy, months-old workspace first and design backwards from it. Everything upstream of that would have to justify itself against how it looks after a hundred uses, not after one.
The right relationship is not: the tool is impressive and you are the audience. It is: you have something to accomplish and the tool is genuinely useful in accomplishing it.
Explore what the platform looks like in practice.