Leads Were Flowing Before the Bug Was Fixed

We were 40 minutes into a debugging call. My developer had an HTTP 400 error staring him in the face. The create-assistant workflow was throwing errors. The frontend wasn't talking to the backend. The chatbot itself - the whole product - looked, from the outside, completely broken.

And then one of the guys on the call checked the leads dashboard.

Leads were coming in. Real ones. Names, emails, phone numbers - all captured and emailed out automatically, right there in the database, timestamped during the same call where we were trying to figure out why nothing worked.

Let that sink in for a second.

The product was broken. And it was generating leads at the same time.

The "Not Ready" Lie Founders Tell Themselves

I've been building software companies for a long time. I've had five SaaS exits. I've been the guy who took an agency from $250K a month to over a million a month. And I can tell you with complete confidence: I have never once worked on a product that was truly, fully, cleanly done at the moment it needed to ship.

Not once.

What I have done - and what kills more founders than almost any other mistake - is wait. Wait until the UI is clean. Wait until the edge cases are handled. Wait until that one integration works. Wait until the team stops finding bugs on the call.

That wait is the real bug. Not the HTTP 400.

Here's what I know from watching this play out over and over again: there is always something broken. That is the permanent condition of a software product. The question is never "is it broken?" The question is "does the one thing it needs to do to generate value actually work?"

In our case, that one thing was capturing leads. And it worked. It worked so well that leads were flowing into the database while we were actively debugging a different part of the same product.

What We Were Actually Building

The product is Galadon - an AI-powered live chat tool built for sales. Not customer support. Sales. There's a meaningful difference. Most chatbots on the market are designed to deflect - answer FAQs, route tickets, reduce support load. We're building something that converts. A chatbot that won't take no for an answer, that keeps the conversation moving, that pushes toward a booked call or a captured lead.

Live chat itself isn't a new idea. tawk.to, which is currently the biggest live chat platform in the world, has over 20% of the market and is installed on millions of websites. That market exists. It's proven. The question is just who owns the sales-focused slice of it.

During this call, while one of my devs was working through a Bubble workflow issue and the other was debugging the API calls, someone in the session pulled up the leads panel. Two leads had come in during the call itself - captured during our own testing. The email was sent, the data was in the database, the phone numbers were there. The lead capture loop was fully functional.

We'd been so focused on what was broken that we almost missed what was working.

The Mistake I Made Before - So You Don't Have To

A while back, I helped a software company book meetings and generate $70K in pipeline. The only problem? The software didn't work well enough to run a live demo. We closed about $5K on the strength of the promise alone. The rest didn't get over the line. The business shut down.

That story isn't about bad cold email or bad sales. The outbound was working fine. The marketing was working fine. The product was the problem - and the product problem wasn't that it was buggy. It was that we kept trying to sell a complete product before we'd validated whether the core value proposition actually delivered.

I think about that constantly when I'm building Galadon. Because the failure mode there wasn't "we launched too early." The failure mode was "we oversold something that couldn't deliver the specific outcome we promised." That's different.

There's a version of "not ready" that's legitimate: your product can't do the one thing it's supposed to do. Don't launch that.

And there's a version of "not ready" that's a cognitive trap: everything works except for three features you wish you had, two UI polish items, and that one Slack integration that keeps throwing errors. That version? Ship it.

Define the One Thing

On our call, one of the developers raised a fair point. He said - paraphrasing - that he wasn't comfortable calling it complete while certain things were still unresolved. And I get it. That's the engineering instinct, and it's a good one. You don't want to ship garbage.

But we talked through the product roadmap and I kept coming back to the same question: what does a user need to get value on day one? For Galadon, the answer is: a chatbot that captures leads and doesn't let visitors bounce without giving up contact info. That works. That was working during the debugging session.

Everything else - the Slack integration, the multi-workspace feature, the streaming text animations, the green online indicator dot, the clickable links in responses - those are future sprints. Real ones. They matter. We'll build them. But none of them are the thing that makes a user pay.

When I built the original Galadon, it took about two months to get to MVP. NeedShark - another product I built - took close to nine or ten months. Omni, my AI content tool, took almost a year before it was launchable, and I spent around two and a half years on it total. I've been on both sides of this. The projects I dragged out never shipped better because I waited. They just shipped later.

