ساخت وب‌اپ بدون کدنویسی: از یک ایده‌ی کوچک تا لینکی که می‌فرستی

سخت‌ترین بخش اولین پروژه، کدش نیست؛ انتخاب چیزی است که واقعاً تمام شود. خیلی‌ها ایده‌ای برمی‌دارند که سه ماه کار دارد و انتظار دارند تا آخر شب آنلاین باشد. ساخت وب‌اپ بدون کدنویسی با دستیارهای هوش مصنوعی امروز شدنی است، اما نه با هر ایده‌ای و نه با هر روشی. این نوشته یک پروژه‌ی کوچک واقعی را قدم‌به‌قدم جلو می‌برد — از انتخاب ایده تا لحظه‌ای که لینکش را برای کسی می‌فرستی — و جاهایی را که تقریباً همه گیر می‌کنند، با اسم و رسم نشان می‌دهد.

ایده‌ی اول باید در یک جمله جا شود

معیار ساده‌ای هست: اگر نمی‌توانی کاری را که برنامه انجام می‌دهد در یک جمله‌ی روشن بگویی، ایده هنوز برای پروژه‌ی اول بزرگ است. «جایی که هزینه‌های سفر گروهی را ثبت می‌کنم و می‌گوید آخرش هرکس به چه کسی بدهکار است» یک جمله است. «یک شبکه‌ی اجتماعی برای مسافران» یک جمله نیست، یک آرزوست.

پروژه‌ی اولِ خوب معمولاً همین شکل را دارد: یک صفحه، یک نوع داده، و دو یا سه کاری که کاربر با آن داده می‌کند. نمونه‌های واقعی:

• فهرست خرید مشترک خانه که چند نفر با یک لینک می‌بینند و تیک می‌زنند.
• ثبت ساعت کار روزانه‌ی فریلنسری با جمع هفتگی و یک خروجی ساده.
• فرم درخواست مرخصی برای یک تیم ده‌نفره که همه‌چیز در یک جدول جمع شود.
• ماشین‌حساب قیمت خدمات: چند ورودی، یک عدد خروجی، یک دکمه‌ی اشتراک‌گذاری.

و برای بار اول نه: هر ایده‌ای که از روز اول به ورود کاربر با رمز، پرداخت آنلاین، اعلان موبایل یا آپلود ویدیو نیاز دارد. هیچ‌کدام غیرممکن نیستند، ولی هرکدام یک لایه‌ی تازه از سرویس و کلید اضافه می‌کنند و تو را از آن چیزی که واقعاً یاد می‌دهد دور می‌کنند: تمام‌کردن یک کار کوچک.

قبل از باز کردن هر ابزاری، چهار چیز را بنویس

دستیار هوش مصنوعی کدنویس خوبی است و ذهن‌خوان بدی. کیفیت چیزی که تحویل می‌گیری تقریباً مستقیم به دقت توضیح تو وابسته است. پیش از هر چت، این چهار چیز را در یک فایل متنی ساده بنویس:

1. کاربر کیست و در چه لحظه‌ای سراغ این برنامه می‌آید.
2. داده دقیقاً چه فیلدهایی دارد (عنوان، مبلغ، تاریخ، پرداخت‌کننده).
3. چند صفحه دارد و در هر صفحه چه می‌بیند.
4. وقتی کاربر کاری انجام داد، دقیقاً چه اتفاقی باید بیفتد.

یک وب‌اپ یک‌صفحه‌ای برای ثبت هزینه‌های سفر گروهی. هر هزینه شامل عنوان، مبلغ به تومان، تاریخ و پرداخت‌کننده از میان اعضای از پیش تعریف‌شده است. صفحه‌ی اصلی فهرست هزینه‌ها را از جدید به قدیم نشان می‌دهد، بالای آن جمع کل و پایین‌تر یک جدول تسویه: هرکس چقدر بدهکار یا بستانکار است. داده فعلاً در همان مرورگر ذخیره شود. بدون ورود کاربر.

این بریف پنج خط بیشتر نیست، ولی همین پنج خط فرق می‌گذارد بین یک دموی بی‌ربط و چیزی که از همان اجرای اول به تصویر ذهنی‌ات نزدیک است. هر چیزی را که ننویسی، دستیار برایت تصمیم می‌گیرد — و تصمیمش معمولاً عمومی‌ترین حالت ممکن است.

در مرورگر بسازم یا روی کامپیوتر خودم؟

برای ساخت وب‌اپ بدون کدنویسی دو مسیر جدی وجود دارد و هرکدام جای خودش را دارد. این جدول تصویر امروز است؛ این حوزه سریع عوض می‌شود، پس پیش از شروع خودت هم یک نگاه تازه بینداز.

ابزار	کجا اجرا می‌شود	نقطه‌ی قوت	جایی که کم می‌آورد
Lovable / Bolt.new	مرورگر	از توضیح تا دموی آنلاین در چند دقیقه	با بزرگ‌شدن پروژه، کنترل روی جزئیات کم می‌شود
v0	مرورگر	ساخت سریع رابط کاربری و کامپوننت	منطق سمت سرور و داده را باید جای دیگری ببندی
Cursor / Windsurf	کامپیوتر خودت	ویرایشگر کامل با چت روی کل پروژه	باید با نصب Node و ترمینال کنار بیایی
Claude Code	ترمینال	کار هم‌زمان روی چند فایل، گیت و اجرای دستور	خط فرمان برای شروع ترسناک به‌نظر می‌رسد

