BeCrystal

beCrystal is built for scaling B2B SaaS companies — the stage where revenue is recorded in several systems at once, each telling a slightly different story, and reconciling them is still nobody's job.

So before any decision gets made, someone first has to put together a number they can rely on. That's the real work. And the people doing it aren't asking for analytics — they're asking to say a number out loud, in a room where someone will check it.

Signal came in pieces: a handful of pilot customers, whatever we picked up from demos with prospects, and later the data real customers brought with them. None of it was a sample, and none of it arrived on a schedule. Every insight had to be assembled from a small number of long conversations and from whatever the next account happened to reveal.

Most of the product didn't exist yet, so there was no broken flow to fix — the question was what the flow should be. Those calls were made together: direction with the CEO and CTO, feasibility with the engineers, and priority against what pilot customers needed next.

Different accounting tools, different billing logic, different naming. And each new customer arrived with a case we hadn't anticipated, so the MVP kept having to stretch to hold it — designing for the shapes we knew while leaving room for the ones we hadn't met yet.

A draft of a dashboard existed when I joined. The pieces were there, but not in a shape that met what people actually needed from it. Rebuilding it around those user needs set the pattern for the rest of the product, so it's the clearest place to start — everything below is what changed and why.

Every figure opens into the records behind it — and the way there had to protect whatever the person was doing when the question came up.

The library behind the product was small; the discipline around it wasn't. Buttons, icons and the recurring components existed once and were reused everywhere, nothing redefined from one screen to the next. New screens started from components and rules that already existed, so consistency wasn't something to check at the end — it was the starting condition.

and with users who matched the same profile. Testing on the prototype rather than describing the idea — the disagreements showed up faster that way.

on a regular rhythm. Most of what shipped was shaped in these, not in Figma alone.

when an idea needed to be argued about rather than described. Cheap enough to discard, real enough to test — no engineering time spent on something we'd drop.

Data quality is where the product surfaces what it couldn't work out on its own. The goal is to achieve the most accurate calculations and the most accurate numbers by accessing clean data. It is the product's whole promise, so we built for it early — with the assumptions we had and the customer data we could see at the time. The model was straightforward: the system finds what it can't resolve, lists it, and a person works through the list.

Three passes later, it works differently. Each version shipped, held for a while, and then broke against data we hadn't seen yet.

The current design starts from the pattern instead of the row. The system reads a company's data, finds what keeps recurring, and proposes a setting that resolves all of it at once — explaining what it found and what the setting would do, so the user can decide whether to accept it. Clearing a queue becomes making a few decisions.

That meant redesigning around the new model rather than adding to the old one:

I learned WCAG properly during this project, which means I know exactly where this product is weak: contrast in the data visualisations, and keyboard navigation through dense tables. In a product read by people under time pressure in a meeting, those aren't edge cases.

The library did its job — it grew alongside the product, shaped by what each screen needed. Next time I'd give it dedicated time at the start instead: rules named, components documented, so the system leads the screens rather than follows them.