The fastest indie developers I've watched - the ones who ship a product in an afternoon and rack up hundreds of users before the week is out - they don't move fast because they're better engineers. They move fast because they've made peace with the idea that "done" is not a real state. Working is the only state that matters, and working means: does it do the one thing?

What "Partially Broken" Actually Looks Like in Practice

I want to be specific here because I think this concept gets misused. "Ship before it's ready" has become startup cliché at this point, and people hear it and think it means "launch a broken product and let users suffer through it." That's not what I'm saying.

Here's what partially broken looked like on our call:

• Working: Lead capture, email delivery, AI chatbot responses, the system prompt enforcing short conversational answers, model implementation, API usage tracking, the core chat experience.
• Not working: The create-assistant workflow throwing HTTP 400 errors, the frontend not correctly passing certain parameters through Bubble, the Slack integration incomplete, some edge case error states visible to users instead of graceful fallbacks.

The "not working" list is real and we're fixing it. But none of those broken items prevent a user from dropping the widget on their site and capturing leads from their traffic tonight. The lead flow - which is the core value proposition - works.

That's the filter. Go through your product right now and ask: what does a user need to do to get the thing they're paying for? Is that path functional end to end? If yes - ship it. Everything else is a future sprint.

The Market Isn't Waiting for You to Be Ready

Here's some context that came up during the call. tawk.to - the current market leader in live chat - is 100% free to use. They make their money on hired chat agents at $1 per hour, so businesses that don't want to staff the chat themselves can outsource it through tawk.to directly. It's a smart model. And they have over 20% of the global live chat market as a result.

That market exists and it's massive. There are roughly 25 million websites using some form of live chat right now if you extrapolate from the market share numbers. Twenty-five million. Most of those tools are built for support, not sales. The opportunity for a sales-first chatbot - one that qualifies leads, pushes toward booked calls, and doesn't just answer FAQs - is genuinely wide open.

But here's the thing: that opportunity doesn't care about my Bubble workflow errors. The market doesn't pause while I fix the HTTP 400. Every day I'm not capturing leads from real visitors, I'm effectively donating that data to the version of me that ships.

I've been mapping out the marketing for months while the dev team builds. LinkedIn scripts, cold email sequences, ad creative, YouTube content - all of it is sitting ready to go. The moment the core product is stable enough to put real traffic through it, we go hard. Not "when it's perfect." When the lead capture works and the chatbot can hold a conversation. Which, as it turns out, it already can.

What to Actually Do With This

If you're building something right now and you're waiting, here's the exercise I'd push you to do:

Write down the one sentence that describes what your product does for a user. Not the roadmap. Not the vision. The one sentence that describes what happens for a user who signs up today with what you have right now.

If you can't write that sentence, your product isn't ready. Go fix the thing that would let you write it.

If you can write it - if there's a real outcome a real user can get from what you have today - then your product is ready. Ship it. The bugs you're staring at are version 1.1. The users you're not acquiring because you're waiting are gone forever.

The leads that came in during our debugging call were the clearest possible proof of this. The product didn't know it was broken. It just captured leads anyway.

Don't let the perfect version of your product steal the pipeline that the working version could have had today.

If You're Still Building Your Outbound While You Build the Product

One thing I do consistently - and I was doing it during this same period - is keep the outbound engine running in parallel with product development. You don't have to wait for a finished product to start building a pipeline. By the time the product is ready to demo, you want leads already warm.

If you're in that stage right now, a few things that can help: ScraperCity's B2B lead database is what I use to pull targeted prospect lists fast - unlimited access, no per-lead pricing nonsense. Pair that with a tool like Smartlead or Instantly to run the actual send, and you can have a working outbound campaign going while your dev team is still closing tickets.

And if you're looking for the actual scripts to run those campaigns, grab my top 5 cold email scripts - these are the templates I've used across multiple product launches to book meetings before the product was "ready." The 7-Figure Agency Blueprint also walks through how I sequenced marketing and product development in parallel when we were scaling.

The point is: don't let dev timelines become an excuse to pause the top of the funnel. Build both in parallel. You'll thank yourself when the product finally ships and there's already a list of people waiting to try it.

Because the alternative - waiting until everything is perfect to start generating interest - means you'll launch into silence.

And silence doesn't pay the bills. Leads do.