I spent about ₹31,000 on Azure building and testing WishCodes.
Bing-grounded search. AI models. VMs. Containers. Load balancers. Retrieval infrastructure. Then another ₹2,000–₹3,000 on domains, inboxes and distribution.
At one point the product had hundreds of automated tests. The recommendation system checked whether URLs were real product pages, whether items were available, whether currencies and budgets matched, whether results were duplicates, and whether the final six recommendations were actually different enough to be useful.
I had ranking logic, fallbacks, caching, rate limits and multiple search providers.
About 200 people had used the product.
That ratio should have bothered me much earlier.
The engineering wasn't useless. WishCodes got much better because of it.
It just wasn't the problem anymore.
And I kept working on it because it was the problem I knew how to solve.
Building was the comfortable part
I've been coding for around six years.
When I started, you wrote almost everything yourself. You dug through documentation, debugged stupid mistakes and slowly figured out how things worked by breaking them.
Then autocomplete got good.
Then Copilot.
Then models started writing whole functions.
Now agents can work across repositories, terminals, browsers, tests and deployments.
The effect on how fast I build has been ridiculous. Something that would have taken me weeks a few years ago can now become a usable MVP in an afternoon.
I've probably built 40 or 50 projects over the years. Businesses, experiments, random tools I wanted for myself.
That also gave me a bad habit.
Whenever something wasn't working, I built.
Recommendations aren't good enough? Improve retrieval.
Search is weak? Add another source.
Results are repetitive? Add diversity rules.
Something might fail under load? Build for scale.
There was always another technical problem I could fix.
And technical problems feel good. I can sit down for six hours and end the day with something clearly better than what existed that morning.
Distribution doesn't give you that satisfaction.
Then a few VCs asked the obvious question
I spoke to a few VCs about WishCodes.
I explained the product, the system behind it, what I'd built and where I wanted to take it.
Their concern was much simpler:
Traction.
That was when it clicked.
I had spent months asking whether WishCodes could produce better recommendations, survive failures and scale cleanly.
Nobody needed me to prove that yet.
What I actually needed to prove was:
Would people create a WishCode?
Would they share it?
Would their friends use it?
Would those people come back and create their own?
I had around 200 users and infrastructure built for problems I didn't have yet.
Traffic wasn't the emergency.
Getting traffic was.
AI makes overbuilding dangerously easy
There used to be a cost to building the wrong thing.
If a feature took three weeks, you had to think pretty hard before committing three weeks to it.
Now an agent can build it tonight.
So you do.
You improve the ranking again. Add another test. Refactor something. Cut latency. Clean up the architecture.
And all of it feels like progress.
Tests turn green. Commits pile up. The product gets faster.
Distribution is much less rewarding.
I was posting on X three or four times a day, replying to around 20 relevant posts daily and sending roughly 500 emails a week through an outbound setup I built with Titan mailboxes.
A day of coding could leave me with thousands of lines of new software.
A day of distribution could leave me with three replies.
Guess which one I wanted to do more.
That's the trap.
When building becomes this cheap, building more becomes one of the easiest ways for a technical founder to avoid the actual problem.
The bottleneck moved
Software used to be expensive to create.
You needed engineers, servers, time and money before you could even find out whether anyone wanted what you were making.
That cost is collapsing.
I can go from an idea to something usable in hours now.
But people haven't become easier to reach.
There might be someone on Reddit right now describing the exact problem one of my projects solves.
Someone on X might be complaining about it.
Someone at a company might be wasting hours doing manually what my software already automates.
The product can exist and the person who needs it can exist, yet neither knows about the other.
That gap started bothering me more than the engineering problems.
I tried solving it manually.
Search for people talking about the problem. Figure out whether the product actually fits. Write something useful. Track who I'd contacted. Follow up. Repeat.
Do that for hundreds of people and it becomes miserable.
Finding good conversations takes forever. Most of what you find is noise. Reply quality drops when you chase volume.
And posting "I built this cool thing" into the void isn't much better.
For the first time, I started looking at distribution the way I'd always looked at software.
As a system.
That became Distrarc
The idea behind Distrarc started with a simple question:
What if software could find people who already have the problem your product solves?
Not scraped lead lists.
Not random email addresses.
Actual intent.
Someone asking for a recommendation. Complaining about a workflow. Looking for an alternative. Trying to solve the exact problem your product was built for.
The system could find those conversations, decide whether there was a real fit and help you reach the right people without manually searching the internet all day.
That became Distrarc.
And yes, I immediately started overengineering that too.
Queues. Agents. Background jobs. Failure handling. More tests.
Apparently recognizing your problem doesn't cure it.
But I'm measuring something different now.
If Distrarc has beautiful architecture and doesn't help WishCodes reach more people, it failed.
The test count doesn't matter.
The amount of code doesn't matter.
What matters is whether it connects a useful product with people who actually need it.
I wasn’t building the wrong thing
I still care a lot about product quality.
A bad product with great distribution is still a bad product. Getting more people to use it just exposes the problem faster.
My mistake was assuming every product weakness deserved to be fixed before distribution became serious.
At some point, WishCodes was good enough.
The bottleneck had moved.
I hadn't.
So now, before spending another day improving something, I try to ask one question:
If I fix this perfectly, does it change what's actually stopping the product from growing?
Sometimes it does.
Often it doesn't.
I used to think the hard part was making something that worked.
It turns out that was only the first bottleneck.