چطور یک بازار آنلاین بسازیم: یک نسخه‌ی اولیه‌ی عملی (MVP)

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

بازار دوطرفه واقعاً چیست

یک بازار دوطرفه دو گروه را به هم وصل می‌کند: کسانی که چیزی ارائه می‌دهند (فروشنده، میزبان، فریلنسر، موجر) و کسانی که آن را می‌خواهند (خریدار، مهمان، مشتری، مستأجر). محصول شما بین آن دو قرار می‌گیرد. اینکه کالای فیزیکی باشد، اجاره باشد یا خدمات، جزئیات را تغییر می‌دهد، اما بیشتر بازارها به همان بلوک‌های ساختمانی نیاز دارند.

داده‌ها

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

دسترسی‌ها

بازارها بیشتر در دسترسی‌ها خراب می‌شوند. قواعد را کتبی بنویسید:

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

این قواعد را با ورود به عنوان یک کاربر و تلاش برای باز کردن صفحه‌های کاربر دیگر آزمایش کنید.

تصمیم‌ها و مصالحه‌ها

با باریک شروع کنید

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

چه کسانی را اول جذب کنید

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

پول چطور جابه‌جا می‌شود

این بزرگ‌ترین تصمیم است و سه پاسخ رایج دارد:

۱. بدون پرداخت روی پلتفرم. خریداران مستقیم با فروشنده‌ها در تماس‌اند و مستقیم پول می‌دهند. درآمد شما از هزینه‌ی آگهی، جای ویژه یا اشتراک فروشنده است. ساده‌ترین برای ساخت، ضعیف‌ترین کنترل روی معامله. ۲. فقط از فروشنده هزینه می‌گیرید. فروشنده‌ها اشتراک یا هزینه‌ی هر آگهی را از طریق یک پرداخت معمولی می‌دهند. باز هم ساده است — همان چیزی است که هر اپ پولی دیگری دارد. ۳. خریداران از طریق پلتفرم پرداخت می‌کنند و شما به فروشنده‌ها پرداخت می‌کنید. روی هر معامله کارمزد می‌گیرید. این همان چیزی است که اغلب مردم تصور می‌کنند و پیچیدگی‌اش همین‌جاست.

پرداخت و پرداخت به فروشنده‌ها: نسخه‌ی صادقانه

گرفتن پرداخت کارت کاملاً شناخته‌شده است. تقسیم آن پرداخت و فرستادن بیشترش به یک شخص ثالث مسئله‌ی دیگری است. معمولاً به یک محصول پرداخت که برای پلتفرم‌ها ساخته شده، مثل Stripe Connect، نیاز دارید، نه یک صندوق معمولی.

طبق راهنمای بازار خود Stripe تا سپتامبر ۲۰۲۶، این تنظیم Stripe را مسئول ثبت فروشنده‌ها می‌داند؛ بازار پرداخت‌ها را دریافت می‌کند، کارمزدهای Stripe را پرداخت می‌کند، بازپرداخت‌ها و اختلاف‌ها را مدیریت می‌کند، کارمزد برنامه را روی هر پرداخت می‌گیرد، و تعیین می‌کند پول کی به فروشنده‌ها برسد. همان راهنما می‌گوید پلتفرم مسئول پوشش موجودی منفی حساب‌های متصل است؛ برای مثال وقتی بازپرداخت یا چارج‌بک بعد از پرداخت به فروشنده برسد. همچنین به ابزارهای تقلب برای مدیریت این ریسک اشاره می‌کند.

در عمل، یعنی کاری فراتر از دکمه‌ی پرداخت:

• ثبت و تأیید فروشنده. هر فروشنده پیش از پرداخت باید بررسی هویت و حساب بانکی را بگذراند. بعضی گیر می‌کنند و از شما کمک می‌خواهند.
• Webhookها. اپ شما باید به رویدادهای سرویس پرداخت گوش دهد — پرداخت موفق بود، حساب فروشنده تأیید شد، پرداخت به فروشنده ناموفق بود — و سوابق خودش را به‌روز کند.
• بازپرداخت، لغو و اختلاف. سیاستتان را تعیین کنید، سپس نرم‌افزار را طوری بسازید که آن را دنبال کند، از جمله اینکه هزینه با چه کسی است.
• کارمزد و گزارش. کارمزد پرداخت و کارمزد پلتفرم روی حاشیه‌ی سودتان اثر می‌گذارد؛ قیمت جاری را در سایت ارائه‌دهنده بررسی کنید.
• مالیات و حقوقی. بسته به محل فعالیت شما و فروشنده‌ها، ممکن است تعهدات مالیاتی، گزارش‌دهی یا مجوز داشته باشید. پیش از نگه داشتن یا جابه‌جایی پول دیگران در مقیاس، مشاوره‌ی درست بگیرید.

هیچ‌کدام از این‌ها ساختن یک بازار را ناممکن نمی‌کند؛ فقط یعنی پرداخت به فروشنده‌ها باید فاز خودش را داشته باشد، با حالت تست، حساب‌های آزمایشی و یک سیاست مکتوب، نه با یک پرامپت تنها. راهنمای ما درباره‌ی افزودن پرداخت به اپلیکیشن اصول صندوق، webhookها و حالت تست را پوشش می‌دهد.

