DEV Community: Michael Egberts

WAVE Coding: Why we built 78 integrations for AI instead of letting AI build them

Michael Egberts — Thu, 14 May 2026 19:38:45 +0000

Every week I see another "I built a SaaS in 4 hours with AI" post. And every week, the comments are the same: "Cool, but does the Stripe integration actually work?"

Usually it doesn't.

That's vibe coding. You prompt, you hope, and you pray that the AI correctly implements a payment flow it's never actually tested. It hallucinates webhook handlers. It guesses at email configs. It builds checkout flows that break on the first real transaction.

We took the opposite approach.

The puzzle piece pattern
We're building WebsitePublisher.ai — a platform where AI assistants build and publish websites and web applications through conversation. Available on 9 AI platforms (Claude, ChatGPT, Gemini, Cursor, Windsurf, GitHub Copilot, Grok, Mistral, n8n) via MCP protocol.
In the last 16 days, we shipped 78 integrations. Each one is a self-contained puzzle piece — proven software running on our web servers. AI doesn't generate the integration code. AI calls the integration.
Here's what that looks like in practice:

User: "I need a webshop with Stripe payments and order confirmation emails"

AI selects:
→ product-catalog (MAPI entity + helpers)
→ shopping-cart (session-based)
→ checkout-flow (orchestration engine)
→ stripe (payment processing)
→ invoice-generator (PDF + accounting)
→ email-templates (Resend rendering)

Result: 6 tested puzzle pieces combined into a working application.

Zero hallucinated Stripe webhooks. Zero guessed SMTP configs. The heavy lifting happens in proven software on the server.

Why this matters
The fundamental problem with vibe coding is that AI is asked to do two things at once:

Understand what you want (AI is great at this)
Implement reliable infrastructure (AI is terrible at this)

WAVE coding separates the two. AI handles #1 — understanding your intent and selecting the right puzzle pieces. The proven software handles #2 — the actual Stripe calls, the email delivery, the database queries.

What's in the 78 puzzle pieces
Some highlights from what shipped in 16 days:
E-commerce stack:
Product catalog, shopping cart, checkout flow, order management, inventory tracking, shipping (MyParcel), invoice generation, discount codes
Communication:
SMTP email, email templates, contact forms, multi-layer spam protection
Data layer:
Server-side rendering for SEO, batch update/delete endpoints, data grids with validation
AI layer:
Coach (guided website creation), concept generation, streaming chat
Platform hardening:
DNSSEC, request tracing, error envelope standardization, security hardening

Each piece follows the same pattern: a handler receives the endpoint, input, and project ID. Dependencies are explicit. No magic.

The results
In the same 16 days:

7 new customers onboarded
World Cup prediction game deployed for PSV Supporters (30,000 members)
Visual editor upgrade shipped
Coach AI guidance system improved

We're calling it WAVE coding

Not because it's a clever acronym. Because each application you build is a wave — one deliberate push that combines existing puzzle pieces into something new. Each wave builds on what came before.
Vibe coding is random energy hoping to land somewhere useful.
WAVE coding is deliberate momentum. 🌊

Curious what you think. Are you building infrastructure for AI to use, or letting AI build infrastructure from scratch?
websitepublisher.ai

We're now in Mistral's connector directory — here's what that means for AI-powered web publishing

Michael Egberts — Tue, 05 May 2026 11:54:06 +0000

Hook: WebsitePublisher.ai is a pre-configured Directory Connector in Mistral's curated MCP connector directory. That's a mouthful, so let me break it down: Le Chat users can now find us in their connector settings, click Add, complete OAuth, and immediately start building websites through conversation.

Key points to cover:
What a Directory Connector is vs Custom Connector
OAuth 2.1 + DCR auto-discovery
55+ MCP tools available
How it compares to our ChatGPT integration (Custom GPT = zero setup)
The 10-platform story
Link to setup guide: websitepublisher.ai/docs/mcp#mistral-setup

Building an AI-native web platform: 69 features in 11 days (solo dev log)

Michael Egberts — Tue, 28 Apr 2026 10:35:51 +0000

I'm building WebsitePublisher.ai — a platform where AI assistants build and publish complete websites through MCP (Model Context Protocol) tools. Here's what the last 11 days looked like.

The Visual Editor Problem
Users could build entire websites through conversation, but changing a single typo required asking the AI to patch the page. Terrible UX for small edits.
Solution: WPE v2 — a visual editor that loads the published page in an iframe, detects editable elements, and lets users click-to-edit text, drag-and-drop images, right-click for context menus, and save back through the same PAPI that AI assistants use.