پیشنهاد صادقانه: با یک ابزار مرورگری شروع کن تا در همان نشست اول چیزی ببینی که کار می‌کند؛ این دیدنِ زودهنگام انگیزه را نگه می‌دارد. ولی خروجی را زود روی کامپیوتر خودت بیاور؛ تا وقتی کد دست خودت نیست، نه می‌توانی نسخه نگه داری و نه در لحظه‌ی گیرکردن راه فراری داری. اگر ترجیح می‌دهی همین چرخه را روی یک پروژه‌ی واقعی و با راهنمای قدم‌به‌قدم جلو بروی، دوره‌ی ساخت سایت با هوش مصنوعی بدون کدنویسی دقیقاً روی همین مسیر ساخته شده است.

اولین اجرای محلی و سه خطای همیشگی

برای اجرای پروژه روی سیستم خودت به Node.js نسخه‌ی LTS نیاز داری، نه آخرین نسخه‌ی آزمایشی. بعد داخل پوشه‌ی پروژه معمولاً دو دستور کافی است:

npm install
npm run dev

و بعد معمولاً یکی از این سه اتفاق می‌افتد:

• پورت اشغال است (EADDRINUSE). یعنی برنامه‌ای دیگر روی همان پورت باز است؛ پنجره‌ی ترمینال قبلی را ببند یا به دستیار بگو پروژه را روی پورت دیگری بالا بیاورد.
• نسخه‌ی Node جور نیست. پیام خطا معمولاً خودش می‌گوید چه نسخه‌ای لازم است. نصب نسخه‌ی درست ساده‌تر از جنگیدن با خطاست.
• بسته‌ای پیدا نمی‌شود. گاهی دستیار نام کتابخانه‌ای را می‌آورد که وجود خارجی ندارد یا اسمش را اشتباه نوشته. نام را در npmjs.com جست‌وجو کن؛ اگر نبود، همین را صریح بگو تا با چیز واقعی جایگزینش کند.

یک عادت که بیشترین بازده را دارد: متن کامل خطا را از ترمینال کپی کن و بدون خلاصه‌کردن به دستیار بده. «کار نمی‌کنه» هیچ اطلاعاتی ندارد؛ ده خط لاگ تقریباً همیشه دارد.

گیت را از همان دقیقه‌ی اول روشن کن

بدترین لحظه‌ی پروژه‌ی اول این است: نسخه‌ای داشتی که کار می‌کرد، یک تغییر کوچک خواستی، دستیار سه فایل را دست زد و حالا هیچ‌چیز بالا نمی‌آید. بدون گیت، تنها راهت این است که از خود مدل بخواهی اوضاع را برگرداند — که معمولاً بدترش می‌کند.

git init
git status --short     # ببین دقیقاً چه چیزی قرار است ثبت شود
git add .
git commit -m "working: expense list and total"

قاعده ساده است: هر بار چیزی کار کرد، کامیت کن. هر وقت تغییر تازه خراب شد، به‌جای بحث با دستیار، با git restore . فایل‌های دست‌خورده را به آخرین حالت سالم برگردان و درخواست را دقیق‌تر از نو بنویس. حواست باشد این دستور فقط فایل‌های ردیابی‌شده را برمی‌گرداند؛ فایل‌های تازه‌ای که دستیار ساخته سر جایشان می‌مانند و در git status دیده می‌شوند.

یک نکته‌ی امنیتی هم همین‌جاست: فایل .env و هر چیزی که کلید و رمز دارد باید در .gitignore باشد. پیش از هر کامیت یک نگاه به git status --short بینداز تا مطمئن شوی چیز محرمانه‌ای وارد ایندکس نشده. کلیدی که یک بار پوش شد، حتی با کامیت بعدی هم واقعاً پاک نمی‌شود و باید در پنل سرویس باطلش کنی.

از دموی قشنگ تا چیزی که داده را نگه می‌دارد

نسخه‌ی اول تقریباً همیشه داده را در حافظه‌ی مرورگر (localStorage) نگه می‌دارد. برای خودت عالی است، ولی همان لحظه‌ای که لینک را برای بقیه می‌فرستی می‌فهمی هرکس فقط داده‌ی خودش را می‌بیند — و پاک‌کردن حافظه‌ی مرورگر یعنی همه‌چیز رفت. اینجا نقطه‌ی طبیعی گذار به یک دیتابیس واقعی است.

سرویس‌هایی مثل Supabase، Neon یا Turso در چند دقیقه یک دیتابیس میزبانی‌شده به تو می‌دهند. کافی است بگویی «ذخیره‌سازی را از localStorage به این دیتابیس منتقل کن و ساختار جدول را هم بساز».

کدام کلید اجازه دارد به مرورگر برسد

