When you become your own client

If you have spent years working with clients or product teams, building something of your own can feel like the natural next step. You already know how to turn an unclear idea into a product, work through complicated flows, and make an experience feel considered. Without stakeholder meetings, approvals, and constant feedback, the work should be easier.

That was part of what I expected when I started building Brisk.

There would be no client requesting another version after approving the previous one. No stakeholder arriving near the end with a requirement nobody had mentioned. No presentation needed to defend a decision I already believed was right. I could decide what to build, move at my own pace, and finally make the product exactly the way I thought it should be made.

For a while, that felt like freedom.

Then I realised that nobody was there to stop me from redesigning the same thing three times.

Clients can make the work frustrating, but they also give it shape. Even a difficult client usually provides several things that are easy to underestimate while you have them:

• A deadline, which eventually forces the work to move forward.

• A scope, even when everybody tries to stretch it.

• An audience, whose needs you are supposed to understand.

• Feedback, including the kind you would rather not receive.

• A definition of done, because somebody eventually approves the work.

Even disagreement is useful. When a client questions a direction, you have something concrete to respond to. You can explain the decision, uncover what they are worried about, change the design, or decide that the trade-off is worth defending.

The conversation eventually pushes the project toward an answer.

When you build your own product, every decision can remain open indefinitely. The onboarding may work, but perhaps another version would convert better. The pricing seems reasonable, but maybe the free plan gives too much away. The website explains the product, but perhaps the positioning is wrong.

You can improve the interface in the morning, question whether the feature should exist in the afternoon, and reconsider the entire audience before bed.

If you are building something of your own and suddenly feel less decisive than you did while working for clients, it may not be because you have become worse at your job. You may simply be missing the structure that another person used to provide.

As designers, we are trained to improve whatever is in front of us. When something feels unclear, we rewrite it. When a flow contains unnecessary steps, we remove them. When a page feels unconvincing, we adjust the hierarchy, add context, and make the value easier to understand.

That instinct is useful, but it can also keep us busy without moving the product forward.

When people are not signing up, the website may not be the problem. When they create an account but never use the product, the onboarding may not be the problem either.

Perhaps:

• The right people have not discovered it.

• The problem is inconvenient, but not painful enough.

• Switching feels riskier than continuing with an imperfect tool.

• People understand the product but do not trust it yet.

• The product solves the problem, just not at the moment they need it.

None of those questions can be answered by polishing the interface alone.

This is where building your own product starts to feel very different from delivering work for someone else. A client project often ends when the solution has been approved and built. A product only begins there.

It still needs to be discovered, understood, trusted, used, and considered valuable enough to return to or pay for.

The screen still matters. It is just no longer proof that the work is succeeding.

Without a client, you need another source of constraints. Those constraints should come from the people experiencing the problem you are trying to solve.

This sounds obvious. Every product book tells you to speak to users, stay close to customers, and understand their needs.

The annoying part is that you first have to find them.

A client has already agreed to pay attention. A potential user has not. They have their own work, deadlines, problems, and tools they already understand. Your product, especially at the beginning, may barely register in their week.

You can spend months thinking about a product that someone else considers for twelve seconds before closing the tab.

Even when a person signs up, they may not care enough to reply to your email. Someone who says they love the idea may never use it. Someone who promises to try it may forget before lunch.

Their time is valuable, and you have not yet earned much of it.

I think this is one of the hardest adjustments when moving from client work to building a product. You are used to being invited into the problem. Now you have to find the people experiencing it and convince them to let you into a small part of their lives.

That means sending messages that receive no reply. Joining communities where nobody wants another founder promoting a product. Asking for 15 minutes from someone who has no obvious reason to give them to you.

It can feel repetitive and occasionally a little desperate.

But without those conversations, almost every idea looks reasonable.

You can convince yourself that people need more templates, a better dashboard, different pricing, or an AI feature. You can point to competitors doing the same thing and treat that as evidence. You can redesign the website again because redesigning feels more productive than admitting that you still do not understand why people leave.

A real user makes the problem specific.

The good news is that connecting with users does not always mean persuading strangers to join a formal 45-minute interview.

Some of the most useful conversations begin with one specific thing you do not understand.

Instead of asking them to “share feedback,” ask what happened in that particular moment. A narrow question feels easier to answer because it does not require the person to review your entire product.

I noticed you created an invoice but did not end up sending it. Did something feel unclear, or did you decide to handle it another way?

You may still receive no answer. But the question sounds like it came from a person, not a research automation.

Hypothetical questions often produce polite, hypothetical answers.

“Would automatic reminders be useful?” is easy to say yes to.

A better question is: “What happened the last time a client paid you late?”

Now you are hearing about a real situation. Perhaps they followed up manually. Perhaps they waited two weeks because they felt awkward. Perhaps they already use another tool that solves the problem well enough.

The conversation becomes less about your feature and more about their life.

You do not always need to bring people into your research process. Sometimes you need to enter their world quietly.

Read the questions they ask in communities. Notice the language they use before they know your product exists. Look at the spreadsheets, templates, and improvised systems they have built for themselves.

The goal is not to join every community and immediately mention your product. People can feel that from a distance.

The goal is to understand the problem well enough that the product begins to sound like it belongs in their world rather than yours.

When somebody does give you their time, do not disappear until the next time you need feedback.

Tell them when something they mentioned changes the product. Ask whether the new version works better. Share a short update without turning every interaction into a sales message.

Over time, those small exchanges can become a group of people who understand what you are building and trust you enough to tell you when it is wrong.

That may be much more valuable than a large audience that politely likes your announcements.

Speaking to users is only useful when what you learn changes what you do.

Otherwise, research can become another activity that feels responsible without forcing any difficult decisions.

A useful constraint might sound like:

• I will not redesign the landing page again until I have spoken to 5 users who did not understand it.

• I will focus on one type of user segment for the next three months.

• I will not build a requested feature until I understand how at least three people currently solve the problem.

• I will measure whether users send their first invoice, not whether they compliment the design.

• I will contact a few users every week instead of waiting until I need something from them.

The purpose of these rules is not to remove intuition from the work. It is to stop intuition from becoming the only evidence available.

I am trying to become stricter about separating questions that need design from questions that need more understanding.

If people want to use the product but cannot complete the flow, that is a design problem worth opening Figma for. If people understand the product but do not care enough to use it, another interface iteration will probably not help.

Both situations can feel like “the product is not working.”

They require completely different responses.

If you are moving from client work into building something of your own, the hardest part may not be creating the product. It may be deciding what deserves your attention when nobody else is setting the priorities.

You may miss the deadlines you once complained about because they made decisions final. You may miss frustrating feedback because at least it confirmed that someone was paying attention. You may even miss the constraints because they gave the work somewhere to go.

The answer is not to recreate the worst parts of client work. It is to replace what was useful about it.

Give yourself a narrow problem. Decide what evidence would change your mind. Stay with one direction long enough to learn from it. Most importantly, get closer to the people whose problems are supposed to guide the product.

You will have to find them. Many will not answer. Most will care less about the product than you do, especially in the beginning.

That is not a distraction from building.

It is part of building.

When you work with a client, the constraints arrive with the project. When you build your own product, you have to go out and find them.

Thanks for reading :) If something in this issue resonated, please reply and tell me.

— Balint

P.S. Here’s what I’m building

A calmer way to run your freelance business.

Brisk helps you give clients a professional experience: from the first agreement to the final payment.

See what I’m building →