How We Validated a Product Idea Before Writing a Line of Code

Most product ideas die in conversation. Not because they are bad ideas, but because the conversation never gets real enough. You describe it, the other person nods, and you both leave the room with completely different pictures in your heads.

I learned this properly while building Farmica.

The story starts before the product

We had an existing client, a farmer in Austria with an online shop we had built for her. At some point we started talking to more farmers to understand how they sell and what their actual problems are beyond needing a website.

What we found: gathering orders is a mess. Farmers collect orders through WhatsApp, phone calls, email, hand-written notes at the market. They were already thinking in terms of order forms, not shops. That was the insight. Not something we invented — something they told us, repeatedly, in different ways.

Bringing the insight back to someone who could confirm it

We did not go hunting for a new customer to test this on. We went back to the one we already had.

She happened to have two frustrations sitting unresolved. The Payload CMS admin we had built for her was more complex than she needed for day-to-day order management. And she wanted a simple order link she could send to customers alongside her shop link. She saw them as different things: the shop for people who want to browse, the order form for people who already know what they want.

The insight from our farmer research connected directly to what she was already feeling. But at this point it was still just a conversation. We had an idea. She had a frustration. That is not the same as having a product.

Making it real enough to react to

This is where most people write a spec, a proposal, or a long email explaining what they are thinking of building. We made a prototype instead.

The goal was not polish. It was to get something in front of her that she could actually respond to. We used Figma Make with a shadcn theme from tweakcn for color and typography, not because those choices mattered deeply at this stage, but because they let us shortcut the visual decisions and focus on what actually mattered: the flow.

There were two sides to get right. The customer placing an order, and the farmer managing it. Both had to feel obvious. If either side required explanation, the prototype had failed.

We kept it simple enough to build fast and specific enough to feel real. Not a wireframe, not a finished UI. Something in between: real enough that she could put herself inside it and see her own problem reflected back.

The conversation that started everything

We sent her the prototype. Her response was not "I like the colours" or "can we change this button." It was recognition. She saw her situation in something she could actually imagine using.

That reaction is something a description can never get you. People cannot react to ideas. They can only react to things. The prototype was the thing.

She became Farmica's first user before Farmica had a name. That one honest conversation, with something tangible in hand, gave us the confidence to start building and the direction to build it right. We are now rolling it out to other farmers.

What this means for your next idea

If you are sitting on a product idea right now, as a designer, a PM, or an entrepreneur, the question worth asking is: have you made it real enough to get an honest reaction?

Not a pitch deck. Not a description. Not even a detailed spec. Something the other person can put themselves inside, even briefly, and tell you whether it reflects their reality.

The gap between "I think this is worth building" and "I know this is worth building" is smaller than most people think. You do not cross it by building more. You cross it by making something just real enough to have one honest conversation.

Farmica started with a Figma file and a farmer who said yes. Everything since has been building on that.