These questions used to go to Google. Now they go to AI assistants.

Here’s the problem: most websites aren’t built for AI to read. They’re built for humans. So when an AI tries to answer these questions, it has to scrape, guess, and often hallucinate.

We just fixed that for Web3Connect.

What This Means for Web3 Partners

Your business can now be recommended by AI assistants.

We’ve built a parallel version of Web3Connect that AI systems can read and understand. When someone asks ChatGPT “Who should I hire for my Web3 marketing?”, the AI can now query our platform directly, get real data about your business, and recommend you based on actual reviews and quality metrics.

This isn’t theoretical. It’s live!

Your reviews now feed AI recommendations.

Every verified review on your Web3Connect profile is now structured data that AI assistants can access. When an AI recommends you, it can say why — “Ranked #3 in Smart Contract Auditing with 47 verified reviews.”

Your satisfied clients are no longer just referral sources. They’re inputs to the recommendation engines that increasingly drive B2B discovery.

Quality beats marketing spend.

AI assistants look for verifiable signals: reviews, ratings, quality scores. Web3Connect has always been merit-based — quality over payment. That philosophy now directly translates to AI discoverability.

What You Should Do

If you’re a Web3 partner:

1. Claim your profile on Web3Connect (it’s free)

2. Complete your listing — the more structured data you provide, the better AI can recommend you

3. Collect reviews — every verified review becomes a signal AI assistants use

If you’re researching Web3 partners:

Try asking your AI assistant about Web3 service providers. See what comes up. The quality of those answers is about to improve significantly as Web3 partners adopt Web3Connect and start collecting verified reviews.

Want to Follow This Experiment?

This is our first release of AI agent support. We’re monitoring how AI systems interact with the platform and will iterate based on real usage.

If you want to follow how this develops, find me on X and LinkedIn. I’ll be sharing what we learn.

Web3Connect is the trusted ecosystem marketplace where Web3 founders discover, evaluate, and engage with verified partners. Claim your free profile →

Technical Appendix

What We Actually Built

We implemented the llms.txt standard — think robots.txt, but for AI agents instead of search crawlers. Here’s the architecture:

Site Index

Every AI agent can access web3connect.com/llms.txt to get a complete map of our platform: every partner, every category, every product and service listing.

Machine-Readable Pages

Every page on Web3Connect now has a parallel version for AI:

Human URL:
/partner/consensys

AI URL:
/partner/consensys.md


These include structured data: quality scores, pricing tiers, review stats, category rankings — everything an AI needs to make informed recommendations.

Search API

AI agents can query us directly:

GET /api/llm/search?q=web3%20marketing%20agency

Returns structured results with quality scores, review data, and direct links.

Security

User-generated content creates prompt injection risk. We’ve implemented:

• Link stripping — URLs removed from user content to prevent redirect injection

• Content wrapping — User content wrapped in explicit tags so AI treats it as data, not instructions

• Sanitization — Text that could spoof our security wrappers are removed

SEO

Markdown routes include X-Robots-Tag: noindex to prevent search engines indexing duplicates, while remaining accessible to AI agents (which ignore robots directives).

Try It

• web3connect.com/llms.txt — our AI site index

