You don't find the right answer. You build into it.

When I joined as the founding engineer at a B2B SaaS analytics startup, we had a clear problem we wanted to solve: startups lacked a standard way to look at their own data. Every company measured the same things differently, every analytics team started from scratch, and the people running these companies were always one step behind the numbers. We had a vision for what the solution could look like and a basic deck to go with it.

What we did not have was any idea of what to actually build first.

So we did what most people do at the start of something new. We debated. Which data transfer tool? Which database? How do we make the product sticky? How do we onboard clients? We had a lot of energy and a lot of questions but no ground under our feet. Weeks passed and nothing moved.

After a while I felt disconnected. Not from the idea — the idea was real. But from the work. I could not feel the problem. I was only thinking about it.

So I stopped.

I took a week and built the bare minimum backend I could — mock data, basic APIs, just enough to see something on a screen. That got the frontend guy building and the product guy thinking about what the dashboards should actually convey. We had something moving.

Not because what we built was good. It was not. But because building exposed the real questions. Once we had something to show, we could approach a pilot client. Once we showed them something real, it earned us access to their data. And once I had access to their data, I stopped thinking about the product and started living inside their problem. I became part of their analytics team. I tried to answer the questions their stakeholders were asking. I replicated what they already had — not because that was the goal, but because it was the only way to understand what they actually needed.

And that is when the real problem showed itself. Not data transfer, not dashboards, not the tools. The problem was knowledge — how analytics teams spend most of their time not analyzing data but understanding the data model, and how that understanding disappears the moment someone leaves. That problem was invisible from a desk. I only found it by doing the work.

I think there is a version of starting something where you think long enough that you arrive at the right answer before writing a single line of code. That might work when you have prior signals — users, feedback, a market you already understand. But when you are building from zero, with no product and no users, thinking alone cannot get you there. The answer is not waiting to be found. It reveals itself through the work.

You don't find the right answer. You build into it.