diff --git a/.optimize-cache.json b/.optimize-cache.json index c8be0f7f87..10e5dd9991 100644 --- a/.optimize-cache.json +++ b/.optimize-cache.json @@ -115,6 +115,7 @@ "static/images/blog/10-open-source-alternatives-to-popular-software-for-startups/Typesense.png": "9487a55e01fa138583067914b37c810103616147d31feaef7aa7a5aa25b8afa0", "static/images/blog/10-open-source-alternatives-to-popular-software-for-startups/Webstudio.png": "e73e63de846c31686fcb05c01c19f7117bb869ee7992326af3207c33e227f848", "static/images/blog/15-git-cli-tips/cover.png": "701de0be53919ffbf09bca6e1f8f8f21491cb1238060058cc48e8bd55a266aee", + "static/images/blog/25-startup-ideas-you-can-build-with-vibe-coding/cover.png": "69e1328071e894cb70e28d4c0c4eaa8f9dc63b71612b8823e455006bec21e25d", "static/images/blog/3-things-you-can-build-with-rust-runtime/cover.png": "fc603d24fd2ef803cb1cc81445ec990081c5cf69d5e7bf8143fce4595c2ed454", "static/images/blog/3-things-you-can-build-with-rust-runtime/webhook-create.png": "b76d6b4fecf5a14960916338580437e5c7b3ded9b7838eb67dae50a048406c79", "static/images/blog/5-claude-hacks-you-need-to-try-right-now/cover.png": "c144874bf9b2dbce69e1e56caaf6b8f6f8e00ea8c35d00ead7f77fd4602335a4", @@ -173,6 +174,7 @@ "static/images/blog/adding-url-shortener/functions.png": "64e977705133028364f8336da706f59d6a3c672a9ea30d16034155c04198a89d", "static/images/blog/adding-url-shortener/shortener.png": "170a82455ab8bc95ccfcccab0ce3bc7ae194caa79b03ff42a83ea7a921ed1306", "static/images/blog/adding-url-shortener/variables.png": "9e5135356992986e0c68f84b75da7f71990d882283693d80ef1461ab209b5a84", + "static/images/blog/agencies-vibe-coding-client-projects/cover.png": "98bcaaf0efde370f4903c1f5448a7a0275c6759913825107d3fcede8a17e7fab", "static/images/blog/agency-backend-standardization/cover.png": "b0f24c2e12e820e8707b1b63dcf11f7181752cd47d4bd142c36bbd29c5018f3a", "static/images/blog/agent-native-backend-platforms/cover.png": "441fab2ce0c04df6b6569db19d33bd1cd9051614ea1dd7045db87a55e45d19c0", "static/images/blog/agentic-ai-vs-generative-ai/cover.png": "fcda7c601879683cc380860c3a9403d8d6868cdc3bbf239cd74077f67df830aa", @@ -353,7 +355,9 @@ "static/images/blog/badge.png": "2d1852c6f826d55c40cb848cc3813f25a4d3d982a6f56d2738c9e5b3d0ac9694", "static/images/blog/Behind_the_pull_request_Stories_from_contributors.png": "16d81aff97deaded8b03c33f4498d3bf6f8ec392fee8edff6dc273d0cafbd132", "static/images/blog/best-backend-for-lovable-apps/cover.png": "579bcfe22908eee951880652a4075c0a26d34b661ab27e4f2c3708bdf717ceaf", + "static/images/blog/best-backend-for-vibe-coding-apps/cover.png": "ee1433142c86983c47bde8a99329c0a774ebe5fc8a530b34e1c3944053334a90", "static/images/blog/best-free-static-website-hosting/cover.png": "022f31c5c5897d77ccfbfc2149ee81ed6f8a7bbaca91b5c3c09cd2b2e9432450", + "static/images/blog/best-frontend-frameworks-for-vibe-coding/cover.png": "508261b8b8c5e3b27396c4e14e7a093f67c98060106068b8464b1f3f620b6397", "static/images/blog/best-ios-android-app-development-platform/cover.png": "68aa7d27a6c8265fc254663fb470f4ae1a436a34b85a0c06faa0776fedcdb2b5", "static/images/blog/best-pagination-technique/cover.png": "6c1cdf54285c0c181eb08f888d924e64919113d7d2fa85b24c8b5a44bd47e52a", "static/images/blog/best-pagination-technique/graph.png": "f62bfa341f17178991d50d40e62ff0c928cf2e62da13bd14648fa6d00a07d3b9", @@ -426,6 +430,7 @@ "static/images/blog/camp-5-barcelona/7.png": "4f1c87b922c2b5cb627066f50f557ee6f64c6632b4d647db49cf02d0dc555fd0", "static/images/blog/camp-5-barcelona/8.png": "af0875e9995d205531d42a67bb21f569e5cf677d5a00f3cfbb74280d001c36ac", "static/images/blog/camp-5-barcelona/cover.png": "4e92cec8cca906399c57464576cbda5f549f7879eb6fe1bf84831d160a49a2f9", + "static/images/blog/can-vibe-coding-replace-junior-developers/cover.png": "741dc095303f9ec91572986452fc8ec3ce062acdfe2bdb84906fa7f58045335c", "static/images/blog/card1.png": "1d21440fde0e1cf722ce4940919e38afbcf92acd96138e7c7009cd72c969bd5e", "static/images/blog/card2.png": "b6dfff0e1e749f7e00e7e5f7d9652431d0b050f31955df346ed0a8f28257e89b", "static/images/blog/card3.png": "71058e9e838ae8c10a1a99babe541a5898c6063c3ec73f643990d7e99042432d", @@ -518,6 +523,7 @@ "static/images/blog/deploy-tanstack-start-app-to-appwrite-sites/cover.png": "4a35c5e6577c52a2b13413bdbf25e990084570816d511e7b420757296abfd29a", "static/images/blog/deploy-tanstack-start-app-to-appwrite-sites/deployed.png": "c8359daee78412da75fb70b4ce754bc13c798861a89954267befd37f72b41bd2", "static/images/blog/deploy-tanstack-start-app-to-appwrite-sites/repository-selection.png": "5b9b389682ba39f34b86771fed70c993aedf2d81590e4736714f98ca2ac4684c", + "static/images/blog/deploy-vibe-coding-projects-to-production/cover.png": "618b550db308fe15f9405a505f3751e714763b278f17efc6dcafaa1d0a7c89a9", "static/images/blog/designing-init/cover.png": "069ffd2c62cada87502fbd35d1b3bdf39e38eb20168b8f2cf24cc58782e2d391", "static/images/blog/designing-init/day0.png": "bc3321f6883469f86b05343b111469af8fa755517757da0c1a234e4c1d381783", "static/images/blog/designing-init/day1.png": "d3ee8acf1db4a1a4e9985cc721db53a61c4bf59410751a24ccc453ad55c48d37", @@ -671,6 +677,7 @@ "static/images/blog/hf-2023-journey/kickoff-blr.png": "2b5d68282f769411fdc055ab39c32cccac9c0a274a2d6654ec1bbfc9621f4c8e", "static/images/blog/hf-hackathon-24/hf-hackathon.png": "b362912129d0e718c5dbc0cc80b42fb5174ac7e2efcc2386916eb69bb3e13645", "static/images/blog/hf-hackathon-24/prizes.png": "002988709aa990a4912206872ad28c14e92eb2fcf3e7cb693c5cfc2867e39e92", + "static/images/blog/hidden-costs-of-vibe-coding-platforms/cover.png": "de4a875c6a5f65598838efbd877a3dc8b004362111447a63f85e640a71e85bd6", "static/images/blog/hipaa-compliance-for-web-apps-a-practical-guide/cover.png": "9aeedd01af7440a10220c53dbfa4355018000d2661d733fdcf7d047e04adbd11", "static/images/blog/hipaa.png": "251c39f22b8e7657db751351366d81a016d57643b45eccfa53eb5faa7baf3e24", "static/images/blog/hooks-appwrite-databases/cover.png": "9c3b307c3cc594932e513aad1023a982647d6c9fced513e46c61ba5669379154", @@ -725,6 +732,7 @@ "static/images/blog/how-to-set-up-sign-in-with-apple/enable-apple-oauth2.png": "f44dad97466f0d1c1f59bf99098b3ad6ad9111d71d11a9d127830bad5111a502", "static/images/blog/how-to-set-up-sign-in-with-apple/Image-1.png": "bc2776831c6c50975d696445c23bac8f8383aad782c0f20756170f12efbfae6d", "static/images/blog/how-to-set-up-sign-in-with-apple/Image-2.png": "88a6c0067983569ce4e7639161bf77b172c34b9eca29a58ac2333dfad279c9bb", + "static/images/blog/how-vibe-coding-is-changing-software-development/cover.png": "d71da5d087b1435c8f80f700cafce466fb7e381a24507e5e8af4a516f00d89dd", "static/images/blog/image-classification.png": "7bc26761d3cf940a19911b23c8c309114e36b870dcf5259edbd24c8cceaa2df6", "static/images/blog/image-transformation-with-appwrite-storage/cover.png": "3885e03ff1f853f5e7e70dea1000018b7c74c47a7e28d3aa634ecc92e1c90ff3", "static/images/blog/implement-sign-in-with-github/cover.png": "e7e2433175cfa528ad63cbe5824e938c95057132c014caa148e08912d613f4db", @@ -1200,6 +1208,8 @@ "static/images/blog/valentines-day-sonnet-generator/output.png": "be28db7b263851719a6fb7b72127dbe8578739fe4e02dac4a1805bf5e1a8f6cd", "static/images/blog/valentines-day-sonnet-generator/templates.png": "e69192c1944e31f086780e91b034797af48bafe4f469631947f73bac50243503", "static/images/blog/vibe-coding-security-best-practices/cover.png": "b0c69c03743fc542ff384da87d2cd733a85d1a057e654dc3bee1f572999a6500", + "static/images/blog/vibe-coding-security-mistakes/cover.png": "f3cfad1ebc8ea5034df673d0011ee87cfc98d0ef15986d75672988347ec29442", + "static/images/blog/vibe-coding-vs-traditional-development/cover.png": "ed973e32ed844c5bb24dff7946cb531d7cfc74e31fee5cd7208391f4feb6fc5d", "static/images/blog/webp-support-for-safari/cover.png": "ea4e965ffe21500f3552073bb7ca325d453020cf095d67164329edbda3f1c799", "static/images/blog/what-developers-actually-want-from-a-backend-platform/cover.png": "0c540d48b12cd7031e3cadaf4223086ded946b42dc283c641cfa024311b2ec36", "static/images/blog/what-is-an-ai-backend/cover.png": "cb36f49035cbdcd97a70ac658783741f275d3a220b7cfd16b39d4fb86a929edd", diff --git a/src/routes/blog/post/25-startup-ideas-you-can-build-with-vibe-coding/+page.markdoc b/src/routes/blog/post/25-startup-ideas-you-can-build-with-vibe-coding/+page.markdoc new file mode 100644 index 0000000000..acbef39aa7 --- /dev/null +++ b/src/routes/blog/post/25-startup-ideas-you-can-build-with-vibe-coding/+page.markdoc @@ -0,0 +1,181 @@ +--- +layout: post +title: "25 startup ideas you can build with vibe coding" +description: "25 concrete startup ideas a solo founder can build with vibe coding tools like Cursor, Claude Code, and Lovable, plus the backend primitives each one needs." +date: 2026-05-11 +cover: /images/blog/25-startup-ideas-you-can-build-with-vibe-coding/cover.avif +timeToRead: 12 +author: aditya-oberai +category: startup +unlisted: true +faqs: + - question: "What kinds of startup ideas are best for vibe coding?" + answer: "Anything with a clear user, a narrow scope, and a small set of backend primitives: auth, a few tables, file uploads, a payment hook, maybe a scheduled function. Vibe coding tools like Cursor, Claude Code, Windsurf, Lovable, and Bolt are excellent at scaffolding apps in this shape. The ideas in this post all fit that profile." + - question: "Do I need to know how to code to build these?" + answer: "It helps. Tools like Lovable and Bolt let non-developers ship a working version, but every idea here will hit a wall the first time a user reports a real bug. Knowing enough to read a diff, understand permissions, and check that secrets are not in the client bundle is the difference between a demo and a startup." + - question: "What backend should I use for these ideas?" + answer: "Pick a backend that covers auth, databases, storage, server-side functions, and hosting under one model. [Appwrite Cloud](https://cloud.appwrite.io) gives you all of that with an MCP server so your AI tool can act on the project. It also reduces the number of vendors a solo founder has to manage in the first six months." + - question: "How long does it take to build a startup with vibe coding?" + answer: "A working prototype takes hours. A launched product takes weeks because of the parts vibe coding does not solve: permissions, payments, support, marketing, and the production review every app needs before users touch it. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) covers the engineering side of that gap." + - question: "Are these ideas original?" + answer: "Some are crowded markets, some are open. The point is not that the idea is unique. The point is that vibe coding has lowered the cost of trying any of them to the point where the experiment is worth running. A founder can ship version one of three of these in a month and let users decide which one is the company." +--- + +The hard part of starting a software company used to be building software. Vibe coding moved that bar. An idea you would have shelved last year because it was too small to justify the work now fits inside a weekend. The bottleneck has shifted to taste, distribution, and execution. + +This post is a list of 25 startup ideas a founder can ship with vibe coding tools like Cursor, Claude Code, Windsurf, Bolt, or Lovable. The first half is the ideas. The second half is what it actually takes to build them and how Appwrite's offerings and AI plugins map to each piece. Pick one, build a version this week, and let users decide whether it is a company. + +# 25 startup ideas to build with vibe coding + +## 1. AI-powered meal planner from your fridge + +Snap a photo of your fridge, the app reads the ingredients, generates a week of meal plans, and writes a grocery list for the gaps. Real examples already exist. The reason this idea keeps showing up is that the unit of value is concrete and the moat is recipe quality, not engineering. The shape is auth, a table for plans, a bucket for fridge photos, and a function that calls a vision model. + +## 2. Personalized bedtime stories + +Generate a bedtime story adapted to a child's age, name, interests, and mood. Save the favorites, replay them, let parents share a story with grandparents. A small table for kids, another for stories, a function for generation, a bucket for narrated audio. It is one of the most repeatable solo founder wins of the last year. + +## 3. AI tutor for a single subject + +Pick one subject. SAT math, conversational Spanish, music theory, intro to chemistry. Build a tutor that explains, quizzes, and tracks progress. The market for a general AI tutor is crowded. The market for a great tutor in one specific exam is open in every country. Auth, a progress table, a function that prompts the model with the student's history. + +## 4. Health log with weekly AI summary + +Users log meals, sleep, mood, workouts. A scheduled function summarizes the week and flags patterns. The hard part is not the AI. It is making logging fast enough that people do it. A single table, a scheduled function on Sunday night, and a clean mobile UI. + +## 5. Receipt-to-expense report + +Photograph a receipt, the app extracts the vendor, amount, tax, and category, and groups receipts into an expense report you can email or sync to QuickBooks. Buckets for the images, a table for receipts, a function for extraction, a function for export. Small businesses pay for this every month. + +## 6. AI study companion that quizzes you from your notes + +Drop in a PDF, the app indexes it, then quizzes you with cards, short answers, and timed reviews. The retention engineering is the hard part, not the AI. A single user, a few tables for documents and reviews, and a function that turns a section into questions. + +## 7. Personalized workout generator + +Generate a daily workout based on goals, equipment, and what the user did yesterday. The product wedge is not the workout. It is how the app handles missed days, plateaus, and injuries. A table for sessions, a function that builds tomorrow's workout from history. + +## 8. AI-powered customer support inbox + +A small business pastes their FAQ and past tickets. The app drafts replies, the human reviews and sends. The price stays under what a part-time support hire costs and the AI handles the boring 60 percent. Team-based auth, tables for tickets, a function that drafts a reply. + +## 9. Niche newsletter that writes itself + +Pick a topic with a few feeds. A scheduled function reads the feeds every morning, summarizes the relevant items, and drafts a newsletter for the human to edit and send. Substack-level UX is not the moat. Topic selection is. + +## 10. Personal CRM for solo founders + +Track everyone you talk to: investors, customers, collaborators. Set follow-up reminders, log conversations, ask an AI to draft the next email. The product is simple. The behavior change is the hard part. A few tables, a scheduled function for reminders, a function that drafts follow-ups. + +## 11. AI-generated postcards from playlists + +Turn a Spotify playlist into a physical postcard with a QR code. Real examples already exist. The category is wide open for variations: poetry from photos, art prints from journal entries, custom posters from saved tweets. A bucket for art, a function for generation, a Shopify or Lemon Squeezy integration for fulfillment. + +## 12. Audio transcription with shareable clips + +Drop in a meeting recording, the app transcribes it, the user marks the interesting parts, and the product turns those into shareable clips. Founders, podcasters, and students all pay for the same workflow. A bucket for audio, a function for transcription, a table for clips. + +## 13. Resume tailoring for a specific job description + +Paste a resume, paste a job description, the app tailors the resume to the job, drafts a cover letter, and tracks every application. The job market is large and the UX bar is low. A table for applications, a function per draft, a clean export. + +## 14. Tiny SaaS that wraps an API your customers should not have to wrap + +Pick a public API your audience uses awkwardly: a translation service, a calendar invite generator, a screenshot tool, a tax lookup, a courier rates aggregator. Build the UX their workflow deserves. Vibe coding gives you the building speed. Distribution decides the company. + +## 15. AI-assisted journaling app + +Daily prompt, the user writes, the app summarizes and reflects back patterns over weeks and months. The retention play is making the user feel seen. A table for entries, a scheduled function for the weekly summary. + +## 16. Couple's shared planner + +Shared grocery list, shared calendar, shared notes, with an AI that nudges the easy stuff (rent due, anniversaries, who is picking up what). A two-person account model, a handful of tables, live updates for shared edits, a scheduled function for reminders. + +## 17. AI-generated quiz from a YouTube video + +Paste a video URL, the app pulls the transcript, generates a quiz, and lets a teacher assign it. The vertical is teachers who use video in class. Team-based auth, a table for quizzes, a function per generation. + +## 18. AI-curated job board for a niche + +Pick a niche: AI engineers in Berlin, designer-engineers, technical PMs in fintech. A scheduled function scrapes a few sources, the AI filters and ranks, the board ships every Monday. Distribution is the hard part. Vibe coding makes the curation engine cheap. + +## 19. Habit tracker with peer accountability + +Small groups of three to five users commit to a habit. The app posts daily check-ins to the group. An AI summarizes the week. A group account model covers the social layer. Live updates keep the check-ins flowing. + +## 20. Local business AI website builder + +A laundromat, a dentist, a wedding venue gets a working site from a phone-call-length intake. The agent generates content, picks a template, and deploys the site to a custom domain. The market is enormous and underserved. Vibe coding is the only way a solo founder can serve it cheaply. + +## 21. AI-powered code review for vibe-coded projects + +A meta play. Solo founders shipping with Cursor, Claude Code, or Lovable still need a second pair of eyes. The app reviews a PR or a generated diff for the classic vibe coding failure modes: missing permission checks, leaked secrets, unvalidated inputs, missing indexes. A function per review, a small dashboard, a Stripe subscription. + +## 22. AI-narrated audio version of any newsletter + +User pastes a newsletter URL. The app generates a clean, listenable audio version and adds it to a personal podcast feed. The unit economics depend on TTS pricing, which keeps dropping. A bucket for audio, a function for narration, a hosted feed endpoint. + +## 23. AI bookkeeper for solo operators + +Connect a bank account, the app categorizes transactions, drafts a P&L, and answers questions about your finances. The market is large. The compliance work is real, which is why vibe coding lets you build a v1, but launch is when the real engineering starts. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) is non-optional here. + +## 24. Photo organizer with smart albums + +Upload photos, the app groups them by event, person, and location, then suggests photo books, video recaps, and shared albums for trips. A bucket for photos, a function for grouping, a table for albums, live updates for shared views. + +## 25. AI assistant for a single profession + +Pick a profession with paperwork: real estate agents, electricians, paralegals, fitness coaches, daycares. Build the one workflow that takes them an hour a day and let an AI shorten it to ten minutes. Auth, a few tables, a function for the workflow, an integration with the one tool that profession actually uses. + +# What it takes to build these and how Appwrite fits + +Every idea on this list runs on the same primitives. Auth, a handful of tables, file storage, a function or two, sometimes live updates, and a hosted frontend. The work is in the product, not in re-inventing the backend each time. The shorter the path from prompt to production, the more weekends you get to spend on the parts only you can build. + +## The backend primitives every idea needs + +Read through the 25 ideas above and the same shapes keep showing up. + +- **Auth.** Every idea has users. Most need email and OAuth, a few need MFA, and the multi-user ideas (8, 16, 17, 19) need a group or team account model. +- **Databases.** Tables for users, content, sessions, applications, entries, reviews, transactions. Typed columns, relationships, queries, and a permission model that does not require a custom RBAC layer. +- **Storage.** Buckets for fridge photos, receipts, audio recordings, generated art, narrated stories, photo libraries. Size limits, MIME limits, antivirus, encryption. +- **Functions.** Server-side logic for every AI call, every third-party integration, every payment hook, every export. Anything touching money, secrets, or third-party APIs belongs here. +- **Scheduled jobs.** Weekly summaries, daily curation, reminders, newsletter generation. A handful of these ideas only exist because a CRON trigger does the work while the user sleeps. +- **Realtime.** Live updates for shared planners, group check-ins, multi-user dashboards. +- **Hosting.** A custom domain, env vars, rollbacks, logs, and a deployment story that does not require manual ops on every push. + +A backend that ships all seven under one model is the difference between a weekend launch and a month of wiring. + +## How Appwrite covers all of it + +[Appwrite Cloud](https://cloud.appwrite.io) is shaped for this exact list. + +- [Auth](/docs/products/auth) handles email and password, OAuth, magic URL, email and phone OTP, MFA, sessions, and [Teams](/docs/products/auth/teams) for the multi-user ideas. +- [Databases](/docs/products/databases) cover tables, typed columns, rows, relationships, queries, transactions, and per-document permissions. +- [Storage](/docs/products/storage) gives you buckets with size and MIME limits, antivirus, encryption, image transformations, and signed URLs. +- [Functions](/docs/products/functions) cover server-side logic in Node, Python, Go, PHP, Dart, Ruby, Deno, Rust, and more, with execution logs, env vars, CRON triggers, and event triggers. +- [Sites](/docs/products/sites) hosts the frontend with custom domains, env vars, rollbacks, and build logs. +- [Realtime](/docs/apis/realtime) covers live updates for any idea that needs them. + +One project, one set of primitives, one vendor to manage in the first six months. + +## The AI plugins that close the loop + +The backend is half the story. The other half is how your AI tool talks to it. Appwrite ships the pieces that turn a vibe coding session into something an agent can actually execute against your project. + +- **[API MCP server](/docs/tooling/ai/mcp-servers/api).** Your agent in Cursor, Claude Code, or Windsurf can create users, manage tables, run queries, invoke functions, and operate on storage through tool calls instead of synthesized HTTP requests. Scope the API key to the resources the agent should manage, and the blast radius shrinks with it. +- **[Docs MCP server](/docs/tooling/ai/mcp-servers/docs).** The agent reads current Appwrite docs at call time instead of relying on whatever was in its training cutoff. Method names stop hallucinating. +- **[Agent Skills](/docs/tooling/ai/skills).** Curated skills for the Appwrite CLI and every major SDK, including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift. The agent picks the right SDK pattern instead of guessing. +- **Editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code), [Cursor](/docs/tooling/ai/ai-dev-tools/cursor), and [Codex](/docs/tooling/ai/ai-dev-tools/codex).** One-step install for MCP, docs MCP, and skills. Open the editor, start prompting, the agent can already act on your project. + +If you are still picking the AI tool to build with, [Best vibe coding tools in 2026](/blog/post/comparing-vibe-coding-tools) walks through the trade-offs. + +# Shipping your first vibe-coded startup with Appwrite + +Pick one idea from this list. Spend a weekend on a working version. Send it to ten people who fit the user profile. The first signal will tell you whether the company is real, and the second will tell you what to build next. + +The leverage from vibe coding compounds only if you ship. The backend is what stops your prototype from becoming the bottleneck the moment the first user shows up. + +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) diff --git a/src/routes/blog/post/agencies-vibe-coding-client-projects/+page.markdoc b/src/routes/blog/post/agencies-vibe-coding-client-projects/+page.markdoc new file mode 100644 index 0000000000..32d6753ea2 --- /dev/null +++ b/src/routes/blog/post/agencies-vibe-coding-client-projects/+page.markdoc @@ -0,0 +1,123 @@ +--- +layout: post +title: "How agencies are using vibe coding to ship client projects faster" +description: "How agencies use vibe coding tools like Cursor, Claude Code, and Lovable to shorten client cycles, standardize backends, and keep margins on fixed-fee work." +date: 2026-05-11 +cover: /images/blog/agencies-vibe-coding-client-projects/cover.avif +timeToRead: 9 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "How does vibe coding change agency economics?" + answer: "Agencies bill by the hour, the project, or the sprint. Vibe coding compresses the hours that go into the predictable parts of a build: auth, CRUD, file handling, integrations, and frontend scaffolding. Margins on fixed-fee projects improve, time-to-pitch shortens, and the same team can run more projects in parallel. The catch is that the review and hardening work does not compress, so the win only lands for agencies that keep both halves of the workflow in shape." + - question: "Which vibe coding tools do agencies use?" + answer: "Most agencies pair an IDE-native agent like Cursor or Claude Code with a hosted prototype builder like Lovable, Bolt, or v0 for the first pass. Browser builders win the discovery and early design phase. IDE agents take over once the project moves to a real repo. The deep comparison lives in [Best vibe coding tools in 2026](/blog/post/comparing-vibe-coding-tools)." + - question: "Should agencies standardize on one backend across clients?" + answer: "Yes. Backend fragmentation across clients is the largest hidden cost in agency work: every new project is a new mental model, every fix is in a stack the on-call dev does not know, and every estimate carries unfamiliar risk. Standardizing on one backend like [Appwrite Cloud](https://cloud.appwrite.io) turns the backend layer into solved infrastructure. The full case is in [How agencies standardize backend stacks across clients](/blog/post/agency-backend-standardization)." + - question: "How do agencies handle client handoff for vibe-coded apps?" + answer: "Document the prompts and decisions, not just the code. The agent can regenerate the code from intent if the schema, permission model, and architectural decisions are clear. Hand over a clean repo, a real domain, scoped API keys per environment, runbooks for the three most likely incidents, and access to the project under the client's account. The client should be able to keep building with their own agent on day one." + - question: "What is the biggest mistake agencies make with vibe coding?" + answer: "Treating the prototype as the launch. The demo flows are not the same as production-ready flows, and the gaps are predictable: leaky permissions, secrets in client bundles, missing indexes, no logs, and a preview URL that never got swapped for a real domain. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) is the version most agency teams converge on." +--- + +The agency model has always been about turning predictable work into repeatable margin. Vibe coding is the largest leverage agencies have had on that math in a decade. The teams that get it right ship more projects per quarter without growing headcount. The teams that get it wrong end up doing the same work twice, once to generate it and once to fix it. + +This is a working view of how agencies are using vibe coding to ship client projects faster, where the leverage actually lives, and how to keep margins clean on fixed-fee work. + +# The agency math has shifted + +For a long time, the bottleneck on agency throughput was developers per project. Three engineers could ship two apps a quarter. Vibe coding moved the bottleneck. The same three engineers can now scaffold five apps in the same quarter, and the constraint becomes review, discovery, and client communication, not typing. + +This is more disruptive to agency economics than to product economics. A product company keeps the same product after a fast prototype. An agency starts over every engagement, so the win on the first day of a build compounds across every project the team takes on. A meaningful reduction in time-to-first-working-version can translate into more pitches and faster iteration across the year. + +The honest catch is that the time you do not spend on the build is partially eaten by the time you spend on the review. The agencies that hit the leverage cleanly are the ones that built a review habit before vibe coding mattered. The ones that did not are shipping more bugs faster. + +# The two-builder pattern + +Agencies tend to use vibe coding in two passes that map to two different tools. + +**Discovery and demo.** Builders like Lovable, Bolt, v0, and Replit are excellent for the first pass. A salesperson can sit with a client, talk through what they want, and have a working UI in the call. The builder's bundled host is fine for the demo. The output is throwaway in spirit. The point is alignment, not production. + +**Build and harden.** Once the project is real, the code moves into a real repo and the workflow moves into Cursor, Claude Code, or Windsurf. The agent has the full project in context, can run tests, can edit across files, and can act on the project's backend through MCP. This is the pass that ships. + +Trying to combine both into one tool is a common mistake. A browser builder is too constrained to ship a real product. An IDE-native agent is too heavy for a 20-minute sales conversation. The two-pass workflow keeps the right tool for the right phase. + +# Standardize the backend before standardizing the agent + +The agent is the visible part of the workflow. The backend is the load-bearing part of the agency's economics. + +Agencies that run a different backend per client pay for the choice every time. Different security defaults, different auth flows, different mental models, different debugging tools, different on-call burdens. A developer joining the team has to learn three stacks before they can be productive. An incident at 2am lands on whoever knows the stack, which is often nobody on the rotation. + +Standardizing on one backend per agency turns this into solved infrastructure. The same auth flow ships in every project. The same permission model. The same file handling. The same logs and rollback story. The agent gets faster too, because the same prompts produce useful output across every engagement instead of starting from zero. + +[Appwrite Cloud](https://cloud.appwrite.io) is shaped for this. [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Sites](/docs/products/sites), and [Realtime](/docs/apis/realtime) under one model, with per-project isolation so every client gets a clean environment. Self-hosting is there for clients who need data residency or compliance. The full case for agency standardization is in [How agencies standardize backend stacks across clients](/blog/post/agency-backend-standardization). + +# Build an internal playbook, not a tooling list + +The agencies pulling the most leverage from vibe coding all converged on the same artifact: an internal playbook the team uses on every project. The playbook is not a tools list. It is a set of decisions made once, encoded so the agent and the team apply them automatically. + +A practical playbook covers: + +- **The default backend.** One platform, one set of primitives, one mental model. +- **The starter repo.** A template with auth, a base layout, lint rules, and the agent's context files already in place. +- **The prompt library.** The prompts the team has refined for common features: signup, file uploads, payments, dashboards. Reusable across projects. +- **The review checklist.** What every engineer reviews before merging an agent-generated diff and before shipping a launch. +- **The handoff package.** What every client receives at the end of an engagement. + +The first project that uses the playbook costs the agency the playbook. Every project after pays it back. + +# Reusable agent context across clients + +The other piece of leverage is agent context. Most agencies start over on every engagement: a new repo, a new prompt history, a new set of constraints the engineer has to re-explain to the agent on day one. The agent has to learn the agency's conventions five times a year. + +The fix is to keep the conventions outside any single project. An `AGENTS.md` or `CLAUDE.md` file in every starter repo. A shared set of [Agent Skills](/docs/tooling/ai/skills) for the backend the agency standardizes on. Editor plugins like the [Claude Code plugin](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor plugin](/docs/tooling/ai/ai-dev-tools/cursor) install the [API MCP server](/docs/tooling/ai/mcp-servers/api), the [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), and the SDK skills in one command, so every developer on every project is on the same baseline. + +# Estimating fixed-fee work in the vibe coding era + +Fixed-fee work is where agency margin lives, and the place where vibe coding is most visibly mispriced. The dangerous failure mode is to scope a project based on how fast the prototype came together. The hours you save on the build are partially absorbed by the review, the hardening, the launch checklist, and the client communication. Pricing the project as if the demo were the deliverable produces an estimate the team cannot hit. + +The honest estimating pattern looks like this: + +- Scope the build in two phases: prototype and harden. Price both. +- Add a fixed line for the pre-launch review. +- Add a fixed line for a handoff package. +- Include a clearly defined revision budget. Vibe coding makes revisions cheap, which means clients ask for more of them. Bound the budget or watch the margin. +- Include a maintenance window post-launch for the first incidents. They will come, and the only question is whether they are billed or eaten. + +This estimating pattern gives an agency the upside of vibe coding without the margin compression that comes from underpricing review. + +# Handoff is where vibe-coded projects go to die + +The agency-specific failure mode for vibe-coded apps is handoff. The team shipped a working app, the client signed off, and six months later the same client comes back because something broke and no one knows the code. The agent that wrote the code is gone. The prompts that produced it were never saved. The conventions are buried in chat history. + +The fix is to treat the handoff package as a real deliverable, not an afterthought. A typical package contains: + +- A clean git repo with a real branch model and protected `main`. +- Real environment variables per environment, with all keys rotated post-handoff. +- A custom domain on the client's account. +- A README that explains the architecture, the schema, and the prompts that produced it. +- An `AGENTS.md` or `CLAUDE.md` that any agent can pick up. +- Runbooks for the three most likely incidents. +- A short loom or written walkthrough. + +Done well, the client picks up where the agency left off, with their own agent in Cursor or Claude Code, against the same standardized backend. The agency stays in scope. The client gets a working product they own. + +# Where Appwrite fits in agency workflows + +The simplest path for an agency starting on vibe coding is to pick one backend, one IDE agent, and one prototype builder, then encode the choices in a playbook. + +[Appwrite Cloud](https://cloud.appwrite.io) covers Auth, Databases, Storage, Functions, and Sites under one platform, with per-project isolation, scoped API keys, and a self-host option for clients with stricter requirements. The [API MCP server](/docs/tooling/ai/mcp-servers/api), the [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), and [Agent Skills](/docs/tooling/ai/skills) install in one step through the [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) plugins. + +For the broader agency tooling stack, [30 dev tools for agencies](/blog/post/30-dev-tools-for-agencies) covers the surface beyond the backend and the agent. + +# Running an agency that ships with vibe coding + +The agencies that turn vibe coding into a long-term advantage do it the same way they turn any tool into one: standardize, document, and review. The first project that uses the playbook costs the agency time. Every project after that is the win. + +If you are building one of these workflows, start with one backend, one IDE agent, one builder, and a written handoff package. [Sign up for Appwrite Cloud](https://cloud.appwrite.io), install the [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) plugin, and the next client engagement starts from the same baseline as the last one. + +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) +- [How agencies standardize backend stacks across clients](/blog/post/agency-backend-standardization) +- [Appwrite AI tooling](/docs/tooling/ai) +- [Backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) diff --git a/src/routes/blog/post/best-backend-for-vibe-coding-apps/+page.markdoc b/src/routes/blog/post/best-backend-for-vibe-coding-apps/+page.markdoc new file mode 100644 index 0000000000..61dca17102 --- /dev/null +++ b/src/routes/blog/post/best-backend-for-vibe-coding-apps/+page.markdoc @@ -0,0 +1,123 @@ +--- +layout: post +title: "Best backend for vibe coding apps in 2026" +description: "What to look for in a backend for vibe-coded apps: MCP, scoped keys, typed primitives, and the trade-offs between Appwrite, Supabase, Firebase, and Convex." +date: 2026-05-12 +cover: /images/blog/best-backend-for-vibe-coding-apps/cover.avif +timeToRead: 10 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "What makes a backend good for vibe coding?" + answer: "Four things: an MCP server so AI agents can act on the project through tool calls, a docs MCP or equivalent so agents read current reference material instead of stale training data, typed and clearly named primitives so agents plan cleaner edits, and scoped API keys so an agent can run in production without master access to the project. Without these, an agent in Cursor or Claude Code will produce code that compiles but breaks in real use." + - question: "Is Firebase good for vibe coding?" + answer: "Firebase ships an MCP server through firebase-tools that exposes Firestore, Auth, Data Connect, Storage, Cloud Messaging, Functions, Remote Config, and Crashlytics. It is a credible agent-native option, especially for teams already on Google Cloud. The trade-off is the Firestore data model, vendor lock-in, and pricing at scale." + - question: "Is Supabase good for vibe coding?" + answer: "Supabase exposes SQL and Edge Function tools through a managed MCP server with read-only and project-scoped modes. It is a strong pick if your team is comfortable writing SQL and wants Postgres semantics, including RLS. The trade-off is that vibe-coded apps often need permissions structured at a higher level than RLS, and AI tools occasionally produce policies that are syntactically valid but semantically open." + - question: "Is Appwrite a good backend for vibe coding?" + answer: "Yes. Appwrite covers Auth, Databases, Storage, Functions, Sites, and Realtime under one model, ships an [API MCP server](/docs/tooling/ai/mcp-servers/api) and a [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), provides [Agent Skills](/docs/tooling/ai/skills) for every major SDK, and bundles all of that into editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor). The primitives are small and named, which produces fewer agent hallucinations than a sprawling cloud surface." + - question: "Should a solo founder use a different backend than a team?" + answer: "Probably not in 2026. The cost of switching backends after launch is high, the vibe coding tools work better against a consistent platform, and the production checklist applies regardless of team size. Pick a backend you can grow on. A solo founder shipping a vibe-coded app on [Appwrite Cloud](https://cloud.appwrite.io) keeps the same primitives when the second engineer joins." +--- + +If you are building a vibe-coded app, the backend choice is more load-bearing than it used to be. The AI tool writes most of the frontend on the first try. The backend is what decides whether the app survives the second user. + +This is a developer-first comparison of what to look for in a backend for vibe-coded apps, where the major options sit, and how to pick one without painting yourself into a corner. It assumes you are shipping with Cursor, Claude Code, Windsurf, Bolt, Lovable, or v0, and that your app needs auth, a database, file storage, server-side logic, and a hosted frontend. + +# What a vibe coding backend actually needs to do + +Strip the marketing pages off every option and the requirements look the same. + +- **Auth that works on the first try.** Email and password, OAuth, magic URL, MFA, session management, and rate limits, with one set of APIs the agent can hold in its head. +- **A database the agent can reason about.** Tables, typed columns, relationships, indexes, queries, and a permission model the agent does not have to invent from scratch. +- **File storage with per-bucket controls.** Size limits, MIME limits, antivirus, encryption, and signed URL semantics. +- **Server-side logic with logs.** Anything touching money, third-party APIs, or sensitive data needs to live on the server, not in the bundle the agent generated for the browser. +- **A hosted frontend with a real domain.** Custom domain, env vars, rollbacks, logs, and a deployment story that does not require manual ops on every push. +- **An MCP server.** Without one, every agent action is a synthesized HTTP call against docs the model may or may not have read recently. With one, the agent operates on your project the way you would. +- **Docs the agent can read at call time.** Training cutoffs are always behind. A docs MCP, or an equivalent, prevents the agent from hallucinating method names from six months ago. +- **Scoped API keys.** A vibe coding workflow uses an agent with a key. That key should not be a master key. It should be the smallest key that does the job. + +A backend that hits all eight is built for this workflow. A backend that hits three or four is going to cost you weekends. Few of the platforms in this comparison cover the full set as first-party features. Appwrite is one of them. + +# How the major backends compare + +The category of agent-native backends has been forming since MCP shipped. Here is how the most relevant options stack up against the checklist above. The detailed deep dive lives in [the rise of agent-native backend platforms](/blog/post/agent-native-backend-platforms); this section is for picking a default. + +## Appwrite + +[Appwrite Cloud](https://cloud.appwrite.io) covers the eight requirements under one platform. [Auth](/docs/products/auth) handles email, OAuth, magic URL, email and phone OTP, MFA, sessions, and Teams. [Databases](/docs/products/databases) provide tables, typed columns, rows, relationships, queries, and transactions. [Storage](/docs/products/storage) gives you buckets with size and MIME limits, antivirus, encryption, and image transformations. [Functions](/docs/products/functions) cover server-side logic in Node, Python, Go, PHP, Dart, Ruby, Deno, Rust, and more, with execution logs, env vars, CRON, and event triggers. [Sites](/docs/products/sites) handles hosting with custom domains, env vars, rollbacks, and logs. [Realtime](/docs/apis/realtime) covers live updates. + +For the agent loop, the [API MCP server](/docs/tooling/ai/mcp-servers/api) lets the agent create users, manage tables, run queries, invoke functions, and operate on storage; the API key's scopes decide which of those the agent can actually call. The [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) lets the agent read current docs at call time. [Agent Skills](/docs/tooling/ai/skills) cover the Appwrite CLI and every major SDK, including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift. Editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) install MCP, docs MCP, and skills in one command. + +## Supabase + +Supabase exposes a managed MCP server at `mcp.supabase.com/mcp` with tools grouped into Database, Debugging, Development, Edge Functions, Account management, Docs, and experimental Branching. Database tools include `list_tables`, `apply_migration`, and `execute_sql`. Edge Functions can be listed, fetched, and deployed. OAuth, read-only mode, and project scoping contain blast radius. + +If your team is comfortable in Postgres and wants SQL as the primary interface, Supabase is a strong agent-native option. The trade-off for vibe-coded apps is that Row Level Security policies are easy for an AI to generate incorrectly, with rules that look right and grant too much. The same vibe coding instincts that produce a clean component can produce a too-permissive policy. The fix is review, not the platform, but the cost is real. + +## Firebase + +Firebase ships an MCP server through `firebase-tools` that exposes Firestore, Auth, Data Connect, Storage, Cloud Messaging, Functions, Remote Config, and Crashlytics, with slash prompts like `/firebase:init` and `/firebase:deploy`. The surface is comprehensive for teams already in the Google ecosystem. + +The trade-offs for vibe coding teams are familiar: the Firestore data model is harder for AI tools to reason about than typed tables, security rules need careful review, and the pricing model can surprise a successful prototype at exactly the wrong moment. Firebase is a credible pick if your stack is already Google-first. + +## Convex + +Convex focuses on agent application primitives inside a TypeScript-only backend. Its Agent component covers threads, message persistence, tool calls, RAG through a dedicated component, workflows, usage tracking, and rate limiting. The pitch is that the platform is what an agent builds on, not just what an agent manages. + +That makes Convex a good fit for AI-first apps where the agent is the product. It is a worse fit if your stack needs flexibility outside TypeScript, or if you need an MCP surface for an agent to manage the project itself. + +## Neon + +Neon takes the Postgres-for-agents angle. The Neon MCP Server, available through OAuth at `mcp.neon.tech/mcp` or via API keys, lets an agent create and branch projects, run SQL, and perform migrations through natural language. The strongest case is the per-agent branch: every agent gets its own database to experiment in without touching production. + +Neon is a great database for a vibe coding workflow. It is not a full backend on its own. You still need auth, storage, functions, and a hosting story. The question is whether you want to compose those yourself or pick a platform that ships them together. + +## Netlify and Cloudflare + +Netlify ships an MCP server that lets clients like Windsurf, Cursor, VS Code, Claude, Goose, and Sourcegraph Amp create projects, deploy, modify access controls, install extensions, enable forms, and manage environment variables and secrets. It is the strongest agent-native hosting pitch. + +Cloudflare's Agents SDK takes the runtime angle. You build agents on top of Durable Objects, each with its own SQL database, WebSocket connections, scheduling, and tool support. It is an agent runtime more than an MCP surface. + +Both are reasonable as part of a stack. Neither is a full backend. + +# The trade-offs that actually decide the pick + +The fair question is not which platform has the longest feature list. It is which trade-offs you are willing to live with. + +- **Composition vs single platform.** Combining Neon, Auth0, a storage vendor, a hosting platform, and a function runtime gives you specialist depth at every layer. Picking [Appwrite](https://cloud.appwrite.io), Supabase, or Firebase gives you fewer vendors, fewer integration points, and an agent that has to load fewer mental models. For a vibe coding workflow, the single-platform path usually wins on cycle time. +- **Document vs relational data model.** Firestore and similar document stores are easier for an agent to scaffold quickly but harder to reason about as the schema grows. Typed tables in Appwrite or SQL in Supabase and Neon are easier to reason about over time. The right answer depends on how complex the schema gets, and most apps drift toward "more complex than I expected." +- **Open source vs managed only.** Appwrite is open source and self-hostable. Supabase is open source with a managed offering. Firebase is managed only. Convex is managed only. If you may ever need to self-host for compliance, residency, or cost, that constrains the choice early. +- **Permissions model.** A vibe-coded app fails on permissions more often than on any other category. A platform where permissions are visible per resource and easy for an agent to set correctly will save you incidents. Appwrite's per-row and per-bucket permissions, Supabase's RLS, and Firebase's security rules are all viable; each has a different failure mode under AI-generated code. +- **Pricing at the scale you actually expect.** A free tier matters for the first prototype. The bill at 10,000 monthly active users matters for the company. +- **Language and runtime support.** [Appwrite Functions](/docs/products/functions) run on Node, Python, Go, PHP, Dart, Ruby, Deno, Rust, and more, with SDKs across the same breadth. Supabase Edge Functions are Deno-based. Convex is TypeScript only. If your vibe coding stack mixes languages, the runtime list narrows the field fast. + +# A practical pick for a vibe coding solo founder + +If you are starting now and you do not have a strong reason to pick something else, run the next vibe-coded project on [Appwrite Cloud](https://cloud.appwrite.io). You get the eight requirements under one platform, an MCP surface your agent in Cursor or Claude Code can use immediately, typed primitives that produce fewer hallucinations, and a self-host path if you ever need it. + +To set it up: + +1. Sign up at [Appwrite Cloud](https://cloud.appwrite.io) and create a project. +2. Install the editor plugin: [Claude Code plugin](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor plugin](/docs/tooling/ai/ai-dev-tools/cursor). This bundles the API MCP, Docs MCP, and Skills in one command. +3. Configure an [API key](/docs/advanced/platform/api-keys) scoped to the resources your agent should manage. Avoid using a master key during development. +4. Pick an [SDK](/docs/sdks) for your frontend or backend language. +5. Start the agent on your first feature. Ask it to design the schema, create the tables, set permissions, write the function, and deploy the frontend to [Appwrite Sites](/docs/products/sites). + +If you would rather start from a template, the [quick start prompts](/docs/tooling/ai/quickstart-prompts) cover every major framework, including [Next.js](/docs/tooling/ai/quickstart-prompts/nextjs), [SvelteKit](/docs/tooling/ai/quickstart-prompts/sveltekit), [React](/docs/tooling/ai/quickstart-prompts/react), [Nuxt](/docs/tooling/ai/quickstart-prompts/nuxt), [Vue](/docs/tooling/ai/quickstart-prompts/vue), [Angular](/docs/tooling/ai/quickstart-prompts/angular), [Flutter](/docs/tooling/ai/quickstart-prompts/flutter), and [Tanstack Start](/docs/tooling/ai/quickstart-prompts/tanstack-start). + +# Before shipping a vibe-coded app to production + +Backend choice is not the whole story. Every vibe-coded app needs a pre-launch review for the failure modes that AI tools repeatedly miss. Open table permissions, secrets in client bundles, missing indexes on hot queries, no logs to debug the first incident, and a preview URL that never got swapped for a real domain. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) walks through the order to run that review in. + +# Picking a backend you can grow on + +The vibe coding loop is faster than any previous developer workflow. The backend you point it at decides whether that speed turns into shipped product or a stack of half-working prototypes. Pick the backend that exposes the primitives your agent can reason about, ships MCP for both the API and the docs, and gives you a production story before you need one. + +[Sign up for Appwrite Cloud](https://cloud.appwrite.io) and start the next vibe-coded project on a backend built for it. + +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Appwrite Docs MCP server](/docs/tooling/ai/mcp-servers/docs) +- [Appwrite Agent Skills](/docs/tooling/ai/skills) diff --git a/src/routes/blog/post/best-frontend-frameworks-for-vibe-coding/+page.markdoc b/src/routes/blog/post/best-frontend-frameworks-for-vibe-coding/+page.markdoc new file mode 100644 index 0000000000..c11a93b478 --- /dev/null +++ b/src/routes/blog/post/best-frontend-frameworks-for-vibe-coding/+page.markdoc @@ -0,0 +1,127 @@ +--- +layout: post +title: "Best frontend frameworks for vibe coding" +description: "The best frontend frameworks for vibe coding in 2026: Next.js, SvelteKit, React, Nuxt, Vue, Astro, and TanStack Start, with what each one is good for." +date: 2026-05-13 +cover: /images/blog/best-frontend-frameworks-for-vibe-coding/cover.avif +timeToRead: 9 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "What is the best frontend framework for vibe coding?" + answer: "Next.js is the strongest default. AI tools have seen more Next.js code than any other framework, the ecosystem is enormous, and most browser builders like Bolt and v0 output React with Next.js conventions. SvelteKit is the strongest alternative for teams that want less boilerplate. Nuxt is the Vue equivalent of Next.js. Astro fits content-heavy sites. TanStack Start is the right answer for React teams that want fully-typed, file-based routing without Next.js conventions." + - question: "Why does framework choice matter for vibe coding?" + answer: "Because the agent's first draft is only as good as its prior. Frameworks with massive training-data footprints produce idiomatic, runnable code on the first prompt. Frameworks with thinner footprints often produce code that mixes patterns from incompatible versions, hallucinates APIs, or skips conventions. The cost of fighting the agent is real, and it compounds across a year of edits." + - question: "Are React Native and Flutter good for vibe coding?" + answer: "Yes, both are well supported by current agents and ship a real native app from a single codebase. React Native benefits from the same training-data advantage as Next.js. Flutter benefits from strong first-party docs and a tight set of conventions that agents respect. [Appwrite ships SDKs and quickstart prompts](/docs/tooling/ai/quickstart-prompts) for both." + - question: "Should I use Astro for a vibe-coded app?" + answer: "Astro is excellent for content-heavy sites, landing pages, marketing surfaces, and documentation. It is less appropriate for app-style flows with dense interactivity. Use it where the product is closer to a website than a SaaS dashboard. Appwrite Sites supports Astro through [Git-based deployments](/docs/products/sites/deploy-from-git) with a one-step quick start." + - question: "What is the easiest way to ship a vibe-coded frontend to production?" + answer: "Pick the framework that fits the product, build with an agent in Cursor or Claude Code, point the data layer at a backend with an MCP surface like [Appwrite Cloud](https://cloud.appwrite.io), and deploy to [Appwrite Sites](/docs/products/sites) with [Git-based deployments](/docs/products/sites/deploy-from-git). Custom domains, env vars, instant rollbacks, and deploy logs come with the host." +--- + +The framework choice for a vibe-coded app is more load-bearing than it used to be. AI agents have wildly different priors across frameworks: more code in their training data, cleaner conventions, fewer breaking changes between versions. Picking the framework with the strongest prior is the difference between an agent that gets your first feature right and one that takes three rounds. + +This is a developer-first guide to the best frontend frameworks for vibe coding in 2026, what each one is actually good at, and how to pair them with a backend the agent can also reason about. + +# Why framework choice matters for vibe coding + +Three things make a framework friendly to vibe coding. + +- **Training-data footprint.** The more code the model has seen, the better its first draft. Next.js, React, and Vue dominate by raw volume. SvelteKit, Astro, and Nuxt are close behind for the patterns most teams care about. +- **Stable conventions.** Frameworks that rewrite their routing or data-fetching primitives every two releases produce agents that mix versions in the same file. The fewer the breaking changes, the cleaner the generated code. +- **First-party docs and TypeScript.** Agents lean on docs at call time when they have a docs MCP available, and they lean on types to verify their own output. Frameworks with good docs and full TypeScript support catch the agent's mistakes earlier. + +The frameworks below all clear a usable bar for vibe coding. The differences below decide which one fits which product. + +# Next.js + +Next.js is one of the strongest default for a vibe-coded app in 2026. Three reasons. + +The training-data footprint is the largest of any modern framework. Cursor, Claude Code, Windsurf, Bolt, v0, and Lovable all produce more correct first drafts on Next.js than on anything else. The App Router has settled enough that agents stop mixing it with Pages Router conventions in the same file. The TypeScript story is strong, and the framework's primitives (`route handlers`, `server actions`, server and client components) map cleanly to backend operations. + +Where Next.js earns its keep is full-stack app work. Authentication, dashboards, CRUD flows, marketing pages, and API endpoints all live in the same project, which means the agent can reason about the whole product without context-switching between frontend and backend repos. The Appwrite [Next.js quickstart prompt](/docs/tooling/ai/quickstart-prompts/nextjs) gives the agent the right starting context, and [Appwrite Sites supports Next.js](/docs/products/sites/quick-start/nextjs) for hosting with SSR. + +The cost is that Next.js is heavier than the alternatives for content-heavy or simple sites. If the product is a landing page or a blog, Astro is the better answer. + +# SvelteKit + +SvelteKit is the cleanest alternative when Next.js feels like too much. The framework's conventions are tighter, the generated code is smaller, and the mental model is narrower. Agents have fewer ways to go wrong because there are fewer ways to do anything. + +For vibe-coded apps, SvelteKit shines on small-team or solo-founder projects. The agent ships less code per feature, which lowers the review burden. The reactivity model is friendly to live, real-time UIs that pair well with [Appwrite Realtime](/docs/apis/realtime). The Appwrite [SvelteKit quickstart prompt](/docs/tooling/ai/quickstart-prompts/sveltekit) covers setup, and [Appwrite Sites supports SvelteKit](/docs/products/sites/quick-start/sveltekit) for SSR-capable hosting. + +The trade-off is community size. The training-data footprint is smaller than React's, so the agent's first draft is occasionally less idiomatic. For most projects this is a fine trade. For projects that pull on niche libraries, the React ecosystem still wins. + +# React with TanStack Start + +For teams that want React with a fully-typed, file-based router and clean SSR without committing to Next.js conventions, TanStack Start is the right answer in 2026. It pairs TanStack Router and TanStack Query, both of which have become standard React building blocks, with a Vite-based framework that agents handle well. + +The agent ergonomics are excellent. The types are sharp enough that the agent catches its own mistakes during the build. The conventions are clear enough that generated code does not drift across files. Appwrite ships a [TanStack Start quickstart prompt](/docs/tooling/ai/quickstart-prompts/tanstack-start) and [TanStack Start hosting on Sites](/docs/products/sites/quick-start/tanstack-start). + +For plain React (without a framework), use TanStack Start or Next.js. Vibe coding against a custom Vite plus React Router setup is doable, but the agent has to be told a lot more about your conventions before its output is consistent. + +# Nuxt + +Nuxt is the Vue equivalent of Next.js: a full-stack framework with file-based routing, server routes, and a stable convention set. For Vue-first teams, it is the obvious vibe coding choice. + +The training-data footprint is large enough that agents produce clean Nuxt code in one shot for common patterns. The auto-imports system shortens generated code further, which is a quiet win on review burden. Appwrite ships a [Nuxt quickstart prompt](/docs/tooling/ai/quickstart-prompts/nuxt) and [Nuxt hosting on Sites](/docs/products/sites/quick-start/nuxt). + +Pick Nuxt when the team already knows Vue, when the design system is Vue-shaped, or when you want a slightly less opinionated alternative to Next.js with the same project shape. + +# Vue (without Nuxt) + +Plain Vue is fine for narrow apps that do not need server routes, auth flows on the server, or SSR. Agents produce clean Vue components on the first try, and the framework's reactivity model is friendly to the kinds of UIs vibe coding produces well. + +For most vibe-coded products, the better answer is Nuxt, which gives you the framework benefits without inventing your own conventions. For internal tools, lightweight apps, or single-page experiences, plain Vue is reasonable. The Appwrite [Vue quickstart prompt](/docs/tooling/ai/quickstart-prompts/vue) covers the integration, and [Sites supports Vue](/docs/products/sites/quick-start/vue) directly. + +# Astro + +Astro is the right pick for content-heavy sites: blogs, documentation, marketing pages, landing pages. The framework's island architecture lets you mix static and interactive content cleanly, and the agent's first draft is usually shippable. + +Where Astro is not the right pick is dense app-style interactivity. The framework is optimized for content with islands of interactivity, not the other way around. If the product is a dashboard, an authenticated SaaS app, or a real-time tool, pick Next.js, SvelteKit, or Nuxt instead. + +[Appwrite Sites supports Astro](/docs/products/sites/quick-start/astro) for static and SSR sites, which makes the hosting story clean even when the agent generates a hybrid Astro project. + +# Angular + +Angular has the strongest discipline of any major framework, which cuts both ways for vibe coding. The conventions are strict enough that agents have a hard time producing the wrong shape. The same strictness produces more code per feature than Vue, Svelte, or React, which raises the review burden. + +For enterprise teams already on Angular, the vibe coding workflow works well. Agents produce idiomatic services, components, and modules without much steering. The Appwrite [Angular quickstart prompt](/docs/tooling/ai/quickstart-prompts/angular) covers integration, and [Appwrite Sites supports Angular](/docs/products/sites/quick-start/angular). + +For teams choosing a stack fresh, Angular is the heaviest option on this list. Pick it when the team or the product already calls for it, not as a default. + +# Solid + +Solid has a small but loyal community, and the model handles its idioms surprisingly well given the smaller training-data footprint. The reactivity model is similar enough to React that prompts written for React produce mostly-correct Solid output, which lowers the friction. + +For most vibe-coded products, the right answer is still a more mainstream framework with a larger footprint. For teams that already use Solid or want the smallest possible runtime, the Appwrite [Solid quickstart prompt](/docs/tooling/ai/quickstart-prompts/solid) covers integration. + +# React Native and Flutter for mobile + +The two mobile options that fit cleanly into a vibe coding workflow are React Native and Flutter. + +React Native benefits from the same training-data advantage as React on the web. Agents in Cursor and Claude Code produce useful first drafts for screens, navigation, and platform-specific integrations. The Appwrite [React Native quickstart prompt](/docs/tooling/ai/quickstart-prompts/react-native) covers integration. + +Flutter has tighter conventions and excellent first-party docs, which the agent respects. Output quality on Flutter is high, especially for UI-heavy apps where the framework's widget model maps cleanly to generated code. The Appwrite [Flutter quickstart prompt](/docs/tooling/ai/quickstart-prompts/flutter) and [Sites support for Flutter](/docs/products/sites/quick-start/flutter) cover the full path. + +# Pairing the frontend with a backend the agent can reason about + +The framework choice handles the agent's prior on the client. The other half of the workflow is the backend the agent reaches through. + +A backend with typed primitives, scoped API keys, and an MCP server produces correct integration code on the first try. A backend without those produces code the agent guesses at, and the cleanup compounds across every feature. + +[Appwrite Cloud](https://cloud.appwrite.io) covers [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Sites](/docs/products/sites), and [Realtime](/docs/apis/realtime) under one model. The [API MCP server](/docs/tooling/ai/mcp-servers/api) lets the agent operate on the project, the [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) keeps it on current docs, and [Agent Skills](/docs/tooling/ai/skills) provide SDK context. Editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) install all of that in one step. + +The full backend comparison is in [Best backend for vibe coding apps in 2026](/blog/post/best-backend-for-vibe-coding-apps). + +# Picking a frontend stack you will not regret in six months + +Pick the framework with the strongest prior for the product you are building. Pair it with a backend the agent can reason about. Run the same pre-launch review every time, and let the agent handle the work it is good at while you handle the parts that still need a human. + +The shortest path is Next.js, SvelteKit, or Nuxt on the frontend, [Appwrite Cloud](https://cloud.appwrite.io) on the backend, and [Appwrite Sites](/docs/products/sites) for hosting. The agent picks up where you stop, and you keep the codebase you will live with for a year. + +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) +- [Appwrite quickstart prompts](/docs/tooling/ai/quickstart-prompts) +- [Appwrite Sites](/docs/products/sites) +- [Best vibe coding tools in 2026](/blog/post/comparing-vibe-coding-tools) diff --git a/src/routes/blog/post/can-vibe-coding-replace-junior-developers/+page.markdoc b/src/routes/blog/post/can-vibe-coding-replace-junior-developers/+page.markdoc new file mode 100644 index 0000000000..9d6045b872 --- /dev/null +++ b/src/routes/blog/post/can-vibe-coding-replace-junior-developers/+page.markdoc @@ -0,0 +1,89 @@ +--- +layout: post +title: "Can vibe coding replace junior developers?" +description: "Vibe coding produces code at a junior developer's pace, but it does not replace the role. Here is what actually changes for hiring, mentorship, and team shape." +date: 2026-05-13 +cover: /images/blog/can-vibe-coding-replace-junior-developers/cover.avif +timeToRead: 8 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "Can vibe coding tools replace a junior developer?" + answer: "Not as a one-to-one swap. Tools like Cursor, Claude Code, Windsurf, and Lovable generate code at or above the speed of a typical junior, but they do not own outcomes, sit in standups, learn the codebase over months, or grow into the senior engineers the team needs in two years. They replace some of the work a junior used to do. They do not replace the role." + - question: "What kind of work still needs a junior developer?" + answer: "Reviewing what the agent produced, owning a feature end to end, debugging incidents, writing and maintaining tests, talking to designers and product, learning the codebase, asking the questions only a new pair of eyes thinks to ask, and growing into the next senior on the team. Vibe coding makes that work faster, not optional." + - question: "Should I still hire juniors in the vibe coding era?" + answer: "Yes, and probably with more intention than before. The junior role becomes less about typing code and more about judgment, review, and product sense. Teams that stop hiring juniors stop training the seniors they will need in a few years. The pipeline is the cost." + - question: "Does vibe coding raise the bar on what juniors should know?" + answer: "It shifts the bar. Memorizing every syntax detail matters less. Reading diffs critically, understanding system design, knowing what an agent gets wrong, and reviewing security implications matters more. A junior who can spot a missing permission check or a leaked API key in generated code is more valuable than one who can write the same code from scratch." + - question: "How does Appwrite fit into a junior-friendly vibe coding workflow?" + answer: "Appwrite covers the primitives a junior would otherwise hand-roll: [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), and [Sites](/docs/products/sites). The [API MCP server](/docs/tooling/ai/mcp-servers/api), [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), and [Agent Skills](/docs/tooling/ai/skills) give the agent enough context to produce code a junior can review without spending the first week guessing at SDK shapes." +--- + +The question shows up in every hiring discussion since 2025. If Cursor and Claude Code can scaffold a full feature in an afternoon, why hire someone who would have taken a week to do the same? The answer is more interesting than the question suggests, and it changes what a junior engineering role actually looks like. + +# What a junior developer used to do + +Before vibe coding, a junior's first year was mostly about producing code. Take a small ticket, find the right file, write the function, open a PR, get review feedback, ship. The throughput was lower than a senior's, but the time spent typing was where most of the learning happened: you saw how the codebase was shaped, you broke things and fixed them, you learned which patterns held up. + +That output is exactly the surface that AI coding tools eat first. A scaffolded form, a CRUD endpoint, a refactor across three files, an integration with a third-party API. These are jobs an agent in Cursor or Claude Code now finishes in minutes, with code that passes review most of the time. + +The naive read is that the junior role is obsolete. The honest read is that the typing part of the junior role is obsolete, and the typing part was never the point. + +# The work that does not transfer to an agent + +A lot of what a good junior does has nothing to do with how fast they can type. They sit in standups. They own a small feature end to end and learn what owning means. They notice that the schema does not match what product asked for. They open a PR with three questions in the description because they do not yet know which answer is the standard. They debug an incident at 11pm and learn what the logs do and do not tell you. + +None of that ports to an agent. An agent does not own anything. It will not call out a missing requirement in a planning meeting. It will not flag that the spec contradicts itself. It will not ask the senior why the team uses a soft-delete pattern in one table and a hard delete in another. The juniors who learn to do those things become the seniors who run the team in three years. If you stop hiring juniors, you stop producing seniors. + +# What the role looks like now + +The junior role has not disappeared. It has shifted up the stack, and the work that lives there is more interesting than the work it replaced. + +A junior now spends less time writing the first draft of a feature and more time reviewing the first draft an agent produced. The skills that matter are reading code critically, spotting the places the agent took a shortcut, asking the senior the question that turns a generated function into a correct one, and learning the architecture of the system well enough to know when the agent's answer fits and when it does not. + +The mental model is closer to an editor than to a typist. The agent produces the prose. The junior decides whether it is honest, accurate, and in the right voice for this codebase. The work compounds the same way it always did: every review teaches you the patterns the team trusts, every bug teaches you a class of mistake that agents make often, every incident teaches you the difference between what looks right and what is right. + +# What juniors get wrong with vibe coding tools + +The failure mode for juniors in the vibe coding era is not laziness. It is accepting a diff before they understand it. An agent will happily commit a function with a missing permission check, a hardcoded admin key, an unsanitized input, or a query that misses an index. The code runs in the demo. The bug ships to production. + +The juniors who get the most out of these tools treat every generated change like a PR from a teammate they do not trust yet. They read the diff before they accept it. They ask the agent to explain anything they cannot follow. They run the change locally, including the unhappy paths. They keep a list of the kinds of mistakes their agent tends to make and review for those mistakes first. + +That habit is the new junior skill. It is the same skill a senior has, applied earlier in the career. + +# What senior developers need to do differently + +The other half of this is what seniors owe their juniors now. Code review used to be a place where a junior learned the patterns of the codebase. With vibe coding, the junior may not have written the diff at all. The senior's job is not to grade syntax. It is to teach what the junior should have caught before sending the diff for review. + +That means more time on architecture conversations, more time on why a generated solution is fine in one place and wrong in another, more time on system design with a whiteboard instead of an editor. The mentorship work that used to happen in line comments now happens earlier, when the junior is choosing which prompts to write and which suggestions to accept. + +Teams that get this transition right end up with juniors who ramp faster and seniors who spend less time on busywork. Teams that get it wrong end up shipping more bugs, faster. + +# What this means for hiring + +Hiring a junior in 2026 is a different conversation than in 2022. The signal you are looking for is not how cleanly someone writes a binary search by hand. It is whether they can read a 200-line diff an agent produced and tell you what is wrong with it. + +Practical interview questions look different. Show a candidate a vibe-coded feature with a real flaw: a missing input check, a leaked secret, a permissions hole, a query without an index. Ask them to find it. The answer to that question tells you more about whether they will grow than any whiteboard puzzle. + +The other signal that matters is curiosity about systems. The junior who asks how authentication works, what an MCP server is, why the team uses tables instead of documents, how Appwrite [Functions](/docs/products/functions) differ from a managed background job queue, is the junior who turns into a senior. Vibe coding makes that curiosity cheaper to satisfy and more valuable to have. + +# Where Appwrite fits for teams hiring junior developers + +The choice of backend matters more for a vibe coding team than it used to. A backend with clean primitives, scoped permissions, MCP support, and documented patterns lets a junior plus an agent produce production-grade code without the senior re-reading every line. + +[Appwrite Cloud](https://cloud.appwrite.io) gives you that shape. [Auth](/docs/products/auth) covers OAuth, sessions, MFA, and Teams. [Databases](/docs/products/databases) cover tables, typed columns, rows, relationships, and queries. [Storage](/docs/products/storage) covers files with permissions, antivirus, and encryption. [Functions](/docs/products/functions) cover server-side logic. [Sites](/docs/products/sites) covers hosting with custom domains and rollbacks. The [API MCP server](/docs/tooling/ai/mcp-servers/api) and [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) keep the agent on current APIs, and [Agent Skills](/docs/tooling/ai/skills) give it SDK context. A junior reviewing this code does not have to debug whether the agent invented an SDK method that does not exist. + +For teams that pair junior developers with vibe coding tools, the same checklist that applies to any production launch applies twice as hard. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) is a good place to anchor your team's pre-launch review. + +# Hiring and training juniors in the vibe coding era + +Vibe coding does not replace junior developers. It replaces a specific slice of what juniors used to do, and it raises the value of everything else. Teams that hire well, mentor well, and put juniors on backends shaped for agents end up with engineers who ramp faster than any previous cohort. Teams that try to skip the role end up with no pipeline. + +If you are building a team that ships with vibe coding tools, start by giving your juniors a backend they can reason about. [Sign up for Appwrite Cloud](https://cloud.appwrite.io), install the [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) plugin, and let the agent handle the syntax while your junior owns the judgment. + +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Appwrite Docs MCP server](/docs/tooling/ai/mcp-servers/docs) +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) diff --git a/src/routes/blog/post/deploy-vibe-coding-projects-to-production/+page.markdoc b/src/routes/blog/post/deploy-vibe-coding-projects-to-production/+page.markdoc new file mode 100644 index 0000000000..e43339b6d1 --- /dev/null +++ b/src/routes/blog/post/deploy-vibe-coding-projects-to-production/+page.markdoc @@ -0,0 +1,149 @@ +--- +layout: post +title: "How to deploy vibe coding projects to production" +description: "A step-by-step guide to deploying vibe-coded apps to production: hosting, domains, secrets, permissions, logs, backups, and a pre-launch review path." +date: 2026-05-14 +cover: /images/blog/deploy-vibe-coding-projects-to-production/cover.avif +timeToRead: 10 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "How do I deploy a vibe-coded app to production?" + answer: "Move the code into a real git repository, point the frontend at a production host like [Appwrite Sites](/docs/products/sites) with a custom domain and SSL, move all secrets to server-side environment variables, narrow permissions on tables and buckets to owner-only where applicable, enable logs on every server-side function, run a pre-launch review against the [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps), and connect a real email inbox before testing auth flows." + - question: "Can I deploy directly from Bolt, Lovable, or Replit?" + answer: "You can for prototypes. Most builders offer a deploy button that ships to their bundled host. The trade-off is lock-in: the URL, the runtime, the rollback story, and often the backend live inside that vendor. For anything that needs a custom domain, scoped keys, and a clean migration path, export the code to git and deploy to a host you control, like [Appwrite Sites](/docs/products/sites) with [Git-based deployments](/docs/products/sites/deploy-from-git)." + - question: "What is the safest order to run the pre-launch steps?" + answer: "Secrets out of the client. Permissions closed down to owner-only on user data. Custom domain with SSL attached. Auth tested on a working inbox. Logs on every production function. Backups confirmed and one restore tested in staging. Rollback path verified. AI-generated server-side functions read end to end. Shipping in any other order tends to expose the wrong thing first." + - question: "How do I handle env vars and secrets cleanly?" + answer: "Keep three environments: development, staging, production. Use a different key per environment, scoped to the minimum permissions the calling code needs. Never put a production key in a client bundle. Rotate any key that ever passed through a cloud AI tool. Appwrite Sites and Functions support [environment variables per environment](/docs/products/sites/environment-variables) so the same code base ships against different secrets." + - question: "What should I do if the AI builder committed secrets to git?" + answer: "Treat every key in the commit as compromised. Rotate them all, including any database URL, OAuth client secret, webhook signing key, or LLM provider key. Rewrite git history to remove the file from the repo and force-push only after the team agrees. Audit access logs on each rotated key for any unexpected use. This is one of the most common vibe coding mistakes; see [vibe coding security mistakes developers ignore](/blog/post/vibe-coding-security-mistakes)." +--- + +The hard part of shipping a vibe-coded app is not generating it. The hard part is turning a working preview into something a real user can hit without breaking it. This is a step-by-step guide to deploying vibe coding projects to production, written for the case where you used a tool like Cursor, Claude Code, Windsurf, Bolt, Lovable, or v0 and now have to launch. + +The order matters. The same checklist run in the wrong sequence ships secrets to the public domain. The same checklist run correctly takes about an afternoon. + +# Step 1: Get the code into a real git repository + +Some builders give you a clean git remote out of the box. Others keep the code inside their environment until you ask. Either way, the first move is to land everything in a repository you control, with a `main` branch, a `.gitignore` that excludes `.env` and `node_modules`, and a clean commit history. + +This step is also where you catch the most common AI builder mistake: a `.env` file or an API key committed to the repo at some point. Search the history before you push to a remote. If you find anything, treat every key in the file as compromised and rotate them later in step 3. + +# Step 2: Decide where the frontend will live + +Picking a host is the first decision that locks in a piece of your launch story. The wrong move is to keep your app on the builder's preview URL. The right move is a production host with a real domain, scoped env vars, and a rollback button. + +[Appwrite Sites](/docs/products/sites) is the path of least resistance if your backend is already on Appwrite. You get [Git-based deployments](/docs/products/sites/deploy-from-git) so every push to `main` builds a new deployment, [custom domains](/docs/products/sites/domains) with automatic SSL, [environment variables](/docs/products/sites/environment-variables) per environment, [deployment logs](/docs/products/sites/logs), and [instant rollbacks](/docs/products/sites/instant-rollbacks) so the first incident is not an emergency. + +If your stack is on Vercel, Netlify, or Cloudflare, the same checklist applies, with different button locations. The non-negotiables are a custom domain, SSL, env vars per environment, and a one-click rollback. + +# Step 3: Move secrets to server-side environment variables + +This is the most common vibe coding failure mode and the single most expensive bug to ship. AI builders happily paste API keys into example components, dump database URLs into client config files, and inline webhook signing keys into the same file as the UI. + +The pre-launch fix is mechanical. + +- Search the repo for hard-coded secrets: API keys, database URLs, OAuth client secrets, webhook signing keys, third-party provider keys. Move every one to a server-side environment variable. +- Confirm that LLM provider keys, payment provider keys, email and SMS keys all live on a server-side [Function](/docs/products/functions), not in the browser bundle. +- Rotate any key that ever passed through a cloud-hosted AI tool. The cost of rotating is hours. The cost of not rotating is years. +- Use separate keys for development, staging, and production. +- Scope each key to the minimum permissions the calling code needs. Avoid master keys outside one-off scripts. + +# Step 4: Lock down permissions before anyone signs up + +The single biggest gap between a vibe-coded prototype and a production app is the permission model. Generated code defaults to writing to a table from the client with whatever role the signed-in user has, without narrowing to the rows the user owns. That is fine for a demo. It is not fine when user B can read user A's data. + +Before launch: + +- Review every table and confirm read and write permissions are scoped to the right roles. Default-deny, then add the minimum. +- Check row-level permissions for any table that stores per-user data: profiles, orders, messages, uploads. [Appwrite Databases](/docs/products/databases) expose row-level permissions per row. +- Confirm that file buckets do not allow public uploads unless the product requires them. [Appwrite Storage](/docs/products/storage) exposes per-bucket and per-file permissions, plus antivirus and encryption flags. +- For collaboration, use [Appwrite Teams](/docs/products/auth/teams) instead of broadening table access. +- Sign in as user A and try to read user B's data. You should fail. + +# Step 5: Wire auth against a real inbox + +Auth is the second most common gap. The signup flow works on the demo account and the builder's preview mailer, so the assumption is that the rest is fine. It usually is not. + +- Decide which identity methods you actually support and remove the rest from your [Appwrite Auth](/docs/products/auth) project: email and password, magic URL, email OTP, OAuth, phone OTP, anonymous. +- Turn on email verification. +- Require a minimum password length and block obvious common passwords. +- Configure session length and confirm you can revoke a session if a user asks. +- Offer MFA for admin and billing surfaces. Appwrite supports TOTP-based MFA on the account. +- Test the password recovery flow on a working inbox, not the AI builder's mailer. +- If you use OAuth, register production callback URLs and remove dev URLs from the provider config. +- Rate-limit signup, login, and password reset endpoints. +- Remove every test account the AI tool created during prototyping. + +# Step 6: Add a custom domain and SSL + +Production lives on your domain, not the builder's preview URL. The setup is mechanical and worth doing before the first user signs up so old links never break. + +- Register the production domain you want users to remember. +- Attach the [custom domain](/docs/products/sites/domains) to your site and confirm SSL is issued. +- Redirect the preview domain to the custom domain so old links keep working. +- Update OAuth callback URLs to the production domain. + +# Step 7: Turn on logs on every server-side function + +The first time you need logs is always worse than any later one. Vibe-coded apps frequently ship without logs because the generator did not enable them and the developer did not check. + +- Enable execution logs for every production [Function](/docs/products/functions). +- Decide on a log retention window that matches your compliance needs. +- Add a log line per meaningful branch: success, validation error, downstream error. +- Confirm auth audit events are accessible so you can investigate suspicious sign-ins. +- Set up at least one basic alert for error spikes. A weekly email is better than no alert. + +# Step 8: Confirm backups and a rollback path + +The moment your UI lets a user delete something, you need a story for getting it back. The moment a deploy ships, you need a story for un-deploying it. + +- Confirm your backend's backup cadence and retention. Write it where the team can see it. +- Test restoring from a backup into a staging project at least once before launch. +- For tables holding irreplaceable data, add a soft-delete pattern so a misclick is recoverable. +- On [Appwrite Sites](/docs/products/sites), confirm [instant rollbacks](/docs/products/sites/instant-rollbacks) are one click away. The first incident is not the moment to learn the rollback story. + +# Step 9: Read every AI-generated server-side function + +Generated server-side code is a first draft that needs the same review you would give a teammate. + +- Read every server-side Function the agent produced. If you would not merge it from a teammate, do not ship it. +- Look for inputs that go straight from request body to database without validation. +- Look for authentication checks that are missing, commented out, or stubbed with a TODO. +- Look for queries built by string concatenation where the backend expects structured query objects. +- Look for secrets that ended up in client code, config files, or example payloads. +- Delete unused endpoints. Dead generated code is an attack surface. + +# Step 10: Run the pre-launch review in order + +If you only have one hour before launch, follow the order from the [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps): + +1. Secrets out of the client. +2. Table, row, and file permissions closed down. +3. Custom domain attached with SSL. +4. Auth flows tested on a working inbox. +5. Logs enabled on every production Function. +6. Backup cadence confirmed and one restore tested in staging. +7. Rollback path confirmed. +8. AI-generated Functions read end to end. + +Each step is small. The combination is the difference between a launch that holds and a launch that does not. + +# Step 11: Hook your agent to production safely + +If you want to keep using your agent against the production project, scope the API key it uses. Avoid handing it a master key. The [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) registers every service automatically, so the API key's scopes are what decide which resources the agent can actually touch. The [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) keeps the agent on current docs, which reduces the rate of generated code that calls methods that no longer exist. + +Editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) install the MCP servers, [Agent Skills](/docs/tooling/ai/skills), and SDK context in one step, which is the cheapest way to keep the post-launch loop working. + +# Shipping vibe-coded apps with Appwrite + +A vibe-coded launch is not about courage. It is about running the same checklist every time and committing to the order. The faster your build loop is, the more often the launch checklist becomes the bottleneck, and the more value there is in having a host, a backend, and an agent surface that fit together. + +[Appwrite Cloud](https://cloud.appwrite.io) covers Auth, Databases, Storage, Functions, and Sites under one platform, with MCP support and Agent Skills for every major SDK. Start the next vibe-coded launch on a stack built for it. + +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) +- [Backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) +- [Appwrite Sites Git-based deployments](/docs/products/sites/deploy-from-git) +- [Appwrite Sites custom domains](/docs/products/sites/domains) diff --git a/src/routes/blog/post/hidden-costs-of-vibe-coding-platforms/+page.markdoc b/src/routes/blog/post/hidden-costs-of-vibe-coding-platforms/+page.markdoc new file mode 100644 index 0000000000..ade2363bb5 --- /dev/null +++ b/src/routes/blog/post/hidden-costs-of-vibe-coding-platforms/+page.markdoc @@ -0,0 +1,101 @@ +--- +layout: post +title: "The hidden costs of vibe coding platforms" +description: "Token bills, lock-in, leaky permissions, schema rot, and vendor risk. The hidden costs of vibe coding platforms and how to keep them from compounding." +date: 2026-05-14 +cover: /images/blog/hidden-costs-of-vibe-coding-platforms/cover.avif +timeToRead: 9 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "What are the hidden costs of vibe coding platforms?" + answer: "Token bills that scale with edits, not output; lock-in to the platform's bundled backend; permission gaps in generated code; schema decisions made by an agent that you live with for years; vendor risk on tools that pivot or shut down; and the time spent on a pre-launch review that the demo never showed you. None of these show up on the pricing page." + - question: "Why is token billing more expensive than it looks?" + answer: "Tools that rewrite entire files on every edit, like Bolt, burn tokens on lines you never touched. Token routing inside agents like Cursor mostly amortizes across small edits, but heavy refactors can run hot. The honest cost is not the monthly subscription. It is what you pay when you are debugging at 1am and re-running the same prompt eight times." + - question: "What is the lock-in cost of vibe coding platforms?" + answer: "Most builders bundle a default backend: Lovable leans on Lovable Cloud and Supabase, Bolt promotes Bolt Cloud Database, Replit runs apps inside the Replit runtime. Switching off the default after launch means rewriting the data layer, the auth flow, and the deploy pipeline. The cheapest fix is to pick a backend at the start that does not change when you outgrow the builder. [Appwrite Cloud](https://cloud.appwrite.io) is open source and portable, which means the data layer survives the move." + - question: "Does vibe coding code cost more to maintain?" + answer: "Sometimes. Generated code without a review pass tends to skip input validation, narrow permissions, and indexes on hot queries. Each of those becomes a maintenance cost the moment real users show up: an incident, a rotation, a migration. A pre-launch review folds most of that work to the front. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) covers the predictable items." + - question: "How do I avoid these costs?" + answer: "Pick a backend with typed primitives, scoped keys, and an MCP surface so the agent generates correct code on the first try. Use a builder you can export from cleanly. Run a pre-launch review before users touch anything. Read every server-side function the agent produced. And rotate any API key that ever passed through a cloud AI tool." +--- + +The pricing page for a vibe coding tool is a snapshot. It tells you what the next bill looks like. It does not tell you what the year looks like after you commit. Most of the cost of using a vibe coding platform lives off the pricing page entirely, and the founders who do not plan for it pay for it twice. + +This post walks through the hidden costs that show up after the prototype works: token bills that scale with edits, lock-in to bundled backends, schema decisions you live with, permission gaps you debug under deadline, and vendor risk on tools that pivot. None of these are reasons not to use vibe coding. They are reasons to use it deliberately. + +# Token bills do not scale with what you ship + +Subscription pricing is the line item people compare. The honest cost is tokens. + +Most agents now bill by tokens or token-equivalent credits. Cursor routes between models. Windsurf caps requests on its base tier. Bolt rewrites entire files on every edit, which burns tokens on lines you never asked it to change. Claude Code prices usage in time-boxed windows, and the higher tiers exist because the lower tier runs out fast on a real codebase. + +The result is that monthly cost is decoupled from output. You can spend $50 in a productive afternoon. You can also spend $50 debugging the same prompt eight times because the agent kept missing the same edge case. Two teams running the same product on the same tool will see bills that differ by an order of magnitude based on prompt habits. + +The fix is not to spend less on tools. It is to spend more on the parts that compound: clear prompts, smaller diffs, and a backend the agent does not have to guess at. The [comparison of vibe coding tools in 2026](/blog/post/comparing-vibe-coding-tools) breaks down where each tool's bill comes from. + +# Bundled backends are the real switching cost + +Every browser-first builder ships with a default backend it wants you to use. Lovable leans on Lovable Cloud and Supabase. Bolt promotes Bolt Cloud Database with Supabase as another option. Replit assembles apps inside the Replit runtime. v0 outputs React components wired to whatever you point them at. + +The cost of accepting the default is invisible at first. Auth is wired to the bundled provider. The data layer assumes the bundled database. The deploy pipeline is opinionated about where it ships. None of this is wrong. It is just a series of decisions you made by accepting the path of least resistance, and the bill comes due if you ever want to move. + +A migration off a bundled backend after launch is rarely just a database export. It is rewriting auth, redoing permissions, swapping SDKs in dozens of files, and rebuilding the deploy story. The cheapest path is to make the backend choice yourself before the agent locks one in. + +[Appwrite Cloud](https://cloud.appwrite.io) is open source and portable. The same primitives that run on Cloud also self-host on any Docker-compatible infrastructure. The migration story is not "rebuild your app" if your needs change. That portability is worth real money over the life of a product. + +# Generated code skips the parts that compound later + +A vibe coding tool optimizes for the demo. The demo is a working flow you can click through. It is not a hardened production app, and the gap shows up in the same places every time. + +- **Permissions narrowed to the wrong scope.** A table that should be owner-only is readable by every signed-in user. +- **Secrets pasted into client files.** The API key the agent used in the example payload ends up in the bundle. +- **Inputs that go straight from the request body to the database.** No validation, no sanitization, no length cap. +- **Hot queries without indexes.** Snappy in development with three rows. A timeout in production with thirty thousand. +- **Functions without logs.** Fine in dev. Impossible to debug in production. + +Every one of these is a cost. You pay it during the incident, the migration, the rotation, or the post-mortem. A pre-launch review folds most of that work to the front, where it costs an afternoon instead of a weekend. The full list is in the [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps). + +# The schema you do not own + +Agents are good at scaffolding tables. They are less good at predicting which queries will dominate in six months. A schema generated in one prompt can lock you into a denormalization decision, a relationship choice, or a column type that becomes painful when the product evolves. + +Schemas are not free to change. A column added now is a migration in three months. A relationship chosen now is a query pattern you optimize against for the life of the table. A type chosen too loosely is a class of bug that lives in the codebase forever. + +The fix is to do the schema design pass yourself, or with the agent, before any feature work starts. Treat the first prompt as "design the schema for this product over the next year, including the queries we will run on it." That prompt produces a different schema than "build me a working version of feature X." + +Backends with typed columns and explicit relationships make this pass easier. [Appwrite Databases](/docs/products/databases) expose tables, typed columns, rows, relationships, queries, and transactions in a model an agent can plan against cleanly. + +# Vendor risk is real and unevenly distributed + +Vibe coding tools move faster than any previous developer category. New entrants ship every quarter. Existing tools change pricing, change limits, get acquired, or shut down. Tools change hands. Roadmaps shift. + +The platform risk lives in two places. One is the tool itself: the editor, the agent, the prompt history. The other is the backend the tool nudged you toward. Tool churn is annoying. Backend churn is rebuilding the app. + +Mitigate both the same way. Pick tools you can swap out without losing your codebase. Pick a backend that is open source, exports cleanly, and is run by an organization you can predict for the next few years. Avoid bundling your product to a vendor that exists only inside one IDE. + +# The cost of a bad prompt is mostly your time + +Token bills are visible. The cost that is not visible is the time spent on prompts that produce the wrong output. A clear prompt with constraints produces a usable diff on the first try. A vague prompt produces five rounds of cleanup. Multiplied across a year, the difference is weeks. + +The skills that lower this cost are not glamorous. Read the diff before you accept it. Keep prompts narrow. Tell the agent what you do not want, not just what you do. Verify against the docs the model may not have read recently. The [seven prompting mistakes you need to stop making right now](/blog/post/7-prompting-mistakes-you-need-to-stop-making-right-now) covers the failure modes most teams converge on. + +A backend with a docs MCP server pulls some of this work off the developer. The agent can read the current docs at call time instead of guessing from training data, which lowers the rate of wrong-method-name diffs. [Appwrite Docs MCP](/docs/tooling/ai/mcp-servers/docs) is the most visible example. The [API MCP server](/docs/tooling/ai/mcp-servers/api) covers the action side: the agent operates on your project through tool calls instead of synthesized HTTP. + +# The cost of a security review that should have happened earlier + +The single most expensive line item in this list is security debt. Vibe coding tools optimize for visible output. Security is mostly invisible right up until it is the only thing anyone is looking at. + +The patterns are predictable: leaky permissions, secrets in client bundles, unvalidated inputs, missing rate limits, and admin keys handed out too liberally. Every team that has shipped a vibe-coded app has at least one of these in their first version. The fix is a review pass before launch, and a second review pass before any feature that touches money, identity, or personal data. The [20 security best practices for vibe coding](/blog/post/vibe-coding-security-best-practices) is a thorough version of that pass. + +# Keeping vibe coding cheap to live with + +The hidden costs do not invalidate vibe coding. They make a case for using it on purpose. Pick tools you can swap. Pick a backend that is open source, exports cleanly, ships an MCP surface, and runs your production app a year from now without a rewrite. Run a pre-launch review every time. Rotate any key that ever touched a cloud AI tool. + +[Appwrite Cloud](https://cloud.appwrite.io) is the path of least resistance for that posture. Open source, MCP for the API and the docs, Agent Skills for every major SDK, and a single set of primitives that cover [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Sites](/docs/products/sites), and [Realtime](/docs/apis/realtime). + +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) +- [Best backend for vibe coding apps in 2026](/blog/post/best-backend-for-vibe-coding-apps) +- [Backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) +- [Appwrite AI tooling](/docs/tooling/ai) diff --git a/src/routes/blog/post/how-vibe-coding-is-changing-software-development/+page.markdoc b/src/routes/blog/post/how-vibe-coding-is-changing-software-development/+page.markdoc new file mode 100644 index 0000000000..609d895f1d --- /dev/null +++ b/src/routes/blog/post/how-vibe-coding-is-changing-software-development/+page.markdoc @@ -0,0 +1,87 @@ +--- +layout: post +title: "How vibe coding is changing software development" +description: "Vibe coding shifts software development from typing code to describing intent. Here is what changes for developers, teams, and the stacks they pick." +date: 2026-05-15 +cover: /images/blog/how-vibe-coding-is-changing-software-development/cover.avif +timeToRead: 8 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "What is vibe coding?" + answer: "Vibe coding is the practice of describing what you want to an AI coding tool like Cursor, Claude Code, Windsurf, Bolt, Lovable, or v0 and letting it generate, edit, and refactor the code for you. The developer's job shifts from typing every line to writing clear intent, reviewing diffs, and steering the agent across multiple files. The term was coined by Andrej Karpathy in early 2025." + - question: "Is vibe coding only for prototypes?" + answer: "No. The early wave of vibe coding produced demo-grade apps, but agent-driven tools now handle real refactors, multi-file changes, and production work. The cap on quality is no longer the model. It is whether the codebase, the docs, and the backend platform are shaped so an agent can reason about them. A well-defined backend like [Appwrite](https://cloud.appwrite.io) with MCP servers and Agent Skills produces production-ready output more often than an ad hoc stack." + - question: "Does vibe coding remove the need to understand code?" + answer: "No. It changes which parts of the work matter. You write less syntax, but you read more diffs, design more schemas, and make more architectural calls. Developers who skip the review step ship broken auth, leaky permissions, and secrets in client bundles. The leverage is real, but only for people who still understand what the agent produced." + - question: "How is vibe coding different from autocomplete?" + answer: "Autocomplete suggests the next token. Vibe coding plans multiple steps. An agent in Cursor or Claude Code can read your repo, edit several files at once, run tests, call your backend through MCP, and iterate on a failure. The interface is closer to delegating to a junior engineer than to using a smarter editor." + - question: "What does vibe coding mean for backend choice?" + answer: "It raises the bar on platforms that are easy for agents to reason about. Backends with clearly named primitives, typed APIs, scoped keys, and MCP servers produce fewer hallucinations and less rework. [Appwrite](https://cloud.appwrite.io) covers Auth, Databases, Storage, Functions, and Sites under one model, ships an [API MCP server](/docs/tooling/ai/mcp-servers/api) and a [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), and provides [Agent Skills](/docs/tooling/ai/skills) so agents do not have to guess SDK shapes." +--- + +Most of the debate about vibe coding gets stuck on whether AI can write good code. That is the wrong frame. The interesting shift is what gets to be the developer's job once the typing is mostly done. + +Vibe coding, the workflow named by Andrej Karpathy in early 2025, is now the default for a real share of new app code. You describe the product, an AI tool like Cursor, Claude Code, Windsurf, Bolt, or Lovable scaffolds the UI and wires the data layer, and you review the diff. The question is not whether this is happening. The question is what it is doing to how software actually gets built. + +# The work is moving up the stack + +Before vibe coding, a developer's time went into syntax, boilerplate, glue code, and a long tail of small refactors. AI tools collapsed most of that. The same hour that used to produce a half-finished CRUD form now produces a working flow with auth, validation, and a usable UI. + +What did not disappear is the work that lives above syntax. Picking a schema you will not regret in three months. Deciding which logic belongs on the client and which belongs on the server. Designing permissions you can defend when traffic shows up. Choosing the third-party services you commit to. Reviewing what the agent generated against the constraints you actually have. + +That is the work vibe coding leaves on the developer's desk, and the better tools are honest about it. The first wave of demos suggested you could ship without reading any of it. The teams that tried that learned the hard way that an AI builder will happily put an admin API key in the client bundle, write to a table with no permissions, and skip every validation check. + +# Iteration cycles are minutes, not days + +The other change is rhythm. Traditional development moves in days: a spec, a branch, a PR, a review, a deploy. Vibe coding compresses that into minutes. Ask for a feature, watch it appear, run it, point at what is broken, ask again. + +This is why prototypes look so different. The barrier between "I want to test this" and "there is a working app" is now mostly the time it takes to type the prompt. Teams that used to schedule a design sprint to explore three ideas now build all three on the same afternoon and pick the one that survives contact with users. + +It also changes what counts as throwaway code. When a working prototype takes an hour, you throw more of them away. When a refactor takes one prompt, you refactor more often. The cost of changing direction has dropped by an order of magnitude, and the products built this way tend to look like it. + +# The skill that matters now is taste + +Once the syntax tax is paid by the agent, the developer's edge shifts to judgment. Which problem is worth solving. Which feature is worth shipping. Which generated diff is fine and which one will break under real traffic. Which third-party dependency you will still want in a year. + +This is taste, and taste does not scale with model size. It scales with experience, exposure, and reading a lot of code. The developers who get the most out of vibe coding are not the ones who type the longest prompts. They are the ones who can look at a generated function, spot the missing input validation in three seconds, and ask for a fix that handles the exact edge case they have in mind. + +Vibe coding raises the floor on what a single person can build. It also raises the ceiling on what the best developers can ship, because they get to spend their hours on the parts of the job that actually need them. + +# Backends become the leverage point + +The agent writes most of the frontend code in seconds. It writes most of the integration code in another few seconds. The thing that decides whether a vibe-coded app survives is the backend it is pointing at. + +A backend designed for human developers expects long onboarding, hand-tuned configuration, and a developer who reads every doc page. A backend designed for agents expects the opposite. It needs clearly named primitives so the agent's tool calls are obvious, typed APIs so generated code compiles on the first try, scoped API keys so least privilege is the default, and MCP servers so the agent can act on the project instead of guessing HTTP shapes. + +This is why platforms have started racing on agent-native surface area, and it is why the [rise of agent-native backend platforms](/blog/post/agent-native-backend-platforms) is a category story, not a feature checklist. + +[Appwrite](https://cloud.appwrite.io) is shaped for this workflow. [Auth](/docs/products/auth) covers identity, OAuth, MFA, and Teams. [Databases](/docs/products/databases) cover tables, typed columns, rows, relationships, and queries. [Storage](/docs/products/storage) covers files with per-bucket permissions, antivirus, and encryption. [Functions](/docs/products/functions) cover server-side logic with execution logs and scoped runtimes. [Sites](/docs/products/sites) cover hosting with custom domains, env vars, and rollbacks. The [API MCP server](/docs/tooling/ai/mcp-servers/api) and [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) let agents act on the project and read current docs, and [Agent Skills](/docs/tooling/ai/skills) give them language-specific SDK context. + +# The roles around the developer are changing + +Vibe coding also changes who is in the room. Product managers who never wrote production code now build internal tools in a weekend. Designers who used to hand off Figma files now ship working pages and let an agent finish the integration. Founders who would have hired their first engineer to build a prototype now run it themselves and hire later, for the parts where judgment is the bottleneck. + +This does not eliminate engineering. It changes the shape of an engineering team. Less time on the parts a model handles, more time on review, architecture, and the systems that keep a vibe-coded app alive in production. The teams that fight this transition spend their hours typing what the agent could have produced. The teams that lean in spend their hours on the parts that still need a human. + +The thing being optimized is not lines of code. It is what gets shipped and how fast it improves once real users touch it. + +# Production hardening still belongs to humans + +A pattern repeats across teams that have shipped vibe-coded apps. The first version comes out fast. The first incident comes out faster. The fix is almost always the same: a layer of production hardening that the prototype never had. + +Permissions narrowed to owner-only on user data. Secrets pulled out of the client and rotated. Server-side functions added for anything that touches money, third-party APIs, or sensitive data. Logs turned on. Backups verified. A custom domain attached. A pre-launch review run against every generated function. + +Vibe coding does not remove that work. It moves it. The faster you can build, the faster you can put something fragile in front of real users, and the more important the pre-launch list becomes. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) walks through the predictable failure modes and the order to fix them in. + +# Building production-ready vibe-coded apps with Appwrite + +Vibe coding is the largest shift in how software gets written since the move from waterfall to continuous delivery. The change is not that AI writes code. The change is that the developer's job is now to define intent, review output, and own the parts a model cannot. The teams that get this right ship more, regret less, and spend their time on the work that actually compounds. + +Start the next vibe-coded project on a backend built for agents. [Appwrite Cloud](https://cloud.appwrite.io) gives you the primitives, [Appwrite Sites](/docs/products/sites) hosts the frontend, and the [AI tooling hub](/docs/tooling/ai) covers MCP, Skills, and editor plugins for Claude Code, Cursor, Windsurf, and more. + +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Appwrite Agent Skills](/docs/tooling/ai/skills) +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) diff --git a/src/routes/blog/post/vibe-coding-security-mistakes/+page.markdoc b/src/routes/blog/post/vibe-coding-security-mistakes/+page.markdoc new file mode 100644 index 0000000000..9c9a694aa0 --- /dev/null +++ b/src/routes/blog/post/vibe-coding-security-mistakes/+page.markdoc @@ -0,0 +1,146 @@ +--- +layout: post +title: "Vibe coding security mistakes developers ignore" +description: "The vibe coding security mistakes developers ignore: leaked keys, open permissions, prompt-history leaks, weak auth defaults, and the fixes that actually work." +date: 2026-05-15 +cover: /images/blog/vibe-coding-security-mistakes/cover.avif +timeToRead: 10 +author: aditya-oberai +category: security +unlisted: true +faqs: + - question: "What is the most ignored vibe coding security mistake?" + answer: "Trusting that table and bucket permissions are correct because the demo worked. Generated code routinely defaults to read and write for every authenticated user, with no narrowing to the row or file that the user owns. The fix is to sign in as user A and try to read user B's data. You should fail." + - question: "Why are API keys leaking in vibe-coded apps?" + answer: "AI builders have no strong prior against pasting a real key into a component file, an example payload, or a config that ships with the bundle. The fix is to grep the repo for known key shapes before launch, rotate any key that ever sat in a cloud AI chat, and move every secret to a server-side environment variable on a Function or a hosted service like [Appwrite Sites](/docs/products/sites)." + - question: "Are prompts and chat history a security risk?" + answer: "Yes. Anything pasted into a cloud-hosted AI tool, including database URLs, OAuth secrets, sample payloads, and customer data, can be cached or logged on the vendor side. Treat every secret that ever passed through chat as compromised, rotate it, and avoid pasting customer data into prompts. Use scoped API keys so the agent only has the surface area it needs." + - question: "What auth defaults should I never accept from an AI builder?" + answer: "Email verification off, password minimum unset, no MFA, no rate limit on signup or login, OAuth callbacks pointing at preview domains, and test accounts still active. Each is a one-line fix in [Appwrite Auth](/docs/products/auth) and one of the most common vibe coding security mistakes." + - question: "Where can I find a complete vibe coding security checklist?" + answer: "Two posts cover the full surface: [20 security best practices for vibe coding](/blog/post/vibe-coding-security-best-practices) covers the practices a vibe coder should run every project. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) is the pre-launch review. This post focuses on the security mistakes developers make repeatedly even after reading those guides." +--- + +The first wave of vibe coding security advice focused on the obvious failures: SQL injection, missing validation, weak password hashing. Those failures still happen, and the 20 security best practices for vibe coding cover them. The mistakes worth a separate post are the ones that survive the first review. The ones developers know about, intend to fix, and still ship anyway. + +This is a working list of the vibe coding security mistakes developers ignore, why each one keeps happening, and the version of the fix that actually closes it. + +# 1. Trusting that permissions are correct because the demo worked + +The single most common failure. Generated code creates a table, sets it readable by every signed-in user, and ships. The demo works because there is one user. The bug ships because there are now two. + +The fix is mechanical and almost no one runs it. Sign in as user A, try to read and mutate user B's rows. You should fail every operation that should not work. If anything succeeds, narrow the row permissions before launch. [Appwrite Databases](/docs/products/databases) expose row-level permissions per row, and [Appwrite Storage](/docs/products/storage) expose them per file. Default-deny on every resource, then add the minimum. + +# 2. Letting API keys live wherever the agent put them + +The agent does not have a strong prior against pasting a real API key into a component file, an example payload, or a config that ends up in the bundle. Most developers know this, search for the obvious ones, and miss the rest. + +The fix is to grep the whole repo for the key prefixes you use, not just `.env`. Database URLs, OAuth client secrets, webhook signing keys, third-party provider keys, internal admin keys. Anything that ever sat inside a generated file. Then rotate every key that passed through a cloud-hosted AI chat at any point. Use separate keys per environment, scope each one to the minimum permissions the calling code needs, and never ship a master key to the client. + +The [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) authenticates with an API key, so the scopes you grant that key decide what the agent can touch. Grant only what the agent's current task needs. + +# 3. Treating chat history as ephemeral + +Prompts and pasted payloads sit on the vendor side longer than developers expect. A database URL pasted once to fix a bug is now in chat history. A sample customer record pasted to ask the agent to generate a query is now in chat history. Developers should assume that prompts and pasted data may be retained or logged by cloud AI vendors. + +The fix is to treat any secret that ever appeared in a cloud-hosted chat as compromised and rotate it. Avoid pasting customer data into prompts. If you need to share data with the agent for debugging, use anonymized samples and dispose of them after the session. For long-running workflows, an [Appwrite Functions](/docs/products/functions) deployment is the right place to debug with real data, not a chat window. + +# 4. Skipping the server-side review for "small" features + +Vibe coding makes new features cheap, and cheap features bypass review. The default failure mode is "this is too small to bother reviewing, ship it." A week later, the small feature is an unvalidated input endpoint that takes user input straight to the database, or an admin-only action that the agent forgot to gate. + +The fix is to never ship server-side logic without reading it. Every [Appwrite Function](/docs/products/functions) that goes to production gets the same review as a PR from a teammate: input validation, permission checks, error handling, log lines, and a sanity pass on what the function will do if called from an unauthenticated client. + +# 5. Leaving every auth method on by default + +Generated auth setups tend to enable everything: email and password, OAuth, magic URL, phone OTP, anonymous. Every method that is enabled is a surface to defend. Most products only need one or two. + +The fix is to decide which identity methods you actually support in [Appwrite Auth](/docs/products/auth) and disable the rest. Verify the methods you keep: enforce email verification, require a minimum password length, configure session length and revocation, rate limit signup and login, and remove any test accounts the agent created during prototyping. + +# 6. Missing MFA on the surfaces that need it + +A vibe-coded app rarely ships with MFA. The agent did not enable it, the developer did not ask, and it works fine in the demo. Then a customer with a real spend gets phished and the support burden is enormous. + +The fix is to offer MFA on accounts that touch billing or admin functionality. [Appwrite Auth supports TOTP-based MFA](/docs/products/auth) on the account. The cost is one configuration toggle and a paragraph in the onboarding flow. The benefit is the difference between "we are sorry, we will reset your account" and "the attacker hit MFA and gave up." + +# 7. Treating preview deploys like production + +Preview deploys do not enforce the same controls as production. They often run with relaxed CORS, weaker rate limits, and admin keys that should not be on the internet. Generated code is happy to keep using the preview URL after launch, because the agent does not know the difference. + +The fix is to attach a real domain before users sign up. [Appwrite Sites](/docs/products/sites/domains) supports custom domains with automatic SSL. Update OAuth callback URLs to the production domain. Redirect the preview domain to the production domain so old links survive. And revoke any admin key that was ever used during preview. + +# 8. Skipping logs on functions because the demo worked + +Logs are the cheapest investment in a production app and the most often skipped. Generated functions ship without explicit log lines, retention windows are left at the default, and the first time anyone looks at logs is during an incident. + +The fix is to enable [execution logs](/docs/products/functions) on every production Function, set a retention window that matches your compliance needs, and add a log line per meaningful branch. Confirm auth audit events are reachable so you can investigate suspicious sign-ins later. A weekly email alert on error spikes is enough to catch the first incident before a customer reports it. + +# 9. Trusting the agent on input validation + +The agent generates input handlers that work for the happy path. It rarely validates length, type, content, or rate. A vibe-coded endpoint will gladly accept a 50 MB string in a field that expects a 32-character handle, and the failure shows up later as a database row that breaks the dashboard. + +The fix is to validate every input on the server, regardless of what the client sends. Reject anything outside the expected shape. Cap lengths. Whitelist enums. Sanitize anything that ever ends up in a query, a file path, or a shell command. The [20 security best practices for vibe coding](/blog/post/vibe-coding-security-best-practices) covers this in depth. + +# 10. Forgetting that the client is hostile + +The hardest mental shift in vibe coding is to treat your own UI as an untrusted client. Generated frontends tend to assume that anything the UI sends is fine, because the UI was just generated and looks reasonable. The agent does not consider that a user can call your backend directly with curl. + +The fix is to never trust data because it came from your own UI. Every server-side function validates inputs as if they came from an attacker. Every permission check happens on the server, even when the client also checks. Every admin action requires server-side verification of role, not just the absence of a hidden button in the UI. + +# 11. Skipping rate limits on auth endpoints + +Generated code ships login, signup, password reset, and OAuth endpoints without rate limits. A scripted attacker can brute-force a weak password or spam the password-reset endpoint with thousands of email addresses before anyone notices. + +The fix is to rate-limit every auth endpoint, plus any endpoint that performs work proportional to user input. [Appwrite Auth](/docs/products/auth) supports session and login rate limits at the platform level. Anything generated for custom flows should be reviewed for the same controls. + +# 12. Letting file uploads accept anything + +Generated file upload code tends to default to "any size, any type, any user." The first user with a 500 MB file ruins the bucket. The first user who uploads an executable provides the attack vector for the next incident. + +The fix is to limit allowed file extensions per [Appwrite Storage bucket](/docs/products/storage), set a sensible maximum file size, turn on antivirus scanning for buckets that accept user uploads, and enforce encryption on buckets that hold sensitive documents. Audit signed URLs and keep their lifetime as short as the UX allows. + +# 13. Believing the AI generated audit log is real + +Some agents generate audit log code that looks complete. The function logs the action, the user, and the timestamp to a console.log. The function does not write to a real append-only store. The function is the audit log only in a narrative sense. + +The fix is to confirm that audit logs are actually durable, queryable, and append-only. If the agent's implementation logs to stdout and stops there, replace it with writes to a [Function](/docs/products/functions) with structured logging or to a dedicated audit table with insert-only permissions. + +# 14. Skipping a real backup test + +Backups exist as a configuration option in almost every backend. Backup restores are tested almost nowhere. The first time you need a restore is during an incident, and discovering at that moment that the restore does not work is the worst possible time. + +The fix is to test a restore into a staging project at least once before launch. Confirm the backup cadence matches your data sensitivity. For irreplaceable data, add a soft-delete pattern so a misclick is recoverable without a restore. + +# 15. Pretending compliance is a future problem + +GDPR, CCPA, HIPAA, and SOC 2 do not check whether your app was generated. They check whether the data is handled correctly. Vibe coding does not change that. The agent will happily ship an app that fails any of these without ever flagging the issue. + +The fix is to decide which compliance regimes apply before you ship anything that handles personal data, and to verify the controls each one requires. For HIPAA, that includes data residency and audit logs. For GDPR, data export and deletion endpoints, plus a privacy review. For SOC 2, scoped access and observability. [Appwrite is GDPR, CCPA, and HIPAA compliant](https://cloud.appwrite.io) on the Cloud and supports self-hosting where data residency is the deciding factor. + +# 16. Trusting the agent's "this should be safe" comment + +A small but real failure mode is the agent's own assurances. A generated comment like "this should be safe" or "no validation needed here, the UI already checks" is not a guarantee. It is a hint that the agent did not think the case through. + +The fix is to delete every "this is safe" comment as a class. If the code is safe, prove it with a test. If you cannot prove it, write the missing check. Comments that explain why are useful. Comments that justify a missing check are a flag, not a feature. + +# Where to go for the full security pass + +The mistakes above are the ones that survive the obvious review. They are also the ones that show up after launch, when the cost is highest. Run them as a second pass on top of the foundational checks. + +For the full surface, two posts cover what should be in every team's launch ritual: + +- [20 security best practices for vibe coding](/blog/post/vibe-coding-security-best-practices): the foundational list every vibe coder should run every project. +- [The backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps): the pre-launch review in order. + +Both pair with a backend designed to make secure defaults cheap. [Appwrite Cloud](https://cloud.appwrite.io) covers [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), and [Sites](/docs/products/sites) under one model, with per-row permissions, per-bucket controls, scoped API keys, and MCP support so an agent can run safely against your production project. + +# Closing the security gaps in vibe-coded apps + +The mistakes above are not exotic. They are predictable, repeat-offender failures that every vibe-coded launch has at least one of. The fix is not better tools. It is a habit of running the same review every time, treating the agent's first draft as a first draft, and choosing a backend where the secure default is the easiest default. + +[Sign up for Appwrite Cloud](https://cloud.appwrite.io) and start the next launch on a backend built for this workflow. + +- [20 security best practices for vibe coding](/blog/post/vibe-coding-security-best-practices) +- [Backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) +- [Appwrite AI tooling](/docs/tooling/ai) diff --git a/src/routes/blog/post/vibe-coding-vs-traditional-development/+page.markdoc b/src/routes/blog/post/vibe-coding-vs-traditional-development/+page.markdoc new file mode 100644 index 0000000000..438141add6 --- /dev/null +++ b/src/routes/blog/post/vibe-coding-vs-traditional-development/+page.markdoc @@ -0,0 +1,107 @@ +--- +layout: post +title: "Vibe coding vs traditional development" +description: "Vibe coding vs traditional development compared by speed, code quality, debugging, scaling, and production readiness, with where each one actually fits." +date: 2026-05-16 +cover: /images/blog/vibe-coding-vs-traditional-development/cover.avif +timeToRead: 9 +author: aditya-oberai +category: ai +unlisted: true +faqs: + - question: "What is the difference between vibe coding and traditional development?" + answer: "Traditional development is typing code from a spec, file by file, with the developer making most syntactic decisions. Vibe coding is describing intent to an AI agent in Cursor, Claude Code, Windsurf, Lovable, or Bolt, reviewing the generated diff, and iterating. The work is the same at the system-design and review level. It is radically different at the typing level." + - question: "Is vibe coding faster than traditional development?" + answer: "Yes for the first version, sometimes by an order of magnitude. The catch is that production readiness is not free. The hours saved on the prototype are partially spent on a pre-launch review that catches the failure modes AI generators repeatedly produce: open permissions, leaked secrets, missing indexes, and missing input validation." + - question: "Does vibe coding produce worse code?" + answer: "It produces different code. The first draft is usually clean and idiomatic for common patterns, and weak on the edges: input validation, permission narrowing, error handling, and edge cases the prompt did not mention. A developer who reads the diff and asks for the missing checks gets code that is competitive with what they would have written by hand." + - question: "When should I use traditional development instead?" + answer: "When the code is novel, high-stakes, or unusual enough that an agent has no useful prior. Anything involving cryptography, fine-grained concurrency, performance-critical paths, security-sensitive infrastructure, or research code where the value is in the design itself. Most application code is not in this category." + - question: "Can vibe coding work on a traditional codebase?" + answer: "Yes, and most professional teams now do both. The agent handles the routine parts of the work, the developer handles the rest, and the codebase looks the same regardless of which lines came from which source. The leverage compounds when the codebase is well-organized and the backend is one the agent can reason about, like [Appwrite](https://cloud.appwrite.io) with its MCP servers and typed primitives." +--- + +The framing of "vibe coding vs traditional development" suggests a choice. In practice, professional teams already do both, and the more useful question is which mode fits which kind of work. This post compares the two honestly across speed, code quality, debugging, scaling, hiring, and production readiness, and lays out where each one earns its keep. + +# What the two modes actually look like + +Traditional development is the workflow most developers have used since they started. Read a spec, open a file, type a function, run a test, repeat. The developer makes every syntactic decision and most architectural ones. IDE features like autocomplete, search, and refactor exist, but the developer is the author of every line. + +Vibe coding moves the typing to an agent. You describe a feature to Cursor, Claude Code, Windsurf, Bolt, or Lovable. The agent plans the change across multiple files, edits them, runs your tests, and returns a diff. You read the diff, accept or revise, and iterate. The developer authors intent and judgment. The agent authors syntax. + +The two modes share the part of the work that decides whether a product is any good: choosing what to build, what schema to keep for a year, what permission model to defend, what trade-offs to make at each integration point. The difference is at the keyboard, not at the whiteboard. + +# Speed + +The first version of a feature is dramatically faster under vibe coding. What used to be a week of work, a spec plus a branch plus a PR plus iterations, often fits inside a few prompts. For routine app code, the productivity gain is real and large. + +Traditional development is faster only in cases where the work is unusual enough that the agent has no useful prior. Custom cryptography. Performance-critical hot paths. Research code with novel algorithms. The category of work where the value is in the design itself, not the syntax. + +The second-order effect on speed is more interesting. Because the cost of trying an idea has dropped, teams try more ideas. The right metric is not lines per hour. It is features that ship and survive contact with users per quarter. On that metric, vibe coding wins for most application work. + +# Code quality + +Both modes produce a wide range of output. The averages are not far apart for routine patterns. An agent writes idiomatic React components, CRUD endpoints, and integration glue at a level that compares favorably with a typical junior developer. + +The honest difference is at the edges. Traditional code is written by someone who held the constraints in their head while they typed. They remembered that the input is user-supplied and added validation. They remembered that the table is per-user and narrowed the query. They remembered that the API key is sensitive and put it on the server. + +Agents forget those things unless you tell them, every time, in the prompt. The fix is not better models. It is a review habit. A vibe-coded function reviewed against a clear checklist is competitive with hand-written code. A vibe-coded function shipped without review is not. The [backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) is the version of that checklist most teams converge on. + +# Debugging + +Traditional debugging benefits from authorship. You wrote the code, so you have a working theory of where it went wrong. The mental model is in your head before you open the file. + +Vibe coding pushes that work into the moment you read the diff. If you accept generated code without understanding it, the first bug is the moment you finally have to read it, under deadline. The teams that work well in vibe coding mode invest in two things: a habit of reading the diff carefully when it lands, and logs that make the agent's behavior recoverable later. Appwrite [Functions](/docs/products/functions) ship execution logs you can turn on per-function, which makes the second part of that easier. + +There is a category of bug that vibe coding catches faster than traditional development: surface-level inconsistencies between files. An agent reading the whole repo will often spot a forgotten import or an outdated type definition the human author missed. + +# Scaling + +Scaling looks the same in both modes once the prototype is in production. The same indexes matter. The same connection pool decisions matter. The same observability matters. The agent does not invent new categories of scaling failure. + +What changes is who notices the scaling work before launch. A traditional developer building feature by feature often catches the schema decisions that will hurt at scale because they had to think through every column. An agent-built feature often skips that pass because the prompt did not ask for it. The fix is to ask. Prompts that include "design for 100,000 rows" or "this table will be queried by user_id often" produce different output than prompts that do not. + +# Production readiness + +This is the most honest gap between the two modes. Traditional development tends to ship slower but more complete. Vibe coding tends to ship faster but with predictable holes. The holes are familiar by now: open table permissions, secrets in the client bundle, missing input validation, missing indexes, missing logs, and a preview URL that was never replaced with a custom domain. + +A pre-launch review closes those holes. It is the same review a senior would do for a junior's PR. The work does not disappear under vibe coding. It moves from "spread across many sessions" to "concentrated in a single review pass." Most teams find the concentrated pass cheaper, but they only get the savings if they actually run it. + +Teams that ship vibe-coded apps without a pre-launch review tend to discover the holes the same way: a user reports something that should not be possible, the team panics, and the next two days are spent narrowing permissions and rotating keys. Once is forgivable. Twice is a process problem. + +# Hiring and team shape + +Traditional development hiring optimized for code production. The signal was syntactic fluency, knowledge of patterns, and the speed of writing a clean function from a spec. + +Vibe coding shifts the signal up. The most valuable engineer on a vibe coding team is the one who can read a 200-line generated diff and find the missing permission check in three seconds. They probably write code more slowly than they used to. They ship more of it. + +The implication for hiring is that the interview should change. Show a candidate a vibe-coded feature with a real flaw and ask them to find it. That answers the right question for the workflow most teams now actually use. The longer take on this lives in [Can vibe coding replace junior developers?](/blog/post/can-vibe-coding-replace-junior-developers). + +# Stack choice + +Stack choice mattered under traditional development too, but the cost of a clumsy choice was a longer onboarding and slower velocity. Under vibe coding, the cost compounds. An agent has to learn the stack before it can be useful, and a stack that is hard for an agent to reason about produces worse code on every prompt. + +This is the case for backends with clear primitives and an MCP surface. [Appwrite Cloud](https://cloud.appwrite.io) ships [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Sites](/docs/products/sites), and [Realtime](/docs/apis/realtime) under one model, plus the [API MCP server](/docs/tooling/ai/mcp-servers/api), the [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), and [Agent Skills](/docs/tooling/ai/skills) for SDK context. An agent in [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) can act on a real Appwrite project on the first prompt, which is the difference between a working prototype in an hour and a working prototype in a weekend. The full comparison across backends lives in [Best backend for vibe coding apps in 2026](/blog/post/best-backend-for-vibe-coding-apps). + +# When traditional development still wins + +There are kinds of work where vibe coding does not pay back yet. + +- **Novel algorithms.** If the value is in the design, the agent has no prior to lean on. +- **Cryptography.** The risk of a confident wrong answer is high enough that hand-rolled review beats agent fluency. +- **Performance-critical paths.** Profilers, micro-optimizations, and careful memory work still want a human in the loop on every step. +- **Highly regulated code.** Audited code paths often need provenance the agent does not provide cleanly. The pattern still works, the process around it has to change. +- **Education.** A student who lets the agent write everything learns less than one who writes it themselves. The leverage is real for someone with judgment to apply. + +For everything else, including much of the application code that fills a startup's first year, vibe coding is becoming a default workflow. + +# Picking the workflow your team should default to + +The honest answer is both. Use traditional development where the work demands it. Use vibe coding everywhere else. Hire and train for the review habits that turn generated code into shipped product. Pick a backend the agent can reason about so the leverage compounds. + +[Appwrite Cloud](https://cloud.appwrite.io) gives you the primitives, the MCP surface, and the production story you need to make vibe coding work past the prototype. Start the next project there, install the [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) plugin, and run the pre-launch checklist before the first user signs up. + +- [Appwrite AI tooling](/docs/tooling/ai) +- [Backend checklist for vibe-coded apps before launch](/blog/post/backend-checklist-vibe-coded-apps) +- [Best vibe coding tools in 2026](/blog/post/comparing-vibe-coding-tools) +- [Sign up for Appwrite Cloud](https://cloud.appwrite.io) diff --git a/static/images/blog/25-startup-ideas-you-can-build-with-vibe-coding/cover.avif b/static/images/blog/25-startup-ideas-you-can-build-with-vibe-coding/cover.avif new file mode 100644 index 0000000000..f663093eaa Binary files /dev/null and b/static/images/blog/25-startup-ideas-you-can-build-with-vibe-coding/cover.avif differ diff --git a/static/images/blog/agencies-vibe-coding-client-projects/cover.avif b/static/images/blog/agencies-vibe-coding-client-projects/cover.avif new file mode 100644 index 0000000000..3ad0083f68 Binary files /dev/null and b/static/images/blog/agencies-vibe-coding-client-projects/cover.avif differ diff --git a/static/images/blog/best-backend-for-vibe-coding-apps/cover.avif b/static/images/blog/best-backend-for-vibe-coding-apps/cover.avif new file mode 100644 index 0000000000..f8aa710d85 Binary files /dev/null and b/static/images/blog/best-backend-for-vibe-coding-apps/cover.avif differ diff --git a/static/images/blog/best-frontend-frameworks-for-vibe-coding/cover.avif b/static/images/blog/best-frontend-frameworks-for-vibe-coding/cover.avif new file mode 100644 index 0000000000..e6e7a64893 Binary files /dev/null and b/static/images/blog/best-frontend-frameworks-for-vibe-coding/cover.avif differ diff --git a/static/images/blog/can-vibe-coding-replace-junior-developers/cover.avif b/static/images/blog/can-vibe-coding-replace-junior-developers/cover.avif new file mode 100644 index 0000000000..68f0631ea8 Binary files /dev/null and b/static/images/blog/can-vibe-coding-replace-junior-developers/cover.avif differ diff --git a/static/images/blog/deploy-vibe-coding-projects-to-production/cover.avif b/static/images/blog/deploy-vibe-coding-projects-to-production/cover.avif new file mode 100644 index 0000000000..842a52b286 Binary files /dev/null and b/static/images/blog/deploy-vibe-coding-projects-to-production/cover.avif differ diff --git a/static/images/blog/hidden-costs-of-vibe-coding-platforms/cover.avif b/static/images/blog/hidden-costs-of-vibe-coding-platforms/cover.avif new file mode 100644 index 0000000000..42f72c371e Binary files /dev/null and b/static/images/blog/hidden-costs-of-vibe-coding-platforms/cover.avif differ diff --git a/static/images/blog/how-vibe-coding-is-changing-software-development/cover.avif b/static/images/blog/how-vibe-coding-is-changing-software-development/cover.avif new file mode 100644 index 0000000000..43ec9fa22e Binary files /dev/null and b/static/images/blog/how-vibe-coding-is-changing-software-development/cover.avif differ diff --git a/static/images/blog/vibe-coding-security-mistakes/cover.avif b/static/images/blog/vibe-coding-security-mistakes/cover.avif new file mode 100644 index 0000000000..97510b1a6c Binary files /dev/null and b/static/images/blog/vibe-coding-security-mistakes/cover.avif differ diff --git a/static/images/blog/vibe-coding-vs-traditional-development/cover.avif b/static/images/blog/vibe-coding-vs-traditional-development/cover.avif new file mode 100644 index 0000000000..3f7dccd2ae Binary files /dev/null and b/static/images/blog/vibe-coding-vs-traditional-development/cover.avif differ