# Users Are Your Boss: What a 10-Week Founder Sprint Taught Me About Customer Discovery, Rejection, and Knowing When to Stop

I spent 10 weeks in the Buerk Incubator trying to act like a founder. Not in the romantic way. Not the “I have a big idea and now the world must understand it” way. More like: talk to users, be wrong, change the idea, talk to more users, build something, realize the thing you built is not the thing people will pay for, and then sit with that.

The idea was Vakilaru, a litigation workflow product. We were looking at how lawyers manage case work, client updates, drafts, deadlines, and communication across messy legal systems. I came into it with one advantage: I had been a lawyer. I knew the pain was real. I had lived some version of it. But founder work is annoying because “real pain” is not enough. The better question is: is this pain urgent enough that someone will change behavior, trust you, pay you, and keep using what you made?

## Users are your boss

The biggest shift for me was realizing that users are not research participants who exist to validate your deck. They are your boss. If they do not understand it, that is your problem. If they do not care, that is your problem. If they say “this is cool” and then never open it again, that is also your problem.

It is very easy to listen selectively. Someone says one positive thing and suddenly your brain wants to turn it into evidence. But users are usually honest through behavior, not politeness. People will compliment your product because they like you, because they do not want to be rude, or because the interface genuinely looks interesting. None of that means they need it.

The real signal is when they start describing the problem without you pushing them. When they ask if they can use it now. When they tell you what they already tried. When they have a workaround that is painful but necessary. That is when you should pay attention.

## If you do not figure it out, someone else will

One uncomfortable thing about customer discovery is that you start seeing how many people are circling the same problems. At first that can feel discouraging. The market is crowded. Someone has already built a version of this. Someone has more money, more engineers, more credibility, more everything.

But crowded does not always mean closed. If users are still complaining, still duct-taping workflows together, still paying for bad tools, or still avoiding the available options, then the market being crowded is not the end of the story. It might mean the existing products are not solving the pain well enough.

The lesson for me was not “competition does not matter.” It does. The lesson was: if the pain is real and you are not the one who figures it out, someone else eventually will. That creates urgency. Not fake startup urgency. Real urgency to understand the user better than your own idea.

## A dying pain is different from a nice-to-have

This was the most important distinction. Some problems are annoying. Some are expensive. Some are embarrassing. Some quietly drain hours every week. Some create risk. Some can cost someone their client, their job, their license, or their peace of mind. Those are not the same category.

A nice-to-have feature can make someone say, “This would be useful.” A dying pain makes someone say, “I need this solved.” In legal tech, this distinction matters a lot because almost everything can sound important. Documents are important. Timelines are important. Client communication is important. Case strategy is important. But importance is not the same as willingness to adopt.

The question is not just “does this matter?” The question is “does this matter enough to interrupt the way this person already works?” That is the bar.

## Cool UX is not the same as use

I care about design, but this sprint made me less precious about it. You can code all you want. You can make the interface clean, clever, even beautiful. You can demo something and get people to say, “That looks cool.” And then nobody uses it. That is humbling.

Good UX can reduce friction, but it cannot manufacture urgency. It cannot turn a weak problem into a strong one. It cannot save a product from unclear value. The best design work in an early product might not be the screen. It might be choosing the right problem. Asking the sharper question. Removing the feature that makes the demo impressive but the product confusing.

That was hard for me to accept because building feels productive. Research feels slower. Waiting for evidence feels uncomfortable. But shipping without understanding can become a very expensive way to avoid the truth.

## Stopping is also a founder skill

We applied to YC. We got rejected. That part was not fun, but it was not the worst part. The harder part was deciding whether the evidence justified continuing.

We had conversations in India and the U.S. We heard real frustration. We saw possible workflows. We could imagine a product. But we did not have enough proof that this exact direction had the urgency, willingness to pay, and repeatable pattern we needed. So we stopped.

I do not see that as a clean failure or a clean success. It was an experiment that taught me what founder work actually feels like. It is not just ideas. It is not just building. It is not just pitching. It is being willing to be corrected by reality.

## What I am taking with me

The Buerk sprint made me better at asking:

- Who has the pain?
- How often does it happen?
- What do they do today?
- What breaks if they do nothing?
- Why would they trust us?
- Why would they switch?
- Why now?

These are simple questions, but simple does not mean easy. I still want to build. I still like early messy problems. I still like the part where there is no perfect role and someone just has to talk to people, make sense of the evidence, write the memo, shape the next test, and move. But I am less attached to being right. That might be the most useful thing I learned.