یک پرامپت اولیه برای سازنده‌ی هوش مصنوعی

دو طرف، آگهی، معامله و دسترسی‌ها را توصیف کنید و پرداخت را از نسخه‌ی اول بیرون بگذارید:

یک بازار MVP به نام GearShare بساز که در آن عکاسان لیسبون تجهیزات دوربین را به یکدیگر اجاره می‌دهند. فروشنده‌ها ثبت‌نام می‌کنند، آگهی می‌سازند (عنوان، دسته، توضیح، قیمت روزانه، حداکثر ۶ عکس، محله) و استعلام‌های مربوط به آگهی‌هایشان را می‌بینند. خریداران بر اساس دسته مرور می‌کنند، با کلیدواژه جست‌وجو می‌کنند، بر اساس قیمت و محله فیلتر می‌کنند، یک آگهی را باز می‌کنند و یک درخواست اجاره با تاریخ‌ها و پیام می‌فرستند. هر کاربر فقط درخواست‌ها و پیام‌های خودش را می‌بیند. یک صفحه‌ی مدیر برای تأیید آگهی‌های جدید پیش از زنده شدن و پنهان کردن آگهی‌ها بگذار. همه‌چیز را در پایگاه داده ذخیره کن و عکس‌ها را در فضای ذخیره‌سازی فایل. فعلاً بدون پرداخت — روی درخواست‌های تأییدشده عبارت «پرداخت را با صاحب آگهی هماهنگ کنید» را نشان بده. سازگار با موبایل و طراحی تمیز.

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

مراحل ساخت

1. حوزه را انتخاب کنید و دو مسیر کاربر را هر کدام در چند جمله بنویسید.
2. فیلدهای آگهی و دسته‌ها را تعریف کنید. محکم نگهشان دارید.
3. آگهی‌ها و مرور را با داده‌ی نمونه‌ی واقعی بسازید.
4. حساب‌ها و نقش‌ها را اضافه کنید و هر قاعده‌ی دسترسی را آزمایش کنید.
5. معامله را اضافه کنید — استعلام، درخواست رزرو یا پیام‌رسانی.
6. مدیریت و نظارت را اضافه کنید: تأیید، پنهان کردن، مسدود کردن، ویرایش.
7. اعلان‌های ایمیلی اضافه کنید تا مردم بدانند درخواست جدید دارند.
8. با عرضه‌ای که دستی جذب کرده‌اید راه بیندازید در حوزه‌ی خودتان و معامله‌های واقعی را دنبال کنید.
9. فقط بعد از آن پرداخت را اضافه کنید، ابتدا در حالت تست و با گروه کوچکی از فروشنده‌های مورد اعتماد.
10. نظرها را اضافه کنید وقتی معامله‌ی کامل‌شده‌ی کافی برای نظردهی باشد.

اشتباهات رایج

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

هزینه‌ها و ابزارها

هزینه‌های اجرای یک MVP متوسط است: میزبانی، پایگاه داده، فضای ذخیره‌سازی برای عکس‌ها و یک ارائه‌دهنده‌ی ایمیل. پرداخت‌ها کارمزد هر معامله و، برای محصولات پلتفرم، کارمزد پلتفرم اضافی دارند؛ قیمت جاری را در سایت ارائه‌دهنده بررسی کنید. هزینه‌ی بزرگ‌تر زمان است: پشتیبانی فروشنده‌ها، نظارت و رسیدگی به اختلاف‌ها.

وقتی یک محصول آماده بهتر است

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

ساختن با Mythex

Mythex می‌تواند MVP توصیف‌شده‌ی بالا را از گفتگو بسازد: آگهی‌ها، جست‌وجو و فیلترها، جریان درخواست و یک صفحه‌ی مدیر، با یک پایگاه داده‌ی اختصاصی Postgres و فضای ذخیره‌سازی فایل وقتی اپ به آن‌ها نیاز دارد. ورود به اپ با روش خودتان است — مثلاً ایمیل و رمز عبور که در پایگاه داده‌تان ذخیره می‌شود یا یک سرویس احراز هویت میزبانی‌شده، و عامل آن را وصل می‌کند. برای پرداخت، حساب Stripe خودتان را متصل می‌کنید و کلیدها به‌عنوان راز پروژه ذخیره می‌شوند؛ قابلیت یک‌کلیکی پرداخت بازار وجود ندارد، پس Connect، webhookها و منطق پرداخت به فروشنده کدی است که خودتان می‌سازید، در حالت تست آزمایش می‌کنید و مالک آن هستید.

مستندات مفید: ساخت اپ CRUD، افزودن ورود (احراز هویت با روش خودتان) و پذیرش پرداخت با Stripe. قالب بازار اجاره یک پرامپت شروع به شما می‌دهد، و راهنمای MVP برای SaaS نشان می‌دهد چطور نسخه‌ی اول را کوچک نگه دارید.

پرسش‌ها