All notes

How I Won Lovable Shipped Season 1 ($100K, 5,800 Builders)

How I won Lovable Shipped Season 1: the six-week GiveFeedback build, what Lovable handled vs. what discipline handled, and the near-miss.

July 6, 2026 · 8-min read

lovable shippedgivefeedbackvibe codingshipping disciplinecase study

I won Lovable Shipped Season 1 in August 2025 by building GiveFeedback.dev solo in six weeks. It took the $100K grand prize against roughly 5,800 builders and ranked #1 globally. It also had paying clients before the prize window closed. That's the short answer to how you win this thing. The longer answer, the one worth writing down: the win had less to do with Lovable than most recaps assume. The parts that mattered are learnable.

Why I entered: eight years of discipline, zero clean tests#

Verto Health took eight years of my life, 2018 to 2026. I was employee number two at the Toronto health tech company and helped scale the team to 80 people. I shipped into more than 100 deployments across Canadian and US health systems and sold to hospital CIOs and clinical leadership. Along the way I absorbed what amounted to several careers: product design, product management, software architecture, data science, sales engineering.

What I never had was a clean test. Inside a company you can always tell yourself a flattering story about which part of an outcome was you and which part was the machine around you.

Lovable Shipped offered the opposite: one person, one product, six weeks, a public leaderboard, $100K on the line. I entered to find out whether the operating discipline I claimed to have was actually mine, or whether it had been the organization I was standing in the whole time. (The honest answer, once the dust settled: both, in proportions I still can't fully separate. More on that below.)

The six-week build of GiveFeedback#

GiveFeedback.dev is a feedback and task management tool for client work: it turns the feedback flying around a project into structured tasks someone owns. I picked the problem deliberately. Six weeks isn't enough time to learn a domain, so I chose one where I could make scope calls in minutes instead of days. Scope calls, it turned out, were most of the game.

The build ran like a client engagement where I was both the operator and the difficult client. Work backwards from the ship date. Cut scope every week, not in a panic at the end. Get something usable in front of people early, then make it worth paying for.

It's the same shape I now sell as a product and build engagement: brief to shipped product, with six weeks as the working number. The competition is where that number got pressure-tested with my own money and sleep.

I want to be straight about the texture of it, because recaps of wins always come out smoother than the weeks felt. The six weeks were rough. Not cinematic rough, just grinding rough. Solo means every context switch is yours: builder in the morning, QA in the afternoon, support and sales at night, and nobody catches the ball you drop.

There were stretches where the honest status update would have been "behind, tired, and not sure the cuts I made yesterday were right." I came out with the win, the #1 ranking, and a noticeably more modest opinion of my own bandwidth.

What Lovable handled#

Credit where it's due, because Lovable is fast. It collapsed the distance between "I know what this screen should do" and "the screen exists and works." Interface iteration that would've taken days took hours. Scaffolding, plumbing, the unglamorous majority of a web product: mostly evaporated. I wrote up where that speed holds and where it breaks in is Lovable good for real products, so I'll keep this part short.

Two data points that the speed is real and not just my bias talking. First, I shipped a second product that same season, Lotso Travel, which ranked #7 globally and now brings in roughly $200 a day passively across 195 countries. You don't ship two globally ranked products in one season with a slow tool.

Second, Lovable certified me at Vibe Coding L5: Diamond, their highest level. I've logged enough hours to know the platform's real ceiling rather than its demo ceiling.

Here's the complication I didn't expect. Going in, I assumed I'd come out with a clean attribution: this much was the tool, this much was me. I couldn't make that split at the end, and I'd underestimated how tangled the two get.

Lovable made my decisions cheap to execute. Good decisions compounded faster, and so did bad ones. Anyone selling you a tidy "the tool did 70% of it" story is guessing.

What the discipline handled#

Everything Lovable can't see. It executes decisions. It doesn't make them, and the leaderboard was decided by decisions.

Scope, meaning what not to build#

Eight years of product management at Verto was mostly this one muscle. I've juggled 14 client working groups, each certain their feature was the critical one. Six weeks solo is the same fight with fewer meetings: every appealing feature is a mugging dressed as an opportunity. The features I cut in weeks two and three are the reason there was a finished product in week six.

Knowing products are bought, not built#

Selling to hospital CIOs for eight years teaches you that a demo is not a deal and applause is not revenue. So I treated Lovable Shipped as customer acquisition with a deadline, not a build with an audience. Talk to the people who feel the problem, put a price on the thing early, and let their behavior (not their compliments) steer the roadmap.

Production posture#

A competition rewards what looks finished. Paying clients punish what isn't. Auth that holds. Data handled like you'd be embarrassed to lose it. Edge cases hunted down before a client trips over them in front of their own customer.

None of this shows up in a launch video, and all of it shows up in whether client number two exists. Eight years of shipping into health systems, where the cost of "mostly works" is measured in incident reports, made this posture automatic rather than aspirational.

The priority fight I almost lost#

This near-miss is the most useful thing in the post, so it gets its own section. In the back half of the build, the marketing site won a priority fight it should not have won. I'd spent years in product marketing by then (something north of 30 GTM strategies at Verto). That instinct argued, persuasively, that the story of the product deserved days of polish while core product work sat unshipped. I gave it those days. I nearly shipped a week late because of it.

The uncomfortable part is that I knew better. Eight years of prioritization discipline, and I still lost the call to my own strongest instinct, in my own head, with no stakeholder to blame.

What I took from it: under deadline pressure you don't get to rely on in-the-moment judgment. Pressure recruits your best skills to argue for the wrong work. You need a rule written before week one. Mine is now blunt: work that blocks revenue outranks work that tells the story, every time, no appeals. Rules are cheaper than willpower.

Paying clients before the prize closed#

GiveFeedback had paying clients before the prize window closed, and of everything on the results sheet, this is the line I'd defend hardest. Money is the only feedback that can't flatter you. Rankings have politics, upvotes have friends, but an invoice paid by someone who could've said no is a fact.

It changed what the $100K meant, too. The prize landed as a bonus on top of a small working business instead of being the business.

I suspect real traction also read well to whoever judged (I can't see inside their scoring). But I'd make the same call if it were invisible: charging early forced product decisions that polish never would have. The first time someone pays, your roadmap stops being a wishlist and becomes a promise, and promises get kept in a different order than wishes do.

What I'd tell a founder entering Season 2 or later#

Five things, in the order I'd want them told to me.

  1. Pick a problem you can make scope calls on in minutes. Domain learning doesn't fit in the window. Judgment speed is the scarce resource; choose terrain where yours is fast.
  2. Charge money before you feel ready. Paying users before the deadline beat any feature I could've built with the same hours. Feeling ready is not a milestone, it's a mood.
  3. Write your priority rule before week one. Decide now what outranks what, because mid-competition you will be the least trustworthy judge of your own work. See the previous section for the scar tissue.
  4. Budget for the roughness. Six solo weeks against a clock costs more than the calendar suggests. Plan the recovery, tell the people around you, and don't schedule anything important for the week after.
  5. Assume the tool is a given. All 5,800 builders had the same Lovable I did. The differential isn't access to speed, it's what you point the speed at.

The quiet meta-lesson under all five: a competition like this doesn't test whether you can build. It tests whether you can operate, which is a different job that happens to include building.

Where to go from here#

If you want the numbers side of this story (what GiveFeedback charges, how revenue developed after the win), the GiveFeedback case study is the companion piece. If you're a founder who'd rather have a build run with this discipline than acquire it the six-week way, that's what my product and build engagements exist for. And if you're entering Season 2: good, enter. The clock is the best teacher I've had in years.

Operator notes, monthly.

Working notes on agentic marketing, Claude Code skills, and the operating models behind four ventures. It ships when there is something worth reading.

Subscribe free