How I Built Smesh.dev Using AI: The Vibe Coding Revolution

We are living in a new era of software engineering. The term "Vibe Coding"—coined to describe developer velocity powered by advanced AI agent code generation tools—is not just a passing trend. It is a highly efficient operational method. When you decouple the developer from the cognitive load of syntax and boilerplate, you allow them to operate as a systems architect, translating business intent directly into production-ready software.

In this post, I am going to walk you through exactly how I built Smesh.dev from scratch, the decoupled architecture we chose, the high-context AI agent workflows we used, and how we integrated n8n and Supabase to build a self-sustaining automation agency site that fetches its content dynamically and deploys via GitHub Actions.

---

1. What is Vibe Coding? (Intent-Driven Development)

Traditional development is syntax-bound. Developers spend up to 70% of their time writing boilerplate, configuring bundlers, fixing minor syntax errors, and reading documentation. Standard AI assistance—like inline autocomplete (Copilot) or simple web-based chat interfaces (ChatGPT)—reduces this friction, but still keeps the developer in the loop for every single line of code.

Vibe Coding represents a paradigm shift to Intent-Driven Development. Instead of writing code, you define system specifications, architectural constraints, and test suites. You then delegate the implementation to high-context AI agents that can read your entire codebase, execute terminal commands, run tests, and diagnose compiler warnings autonomously.

By shifting your role from a "writer of syntax" to a "verifier of logic," you unlock a level of velocity where full-stack applications can be scaffolded, tested, and shipped in hours instead of weeks.

---

2. The 4 Pillars of Vibe Coding

To implement rapid development with AI successfully without introducing technical debt, you must follow a disciplined framework. At Smesh.dev, we structure our Vibe Coding workflow around four primary architectural pillars:

Pillar 1: Intent Specification (The Compiler of Intent)

AI agents are only as good as the context and instructions you feed them. If you give vague prompts like "build a contact page," the agent will make assumptions, resulting in generic layouts and broken states.

• In Vibe Coding, you write precise Markdown specifications (PRDs) detailing data fields, validation requirements, responsive layouts, and UX states.
• These specs act as the compile target for the agent, ensuring that the generated code aligns exactly with your product goals.

Pillar 2: Agentic Co-Execution (Tool-Equipped AI)

Vibe Coding goes beyond conversational web chats. It leverages autonomous agents equipped with system tools.

• The agent runs directly in your workspace terminal, with permissions to read directory trees, view files, write files, install npm packages, and execute shell commands.
• This allows the agent to diagnose compiler errors and run terminal build checks autonomously, looping until the code runs cleanly.

Pillar 3: Continuous Verification Loop (Lint, Typecheck, Test)

To maintain code quality while moving at 10x speed, you must implement automated quality gates.

• Every code edit by the agent must trigger automated syntax checks: linting (ESLint), static typechecking (TypeScript tsc), and test suites (Vitest/Playwright).
• If the agent introduces a bug, the test runner catches it immediately, and the agent corrects its own output before committing the change.

Pillar 4: Modular Architecture (Astro Islands & Decoupled Backends)

Large, monolithic code files overwhelm AI context windows, causing code truncation and logic errors.

• We design our codebases to be highly modular. Components are broken down into small, single-responsibility files (typically under 200–300 lines).
• Using Astro's Island architecture and decoupled serverless backends like Supabase ensures that components are self-contained, making them easy for AI agents to parse and refactor cleanly.

---

3. Why Choose This Approach?

When launching Smesh.dev, I had two choices: spend months manually writing boilerplate using traditional React/Next.js frameworks, or use a high-context Vibe Coding stack to build it in days.

For a modern services business, speed-to-market and operational efficiency are critical. Traditional development gets bogged down in infrastructure setup, while basic autocomplete tools require constant developer micro-management. By utilizing Vibe Coding with Astro and Supabase, we eliminated repetitive coding entirely, allowing us to launch Smesh.dev in less than 3 days.

Traditional Development vs. Autocomplete AI vs. Vibe Coding

Dimension	Traditional Development	Autocomplete AI (Copilot)	Vibe Coding (High-Context Agents)
Primary Activity	Writing syntax line-by-line	Accepting inline code predictions	Directing intent, design systems, and tests
Workflow Loop	Manual edit ➡️ Build ➡️ Debug	Tab-complete ➡️ Build ➡️ Debug	Declare intent ➡️ Agent runs loop ➡️ Review diff
Context Window	Local developer brain	Current file + open tabs	Full repository structure + live tools
Code Quality Gates	Manual PR reviews & CI tests	Developer manually reviews prediction	Agent runs automated type-checks and test suites
Role of Developer	Code compiler & debugger	Code editor	System architect & verification authority
Dependency Management	Manual lockfile updates	AI autocompletes package names	Agent runs npm install, runs tests, fixes mismatches
Development Speed	1x (Baseline)	1.5x - 2x	5x - 10x