اینجا رایج‌ترین اشتباه پروژه‌های اول اتفاق می‌افتد. این سرویس‌ها معمولاً دو جور کلید می‌دهند: یک کلید عمومی که عمداً برای اجرا در مرورگر ساخته شده، و یک کلید سرور که همه‌ی محدودیت‌های دسترسی را دور می‌زند. در Supabase دومی همان کلید service role است و هرگز نباید در کد سمت کلاینت بیاید؛ هر چیزی که به مرورگر برسد با ابزار توسعه‌دهنده قابل دیدن است.

نکته‌ی دوم همان‌قدر مهم است: کلید عمومی فقط وقتی بی‌خطر است که روی جدول‌ها قواعد دسترسی سطح سطر (Row Level Security) فعال و نوشته شده باشد. بدون آن، کلید عمومی یعنی هرکسی می‌تواند کل جدول را بخواند یا پاک کند. جمله‌ای که به دستیار می‌گویی چیزی در این مایه است: «روی این جدول RLS را فعال کن و سیاست دسترسی بنویس؛ کلید سرویس هم نباید در باندل کلاینت برود — فراخوانی را به یک روت سمت سرور ببر و کلید را از متغیر محیطی بخوان.»

انتشار: کار اصلی ساده است، خطاهایش تازه‌اند

مسیر استاندارد این است: کد را روی GitHub بگذار، بعد در Vercel یا Netlify یا Cloudflare Pages مخزن را وصل کن. از آن به بعد هر بار که پوش می‌کنی، نسخه‌ی جدید خودش ساخته و منتشر می‌شود. یک زیردامنه‌ی رایگان و گواهی HTTPS هم خودکار می‌آید؛ برای شروع کافی است و لازم نیست از روز اول دامنه بخری.

خطاهایی که فقط همین‌جا ظاهر می‌شوند و کسی از قبل هشدارشان را نمی‌دهد:

• متغیرهای محیطی. روی لپ‌تاپ فایل .env هست، روی سرور نیست. باید همان مقادیر را دستی در پنل هاست تعریف کنی، وگرنه بیلد یا اجرا شکست می‌خورد.
• حساسیت به بزرگی و کوچکی حروف. ویندوز و مک به‌طور پیش‌فرض فرق Card.jsx و card.jsx را نمی‌بینند؛ سرور لینوکسی می‌بیند. «روی سیستم من که کار می‌کرد» اغلب دقیقاً همین است.
• فرق حالت توسعه و بیلد. پیش از پوش، یک بار npm run build را روی سیستم خودت بگیر. خیلی از خطاها فقط در بیلد خودشان را نشان می‌دهند.
• تشخیص اشتباه فریم‌ورک یا پوشه‌ی خروجی توسط سرویس میزبان، که با یک تنظیم دستی در همان پنل حل می‌شود.

اگر بیلد شکست، تمام لاگ را به دستیار بده و روی ابتدای خطا تمرکز کن، نه انتهایش؛ خط اول خرابی معمولاً علت است و بقیه فقط بازتاب آن. همین چند نکته، ساخت وب‌اپ بدون کدنویسی را از «چرا آنلاین نمی‌شود» به یک کار کوتاه و قابل تکرار تبدیل می‌کند.

بعد از انتشار، حلقه را کوچک نگه دار

لینک را برای سه نفر واقعی بفرست و کاری نکن جز تماشا. جایی که مکث می‌کنند، جایی که دکمه‌ی اشتباه را می‌زنند و سؤالی که می‌پرسند، از ساعت‌ها حدس‌زدن ارزشمندتر است. بعد هر بار فقط یک تغییر بده، اجرا کن، ببین درست است، کامیت کن. چند تغییر هم‌زمان یعنی وقتی چیزی خراب شد نمی‌دانی کدامش مقصر بوده.

یک فایل README یا یادداشت تصمیم‌ها کنار پروژه نگه دار: چه چیزی کجا ذخیره می‌شود، چرا فلان انتخاب را کردی، چه چیزهایی عمداً ساخته نشده. دستیار بین جلسه‌ها حافظه‌ای از پروژه‌ی تو ندارد و همین فایل، دفعه‌ی بعد در چند ثانیه برش می‌گرداند.

و آخرین نکته: اولین پروژه قرار نیست خوب باشد، قرار است تمام شود. همین که یک بار کل چرخه — ایده، بریف، اجرا، گیت، دیتابیس، انتشار — را رفته باشی، پروژه‌ی دوم خیلی سریع‌تر پیش می‌رود. برای انتخاب مسیر بعدی سری به فهرست دوره‌ها بزن، و اگر دنبال نکته‌های کوتاه‌تر و موردی هستی، نوشته‌های بلاگ همان کار را می‌کنند.

محمدرضا حسینی

مهندس نرم‌افزار و مدرس وایب کدینگ. بیش از ۱۰ سال تجربه ساخت محصولات وب، و سه سال تمرکز روی ساخت محصول با ابزارهای هوش مصنوعی. تا امروز بیش از ۴٬۰۰۰ نفر در دوره‌هایش شرکت کرده‌اند.