Helping a founder find the one chart worth building
QuantaLyric's founder wanted three products at once for a pre-seed startup: a forecasting tool, the tooling to run it, and an investor-ready site. I had forty hours. From our first meeting, I asked where the value lived and who it was for, until the answer was one chart for energy traders. Then I designed the whole vision and built only that.

A vision three products wide
The founder had been Director of Energy Infrastructure for the Australian government. His vision was a single surface for three very different people: machine learning (ML) engineers building forecasting models, data scientists checking them, and energy traders acting on what the models produced. The ask was just as wide. He wanted the forecasting product, the tooling behind it, and an investor-ready marketing site, all in parallel, with one part-time developer.

Anyone could see the scope was too large, and the founder knew it too. As a pre-seed company, he wanted to be careful with money, and he was looking for guidance on what to build first.
Finding where the value lived
So from our first meeting, I kept returning to two questions: where does the value of this product live, and who is it for? The answers kept pointing the same way. Traders lost money every week to weak forecasts, while ML engineers had workarounds. Competitors' model tooling was mature, but their accuracy claims were vague. And every investor pitch came back to the same question, "what's the moat," meaning what would stop a competitor from copying this. An accuracy demo could answer that. Admin tooling never would.

By the time I proposed shipping forecasting for traders first, the founder welcomed it, and together we cut the scope roughly in half. I designed the rest of the vision without building it, so he still had a complete picture to pitch.

Making one chart readable
The first contract mapped the whole product and its core flows. The second went entirely to the chart. The official government forecast that traders already relied on wasn't one line. It was thirty to forty model runs, three summary lines, and a time axis marked in half-hour periods instead of clock times, so reading the time took arithmetic. Layering QuantaLyric's forecast on top would have doubled what traders had to read.

The founder's own experience reading the official chart set the principle: clarity by default, detail on demand. Both forecasts appear as shaded bands, so where they agree is visible at a glance and where they part reads as the signal. The individual model runs set the width of the confidence band instead of being drawn as lines. Real dates and times replaced the half-hour periods, and hovering shows exact values from both forecasts at once.

Two smaller calls protected the hours. I used Radix, an off-the-shelf library of interface components, instead of building a custom design system. A custom system would have cost a one-developer team six to eight weeks, and the product's identity lives in its charts. Everywhere else, traders trust calm, familiar interfaces. I also built accessibility in from the first chart rather than saving it for later. Government buyers require software that meets WCAG accessibility standards, about one in twelve men see color differently, and some of the investors the founder was courting are color blind.
What changed
The proof of concept shipped inside the forty hours, and QuantaLyric is pursuing seed funding with it. Radix saved enough time that the team shipped a mobile version as a stretch goal, which matters because a phone is the first thing an investor sees when a founder hands one over in a pitch. The chart colors stay readable in simulations of the major types of color blindness, which keeps government and other regulated sales open.

Looking back
The call I'd make differently was my own. I committed to extending Radix's built-in color scales for the charts and kept at it as they resisted, and that sunk cost took hours the forecast chart could have used. A palette for charts has different jobs than a palette for buttons, and next time I'd build a separate one for data visualization from the start. Cutting scope is a discipline, and it has to apply to my own decisions too.