Don’t build before customer validation, unless you’re honest that it’s for fun
I’m going to keep documenting this #buildinpublic experiment, but I want to be clear about the rule underneath it.
If you are treating something like a business, do not jump straight into building.
Do customer discovery first.
I know this is not the fun answer. Building is more fun. I build things for fun all the time. Sometimes I build multiple tiny apps in a day because I am curious, or because I want to see if a workflow is possible, or because I just enjoy making things exist.
That is fine.
But building for fun is not the same as building a business.
A business starts with a customer pain point.
Pain first, product second
For over a decade, I have suggested that anyone with a business idea should resist the urge to jump straight to an MVP.
The usual advice is something like:
Build a minimum viable product and see what happens.
That can work, but it often turns into a trap. Especially now.
AI makes building easier, which also makes it easier to build the wrong thing quickly.
The better first question is not “what can I build?”
The better question is:
Who has a painful enough problem that they will pay to make it go away?
If you cannot answer that, you are probably not ready to build the business version yet.
You might still build the fun version. I do that too. Just be honest about which one it is.
Find the core persona
The first step is defining the core persona.
Who actually has the pain point?
Not vaguely. Not “small businesses” or “founders” or “busy people.” Those are too broad to be useful.
You want to know the specific type of person who feels the problem often enough, badly enough, and with enough budget or urgency to do something about it.
If the idea is not solving a pain point and is only providing a gain, the gain needs to be very strong. I usually think in terms of a 10x gain over what they already do.
Otherwise, you are asking someone to change behaviour for a mild improvement. That is a hard sell.
I built CorePersona partly around this problem, and wrote more about the workflow in Discover and Validate Your Core Persona: most people do not know who their website is really speaking to. If you cannot define the person clearly, your marketing gets vague, your product gets vague, and your validation gets noisy.
Do not sell during discovery
When you talk to the core persona, do not try to sell your solution.
That is one of the biggest mistakes I see.
You are not there to convince them that your idea is good. You are there to understand their pain point.
Ask questions. Listen. Take notes. Record the call if appropriate and with consent. Pay attention to the exact words they use.
Those words matter later.
The way a customer describes the pain is usually better than the way a founder describes the product.
If enough people in the actual core persona describe the same pain, in similar language, and some of them are willing to pay, now you have something.
Not friends and family saying they would “totally pay for that” if you built it. That is nice, but it is usually not validation unless they are actually the buyer.
Assuming the person has the budget, if they are not willing to pay you to solve it, one of two things is probably happening: you are not using language that reaches the pain point, or they do not trust you to solve it yet.
Either way, you learned something useful.
Praise does not pay invoices.
Payment changes the conversation
If you have really found a pain point, or if the gain is notable enough, people will often pay you to build the solution.
Not always. Not every market works the same way. But willingness to pay changes the conversation.
It turns “nice idea” into a signal.
It also forces you to confront whether the work is worth doing as a business.
I have seen a lot of builders polish landing pages, ship prototypes, post once, and then get confused when nothing happens.
I get it. Building is satisfying. Shipping is satisfying. A new domain and a nice landing page can feel like momentum.
But if no one has validated the pain strongly enough to commit to paying, you may just be building with hopium.
Again, that can still be fun.
Just do not confuse it with customer validation.
Why I care about this
Everyone is an entrepreneurial expert on LinkedIn.
So here is my receipt.
My latest company, Petrichor Labs, reached over $50,000 MRR in its first month. That was not a one-off project invoice. Those were repeating monthly contracts.
No investors. No outside control. A customer-validated pain point.
We build for customers. We keep doing customer validation throughout the relationship, not just at the beginning. We have never missed a milestone commitment to a customer, because the point is not startup theatre. The point is solving the problem the customer is actually paying us to solve.
That is also why I get frustrated with how much attention goes to companies chasing VC money before they have customer truth.
Raising money is not product-market fit. It can just make you burn money faster.
The real work is finding people with painful problems, understanding them, and delivering consistently.
Why IT Butler exists
This brings me to IT Butler.
I did not wake up one morning and decide to build another AI landing page because the world needed one more AI landing page.
The domain was sitting idle.
I have recently decided that every domain I own gets two years to make money, or I sell it. Domains are not collectibles for me anymore. They either become useful or they leave.
What I kept hearing from people was different from the work Petrichor Labs usually does.
Petrichor Labs customers are generally in the five-figures-a-month range. That is appropriate for larger, serious projects.
But outside of my classes, I kept hearing from solo founders and small businesses who wanted practical AI workflows but did not need, and often could not justify, a larger engagement.
Some wanted me to teach them how to implement AI safely in their business.
Others wanted me to do it with them or for them.
That is a different market with different needs.
So IT Butler is the smaller offer:
$500/month for practical AI workflow help for solo founders and small businesses.
Not theory. Not generic “AI strategy.” Not another course they never finish.
One useful workflow a month.
Why I built it now
I built IT Butler because I had already found people with the pain point.
More importantly, I had found people willing to pay around this price point.
That matters.
At $500/month, I know I can provide more than $500/month of value to the right person. If I cannot, the offer should not exist.
That is the bar.
The current annoying bottleneck was not the idea or the landing page. It was payment rails.
I opened a business chequing account with one of the big Canadian banks specifically for payments. I completed KYB. I even had my bank manager provide documents proving the account is a chequing account.
The payment provider’s app still did not detect it properly.
That turned what should have been a quick setup into more than two weeks of delay and 10+ hours of my time.
Ridiculous.
I added PayPal as the live subscription path while PayRails finishes its bank-account review. Not my ideal payment stack, but better than letting a broken onboarding flow block a validated offer.
On the bright side, the delay gave me time to realize I should document the whole journey. Not just the clean launch story, but the operational nonsense too.
The good, the bad, and the boring.
What I will document
I am going to document IT Butler as the first public build-in-public project in this run.
I will share:
- the positioning
- the offer
- the customer conversations
- what people actually seem willing to pay for
- the AI workflows
- the mistakes
- the payment rail nonsense
- whether anyone pays and sticks around
I am not doing this because I think every step will look impressive.
I am doing it because the boring parts are usually where the real business lessons are.
If you are building something because it is fun, enjoy it. I mean that sincerely.
But if you are treating it like a business, find the customer pain first.
Otherwise you are not building a business yet.
You are building for fun and hopium.
And hopium has terrible retention.
If you want to follow the experiment, start here: IT Butler.
Leave a comment