---

4. Smesh.dev Technical Stack & Tools

To achieve sub-second page loads, zero hosting costs, and optimal SEO crawlability, I designed a decoupled, static-first architecture for Smesh.dev.

┌──────────────────┐       Astro Build       ┌────────────────────────┐
│  Supabase (DB)   ├────────────────────────>│  Astro Build Engine    │
│  - blog_posts    │  Queries data during    │  - Static compilation  │
│  - resources     │  site compilation step  │  - Zero-JS by default  │
└──────────────────┘                         └───────────┬────────────┘
                                                         │
                                                         │ Outputs HTML/CSS
                                                         ▼
┌──────────────────┐       Webhooks          ┌────────────────────────┐
│  n8n Workflows   │<────────────────────────┤     GitHub Pages       │
│  - Lead capture  │   Triggers auto-reply   │  - Free global CDN     │
│  - CRM routing   │   communications        │  - Sub-second LCP      │
└──────────────────┘                         └────────────────────────┘

The stack consists of five core pillars:

• Astro 5: We use Astro as our frontend framework, utilizing output: 'static' for build-time generation. Astro's island architecture ensures that only necessary interactive components are hydrated on the client, resulting in a zero-JS bundle footprint for informational pages.
• Supabase: Instead of storing blog posts, portfolio items, and resources inside local Markdown files, they are centralized in a Supabase instance. During the Astro build step, we query Supabase using the JavaScript SDK to pull the latest content dynamically.
• n8n: To automate lead capturing and processing, Smesh.dev integrates with a self-hosted n8n instance. When a user submits an inquiry via the contact form, the data is pushed to Supabase, which triggers an n8n webhook to automate follow-up workflows.
• Tailwind CSS & CSS Custom Properties: The styling is built on a custom design system defined in global.css, combining Tailwind utilities with strict CSS variables to maintain visual consistency across all viewports.
• GitHub Actions: The entire compilation and deployment process is automated. Whenever a commit is pushed to the repository, a GitHub Action runs npm run build and deploys the static files to GitHub Pages.

---

5. Step-by-Step Vibe Coding Workflow

Building Smesh.dev followed a structured, intent-driven workflow. Rather than coding randomly, we established a systematic build loop.

Step 1: Ingesting the Specification

First, I wrote a comprehensive layout draft and database model spec inside a local PRD.md file. I fed this file to the AI agent as a system constraint. This aligned the agent with Smesh.dev's design standards, such as the 8px spacing grid, rounded corner scales, and typography sizes.

Step 2: Database Scaffolding via SQL Migrations

Next, we scaffolded the database schema. Instead of manual UI click-ops, we directed the agent to write a structured SQL migration file defining our tables. For example, the blog_posts table was modeled with dedicated SEO and structured schema columns:

CREATE TABLE public.blog_posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  slug text UNIQUE NOT NULL,
  title text NOT NULL,
  content text NOT NULL,
  excerpt text NOT NULL,
  category text NOT NULL DEFAULT 'Automation',
  tags text[] DEFAULT '{}'::text[],
  published boolean NOT NULL DEFAULT false,
  published_at timestamptz DEFAULT now(),
  cover_image text,
  seo_title text,
  seo_description text,
  faq_schema jsonb DEFAULT '[]'::jsonb,
  related_slugs text[] DEFAULT '{}'::text[],
  canonical_url text,
  og_image text
);

Step 3: Astro Component Design

With the database ready, we directed the agent to create reusable, modular UI templates:

• PostHeader.astro: Renders dynamic headers, tags, read-time, and share options.
• AuthorBio.astro: Renders author biography block and verified credentials.
• RelatedPosts.astro: Queries related posts matching the target category.

Step 4: Configuring Build-Time Fetching

We configured Astro to query the database during compilation. In the src/lib/supabase.ts helper, we setup parallel queries:

import { createClient } from '@supabase/supabase-js';

const supabaseUrl = import.meta.env.PUBLIC_SUPABASE_URL;
const supabaseAnonKey = import.meta.env.PUBLIC_SUPABASE_ANON_KEY;

export const supabase = createClient(supabaseUrl, supabaseAnonKey);

export async function getAllBlogPosts() {
  const { data } = await supabase
    .from('blog_posts')
    .select('*')
    .eq('published', true)
    .order('published_at', { ascending: false });
  return data || [];
}

In the dynamic route src/pages/blog/[slug].astro, we define getStaticPaths to pull all slugs from Supabase and map them to static pages during compilation:

---
// src/pages/blog/[slug].astro
import BaseLayout from '../../layouts/BaseLayout.astro';
import { getAllBlogPosts } from '../../lib/supabase';