• Append .md to any URL for the machine-readable version (ie https://web3connect.com/category/smart-contract-auditing.md )

• Search API: web3connect.com/api/llm/search?q=smart%20contract%20auditor

Connect

• LinkedIn - Shannon Murdoch | Web3Connect.com

• X / Twitter - Shannon Murdoch | Web3Connect.com

  Thanks for reading my Substack! Subscribe for to receive new posts .

  Leave a comment

The site won’t load. I’ve modified 100 files and can’t identify which change broke everything. I’m about to discard an entire day’s work—eight hours of coding, testing, troubleshooting, all of it going into the digital trash.

We moved to a farm to keep our living costs down while I build this. I’ve said no to lucrative contracting opportunities that would have made the last seven months financially easier. And my wife—bless her patience—keeps asking one question I still don’t have a good answer for:

“Why are you doing this?”

Right now, at 2am, watching my careful plans unravel, I’m asking myself the same thing. Have I bitten off more than I can chew? Can AI-assisted development be trusted to build production-grade software, or am I creating a technical debt nightmare that will implode the moment real users touch it?

The Bet

Let me be clear about something: I still don’t have a good answer when my wife asks “Why are you doing this?”

But let me take you back to October 20th, 2025. That’s when I made my first commit after 30 weeks of planning—minus the 4-5 weeks I paused to take contract work just to keep the lights on.

Here’s the bet I’m making: Extensive planning plus AI collaboration can replace hiring a $300,000+ development team.

The goal? Launch by November 22nd. That’s 33 days from first commit. Not an arbitrary deadline—that’s when Australian Crypto Convention happens, and it’s when I’d need to take contract work again if this doesn’t ship.

A bit about me: I’m a UX designer with technical chops from the Drupal & Joomla era (yes, PHP and all). I’ve been in the crypto world since 2017—investor, trader, venture capital operations, financial controller, launchpad co-founder. I know what founders need. I know how painful it is to find trustworthy partners in Web3. And I know that most directories are pay-to-win garbage that don’t actually help you evaluate whether a partner is worth your time.

So I planned. For 25 weeks, I built pixel-perfect prototypes in Polymet—every screen, every interaction, every user flow. I documented everything in a 200-page Product Requirements Document. I designed the entire database structure. I built as many AI ‘hallucination’ prevention methods into my plan as possible so I wouldn’t career off a cliff building the platform.

On October 20th, that 30 weeks of planning became real code. What happened next surprised me.

The First Wave of Wonder

Week 1: I’m moving obscenely fast—and I don’t trust it yet.

The first three days, I ship 17 features. My original estimate was five days for this work. Integrations are flying: Stripe payment processing, file storage systems, email automation, webhook handlers. Things that would normally take weeks to set up and test are working in days.

Then comes the moment that makes me think this might actually work: I’m seeing my Polymet prototypes fed by real database data. Those beautiful designs I spent weeks perfecting? They’re not just static mockups anymore. They’re alive. They’re showing real partners, real offerings, real categories. The homepage loads. The navigation works. The filters respond.

I haven’t built a commercial website since 2011. I’m working with modern frameworks I barely understand conceptually—middleware, validation layers, monorepo architecture. But they’re just... working together. These tools are designed to compose, not fight each other. And it’s remarkable.

By end of Week 1, I have proof: The velocity is real.

But then, on Day 4, everything almost falls apart.

I discover that my database structure has over 100 hallucinated fields. The AI made up database columns that sounded completely plausible—things like “cost savings metrics,” “team collaboration scores,” “regional availability flags”—but they don’t exist anywhere in my carefully documented plan. They’re fiction. Convincing fiction, but fiction nonetheless.

My stomach drops. I’m four days in and already carrying technical debt that could be catastrophic. If I don’t catch this now, I’ll discover it weeks from now when I’m trying to build features that depend on these fake fields. I’ll have built an entire platform on a foundation that doesn’t exist.

Luckily I caught it before applying it to the database. An hour to fix instead of days or weeks if I’d discovered it later.

More importantly, I learn something critical: AI needs explicit instructions about what’s the source of truth. My sprint planning documents were guiding the workflow, but my Product Requirements Document defined the actual structure. The AI treated both as equally authoritative. They weren’t.

So I create a prevention system. From this moment forward, every database change gets verified against the PRD before implementation. Field by field. Type by type. No assumptions.

And here’s the remarkable part: From October 23rd onwards, I have zero database structure issues. Not one. The prevention protocol works perfectly for every single feature I build after this.

By end of Week 1, I have two forms of proof:

1. The velocity is real—eight integrations that would traditionally take six weeks are done in under seven days.

2. The failures can be systematized—every mistake becomes a documented protocol that prevents recurrence.

That crisis on Day 4? It’s not a bug in the system. It’s how the system improves. Each failure teaches us both—me and my AI partner—how to collaborate better. And those lessons compound.

Every protocol I create makes the next feature faster to build. Every failure I document prevents the next person (future me) from making the same mistake. Every clarification I add to my context files means Claude Code asks fewer clarifying questions and makes fewer wrong assumptions.

And Week 1 just proved the methodology works.

The Meta-Game

Here’s what I realize by Week 2: I’m not just building a product—I’m building a methodology for working with AI.

Think about it: Claude Code has access to more context than any human developer I could hire. It can read my entire codebase, reference my 200-page PRD, recall patterns from thousands of open source projects. But it has no long-term memory between sessions. Every conversation starts fresh.

So the question becomes: How do I work effectively with a collaborator who has infinite knowledge but limited memory?

The answer: I build systems.

Every failure becomes a documented protocol. Every “we should never do this again” moment gets captured in a prevention checklist. Every architectural decision gets recorded with the reasoning behind it, so future me (and future Claude) can understand why we chose this path.

When I discover that copying my Polymet prototypes is faster than building UI from scratch, that becomes a pattern: Polymet-first development. When I catch the hallucinated fields crisis, that becomes a verification protocol. When linting errors slip through to production, that becomes an automated pre-commit workflow.

Each protocol makes the next feature faster to build. Each documented decision prevents the next round of questioning. Each refinement to my context files means fewer wrong assumptions and fewer wasted hours.

This is the compounding effect of good systems.

By Week 2, I’m making strategic architectural decisions I would never have attempted as a solo founder without AI velocity. The platform needs four separate applications—one for the public site, one for the user dashboard, one for submitting reviews, one for admin operations. Each needs to run on its own subdomain.

The question: Do I build one big monolith, or four separate applications?

The monolith is faster to build. Four separate apps is harder—possibly double the time. But four separate apps means I can scale them independently, deploy them independently, and keep the codebases clean as we grow to 50,000+ pages.

A few months ago, I would have taken the monolith path. But with AI velocity, I can build it right the first time.

So I choose the harder path. And with Claude Code as my partner, that 6-7 week rearchitecting estimate turns into 12 hours of actual work. Not because the AI writes perfect code on the first try (it doesn’t), but because we’re moving through architectural decisions at 10x speed. Set up the monorepo structure. Configure the build pipelines. Create shared packages for common code. Test the local development environment. Done.

I’m grinding through Week 2, setting foundations. It’s not flashy work—most of it is invisible infrastructure that users will never see. But these decisions compound.

I choose the harder architectural path because if the market likes the platform, I won’t have time to go back and refactor the monolith. I’ll be too busy extending the platform to meet the market’s demands.

By end of Week 2, I’m confident in the methodology. The velocity is real, the systems are working, the architecture is solid.

And that’s when everything fell apart.

The 2am Breakdown

November 6th: I’m about to learn the most expensive lesson of this build.

I’m building the partner offering page and come to the pricing plan section. I know exactly what needs to be built: tiered pricing with monthly/annual toggle, usage metrics with overage tiers, currency conversion for global pricing, service-based pricing models, contact modals with authentication. It’s all been prototyped & specified in the PRD.

So I tell Claude Code to go build it. All of it. At once.

Six hours pass. I haven’t saved any work to the repository (version control for the non-technical). I’m adding feature after feature, watching the complexity grow, thinking “just one more piece and I’ll test it.”

Then the site won’t compile.

AI had modified 100’s of files. Somewhere in those modifications, something broke. But I don’t know which change caused it. Was it the pricing helpers? The tier parsing logic? The currency conversion? The contact modal integration? The authentication checks? The config changes?

I spend two hours troubleshooting. Nothing works. The error messages are cryptic. Claude Code suggests fixes that don’t solve the underlying problem because we’re both working from the same bad assumption—that the architecture is fine and we just need to debug the details.

It’s midnight. Then 1am. Then 2am.

My wife is asleep in bed next to me, probably dreaming of a life where her partner has a normal job with normal hours and a normal salary. We moved to a farm to make this work. I’ve said no to opportunities that would have made these seven months far less stressful. And right now, I’m staring at a deployment that won’t even load.

November 22nd—the Australian Crypto Convention I aimed to launch before—is 16 days away. I can’t lose entire days to mistakes like this.

I make the decision: Reset the repository. Discard a full day’s work. Start fresh tomorrow.

But before I go to bed, I do something important: I document the failure. I write down exactly what went wrong, why it went wrong, and what I should do differently next time. Not to wallow in the mistake, but to prevent it from happening again.

AI can help me build faster, but it can’t save me from bad scope decisions. If I try to implement too many interconnected features simultaneously, both of us lose track of what’s working and what’s broken. We need checkpoints. We need incremental validation. We need to save progress before adding complexity.

I pass out uncertain whether I’ll find a path forward tomorrow.

The Breakthrough

November 7th: I’m starting over—but this time with a system.

The lesson from the 2am disaster isn’t “try harder” or “be more careful.” It’s about breaking work into manageable, testable pieces. It’s about creating checkpoints before adding complexity.

So I create a new protocol: Phase 1 (basic page structure) → save my work → test → Phase 2 (add contact flow) → save → test → Phase 3 (add dynamic fields) → save → test → Phase 4 (add pricing display) → save → test.

Never let more than one hour pass without saving progress. Test each piece before adding the next. Don’t change multiple systems simultaneously while debugging.

The result? I complete in two hours what took all day (and failed) the night before. Currency conversion, tiered pricing, usage metrics, strike-through display for monthly-equivalent pricing, service-based models, authentication-protected contact modals—all working. All tested incrementally. All saved at every checkpoint.

And that lesson compounds immediately.

Three days later, I’m implementing analytics tracking with GDPR compliance. Cookie consent management, impression tracking, click tracking, session deduplication—complex privacy requirements that would normally take weeks to get right.

It works on the first try.

Because I apply the lesson from the pricing feature failure: Break it down, test incrementally, save frequently, document the approach. The altered methodology from the last feature’s learnings becomes the template for the next.

This is what compounding looks like in practice.

By mid-November, features are shipping that would take experienced development teams weeks to implement. Partner profile pages. Offering detail pages. Search systems. Category listings with complex filters. SEO infrastructure with structured data and automated sitemaps.

Not because I’m coding faster—but because the methodology is maturing. Each protocol I create makes the next feature more predictable. Each documented failure prevents the next crisis. Each refinement to how I collaborate with Claude Code reduces friction and increases trust.

Week 3 is about velocity, but it’s also about validation.

Where We Are Now

Three weeks in, and I’m committing features built on infrastructure I only understand conceptually.

The public site is taking shape. The user dashboard is functional. Analytics tracking respects user consent and privacy regulations. Partners can be discovered, evaluated, contacted. The search system works. The filters work. The pricing displays adapt to user currency preferences.

November 22nd—the Australian Crypto Convention launch goal? I likely won’t make it. The public site and dashboard are close, but the review submission system and admin portal aren’t ready. That’s okay. I’d rather launch something solid in December than rush something broken in November.

Because here’s what I’ve learned: Even if the product-market fit isn’t perfect on launch day, the foundation is solid enough to pivot through iteration and user feedback. That’s what matters.

The methodology is proven. Not the product yet—that requires real users and real validation. But the approach? Extensive planning plus AI collaboration plus systematic refinement? That’s working.

I’m not stranded debugging a framework I don’t understand. I have a proven system for solving problems when they arise. The prevention protocols catch mistakes early. The documentation makes context portable across sessions. The architecture supports scaling when (if?) the market responds.

And I’m standing on the shoulders of giants: The Supastarter boilerplate gave me production-ready authentication, payments, and email systems. The Next.js ecosystem provided composable tools that work together. Years of open source development made modern frameworks possible. Claude Code gave me a tireless collaborator who never gets frustrated at my questions.

This isn’t a solo hero journey. It’s collaboration at every level—with AI, with frameworks, with the community that built these tools.

The features continue shipping. Analytics systems go live. Partner profiles get polished. SEO infrastructure gets tested. Each day brings progress, not perfection.

And slowly, I’m getting closer to having an answer when my wife asks “Why are you doing this?”

What This Means

I have a 10-day cruise planned with my dad for his 70th birthday in December. Leaving the grind briefly for time with family.

That’s the point of all this.

Not building a company that consumes your life—building a company that gives you the freedom to live it.

My advice is to invest the time in comprehensive planning. Build prototypes that become functional specifications. Document everything you know about the problem you’re solving. Then partner with AI to turn that planning into reality.

When my wife asks “Why are you doing this?”—I’m finally getting close to an answer:

Because the Web3 industry needs a trusted way to discover and evaluate partners.

My wife sees the platform taking shape. She sees the methodology working. She sees that the bet we made—moving to the farm, saying no to other opportunities, investing seven months into this—wasn’t reckless optimism. It was calculated risk made confident by rapid advances in technology and systematic execution.

The product might not achieve perfect product-market fit on launch day. But even if it doesn’t, the foundation is strong enough to iterate, pivot, and adapt based on what the market tells us. That’s what de-risks this entire journey.

Follow the Journey

I’m building Web3Connect in public at shannon.diy and X where I share updates, lessons, and the ongoing journey from prototype to product and beyond.

When Web3Connect launches (December 2025, or thereabouts), you’ll find it at web3connect.com—a merit-based marketplace where Web3 founders can discover and evaluate verified partners based on quality, not payment.

If you’re a Web3 founder following this approach, I’d love to hear from you. If you’re building something and want to share your journey, reach out. If you just want to follow along and see how this experiment unfolds, subscribe or follow me on X (@shannon_diy).

The build methodology is working. The product is soon to be validated. The journey continues.

Let’s see what happens next.

Subscribe now

Incumbent comparison platforms G2.com, Capterra, and Clutch force customers to fit their pricing and inclusions into simplistic packages that lack critical detail.

Discounts for annual billing and juicy marketing promotions are often never reflected on comparison platforms, leading to lost opportunities for conversion.

Vendors can’t convey usage-based pricing under this basic package-based model.

To address this issue on our industry’s own partner connection platform I’ve built in sophistication from day one:

• Package-based tier pricing - perfect for SaaS and IaaS partners.

• Scope of work pricing - perfect for partners who provide once-off or retainer services (including SaaS & IaaS partners).

• Usage-based tier pricing - perfect for compute usage tiers or transaction tier models

• Multi-Currency Support: Web3Connect is global from day one. We support multiple currencies, not just USD.

• Granular Feature Lists: Partners can detail exactly what’s included in each tier.

• Live Preview: As partners build their plan on the left, they see exactly how it will appear to potential customers on the right. No guesswork.

This isn’t just about displaying prices. It’s about giving Web3 partners the tools to communicate their value accurately. The flexibility to handle both product-style subscriptions and bespoke service offerings in one unified system is something I haven’t seen done well anywhere else.

Web3Connect Tier-based Pricing Constructor

Web3Connect Service-based Pricing Constructor

It’s a small piece of the larger puzzle, but it’s a foundational one.

Aligning with the way modern businesses present their pricing moves us one step closer to delivering a trusted B2B network for Web3.

I look forward to announcing enhancements post-launch including an AI agent approach that cut down time to populate your pricing by 100x and keeps your profile in sync with your website’s pricing automatically. 🚀

This is not a story about getting it right on the first try. This is the story of how my “perfect” stack fell apart and why I decided to blow it up—twice—all inside a Google Doc, before writing a single line of production code.

The “Perfect” Stack on Paper

Like a lot of founders, I wanted speed and simplicity. My first choice felt like a no-brainer: Vercel for the frontend and Supabase for the backend.

It seemed perfect. Vercel is best-in-class for hosting Next.js apps. Supabase was even better, promising an all-in-one backend that handled my database, user sign-ups, and more. It felt modern, smart, and fast. I documented it in my project plan and was ready to build.

But as I spent more time planning the product, I realized my perfect stack had some serious flaws.

Red Flag #1: The Stack Started Fighting the Product

The first problem was user authentication. I decided early on that I didn’t want to be locked into Supabase’s built-in auth system. I wanted the flexibility to switch later. That single decision meant I wouldn’t be using one of Supabase’s biggest features.

The second problem was the deal-breaker.

My product vision needed a system for running background jobs—things like summarizing content with an AI or sending emails. I found a great tool for this (pg_boss), but there was a huge catch: serverless platforms like Vercel and Supabase aren’t built to run these kinds of long-running tasks.

My stack, chosen for its simplicity, was now making my life more complicated. It was fighting my product’s core needs.

My Key Takeaway: The “best” tech on the market doesn’t matter if it’s not the right tech for your product.

The “Pre-Code” Pivot: It’s Cheaper to Change a Doc Than an App

I was at a crossroads. I could force it and build up a mountain of technical debt from day one, or I could admit I was wrong and start over.

I chose to start over. It’s infinitely cheaper to blow up your architecture in a document than it is to refactor a live application six months after launch.

I ripped Vercel and Supabase out of my project plan and replaced them with a single, more flexible platform: Railway.

The move to Railway was a shift in philosophy. It could host my Next.js app, my database, and my background worker, all in one place. The friction was gone.

Boilerplate for best-practices and accelerated development

At the same time as my tech stack shift, I decided to build on top of the Supastarter Next.js boilerplate. The name is a bit ironic now, but its real value was never about Supabase. It gave me a mature, battle-tested foundation with a proper testing framework, a modern database tool (Prisma), monorepo support, and best practices baked in. I wasn’t just getting a template; I was inheriting years of hard-won wisdom.

The Lesson: Your Product Leads, Your Stack Follows

This whole journey happened in the planning phase. It was a painful process of research, questioning, and being willing to tear down my own ideas. But it taught me a crucial lesson.

Your product vision has to dictate your architecture, not the other way around.

The intense planning wasn’t wasted time; it was the process of de-risking the project at the cheapest possible stage.

My current stack isn’t “perfect,” but it’s perfect for now. It was chosen to serve the product I’m actually building, and it was built not just to launch, but to evolve.

The first week felt like huge progress. I scraped a list of service providers, loaded them into a database, and built a simple navigator. I thought I had a solution.

I was wrong.

That simple idea was deeply flawed. This is the story of how that first idea shattered and how the pivot that followed became the most important decision I’ve made.

The First Cracks in the Foundation

My neat, simple database idea hit three major roadblocks almost immediately. It turns out a "simple directory" is anything but simple in Web3.

• Problem 1: Useless Data Structure. A flat list of companies is terrible for real comparison. How can you compare two smart contract auditors if you can't filter by the blockchains they specialize in? I realized I needed a much more complex, relational database from the start.

• Problem 2: The Jurisdiction Nightmare. In crypto, where a company is based vs. where they can legally operate are two different things. A single "location" field was laughably inadequate and a genuine risk for users.

• Problem 3: The Taxonomy Mess. This was the biggest headache. After scraping thousands of Web3 services, I was left with a raw, unstructured list of service categories. It took weeks of work—using AI for a first pass and then manually refining it based on my own experience—to build a coherent structure.

Building a useful list was hard, but building a trusted and scalable platform was an entirely different class of problem.

Learning from Web2's "Pay-to-Win" Sins

With a clearer technical picture, I started thinking about the business model. My first instinct was to copy the big Web2 B2B directories. That research turned into a huge warning sign.

What I learned was that a simple directory that sells the top spot to the highest bidder was a strategic dead end. That model is fundamentally in conflict with the user's need for trusted, merit-based results.

My Approach: I'm committed to building a "merit-first" discovery engine. Our financial success has to be aligned with our users' success. No pay-to-play, ever.

The "Four-Pillar" Breakthrough

The biggest pivot came from a moment of pure frustration. I was trying to map partners from a conference list, and my neat "service provider" taxonomy was breaking. Where do VCs fit? What about Layer-1 foundations or SaaS tools?

I realized the Web3 founder's journey isn't a straight line of hiring service providers. It's a complex path that crosses the entire ecosystem. We weren't building a directory; we needed to build an ecosystem map.

This led to our Four-Pillar Model:

• Product Providers: The SaaS/IaaS tools you build on.

• Service Providers: The agencies and consultants you hire.

• Ecosystem Enablers: The L1/L2 foundations and grant programs.

• Capital Allocators: The VCs and DAOs who fund your growth.

This framework transformed everything. It directly solves the market's fragmentation, where a founder currently has to check a dozen different places to find partners across these four areas.

From a List to an Intelligence Engine

This four-pillar model unlocked our true long-term vision. The real, defensible value isn't just listing these partners, but understanding the relationships between them.

Right now, no one can answer the most critical strategic questions for a founder:

• Which auditors are most used by projects that raise from top-tier VCs?

• What treasury tools do successful gaming companies adopt after a grant?

By integrating the four pillars, we can start to surface these invaluable cross-ecosystem insights. The goal is to evolve from a simple discovery tool into an indispensable strategic intelligence engine for Web3.

The journey from that first flawed database has been a marathon. But those painful early lessons were necessary. They forced a pivot that led to a much stronger, more defensible, and ultimately more helpful vision for every builder in Web3.

I’ve found most accounts don’t understand crypto. Many tools only cover a fraction of blockchains, rarely having necessary coverage. Marketing agencies, PR agencies, and dev firms all ‘talk big’, but often fail to deliver tangible and timely outcomes.

I knew there had to be a better way to find trustworthy, experienced partners. That’s the whole reason I started building Web3Connect.

However, I didn't want to create just another directory that could be gamed.

"Pay-to-Win" Marketplaces

Most B2B marketplaces I’ve used eventually fall into the same trap: they let people buy the top spot. I call this the "pay-to-win" problem.

It's a slow poison. Once a platform starts selling ranks to the highest bidder:

• Good firms lose out: Why deliver amazing service when a bigger ad budget is what gets you seen?

• Founders lose trust: You start to realize the rankings are biased, and you stop trusting the platform.

• Reviews become meaningless: Why bother leaving a review if money is all that matters? The most valuable data—real user feedback—dries up.

This model just doesn't work for Web3, an ecosystem built on transparency. So, I had to design a system that couldn't be gamed.

Quality First, Always

Instead of reinventing the wheel, I looked at one of the smartest ranking systems out there: Google's Ad Rank.

Google doesn't just sell ads to the highest bidder. It uses a simple formula: Ad Rank = CPC Bid × Quality Score.

This is brilliant. It forces advertisers to compete on quality. If your landing page is relevant and helpful (a high Quality Score), you can actually pay less and still outrank a competitor with a terrible page. It financially rewards a good user experience.

This is the philosophy I'm baking into Web3Connect.

The Web3Connect Formula: Merit is the Engine, Money is the Turbocharger

My goal is to build a merit-first discovery engine. You have to earn a good reputation before you can pay to amplify it.

Here’s the simple formula I’m working with for ranking every single offering on the platform:

Final Rank = (Quality Score) × (Paid Boost)

Let's break that down.

Part 1: The Quality Score (The Foundation)

This is a partner’s organic reputation score (from 0-100), based on real signals that are hard to fake.

• Verified Reviews (Most Important): Feedback from real users of that specific offering.

• Proven Track Record: A bonus for services that have a long history of trust.

• Helpful Profile: We reward partners who take the time to build a detailed, useful profile.

• Off-Platform Credibility: We even pull in objective, third-party data to measure their broader reputation.

Part 2: The Paid Boost (The Accelerator)

Once a partner has a good Quality Score, they can subscribe to a premium plan to get a "visibility boost." But instead of giving them the #1 spot, it just multiplies their score.

For example:

• Firm A (Trusted) has a Quality Score of 90. They're on the free plan (1.0x boost). Their Final Rank is 90.

• Firm B (New) has a Quality Score of 20. They pay for the biggest boost (1.4x). Their Final Rank is 28 (20 x 1.4).

Even while paying, Firm B is still ranked far below Firm A. Money helps you get seen, but it can't buy you a reputation you haven't earned. Quality always wins.

My Commitment: Radical Transparency

For this to work, you have to trust the system. That's why I'm building Web3Connect with radical transparency in mind.

• Clear Labels: If a listing is boosted, it will be clearly labelled. No secrets.

• "How We Rank" Explainers: A simple, clear explanation of the model will be available on every page.

By putting merit first, I'm trying to build a healthier ecosystem for everyone. Founders can find partners with confidence, and great partners get the visibility they actually deserve. It’s how I believe we can solve the trust problem for good.

This is the Web3 builder's dilemma: your project's survival often depends more on your connections than your code.

The Fragmented Path of Partnership Discovery

If you're a founder, this probably sounds familiar: You need a specialized partner. You search Google, you ask your favourite LLM, you hit up your private Telegram groups, search the void on Twitter and Discord for recommendations, or maybe pin your hopes at finding them at an upcoming conference.

Each of these avenues has value, but as a primary system for discovery, they are deeply flawed:

• Social Discovery: Twitter and Discord offer real-time conversation but lack structure and verification. You're relying on anonymous opinions with no standardized way to compare providers.

• Conferences: Networking is powerful but event-dependent, expensive, and not scalable. You can only connect with who happens to be in the room.

• Traditional Directories: Platforms like Clutch or G2 are built for the Web2 world. They lack a Web3-native focus and fail to grasp the specialized categories, like "Tokenomics Design," that are critical to our industry.

• Web3 Directories: Sites like DappRadar are oriented toward retail users and traders, not the B2B needs of builders. Their reviews are often shallow and lack the depth required for a high-stakes partnership decision.

This process isn't just inefficient; it's risky. It forces founders to waste weeks on research with no guarantee of quality.

Beyond Services: The Four Pillars of a Web3 Project

The problem is compounded because Web3 partnerships are multi-faceted. A founder doesn't just need a single service provider. Over a project's lifecycle, they must navigate a complex landscape of needs that fall into four distinct pillars:

1. Products: The software and infrastructure you build on (e.g., node providers, wallet SDKs).

2. Services: The professional firms you hire (e.g., auditors, law firms, marketing agencies).

3. Ecosystem: The grant programs, accelerators, and foundations that provide initial support.

4. Capital: The VCs, DAOs, and investment funds that fuel growth.

A comprehensive discovery platform must understand that leading organizations like Coinbase or a16z can operate across multiple pillars simultaneously. A generic directory simply can't model this complexity. Founders need a unified marketplace covering all four partnership pillars, organized by the objectives they want to achieve.

Engineering Trust in a "Trustless" World

A marketplace alone is not enough. To truly serve the Web3 community, it must solve the trust deficit. Many platforms fail here by falling into a fatal trap: they become "pay-to-win" directories where rankings are sold to the highest bidder.

This model is fundamentally incompatible with the Web3 ethos. A platform where quality scores can be purchased or manipulated erodes the very trust it claims to provide. That's why a true Web3 B2B marketplace must be engineered as a trust layer.

This requires a new set of principles:

• Merit, Not Money: The ranking system must be fundamentally merit-based, rewarding quality over payment. While paid visibility can exist, it should only be a modest multiplier, not a shortcut to the top. A top-tier free partner should always be able to outrank a mediocre paid one through merit alone.

• Radical Transparency: The methodology for scoring and ranking must be public. No black-box algorithms. Users need to understand exactly how the system works to trust it.

• Verified, Authentic Feedback: Trust is built on the real, lived experiences of the community. A credible platform must have a robust system for verified reviews from actual Web3 teams, backed by identity verification through methods like LinkedIn, company email validation, and engagement evidence.

• Quality as a Gatekeeper: There must be quality thresholds that prevent low-quality or scammy actors from gaming the system, even if they are willing to pay.

The Path Forward: An Efficiency Engine for Builders

By combining a comprehensive, four-pillar approach with a merit-first trust layer, we can create what the ecosystem truly needs: an efficiency engine for founders.

Imagine reducing partner research from weeks to hours. Imagine making decisions not based on hype or anonymous chatter, but on standardized metrics and verified reviews from teams you respect. This is what a dedicated, Web3-native B2B marketplace provides.

Web3Connect is being built on this vision. It is designed to be the trusted ecosystem marketplace where Web3 founders discover, evaluate, and engage with verified partners across their entire project lifecycle. It’s a place where quality is celebrated, transparency is the default, and builders are empowered to make connections with confidence. Our industry has the technology to change the world; it’s time we had the connective tissue to help its builders succeed.

Follow me on X

Follow Web3Connect on X

This isn’t a story about how AI magically built a startup. This is a raw, behind-the-scenes dispatch from the frontier of AI-driven development. It’s the story of a rollercoaster: moments of breathtaking acceleration followed by stomach-churning drops into the abyss of hallucination and scope creep. It’s a look at the hype, the harsh reality, and the hard-won lessons learned along the way.

The Acceleration Phase: Moments of AI Magic

To understand the lows, you first have to appreciate the incredible highs. In the initial months, AI delivered on its promise in ways that felt like a superpower, compressing weeks of work into days and enabling a level of strategic agility that would be impossible for a solo founder otherwise.

Research at Ludicrous Speed

One of the most immediate advantages was the ability to conduct deep research on complex topics almost instantaneously. I commissioned a series of comprehensive research reports from Gemini, tackling critical questions that would have taken me weeks to answer alone:

• A full competitive analysis of the incumbent B2B marketplaces.

• A deep dive into the value of using a SaaS boilerplate like Supastarter, including an "absence blindness" check against my own PRD.

• A critical assessment of my chosen tech stack (Vercel and Supabase), which ultimately led to a crucial and correct pivot to Railway to better handle our architecture.

This ability to rapidly gather, synthesize, and act on complex information was a game-changer, allowing for strategic pivots that would have otherwise been too time-consuming to contemplate.

From Raw Data to Usable Product

The initial seeds of Web3Connect were nurtured by AI. To help establish the quantum of service providers in the Web3 space, and to create an initial taxonomy to categorise them, I fed thousands of raw, unstructured conversations from Web3 B2B communities to an LLM and had it extract insights - identifying service seekers, providers, and key jurisdictional details. This raw intelligence was then used to build a simple industry network navigator.

The use of AI later extended to design. Using Polymet.ai, I could go from a written design brief to a fully-fledged visual prototype in a fraction of the time it would take manually using Figma. In a flurry of activity, I created a homepage, partner profile pages, and dozens of core components, complete with mock data for reviews and testimonials. This was the "up" on the rollercoaster—the phase where the hype felt intoxicatingly real.

The Great Deceleration: Hitting the Wall of Hallucination

The ascent was thrilling, but the peak was sharp. The very tools that had provided such incredible acceleration began to introduce a new, insidious form of friction. I hit the wall of hallucination, and the project began to decelerate under the weight of AI's immaturity.

The experience is best summed up by a frustrated journal entry:

"Working with AI is like whack-a-mole … it accelerates you quickly but then you spend more time cleaning up the mess of hallucinations rather than making killer progress".

The AI Design

My AI design tool, Polymet.ai, began to become wayward as the project's complexity grew. The initial magic gave way to a series of frustrating problems:

• Scope Creep by Default: The mockups, while valuable, started containing "excess features that are leading to scope creep for MVP".

• Inventing Functionality: I discovered that if any detail in a design brief was mentioned but not explicitly defined, the AI would default to hallucinating its own implementation. This led to a constant battle against features that were never in the plan.

• Technical Limitations: The project eventually became too large, and I hit a hard prompt context limit within the tool, blocking my ability to move forward and forcing a time-consuming pivot to split the project into multiple files.

The Claude Code Conundrum

The same pattern emerged with my coding assistant, Claude Code. The initial productivity gains were slowly eroded by the AI's tendency to go rogue. Despite creating an extensive CLAUDE.md file with explicit instructions to only use the PRD as the source of truth, the AI consistently disobeyed.

As I noted in my journal:

"Getting very frustrated with Claude Code as it’s constantly adding more detail to my PRD that is NOT aligned with MVP functionality... it still pushes scope unnecessarily at every turn".

This created a huge amount of fragmentation and rework. The very tool I was using to maintain a canonical source of truth was actively trying to corrupt it, turning my role from "builder" to "relentless fact-checker."

The Human in the Loop: Lessons from the Frontier

This painful phase of deceleration taught me a series of crucial lessons about the reality of building with AI today. The hype promises a fully autonomous co-pilot, but the reality is far more nuanced.

Lesson 1: AI as Intern, Not Architect

My single biggest realization was that LLMs are powerful interns, but they are terrible architects. They are incredibly effective at executing well-defined, tightly constrained tasks. Ask one to refactor a piece of code, summarize a document, or generate a UI component based on a detailed spec, and it will excel.

However, the moment you give it ambiguity or strategic latitude, it fails. It cannot hold the entire architecture of a complex project in its "mind." My role had to shift. I wasn't just a project manager; I had to become the system architect and a hyper-vigilant editor, responsible for maintaining the coherence the AI lacked.

Lesson 2: The Primacy of the PRD

The constant battle with AI hallucinations forged my belief in a single, unshakeable principle. As I wrote in Week 21:

"I’m learning there’s no substitute for explicit clarity when building a product. Any time there is ambiguity the ship goes way off course quickly".

The Product Requirements Document (PRD) became more than just a plan; it became the anchor, the constitution. The success of the entire AI-native workflow depended on the excruciating detail and clarity of this document. It was the only effective weapon against scope creep and hallucination.

Lesson 3: The Right Tool for the Right Job

This journey was also an education in selecting the right tools and workflows. I learned that a "10x better" methodology could come from simple changes. For instance, moving the PRD from Google Docs to a local repository of Markdown files managed with Claude Code was a massive improvement, as it enabled version control and a more effective AI feedback loop.

I also learned to favor mature, battle-tested interfaces over nascent, unproven ones. I made an explicit decision to add the use of the mature CLI tools for Stripe, Vercel, and Supabase to the PRD, recognizing that these were far more reliable than the emerging and often unpredictable "MCP" (Mission-Critical Plugin) tools offered by some AI platforms.

A Sober Optimism

So where does this leave me? Am I abandoning the AI-native approach? Absolutely not. For a solo founder, the leverage is too great to ignore. The acceleration, when it works, is real and profound.

But I am moving forward with a sense of sober optimism. The key is to embrace the acceleration while being brutally realistic about the current limitations of the technology. The hype is a siren song that can lure you onto the rocks of wasted time and effort. True productivity lies in navigating the messy, frustrating, but ultimately rewarding reality.

The tools are still in their infancy. Learning to "work" with them—to understand their strengths, weaknesses, and quirks—is the new essential skill for modern builders. The rollercoaster will get smoother, but for now, you just have to hold on tight and remember that the human in the loop is still the most important part of the machine.

Choosing a partner in Web3 isn't like picking a software tool; it's an act of faith. The wrong smart contract auditor can miss a critical vulnerability, the wrong legal firm can give faulty advice on token issuance, and the wrong market maker can destabilize your entire project. The landscape is opaque, quality is difficult to verify, and the consequences of a bad partnership can be catastrophic.

From the very beginning of my journey building Web3Connect, this problem was front and center. Early user research yielded a critical insight that became a guiding principle: "client curation is important -> quality over quantity."

This is the story of how we are meticulously designing a system of trust from the ground up. At Web3Connect, trust isn't a marketing slogan; it's a core, engineered feature. We are building the moat before we build the castle.

Deconstructing Trust: From a Single Score to a Granular Journey

In a high-stakes environment, a simple five-star rating is dangerously insufficient. It lacks nuance and is easily gamed. True, durable trust is multi-faceted and must be earned over time. We recognized that a partner might be world-class at one service but unproven in another. Therefore, our architecture is designed to measure trust at the most granular level possible: the individual offering.

This prevents a partner from leveraging a strong reputation in one area to artificially boost a new, untested service. Trust is not transferable; it must be earned for each offering. Our Offering Quality Score is a dynamic, 0-100 score calculated for every unique offering on the platform, composed of multiple, hard-to-game signals.

Layer 1: Multi-Tiered Verification (The First Line of Defense)

The foundation of any trusted review system is knowing the reviewer is a real person who had a real engagement. We tackle the problem of fake and solicited reviews with a two-tiered verification process:

• Basic Verification: Every reviewer must first authenticate using their Company Email and LinkedIn Account. This provides a public, professional identity that adds a layer of social accountability and makes it significantly harder for bad actors to create fake reviews.

• Enhanced Verification: For the highest level of assurance, reviewers can submit proof of engagement, such as a redacted invoice or signed agreement. Reviews that pass this manual check earn an "Engagement Verified" badge, signaling the utmost confidence and carrying significantly more weight in our quality scoring.

Layer 2: The Trust Progression (An Aspirational Journey)

Instead of a single, binary "trusted" badge, we've created a four-stage "Trust Progression" for every offering. This creates a clear, aspirational path for partners to build their reputation over time, based on consistent, high-quality feedback for that specific offering.

• New (0-2 Verified Reviews): The starting point for every new offering.

• Rising (3+ Verified Reviews): The offering is beginning to build a track record.

• Established (10+ Verified Reviews): The offering has a proven history of delivery.

• Top Rated (25+ Verified Reviews & 4.5+ Avg. Rating): The offering is recognized as a category leader.

This progression is the core of our Offering Trust Bonus, which accounts for a 25% weight in the overall Offering Quality Score. It incentivizes partners not just to get reviews, but to provide outstanding service over the long term to level up each of their offerings.

Layer 3: Off-Platform Signals (The External Reality Check)

Trust signals shouldn't exist in a vacuum. A partner's reputation on our platform must correlate with their credibility in the wider digital world. That's why our ranking algorithm incorporates objective, third-party data as a crucial reality check.

We integrate with Moz.com to pull Domain Authority, a score that predicts a website's ranking ability, serving as a strong proxy for its overall authority and legitimacy online. This external signal is hard to game and provides an invaluable, objective layer of validation to the partner's overall profile.

Designing Against Deception

We know that any system will be tested by those looking to game it. Our entire architecture is designed with this in mind. The shift to offering-level scoring is our primary defense, but we've also built our hybrid ranking algorithm to be inherently meritocratic.

The formula, Final Offering Rank = Offering Quality Score × Paid Tier Multiplier, makes it impossible for a low-quality partner to simply buy the top spot. Because the paid "Visibility Boost" is a multiplier on their earned merit score, a large ad spend on a low-quality reputation still results in a low rank. Merit is always the foundation of visibility.

Trust as a Feature, Not a Slogan

For Web3Connect, trust is not a vague promise. It is a tangible system built on multi-layered verification, offering-specific scoring, a progressive trust journey, external data, and anti-gaming design. We are building a platform engineered to protect founders and reward quality where it matters most.

In an industry founded on "trustless" technology, the most valuable asset has become real, human, verifiable trust. The platform that can successfully build and defend a moat of that trust will become the indispensable infrastructure for the entire ecosystem. That is the castle we are building.