کل قیف یه فیلده
با AI سریع میسازی — صفحه، قابلیت، کپی. ولی همون فیلدی که تعیین میکنه لانچت بازار داره یا نه، معمولاً کمترین بخشیه که بهش فکر کردی. مال من فرمی بود که ایمیل میگرفت و هیچ راهی نداشتم بدونم ایمیلها واقعاً به دستم میرسن یا نه.
هر کسبوکاری یه نقطهی کلیدی داره که همهچی بهش گره خورده. برای محصولِ قبل از لانچی مثل این سایت، اون نقطه یه کار سادهست: اینکه یه بازدیدکنندهی واجد شرایط ایمیلش رو توی لیست انتظار بذاره. برای یه کسبوکار خدماتی، فرم استعلام قیمته یا رزرو. باقی صفحهها — فاندر، یادداشتها، هاب ویژگیها — همه وجود دارن تا همین یک فیلد امن و قابلاعتماد به نظر برسه.
صفحاتِ دور و برِ اون فیلد رو با AI سریع میسازی. برای همین دقیقاً خود فیلد مهمتره: تنها جاییه که نمیشه قلابی درش آورد. فرم لیست انتظار من کمترین بخشِ بررسیشدهی سایت بود — پیامهای خطا و موفقیت بدِ تراز بودن، توی فارسی ترجمهنشده بودن، و مقصد ایمیل هم یه سرویس شخص ثالث بود که اصلاً نمیتونستم ازش کوئری بگیرم.
اگه نتونی خروجی قیف رو بخونی، نمیدونی قیف کار میکنه یا نه. فقط میدونی دکمه کلیک شده.
اول پیامها، بعد دادهها
دو مشکل جدا از هم: حالت UI فرم، و مقصد ایمیل. به همون ترتیب درستشون کردم — اول ظاهر، بعد یه بکاند که واقعاً بتونم بررسیش کنم.
قدم اول ظاهر بود. پیامهای خطا و موفقیت بهصورت متن ساده کنار فیلدها انداخته شده بودن؛ تراز نشده؛ توی فارسی ترجمهنشده؛ و از تم جدا. به یه جعبهی درست نیاز داشتن: باکسی که توی همون سیستم بصری بقیهی فرم باشه، با فیلد همتراز بشه و درست رنگ معنایی داشته باشه.
پیام موفقیت بخشی از محصوله. اگه طراحی نشده باشه، یعنی محصول طراحی نشده.
جدول ایزوله با دسترسی فقط-درج
فرم باید ایمیل بنویسه و هیچ کار دیگهای نکنه. یک جدول، یک پالیسی، یک کلید.
برای مقصد، نیازم ساده بود: یه جدول تکمنظوره که فقط ثبتنام جدید بپذیره. نه دیتابیس مشترک، نه جمعآوری همهی لاگها، نه سرویس فرمی که نتونم بازرسیش کنم. یک جدول waitlist_signups، RLS فعال، با یه پالیسی فقط-درج برای کاربران ناشناس.
یعنی بازدیدکنندهی ناشناس فقط میتونه یه ردیف اضافه کنه و هیچ کارتر دیگهای — نه select، نه update، نه delete. اون کلیدِ publishable رو میشه خیال راحت توی کلاینت گذاشت، چون خودِ پالیسی از داده محافظت میکنه، نه اون کلید.
جدول
waitlist_signups، ایزوله. یک هدف، یک شکل.
پالیسی RLS فعال، فقط-درج برای کاربران ناشناس. خواندن بستهست.
کلید کلید publishable توی کانفیگ، استفادهشده سمت کلاینت، و ایمن چون پالیسی محافظه.
امنیت با پالیسی، نه با پنهانکاری. اگه کلیدِ سمت کلاینت باید مخفی بمونه، یعنی دادههات از قبل آلودهان.
قیف یه قوله
هر ایمیل توی اون جدول، آدمیه که قبل از لانچ دستش رو بلند کرده. اون لیست تنها داراییست که قبل از درآمد زنده میمونه.
وقتی فرم بالاخره به جدولی نوشت که میتونستم کوئریش کنم، کار غیرجذاب رو انجام دادم: چک کردم. چند ثبتنام آزمایشی، یه کوئری روی جدول، ردیفها حاضر. برای اولین بار ثابت شد قیف بیصدا نشت نمیکنه.
اگه میخوای از AI نتیجهی واقعی بگیری، باید باهاش مثل یه تیم برخورد کنی که مسیر کارش قابلبررسیست، نه مثل یه پنجرهی چت که امیدواری درست جواب بده. مسیری که نتونی بررسیش کنی، مال تو نیست. لیست انتظار کوچکترین قیف سایت بود و بیشترین پیامد رو هم تنها خودش میبرد.
فرم تا وقتی نتونی خروجیش رو بخونی محصول نیست؛ قبل از اون فقط یه امیده.
فرم حالا روی یه صفحهی فروند نشسته که دور و بر معماری واقعی SpielOS ساخته شده — نقشها، مهارتها، جا کانتکست و هارنس (همون بخشی که ایجنتها توش مدیریت و اجرا میشن) — تا همون قولِ ایمیل با محصولی که معرفی میکنه یکی باشه. اون صفحه وابسته به زبانه: هر برچسب، هر حالت، هر پیام از لایهی ترجمه رد میشه، هم انگلیسی هم فارسی.
همون یک فیلد رو بررسی کن
سه چک قبل از اینکه هر چیزی که تقاضا جذب میکنه رو لانچ کنی.
میتونی خروجی رو بخونی؟ لیدها کجا میرن؟ همین الان میتونی کوئری بزنی؟ اگه جواب یه داشبورده که کنترلش دست تو نیست، داری فقط حدس میزنی.
همهی حالتها طراحی شدن؟ لودینگ، خطا، موفقیت — هر حالتی بخشی از رابطانه. اگه موفقیت تصادفی به نظر برسه، اعتماد هم فقط نتیجهی تصادفه.
با هر زبانی که سرویس میدی حرف میزنه؟ اگه سایتت دو زبانهس، فرم هم باید دو زبانه باشه. فرمِ ترجمهنشده توی سایتِ ترجمهشده، یه سیگنال بلنده که سایت رهشن.
اون فیلدی که تقاضا جذب میکنه، خودش یه محصوله. اونجوری بسازش که انگار کل کسبوکار بهش وابستهست، چون واقعاً وابستهست.
فرم لیست انتظار بالاخره به جدولی مینویسه که میتونم بخونم.
یک جدول، یک پالیسی فقط-درج، یک کلید. اگه نتونی قیف رو بررسی کنی، قیف نداری.
ثبت درخواست — بررسی رایگان