export async function getStaticPaths() {
  const posts = await getAllBlogPosts();
  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
---

Step 5: Verification Gate & Build check

Before deploying, we run our verification loop: TypeScript compiling checks, linter checks, and static pre-rendering build tests. This guarantees that any syntax or import errors are caught before the code leaves local staging.

---

6. Automation: n8n Workflow Integration

An agency website shouldn't just look good; it must automate backend operations. We integrated Smesh.dev with n8n to automate our lead-capture and routing processes.

┌──────────────────┐       Web Hook          ┌───────────────────────┐
│ Contact Inquiry  ├────────────────────────>│  n8n Webhook Node     │
│ (Form Submitted) │   Triggers workflow     │  - Authenticates lead │
└──────────────────┘                         └───────────┬───────────┘
                                                         │
                                                         ▼
┌──────────────────┐       WhatsApp Msg      ┌───────────────────────┐
│ Client Reply     │<────────────────────────┤  WhatsApp API Node    │
│ (WhatsApp Link)  │   Sends instant intro   │  - Pre-fills details  │
└──────────────────┘                         └───────────────────────┘

The workflow works as follows:

1. Form Ingestion: When a potential client submits their project requirements using our interactive Contact Form, the details are written to the Supabase contact_submissions table via client-side JavaScript.
2. Webhook Trigger: Supabase's database webhook listens for insert events on the submissions table. When a new row is added, it immediately posts the payload to a secure URL pointing to our self-hosted n8n instance.
3. n8n Lead Router: The n8n webhook node parses the client's information (budget, project description, business type). It filters out spam and categorizes the lead score based on target metrics.
4. Instant WhatsApp Alerts: n8n invokes a custom HTTP node to communicate with the WhatsApp Business API. It pre-fills a click-to-chat WhatsApp link (site.whatsappLink) and shoots an instant notification to both the sales coordinator and the client.
5. Database Logging: Once sent, n8n logs the message delivery status back to Supabase, closing the execution loop.

Under the Hood: n8n Lead Score Scoring Script

Inside our n8n workflow, a JavaScript Function Node runs immediately after the Webhook Node to automatically evaluate lead quality. This allows Smesh.dev to prioritize high-intent inquiries instantly. Here is the scoring logic executed inside n8n:

// n8n Javascript scoring block
const items = $input.all();
for (let item of items) {
  const data = item.json;
  let score = 0;
  
  // Budget evaluation
  if (data.budget === 'high' || data.budget === 'medium') score += 40;
  else if (data.budget === 'low') score += 10;
  
  // Description depth
  const descWordCount = (data.description || '').split(/\s+/).length;
  if (descWordCount > 30) score += 30;
  else if (descWordCount > 10) score += 10;
  
  // Service category check
  if (data.services && data.services.includes('automation')) score += 30;
  
  item.json.lead_score = score;
  item.json.route_to_whatsapp = score >= 50; // Auto-route to WhatsApp if high intent
}
return items;

If the route_to_whatsapp value evaluates to true, the workflow automatically generates an alert message containing the prospect's project brief and pushes it to our team channel using the official Meta Cloud API, enabling response loops in less than one minute.

---

7. How We Maintained Craftsmanship & Code Quality

Moving fast using AI can easily result in messy, unmaintainable code if you do not enforce strict structural rules. To keep Smesh.dev clean and professional, we followed three core guidelines:

1. Strict Spacing & Color System: We avoided ad-hoc values like p-[17px] or custom color hexes in individual templates. All spacing uses an 8px-based grid (e.g., space-y-4, p-8) and colors are mapped to CSS custom variables (var(--bg-soft), var(--line)).
2. Modular File Sizes: We follow a rule of separating layout concerns. By breaking down the blog post layout into modular sub-components like PostHeader.astro, AuthorBio.astro, and RelatedPosts.astro, we keep each file size under 300 lines, ensuring easy readability and fast AI parsing.
3. Type Safety & Schema Validation: All database inputs and outputs are validated at system boundaries. Form inquiries captured in ContactForm.astro are checked against a strict schema before insertion, preventing database pollution.

---

8. Technical Case Studies: Challenges & Solutions

Vibe Coding is not a magic bullet; it requires active problem-solving and architectural debugging. Here are four real engineering challenges we faced during the Smesh.dev build and how we resolved them:

Case Study 1: The Astro Dynamic Image Build Crash

The Problem: Astro 5 features an optimized <Image> component that compresses images and calculates dimensions at compile time. However, when we attempted to render dynamic blog cover images loaded from Supabase (e.g., paths pointing to /assets/images/blog/whatsapp-automation.webp), the compiler crashed with a MissingImageDimension error. The compiler could not calculate dynamic metadata for public-hosted files during the static build phase.

The Solution: We refactored SmartImage.astro to bypass Astro's build-time image processor for dynamic database paths. Instead of <Image>, we used standard, highly-optimized HTML <img> elements with inline Tailwind wrapper constraints and lazy-loading attributes:

<!-- src/components/SmartImage.astro -->
<img 
  src={src} 
  alt={alt} 
  class={className} 
  loading="lazy" 
  decoding="async" 
/>

This eliminated compilation crashes while maintaining optimal page loading speeds.

Case Study 2: Designing Public Row Level Security (RLS) Policies

The Problem: We wanted clients to submit inquiry forms directly via client-side Supabase calls. However, enabling public writes to a database table risks data injection or leakage if users can also read the table.

The Solution: We enabled PostgreSQL Row Level Security (RLS) on the contact_submissions table and wrote target policies that grant public INSERT access but block SELECT actions entirely for anonymous web visitors:

-- Allow anyone to submit a contact inquiry
CREATE POLICY "Allow public inserts" 
ON public.contact_submissions 
FOR INSERT 
WITH CHECK (true);

-- Prevent unauthorized reading of submissions
CREATE POLICY "Block public select" 
ON public.contact_submissions 
FOR SELECT 
USING (false);

This setup secures client inquiries without requiring a backend API server.

Case Study 3: Layout Breakage due to Missing Close Tags

The Problem: During an AI-directed homepage redesign, the layout broke on mobile viewports. The integrations logo ticker was nested inside the hero's second column instead of spanning full-width, resulting in a misaligned mobile grid.

The Solution: We ran a markup audit and discovered a missing closing grid </div> tag in the hero layout container. By closing the grid column container, we separated the hero elements from the footer logo ticker, allowing it to correctly span full-width.

Case Study 4: Supabase Edge API Rates & Timeouts

The Problem: When running multiple concurrent builds during heavy updates, we experienced connection timeouts (504 Gateway Timeout) from the Supabase edge interface. Our build runner made dozens of separate API calls to retrieve dynamic relations for portfolios, services, resources, and blog posts simultaneously.

The Solution: We refactored our fetching layer inside src/lib/supabase.ts. Instead of calling multiple separate .select() connections, we unified the resource fetches into single aggregated views and implemented a cache wrapper. If the client makes multiple requests for the same dataset within a single build tick, the client returns the cached promise instead of hitting the remote PostgreSQL endpoint:

// Simple in-memory fetch cache for build performance
let cachedPostsPromise: Promise<any[]> | null = null;

export async function getAllBlogPosts() {
  if (!cachedPostsPromise) {
    cachedPostsPromise = supabase
      .from('blog_posts')
      .select('*')
      .eq('published', true)
      .order('published_at', { ascending: false })
      .then(res => res.data || []);
  }
  return cachedPostsPromise;
}

This eliminated edge network timeouts and cut our compilation times in half.

---

9. Business Value: Why This Matters for Client Work

The Vibe Coding methodology is not just a tool for personal builds—it is a competitive advantage for delivering client projects.

At Smesh.dev, we build and deploy production-ready systems for our clients in weeks instead of months. Here is why this workflow delivers superior value:

Key Client Benefits:

• Speed (Fast Delivery): Scaffolding basic database models and layout boilerplate is delegated to AI, allowing us to spend 90% of our time refining business logic and integration flows.
• Reduced Costs: By deploying serverless databases (Supabase) and static pre-rendered pages (Astro), client sites cost $0 to run and require zero infrastructure upkeep.
• Zero Recurring SaaS markups: Integrating n8n allows us to build complex client routing and lead management workflows without forcing clients into expensive Zapier subscriptions.
• 100% Code Ownership: Clients receive complete access to their Supabase database tables and codebase, preventing vendor lock-in.

Whether you need a custom workflow automation setup or an AI support chatbot, Vibe Coding enables us to deliver hand-crafted, high-performance systems with extreme speed.

---

10. Key Takeaways for Developers & Founders

1. Establish Quality Gates: Never let AI commit code directly without automated verification. Set up TypeScript compiler tests and local linting to catch errors early.
2. Write Detailed Specs: AI is only as good as the context you provide. Spend time writing clear Markdown specifications before asking an agent to write code.
3. Decouple Data from Layout: Centralizing content in Supabase tables ensures you can edit blog posts, portfolios, and resources from anywhere without messing with source code files.

---

Ready to Automate Your Business Systems?

If you want to eliminate manual administrative work, capture leads automatically, or integrate custom AI agents into your daily operations, we are here to help.

• Claim a Free Automation Audit to review your current tech stack.
• Browse our Free Resources Hub to download ready-to-import n8n workflow blueprints.
• Explore our specialized WhatsApp Automation Services to capture customer inquiries 24/7.