What’s new in Seshy.

There are two honest ways to quote what taking a card costs, and they behave differently on a page someone is scanning.

You can list the parts — processing at 2.9% plus 30¢, then our fee on top. It is accurate and it reads as three separate charges, which is three decisions to make before anyone knows what a session actually costs them.

Or you can quote one blended number. That is what we do: 4% on Solo, 3% on Studio, all in. One price is one decision.

The problem is what a blended number does when it stands alone. Most of that 4% is Stripe's — our own fee on Solo is 1%. A visitor who reads "4%" with nothing beside it has just been told Seshy takes about three times what Seshy takes. The single number is friendlier and, unqualified, it is worse than the itemised one.

So the rate and its arithmetic ship together. /pricing prints the components and what they sum to, on the same page as the headline figure, and the number in our marketing is stated in one place rather than recomputed wherever it appears. A quoted rate you cannot check is a rate you are asked to take on trust, and we would rather you did not have to.

Five of our routes ended the same way. Something went wrong, the code caught the error, and it put that error's own message in the response — which the booking page then displayed to whoever was standing there trying to book.

Most of the time that is merely unhelpful. Twice it was worse. One client was shown a sentence naming an internal pricing rule by its identifier and instructing a developer to migrate the provider's account. Another was shown the verification provider's own error text, verbatim. Neither person was a developer. Both were trying to book an appointment.

The obvious repair is to look for the bad phrases and strip them. We did not do that, and the reason is the whole point: stripping known-bad text fixes exactly the messages someone has already seen and leaks the next one. Every future error anywhere beneath those routes — ours or a vendor's — would be a new candidate, and nobody would find out until it appeared on a client's screen.

So nothing derived from a caught error reaches a response at all. The only text that goes out is a sentence written at the point in the code where a human decided what a person in that situation ought to be told, and where a reviewer can read it before it ships. The real error still exists; it goes to the log with its context, which is where whoever has to fix it will look.

Your clients see the failure. They should not have to see the plumbing.

Our About and Features pages described Seshy as offering privacy-first, on-device tools, and said in as many words that your data stays on your phone.

That is not how Seshy works. Your clients' details are encrypted, and they are encrypted on a server — which is what lets your booking page take a booking while your phone is in a drawer, and what lets you open the same client list on a different device. It is a real design decision with real benefits. It is not the one those two sentences described.

We took the claim down rather than rewriting it into something narrower. A softened version of a promise about where data lives is still a promise about where data lives, and it invites the reader to fill in the part we left vague. The pages now say what the product does, and the specifics of what is stored, encrypted and shared live in the privacy policy, where they can be stated precisely instead of summarised into a slogan.

One detail worth naming, because it was the part we nearly missed: the sentence was also in the page description that search results and shared links render. A claim can outlive the page it was removed from.