Key decisions: httpOnly cookies instead of URL tokens, change count badge in dashboard, overlay detection for CSS-covered images.

The Integration Cookbook
Our integration engine (IAPI) supports http (external proxy) and internal (PHP handler) drivers. After shipping LinkedIn posting and SMTP email in the same week, I wrote an Internal Integration Cookbook:

Create manifest JSON with endpoint definitions
Implement handler extending InternalIntegrationHandler
Define body_transform and response_transform hooks
Register in engine

Result: the API Proxy integration took 2 hours from start to production.

MCP Session Stability
OAuth 2.1 + PKCE authentication. Claude's connector occasionally lost session state → 401 errors mid-conversation. Fixed with a 6-layer approach: token refresh, graceful 401 handling, session persistence, stale token detection, project selector refresh, frontend error boundaries.

Custom Domains with DNS Pre-validation
SSL certificate requests would fail when DNS hadn't propagated. Now we validate CNAME resolution before calling certbot. Clear error messages instead of cryptic failures.
Numbers
Tasks completed (11 days): 69
Total MCP tools: 55
AI platforms supported: 9
API layers: 10
Directory listings: 15+

→ websitepublisher.ai

Week 16 Dev Log: From First Customer to 56 MCP Tools — Building an AI-Native Website Publisher

Michael Egberts — Mon, 13 Apr 2026 14:05:54 +0000

I'm building WebsitePublisher.ai — a platform where AI assistants build and publish websites through MCP (Model Context Protocol) tools. This week: first paying customer, team collaboration, and some interesting architecture decisions.

The Stack

Quick context: Laravel/PHP backend, dual-server DigitalOcean cluster, Redis Sentinel, MySQL, S3 for assets. The AI layer is a multi-API stack:

PAPI — pages and assets
MAPI — entities and structured data
VAPI — vault/secrets management
IAPI — third-party integrations (Stripe, Resend, Twilio, etc.)
SAPI — sessions, forms, visitor auth
TAPI — task tracking across AI sessions
AAPI — scheduled automations

All exposed as MCP tools. Currently 56 tools, accessible from Claude, ChatGPT, Cursor, Windsurf, GitHub Copilot, Gemini, Grok, Mistral, and n8n.

What shipped this week

Team Collaboration

Our first paying customer — an agency — asked for multi-user support on day one. We shipped it within 48 hours:

Owner invites team members via email
Team members get full access to all projects
Magic link authentication (no passwords)
Max 5 members per Agency account

Architecture decision: no per-project granularity in v1. Simpler model, ship fast, iterate based on real usage.

Dashboard Vault — Secrets Without AI Exposure

A security feature I'm particularly proud of: the Vault tab lets users manage API keys (Stripe, Resend, etc.) through the browser UI. The key insight: if you share an API key in an AI chat, it ends up in transcripts, logs, and context windows. The Vault bypasses AI entirely — write-once, never displayed, rotate or delete only.

Backend uses AES-256-GCM encryption keyed per project, so even if someone gains database access, secrets from other projects are unreadable.

Language Refactor — From 4 Hardcoded Lists to Zero

Our AI Coach (a conversational website builder) needed proper i18n. The old code had 4 separate hardcoded language→string mappings scattered across the codebase. We refactored to a single CapiLanguage value object with a Redis → DB → Haiku → fallback chain:

Check Redis cache
Check papi_language_meta table (27 seeded languages)
Ask Claude Haiku for language detection (costs ~$0.001)
Fall back to English

Result: any of the 250+ ISO 639-1 codes work automatically. Adding a new language = 1 database row.

get_asset MCP Tool — Closing the Read Gap

We had tools to list, upload, patch, and delete assets — but no tool to read them. AI agents were doing blind find/replace via patch_asset without knowing the current file state. get_asset closes that gap: text content returned directly, binary assets as base64.

The Activation Challenge

67 signups, one paying customer. The gap is real. Our research this week showed that the friction is in the "how do I start?" moment — users sign up, see a dashboard, but don't know which AI platform to connect or how to begin.

Our answer: an embedded AI coach right inside the dashboard. Uses Sonnet (not Opus — cost control), generates one concept, writes directly to the user's first project. From "I just signed up" to "I have a website" in under 2 minutes.

What's next

Friday release agent (AAPI-powered automated changelog + test plans)
patch_asset optimistic concurrency (base version hash to prevent conflicts)
CAPI language refactor retest (waiting on external tester confirmation)

If you're building with MCP or interested in AI-native development tools, I'd love to connect. The MCP ecosystem is moving fast.

