6 months in
Almost 50,000 people signed up. Most of what I built still failed.
I can’t believe it has been six months since I took a leave of absence from Duolingo and started tinkering with AI on Lazyweb.com
Time flies.
So much has happened since:
I built a Mac app (fail), a web app (fail), and an MCP that went kinda viral. All different flavors of the same product.
Close to 50k people signed up for Lazyweb.
Crossed 15k active users.
More than 1m organic social impressions (a surprising amount from Japan. Still figuring that one out 😆)
I met my cofounder, Francesco Polizzi.
Left Duolingo for real.
A few copycats here and there (:
I said goodbye to The Pitt as my home.
A few more grey hairs emerged.
I spent most of those months building things nobody wanted, wondering if I was wasting my time, then stumbled into something people actually use.
The metrics are fun. But the thing I cherish most is that my value system changed.
I keep coming back to Ray Dalio’s idea that principles are decisions you make once, then pressure-test every time reality disagrees with you.
His version: “Pain + Reflection = Progress.”
I am nowhere near a finished operating system for life or work. But here are five principles I am building one painful repetition at a time.
1. Don’t solve problems that don’t exist
Easy to say. Nearly impossible when you have no boss, an infinite backlog, and AI that makes every detour feel buildable.
Early on, I caught myself thinking about SOC 2, database redundancy, team plans, pricing, and polished error states. Before a single person needed the core product. All reasonable. Just not yet.
The honest question was different: what am I avoiding because it might prove the whole idea wrong? For a while, that was getting the MCP running and in front of real people. Shipping another feature was safer. That was the tell.
I wrote more in Don’t solve problems that don’t exist. Short version: necessary work is not important work, and important work is almost never the comfortable work.
2. Optimize for learning
“Build product and talk to users” is directionally right, but I struggled with this advice…a lot.
You still have to decide what to build, and building is easier than ever.
Some soul-searching, reflection, and mistakes led me to find the biggest unknown, then build the smallest thing that gives you a real answer.
Learning compounds; every clean answer buys me a little more intuition, and intuition is what makes the next product call better.
When I started hacking away at Lazyweb, I was sure of a lot. It had to be a native Mac app. It had to (eventually) use local models for deep design research. It needed a pile of metadata and features for running experiments. None of it was validated.
The first shock to my system was that people referenced ChatGPT when I asked how they came up with growth ideas and interesting design patterns: “I just use Codex.” “I use ChatGPT.” “I ask Claude.”
I genuinely never thought of LLMs as competitors…more so things like Mobbin, DoWhatWorks…etc.
These conversations led me to a fork: Is no one using my web app because it sucks, or because switching context is so high effort?
I attempted a few ways to learn the answer here…I built my own agent (it sucked!) and an MCP that put Lazyweb inside the conversation where people were already asking questions and making decisions.
The goal was never to protect my idea…or, even worse, “be right” about my uninformed intuition going into this journey.
It was to get to the truth as fast as humanly possible…took me a minute to realize that was the only goal that mattered pre-PMF (:
3. Embrace hard problems with high effort and high upside
Humans hate uncertainty.
The research term is ambiguity aversion: we prefer a known risk over odds we cannot calculate. Useful instinct. Also a great way to keep a company small.
I saw the milder version as a growth PM. Removing a little friction/confusion point has an outsized effect on metrics because people dodge the effort right in front of them, even when the upside is obvious.
Building a company is the same dynamic at a bigger scale.
At the beginning, you have no moat. You have an idea and a pile of things that look easier than the work that matters.
The moat gets built by solving the problems everyone else keeps walking around…
If we think back together, what do “network effects,” “brand,” “economies of scale”…etc. all have in common? They were pretty darn hard to get started (: Solving hard problems with high upside is the closest thing to a directional compass—or mental model—I have found for building a moat and a defensible business over time.
So the question I am trying to ask more often: what is the hardest unknown with the highest leverage? Then I RUN TOWARDS IT AND EMBRACE IT WITH BOTH ARMS OPEN.
4. Push the limits and fail often
AI changed what failure looks like. Impossible three weeks ago can be feasible today. So the right question is not “does this work?” It is “does this work yet?”
A small startup’s edge is speed. No reorg, no planning cycle, no six layers of approval. But speed only matters if you keep re-testing the frontier instead of treating the first failure as a verdict.
Building the experiment data was brutal. I tried four or five times to get vision models to annotate screenshots, as far back as GPT-4 and Claude 3.5. Not good enough.
So I annotated manually and kept a running list of what is not doable and where the model trips. I didn’t write it down, but it was very clear in my head, and I worked around these limitations…for instance, I created an ensemble of OCR, Embedding, and Vision Description that was able to roughly act like a good vision model (:
I no longer need any of this, cuz the models are good enough…but I pushed the limits…scotch-taped a solution (spent many hundreds of hours annotating screens), squinted my eyes and did a ton of manual labor and convinced myself it would all be better in 6 months…
Shocker…it was.
5. Find new sources of energy
The hardest part of building a company is not the product, the ops, or the people. It is emotional.
A founder I spoke with after he sold his company to Salesforce put it better than I could: the job is operating through the swings. Depression, euphoria, self-doubt, a real existential threat, an unexpected win. Sometimes all in the same week.
I assumed energy would come from freedom and momentum. Sometimes it does. Most weeks I have to go find fuel on purpose, outside the company and inside it.
Outside: walking away from the screen, cooking, journaling, talking to someone who gets it. Inside: protecting time for work I genuinely love, even when, on a spreadsheet, it is only 50% optimal for the business and 100% good for my energy.
I use these as reward mechanics…this thing you really enjoy doing…well, you get to do it after you solve this very hard problem with high upside and high uncertainty.
It keeps me going for the long run.
I do not have a neat conclusion. We’re six months in. The company is still very early, and so am I.
But I am more convinced than ever that building something is not just learning how to make a product. It is learning who you become when nothing is guaranteed.
Thank you for joining me (& Francesco) on this ride.
More exciting updates soon (:
Ali Abouelatta