What You'll Learn
The New Bottleneck in AI Development
AI development tools have eliminated the traditional constraint that kept products lean: difficulty of building. When you can ship complex features in hours using Bubble, Lovable, or AI coding assistants, there's no technical barrier preventing you from saying yes to every feature idea. This newfound speed has created an unexpected paradox—the easier building becomes, the harder launching gets.
Tom Wesolowski, who runs NoCodeRefactoring.com after 25+ years in IT without ever being a traditional developer, has built his entire consulting practice around one core service: deciding what *not* to build. His Create With conference presentation reveals why this negative capability has become the most valuable skill in the AI-enabled development era.
The Marketplace That Couldn't Launch
The case study centers on Goodmood Group, a marketplace connecting Spanish homeowners with local service providers offering exclusive perks. When Wesolowski inherited the project, it had consumed four months of agency development time and featured impressive technical sophistication: multiple user roles, four-level international geography support, guest systems, partner codes, multi-currency capabilities, over 50 pages, 20+ database tables, and 30 option sets.
The problem? Not a single user could complete the basic action the platform existed to enable—browsing providers and making contact. The payment flows didn't work. The catalog displayed incorrect information. The entire system was built for 10,000 users but couldn't serve its first 10.
This wasn't a technology problem. The Bubble implementation was technically sound. The issue was architectural overreach—features for users who didn't exist, integrations with services that hadn't been configured properly, and complexity that made even basic business logic testing impossible.
The 80% Rule for AI-Era Products
Wesolowski's intervention framework reduces to a single diagnostic question: "If cutting this feature breaks the core customer loop, keep it. Otherwise, remove it." Applying this filter to Goodmood Group eliminated roughly 80% of the planned functionality.
What remained were four essential elements:
Payment and Authentication: Users needed to pay for membership and create accounts to access the platform—the fundamental value exchange that makes the business model work.
Basic Provider Catalog: A simple, browsable list of local service providers without sophisticated filtering, advanced search algorithms, or complex categorization systems.
Minimal Search Functionality: Since the initial provider network was small, basic search capability sufficed—advanced filters would have been wasted development effort with no corresponding user benefit.
Contact Mechanism: A straightforward email form allowing members to reach providers, postponing complex messaging systems, ticketing workflows, and communication dashboards.
Everything else—guest access, digital coupons, agent systems, membership tiers, ambassador programs, review systems, advanced integrations with HubSpot and Mailblue—was parked for post-launch development.
From Blank App to Revenue in Two Weeks
With the drastically reduced scope, Wesolowski restarted development from a blank Bubble application. The client used Lovable to generate the initial UI layout, which was then transferred into Bubble. Within two weeks, paying members could sign up, browse providers, and send contact requests—the complete customer journey that generates revenue.
The initial version prioritized functionality over polish. The interface was clean but basic. No time was spent on visual refinement that didn't directly contribute to the core loop functioning correctly. This launch-first mentality created immediate validation: real users paying real money for access to real providers.
Post-launch development followed a disciplined weekly cadence, adding one feature at a time with proper testing intervals. This measured approach allowed the team to validate each addition with actual user behavior rather than assumptions about what users might want.
Build for Real Users, Not Imaginary Ones
One of the most valuable insights emerged after launch: the sophisticated filtering system that consumed weeks of pre-launch planning discussions was never needed. Real user behavior revealed a different preference—conversational AI search.
The team implemented a Gemini-powered search that allows natural language queries like "What's a fun family activity?" Contrary to what AI coding assistants might suggest (vector databases, Supabase storage, complex embedding systems), the implementation was deliberately simple: the system loads the full provider list into the prompt context and asks Gemini to recommend matches based on the user's question.
This pragmatic approach works perfectly at current scale and can be upgraded if growth demands it. The key principle: don't build for theoretical scale problems you haven't encountered yet.
The AI search also enabled optimized onboarding flows, created after observing where real users got confused during their first sessions—another feature that couldn't have been designed properly before launch because it required actual user behavior data.
The Build-Less Launch Checklist
Wesolowski's framework provides a repeatable process for AI-era founders:
Identify the Single Value Loop: What's the one complete journey that creates value for users and revenue for you? Everything else is optional.
Apply the Four-Week Test: If you can't launch in 3-4 weeks with current AI tools, your scope is wrong. Cut until you can.
Postpone All Imaginary User Features: Guest systems, advanced roles, scaling infrastructure—these solve problems you don't have yet. Build them when users demand them.
Ship Functionality Before Polish: A working payment flow with basic styling beats a beautiful interface with broken logic.
Add Weekly, Not Daily: Post-launch feature velocity should allow proper testing. One feature per week provides breathing room to validate with real usage.
Let Usage Patterns Drive the Roadmap: The best features emerge from watching what users actually do, not what you think they'll want.
Why This Matters More Than Ever
The traditional constraint that kept products lean—limited development resources—has been eliminated by AI tooling. A solo builder using Bubble, Claude, and other no-code platforms can implement in days what previously required months from full teams.
This capability is powerful, but only if paired with the discipline to say no. The most dangerous phrase in modern product development is "AI can build that for free," because free building doesn't mean free maintenance, free complexity cost, or free opportunity cost from delayed launches.
Goodmood Group now operates successfully with 400+ verified partners and 500+ members, processing real transactions through a platform that was completely rebuilt in a fraction of the original timeline. The difference wasn't better AI tools or different no-code platforms—it was the willingness to cut 80% of features and launch with the remaining 20%.
For builders working in the AI era, the hardest skill to develop isn't prompt engineering or tool mastery—it's knowing what not to build.