GitHub: megberts/websitepublisher-mcp
MCP Server: mcp.websitepublisher.ai

How we built an MCP server that lets AI assistants publish complete websites

Michael Egberts — Wed, 25 Mar 2026 07:53:24 +0000

Building a website with an AI assistant usually ends the same way: you get a wall of HTML in a code block, you paste it somewhere, and then you're on your own for hosting, deployment, and every update after that.
We wanted to fix that. So we built WebsitePublisher.ai — a platform where AI assistants don't just describe websites, they actually build and publish them.
Here's how it works under the hood.

The core idea: AI as a first-class developer
The premise is simple. Instead of AI being a code generator that hands off to a human, we wanted AI to be the developer — with access to a real API it can call directly.
That API needed to cover the full stack of what a website actually needs:

Pages and assets (HTML, CSS, images)
Structured data (entities, records)
Forms and visitor sessions
Integrations (email, SMS, payments)
Scheduled tasks
Vault (credentials management) So we built it. Eight API layers, all exposed through a Model Context Protocol (MCP) server.

What MCP gives us
MCP is an open protocol that lets AI assistants call tools — similar to function calling, but standardized across clients. Claude, ChatGPT, Cursor, Windsurf, GitHub Copilot, and others all support it.
Our MCP server exposes ~55 tools. An AI can call create_page with HTML content and it's live. It can call configure_form and a contact form appears. It can call create_scheduled_task and a nightly content refresh starts running.
The AI doesn't need to know about hosting, DNS, or deployment. It just calls the tools.

The API layers
We ended up with eight layers, each with a clear responsibility:
PAPI (Pages & Assets) — Create, update, and version HTML pages and static assets. Includes diff-patch for surgical updates, URL fetching, and a content quality warning system.
MAPI (Entities & Data) — A schema-less data layer. The AI defines entities (think: database tables) and creates records. Powers everything from contact lists to leaderboards to inventory.
SAPI (Sessions & Forms) — Anonymous visitor sessions, form submissions, visitor authentication, and analytics. No cookies to configure — it just works.
VAPI (Vault) — Encrypted credential storage. The AI stores API keys that are then used by integrations — never exposed back to the client.
IAPI (Integrations) — A proxy engine that routes calls through stored credentials to external services. Resend, Mailgun, Stripe, Mollie, Twilio — the AI picks the integration, the vault provides the credentials.
AAPI (Agent API) — Scheduled tasks. The AI creates cron jobs that run PHP handlers on a schedule. Daily content refresh, nightly cleanup, automated data sync.
CAPI (Coach API) — A conversational intake system. Ask four questions, generate a complete website. The AI handles the conversation; the platform handles the generation.

A real example
Here's what a Claude session looks like when building a site from scratch:

User: Build me a landing page for my consulting business. Focus on lead generation.

Claude: [calls get_skill to load WebsitePublisher context]
[calls create_page with full HTML/CSS]
[calls configure_form with name, email, message fields]
[calls setup_integration with Resend credentials]
[calls execute_integration to test email delivery]

Done — your page is live at yourproject.websitepublisher.ai.
The contact form sends leads to your inbox via Resend.
Want me to add a thank-you page or set up SMS notifications too?

No copy-paste. No deployment step. The AI did it.

The interesting engineering problems
A few things that weren't obvious until we built them:
Multi-session coordination. When multiple AI sessions work on the same project in parallel, they can overwrite each other's progress. We built TAPI — an append-only task tracking system — specifically to solve this. Each session logs progress via INSERTs only. MAX(completion_pct) from history records prevents any session from accidentally rolling back another's progress.
Tool count limits. Our MCP server returns 55 tools in tools/list. Some clients have limits on how many they load. Our workaround: the get_skill tool loads a SKILL.md document that gives the AI a map of the full API — so even with five tools loaded, it can use the REST API directly for everything else.
Content quality detection. AIs occasionally send a file path instead of HTML content to create_page. We added a WarningCollector that catches this pattern and returns a structured warning before anything gets saved.
Authentication across API layers. Each layer needed a different auth model. Project tokens (wpa_) for AI access. Dashboard sessions (wps_) for humans. Admin tokens (wsa_) for visitor-facing login flows. Getting these to coexist cleanly took a few iterations.

What's next
We're currently in the Mistral sprint — working on SSE streaming for the conversational intake (so responses feel instant instead of batched), parallel concept generation, and getting listed in Mistral's connector directory.
If you're building with MCP, or thinking about what "AI-native" infrastructure actually means in practice — we'd love to hear what you think.

The MCP server is at mcp.websitepublisher.ai
Full docs at websitepublisher.ai/docs