Say what works today

A beta wants to look finished

A beta goes live before the product is finished, and that's when it's tempting to make it look finished. The landing page has to convince, and a feature that isn't built yet can pass for one that is, at least in a screenshot. My rule runs the other way: say what works today, say what doesn't yet, and say both on the product's own pages, next to the thing itself.

ONEbasket is one of the client builds on my Portfolio, and in its beta sprint I built the landing at onebasket.ai and Baski, the AI helper on it. The hero reads "Introducing the beta", and further down the page draws the line: "Saving and price tracking work today. Sorting that organises itself and a nudge for when to buy are on the way." One sentence for now, one for later.

Put the label next to the thing

A roadmap tells people what's planned; a mark beside a button tells them whether it works before they press it.

ONEbasket's hero offers its modes as a group of native radio buttons, the browser's own form controls: Ask, Save link, Search, Trending and Agentic, with Save link chosen by default. Search, Trending and Agentic each carry a small clock icon labelled "Coming soon". The design and the markup do the same job: the status sits inside the control people use, not on a page they'd have to go looking for.

The method section works the same way. Of its four steps (Read, Normalise, Match and Re-read), Match is tagged "Coming soon", and Re-read says it runs once a week, for the products you saved. The FAQ keeps the tag on its question about price alerts, then says what happens today instead: every product in your basket is re-read each week.

The answer about data has the line I'd want in every beta: "Exporting or deleting everything from one screen is coming soon; until then, email us … and we will do it for you." The screen isn't there yet, so the page names another way to get the same result, and nobody has to wait for it.

Let the assistant state its limits

An assistant needs the same plainness, and it needs it before the first question. Baski states its scope and limits next to the input: "Answers about ONEbasket only", and "Baski is an AI helper still in training, so answers can be wrong. Please don’t share personal information."

Doesn't that undersell it? A little, and I think that's the right amount. Not because modesty looks good on a landing page, but because an empty text box looks as if it will answer anything, and no assistant can.

The scope line says what to ask. The disclaimer says how far to trust the answer, and what to keep out of the box.

Leave it empty rather than guess

The same idea holds below the interface, where ONEbasket reads each product. In the ONEbasket case study I wrote it down as a rule: leave a price empty rather than guess. When the reader is unsure of a price, it stores nothing. A wrong price is worse than a missing one.

Why store nothing instead of a best guess? Because a blank looks unfinished and a guessed price looks exactly like a real one, and I'd rather people check a gap than trust a guess.

It's the "Coming soon" mark one layer down. The page doesn't present a feature that isn't ready as one that is, and the data doesn't hold a price the reader wasn't sure of.

Less impressive now, believed later

Add it up: a hero with clocks in it, a method with a step still to come, an FAQ that answers "coming soon", an assistant that says it can be wrong, and a reader that would rather store nothing than guess. That makes a less impressive demo than one where everything seems to work.

What it buys is being believed later. I rank that above looking finished, because a beta asks people to try something unfinished, and the page is what they have to go on. When price-drop alerts arrive and the FAQ loses its tag, people will have a reason to believe the new answer, because the old one was exact.

That's the trade I'd make on any beta: a smaller first impression, and a page people can take at its word.