The Vibe Coding Manifesto
by Tony Aly
I've been building on the internet since 1997. AltaVista doorway pages. ColdFusion. Inktomi paid inclusion. I was doing SEO before most people knew what a search engine was. I've scaled platforms from zero to a million daily users, co-founded agencies, built lead gen networks, and spent two and a half decades learning what actually makes something work online versus what just looks like it might.
So when vibe-coding arrived, I didn't see magic. I saw a craft problem.
I've shipped over 100 sites in the last few months using a system I've been refining my entire career. Some of those sites are simple. Some are genuinely complex platforms with data pipelines, AI-generated media, and interconnected API contracts running across dozens of domains. All of them follow the same principles. None of them started with code.
This is what I've learned. Not what you should do. What works, and why.
The Spec Is the Skill
The AI will write the code. It is remarkably good at writing the code. What it cannot do is know what you're building, why you're building it, who it's for, how it makes money, what the user does next, or where this site sits inside your larger network of domains.
That's your job. And that job happens in the spec, not in the prompt.
Before I write a single queue item, I know: the page hierarchy, the data sources, the conversion event on every page, the SEO structure, the design direction, the voice and tone, and exactly where this domain sits relative to every other domain in my portfolio. The spec is where I think. The AI is where I execute.
If you're prompting without a spec, you're not vibe-coding. You're improvising. Those are different things with different outcomes.
Every build I ship has a queue-based spec: one discrete task per queue item, in order, with no ambiguity. It also ships with three companion documents before the first line of code: a Page Copy Doc, an SEO Doc, and a Voice and Tone Reference. Every time. No exceptions.
The spec is the skill. The AI is the hands.
Build for the Person Who Finds You at 11pm on a Tuesday
Unless you're building yourself an expensive tool, you're building for users. Users come from somewhere. They arrive with intent. They decide in seconds whether to stay. And if you haven't planned for that moment at spec time, you're going to rebuild for it later at twice the cost.
SEO is not a feature you add. It's a foundation you build on. Server-rendered HTML is the only foundation that holds. Crawlers don't execute JavaScript. Your content needs to exist in the document, not load into it. Location hierarchy, semantic heading structure, breadcrumbs, canonical URLs, internal link architecture: these aren't technical niceties. They're the difference between a site and a ghost.
Conversion is architecture, not a button you drop in at the end. Every page has a job. The job is never "exist." The job is always "move the user toward a specific action." I define that action in the spec. I build the page around it. The CTA, the form, the next step in the journey: all specced before queue one.
And SEO and conversion aren't in tension. A page that ranks for the right query and immediately answers that query with a clear path forward: that's a page that works. Build that page every time.
You're Not Building Sites. You're Building a Network.
This is the thing most vibe-coding guides miss entirely, because most guides are written by people who've built one or two things and wrote about it. I want to give you the frame that changes everything.
A site is a dead end. A node is a connection point.
When I spec a new domain, I'm not asking "what does this site do?" I'm asking: what does this node know, what does it need, what does it feed, and where does it sit in the network? Every domain I build has a defined relationship to other domains I own. That relationship shapes the spec from the first queue item.
There are three types of domain relationships worth understanding.
Source of Truth to Distribution. One domain owns a dataset. Other domains consume it. I run a fictional universe called New Vibe City: 43 citizens, 65 businesses, 149 domains. Canon Talent at canontalent.com is the source of truth for every character. Every downstream business site pulls from it via webhook API contract. Change a detail once, it propagates everywhere. This is how media companies operate. You can build it solo, with vibe-coding, if you think about it at spec time.
Topical Cluster to Authority Hub. You build 10 to 15 sites in a vertical. Each one targets a different slice of the topic or a different geographic tier. They cross-link with genuine topical relevance. Collectively they build more domain authority than any single site could alone, because search engines see a coherent ecosystem of expertise. My NearYou network runs 130+ owned-and-operated sites across local verticals. Each one is a node. Each node strengthens every other node.
Funnel Chain to Conversion Architecture. Some sites exist specifically to hand traffic to each other toward a conversion event. Three separate sites, three entry points, one funnel. Someone lands anywhere and the network routes them toward the highest-value action. The tactical rule: every site in a chain has a defined "next node." What does a user do when they're done here? Where do they go? What's the handoff? This lives in the spec, not the afterthought.
When you build this way, every new domain you launch increases the value of every domain you already own. More cross-linking surface. More data flowing through the system. More entry points into the funnel. That's compounding. Standalone sites plateau. Networks compound.
Wire In the Intelligence Layer
Three years ago, assembling a platform with real-time data feeds, AI-generated media, dynamic pricing intelligence, and generative audio required a team. Today it requires a Replit spec and clear thinking about data contracts.
This is the part of vibe-coding that most people haven't caught up to yet. The question is no longer "can I build this?" The question is "what's the right data contract between these APIs and my network?" That's a product thinking question. Vibe-coding moved the bottleneck from engineering to product thinking.
Here's what's actually available to a solo builder right now:
Data intelligence. DataForSEO for keyword and SERP data. RapidAPI for hundreds of vertical-specific feeds: shipping, weather, sports, finance, real estate, anything. Your sites don't just publish content. They publish intelligence. That's a different product entirely.
Generative media. Replicate for image and video generation. MiniMax for audio. Your platform generates original media at the moment of need, not from a static asset library. OldSoulRadio, one of my builds, has an AI DJ named Soul who generates original commentary between public domain jazz tracks using MiniMax Music 1.5. One developer. One spec. Running in production.
AI reasoning as infrastructure. I'm not using AI as a chatbot. I'm wiring it into pipelines. OrbSignal pulls from 467 news sources and applies 14 intelligence lenses. Plotfinity runs a storyboard-driven video generation pipeline. These aren't AI features bolted onto a site. The AI is the architecture.
The ceiling for a solo vibe-coder who understands APIs is genuinely hard to see from here. Pick your vertical. Find the data that powers it. Wire it in from the start.
AI Has No Taste. You Do.
The most underrated principle in this entire manifesto.
AI will generate something. It will look like a website. It will function. It will be forgettable.
Taste is not something you prompt into existence. It's something you bring to the conversation before the conversation starts. Before I spec any UI, I work through aesthetic direction: the mood, the color world, the typography, the reference world I want this thing to live in. I run a Design Directive System: a locked base block that establishes my non-negotiables, with a swappable aesthetic direction line that changes per project. This gets prepended to every UI spec before the AI sees it.
Every photo placement in a spec has an inline image generation prompt. Not "add a hero image here." An actual prompt: what's in the frame, what's the mood, what's the lighting, what's the composition. Never vague. Never a placeholder.
The result is sites that look intentional. Because they were. Before the AI touched them.
The Rules That Compound
These are short. They're non-negotiable.
Spec first. Always. Never jump to code. Ideate, then spec, then queue, then ship. In that order.
SSR always. Server-rendered HTML, every time. No JavaScript for initial content load. No exceptions.
One task per queue. Complexity kills velocity. Break it down until each item is unambiguous.
Open source and free over paid SaaS. Replit Object Storage. Resend. Leaflet and OpenStreetMap. Stripe for payments. I don't use Twilio, PayPal, Calendly, Google Maps, or Google Analytics. Not because they're bad. Because better free options exist and lock-in is expensive.
Monetization is queue one thinking. How does this make money? Define it before you define anything else. Then build toward it.
Build the companion docs. Page Copy, SEO, Voice and Tone. Every build. If you skip these you're building something that works technically and fails commercially.
Treat the AI as a co-founder. Brief it like one. Give it context, constraints, opinions, and a clear job. It will return that energy.
Where to Go Deeper
This is the frame. The full playbook lives at vibe-coding-101.com: every principle above expanded into actionable modules, with the spec system, the design system, the SEO architecture, the API layer, and the domain network strategy laid out in full.
I update it as I learn. Which is constantly.
Twenty-five years in, and vibe-coding is the most interesting thing that has ever happened to building on the internet. I'm not slowing down. Neither should you.
— Tony Aly
Tony Aly is a Canadian internet entrepreneur and 25-year digital veteran. He builds interconnected platforms, SaaS products, and physical ventures from Denman Island, BC.