ساخت اپلیکیشنی مثل اسنپ یعنی ساخت دست‌کم چهار محصول به‌هم‌پیوسته: اپ مسافر، اپ راننده، یک سرور مرکزی که سفر را به نزدیک‌ترین راننده‌ی مناسب می‌سپارد و یک پنل مدیریت برای اداره‌ی کل سیستم. بخش سخت ماجرا ظاهر اپ نیست؛ تخصیص لحظه‌ای سفر، موقعیت‌یابی دقیق، قیمت‌گذاری، پرداخت و اعتماد دو طرف است. برای همین، راه واقع‌بینانه شروع با یک نسخه‌ی کوچک برای یک شهر یا یک نیاز مشخص است، نه کپی کامل یک سوپراپ.
در این مقاله، از نگاه تیمی که سال‌ها روی محصولات دیجیتال پرکاربرد ایرانی کار کرده، توضیح می‌دهیم یک اپلیکیشن درخواست خودرو از چه اجزایی ساخته می‌شود، چه چالش‌هایی مخصوص بازار ایران است، نسخه‌ی اول را چطور تعریف کنید و هزینه ساخت اپلیکیشن اسنپ یا هر سرویس مشابه دقیقاً به چه چیزهایی بستگی دارد. اسنپ در این متن فقط یک مثال شناخته‌شده است و دییر هیچ ارتباطی با آن ندارد.
ساخت اپلیکیشنی مثل اسنپ دقیقاً یعنی ساخت چه چیزی؟
وقتی کسی می‌گوید «یک اپ مثل اسنپ می‌خواهم»، معمولاً تصویرش صفحه‌ی نقشه و دکمه‌ی «درخواست» است. اما آنچه کاربر می‌بیند نوک کوه یخ است. یک سرویس تاکسی اینترنتی یک پلتفرم دوطرفه است: باید هم‌زمان برای دو گروه با نیازهای کاملاً متفاوت ارزش بسازد و این دو را در لحظه به هم برساند. اگر راننده نباشد مسافر برنمی‌گردد و اگر مسافر نباشد راننده اپ را حذف می‌کند.
- اپ مسافر: انتخاب مبدأ و مقصد، دیدن قیمت، درخواست، پیگیری راننده روی نقشه، پرداخت و امتیازدهی.
- اپ راننده: ثبت‌نام و احراز هویت، آنلاین و آفلاین شدن، پذیرش سفر، مسیریابی، درآمد و تسویه.
- بک‌اند و موتور تخصیص: دریافت موقعیت‌ها، پیدا کردن راننده‌ی مناسب، محاسبه‌ی قیمت و مدیریت وضعیت هر سفر.
- پنل مدیریت و پشتیبانی: تأیید راننده‌ها، رسیدگی به شکایت، تنظیم نرخ‌ها، گزارش‌ها و کنترل تقلب.
هر کدام از این اجزا یک محصول مستقل با کاربر، سناریو و معیار موفقیت خودش است. اشتباه رایج این است که بودجه و زمان صرف اپ مسافر شود و اپ راننده و پنل مدیریت «در حاشیه» ساخته شوند؛ در حالی که کیفیت عملیات روزانه دقیقاً به همین دو بخش وابسته است.
اپ مسافر: لحظه‌های اول تعیین‌کننده است
مسافر معمولاً عجله دارد، گاهی در خیابان ایستاده و با یک دست با گوشی کار می‌کند. پس تجربه‌ی اپ مسافر باید تا حد ممکن کوتاه و قابل پیش‌بینی باشد. اصول عمومی این نوع طراحی را در راهنمای طراحی رابط کاربری اپلیکیشن موبایل توضیح داده‌ایم؛ اینجا روی نکته‌های خاص این حوزه تمرکز می‌کنیم.
انتخاب مبدأ و مقصد
بیشترین خطا و ناامیدی کاربر در همین مرحله رخ می‌دهد. موقعیت GPS در کوچه‌های باریک یا کنار ساختمان‌های بلند جابه‌جا می‌شود و جست‌وجوی آدرس فارسی با املاهای مختلف نوشته می‌شود. پیشنهاد مکان‌های پرتکرار، ذخیره‌ی آدرس خانه و محل کار، امکان جابه‌جا کردن پین روی نقشه و نمایش نام خیابان زیر پین، چیزهای کوچکی هستند که تعداد سفرهای لغوشده را کم می‌کنند.
شفافیت قیمت و وضعیت سفر
مسافر باید قبل از درخواست بداند چقدر می‌پردازد و بعد از درخواست بداند دقیقاً چه خبر است: در حال جست‌وجوی راننده، راننده پیدا شد، راننده رسید، سفر شروع شد. هر لحظه‌ی بی‌خبری حس بی‌اعتمادی می‌سازد. مشخصات خودرو و پلاک، تماس با راننده بدون افشای شماره و امکان اشتراک‌گذاری سفر با خانواده جزو انتظارات پایه‌ی کاربر امروز است.
اپ راننده: ابزار کار، نه یک اپ جانبی
راننده ساعت‌ها پشت فرمان با این اپ کار می‌کند؛ پس آن را باید مثل یک ابزار حرفه‌ای طراحی کرد. دکمه‌های بزرگ، اعلان صوتی برای سفر جدید، حداقل تایپ هنگام رانندگی و مصرف معقول باتری و اینترنت از ظاهر زیبا مهم‌ترند. اپ راننده باید روی گوشی‌های میان‌رده و قدیمی‌تر هم روان کار کند، چون بخش بزرگی از ناوگان با همین گوشی‌ها کار می‌کند.
- فرایند ثبت‌نام و بارگذاری مدارک که بتوان آن را مرحله‌به‌مرحله و با ذخیره‌ی پیش‌نویس انجام داد.
- ارسال موقعیت در پس‌زمینه با تعادل میان دقت و مصرف باتری.
- نمایش شفاف درآمد هر سفر، کمیسیون و زمان تسویه؛ ابهام در پول سریع‌ترین راه از دست دادن راننده است.
- مسیر روشن برای اعتراض، گزارش مسافر و تماس با پشتیبانی.
ما در دییر معمولاً پیش از طراحی اپ راننده با چند راننده‌ی واقعی مصاحبه می‌کنیم و یک روز کاری را کنارشان مشاهده می‌کنیم. این نوع تحقیقات کاربر نکته‌هایی را نشان می‌دهد که هیچ جلسه‌ی داخلی به آن نمی‌رسد؛ مثلاً اینکه راننده گوشی را روی پایه‌ی کنار شیشه می‌گذارد و زیر نور مستقیم آفتاب صفحه را به‌سختی می‌بیند.
موتور تخصیص سفر چطور راننده را انتخاب می‌کند؟
قلب هر اپلیکیشن درخواست خودرو بخشی است که کاربر هرگز آن را نمی‌بیند: موتور تخصیص یا Dispatch. این بخش باید در چند ثانیه از میان راننده‌های آنلاین، مناسب‌ترین را پیدا کند، درخواست را برایش بفرستد و اگر رد کرد یا پاسخ نداد سراغ نفر بعدی برود. ساده‌ترین نسخه «نزدیک‌ترین راننده در خط مستقیم» است، اما در شهری با بزرگراه، دوربرگردان و خیابان یک‌طرفه، نزدیک‌ترین راننده روی نقشه لزوماً زودتر نمی‌رسد.
به همین دلیل، منطق تخصیص معمولاً به‌مرور پیچیده‌تر می‌شود: زمان تخمینی رسیدن به جای فاصله، نوع خودرو، امتیاز راننده، جلوگیری از ارسال پیاپی درخواست به یک نفر و توازن میان رضایت مسافر و درآمد عادلانه‌ی راننده‌ها. نکته‌ی مهم این است که نسخه‌ی اول لازم نیست هوشمند باشد؛ لازم است قابل‌اعتماد، قابل‌اندازه‌گیری و قابل‌تغییر باشد تا بعداً با داده‌ی واقعی بهترش کنید.
در پلتفرم‌های درخواست لحظه‌ای، بیشتر از هر الگوریتم پیچیده‌ای، این مهم است که هیچ درخواستی بی‌پاسخ و هیچ سفری بی‌صاحب نماند.
از نظر فنی هم این بخش با یک وبسایت معمولی فرق دارد: ارتباط دوطرفه‌ی لحظه‌ای با اپ‌ها، به‌روزرسانی پیوسته‌ی موقعیت هزاران دستگاه، مدیریت وضعیت سفر حتی وقتی اینترنت یکی از طرفین قطع و وصل می‌شود و ثبت دقیق هر رویداد برای رسیدگی به اختلاف‌ها.
نقشه، مسیریابی و موقعیت‌یابی در ایران
اینجا جایی است که ساخت اپلیکیشن تاکسی اینترنتی در ایران با نمونه‌های خارجی فرق جدی دارد. استفاده‌ی تجاری از سرویس‌های نقشه‌ی گوگل برای تیم‌های ایرانی با محدودیت تحریم و پرداخت روبه‌رو است، پس معمولاً سراغ سرویس‌های نقشه‌ی داخلی مثل نشان یا Map.ir، یا راه‌اندازی زیرساخت مسیریابی روی داده‌های OpenStreetMap می‌روند. هر گزینه در کیفیت داده‌ی آدرس، دقت جست‌وجوی فارسی، هزینه‌ی هر درخواست و پوشش شهرهای کوچک تفاوت دارد و باید پیش از شروع توسعه مقایسه شود.
- نمایش نقشه و کاشی‌ها (Tiles) در اپ مسافر و راننده.
- جست‌وجوی آدرس فارسی و تبدیل مختصات به آدرس خوانا.
- محاسبه‌ی مسیر و زمان تخمینی رسیدن برای تخصیص و قیمت‌گذاری.
- ثبت مسیر واقعی سفر برای محاسبه‌ی نهایی کرایه و رسیدگی به شکایت.
محدودیت‌های دیگری هم هست: ارسال اعلان (Push) از طریق سرویس‌های خارجی همیشه پایدار نیست و اغلب به یک راه جایگزین یا سرویس داخلی نیاز است؛ انتشار اپ iOS برای تیم‌های ایرانی از اپ‌استور مستقیم ممکن نیست و باید سراغ فروشگاه‌های جایگزین یا نسخه‌ی وب‌اپ (PWA) رفت؛ و ورود با رمز یک‌بارمصرف پیامکی تقریباً استاندارد است. این تصمیم‌ها روی معماری و هزینه اثر مستقیم دارند.
قیمت‌گذاری، پرداخت و کیف پول
قیمت سفر معمولاً از چند جزء ساخته می‌شود: ورودی پایه، مسافت، زمان، و ضریب‌هایی برای ساعت شلوغ یا مناطق پرتقاضا. قیمت‌گذاری پویا ابزار مهمی برای جذب راننده به جایی است که تقاضا زیاد است، اما اگر بی‌توضیح و ناگهانی باشد اعتماد مسافر را از بین می‌برد. در طراحی، نمایش دلیل افزایش قیمت و ثابت ماندن قیمت پس از تأیید مسافر به اندازه‌ی خود فرمول اهمیت دارد.
در بخش پرداخت هم باید از ابتدا تصمیم بگیرید: پرداخت نقدی به راننده، پرداخت آنلاین از درگاه بانکی، کیف پول داخل اپ یا ترکیبی از این‌ها. کیف پول تجربه را سریع‌تر می‌کند، اما یعنی نگهداری حساب مالی کاربر، تسویه‌ی دوره‌ای با راننده‌ها، بازپرداخت در لغو سفر و الزامات حقوقی و بانکی که باید پیش از ساخت بررسی شود. محاسبه‌ی کمیسیون پلتفرم، کدهای تخفیف و گزارش مالی شفاف برای حسابداری هم بخشی از همین سیستم است.
ایمنی، اعتماد و پنل مدیریت
در سرویسی که دو غریبه را در یک خودرو کنار هم قرار می‌دهد، ایمنی یک ویژگی جانبی نیست. احراز هویت راننده و بررسی مدارک خودرو، دکمه‌ی اضطراری، اشتراک‌گذاری زنده‌ی سفر، پنهان ماندن شماره‌ی تماس دو طرف و امتیازدهی دوطرفه حداقل‌هایی هستند که باید در نسخه‌ی اول هم وجود داشته باشند. کنار این‌ها، امنیت داده‌ها اهمیت دارد؛ چون سیستم مسیر رفت‌وآمد روزانه‌ی آدم‌ها را ثبت می‌کند.
پنل مدیریت جایی است که تیم عملیات تمام روز در آن کار می‌کند: تأیید یا تعلیق راننده، دیدن سفرهای جاری روی نقشه، رسیدگی به شکایت، تنظیم نرخ‌ها و محدوده‌های خدمت، و تشخیص الگوهای مشکوک مثل سفرهای ساختگی برای سوءاستفاده از تخفیف. جزئیات طراحی چنین ابزارهای داخلی را در راهنمای طراحی پنل مدیریت نوشته‌ایم.
برای ساخت اپلیکیشنی مثل اسنپ، چرا نباید اسنپ را کپی کرد؟
سرویس‌های بزرگ تاکسی اینترنتی سال‌ها زمان، تیم‌های بزرگ و بودجه‌ی سنگین بازاریابی صرف کرده‌اند تا به نقطه‌ی فعلی برسند و حالا اثر شبکه‌ای قوی دارند: راننده‌ی بیشتر یعنی انتظار کمتر، و انتظار کمتر یعنی مسافر بیشتر. ورود مستقیم به همان بازار با همان محصول، یعنی جنگیدن در زمینی که رقیب در آن برتری ساختاری دارد. در عوض، فرصت واقعی معمولاً در جایی است که بازیگران بزرگ یا حضور ندارند یا نیاز خاصی را پوشش نمی‌دهند.
- یک شهر کوچک یا متوسط که پوشش سرویس‌های بزرگ در آن ضعیف است.
- یک نیاز خاص: سرویس مدرسه، حمل‌ونقل سازمانی کارکنان، جابه‌جایی بیماران و سالمندان، یا سفرهای بین‌شهری.
- یک نوع خودرو یا خدمت متفاوت: وانت و باربری، موتور پیک، یا خودروهای ویژه‌ی افراد کم‌توان.
- یک مدل کسب‌وکار متفاوت: ناوگان اختصاصی یک شرکت یا تعاونی تاکسیرانی که می‌خواهد دیجیتال شود.
نسخه‌ی اول (MVP) واقع‌بینانه چه شکلی دارد؟
یک کمینه محصول پذیرفتنی برای این حوزه یعنی همه‌ی چرخه‌ی سفر کار کند، اما فقط برای یک محدوده و یک سناریو: اپ مسافر با درخواست، پیگیری و پرداخت پایه؛ اپ راننده با پذیرش سفر و نمایش درآمد؛ تخصیص بر پایه‌ی نزدیکی؛ و یک پنل عملیات که بتوان سفرها و راننده‌ها را کنترل کرد. ویژگی‌هایی مثل سفر اشتراکی، رزرو برای آینده، چند مقصد، باشگاه مشتریان و قیمت‌گذاری پویای پیشرفته می‌توانند منتظر داده‌ی واقعی بمانند.
پیش از ساخت هم ارزش دارد یک دوره‌ی کوتاه کشف محصول انجام دهید: چند راننده حاضرند از روز اول بیایند؟ چرا مسافر از راه فعلی‌اش ناراضی است؟ آیا ساعت‌های اوج تقاضا با ساعت‌های در دسترس بودن راننده‌ها هم‌خوان است؟ پاسخ این سؤال‌ها مهم‌تر از هر انتخاب فنی است، چون مشکل اصلی پلتفرم‌های دوطرفه معمولاً شروع سرد است، نه کد.
هزینه ساخت اپلیکیشن اسنپ به چه عواملی بستگی دارد؟
عدد ثابتی برای هزینه ساخت اپلیکیشن اسنپ یا هر سرویس مشابه وجود ندارد و هر کسی بدون شناخت دامنه‌ی کار قیمت قطعی بدهد، احتمالاً یا بخشی از سیستم را نادیده گرفته یا قرار است بعداً هزینه‌های پنهان اضافه شود. منطق کلی برآورد هزینه‌ی اپ را در مقاله‌ی هزینه ساخت اپلیکیشن شرح داده‌ایم؛ جدول زیر عواملی را نشان می‌دهد که در یک پلتفرم درخواست خودرو بیشترین اثر را دارند.
| عامل | نسخه‌ی ساده‌تر | نسخه‌ی پیچیده‌تر |
|---|---|---|
| تعداد اپ‌ها و پلتفرم‌ها | اپ اندروید راننده و وب‌اپ مسافر | اپ‌های بومی اندروید و iOS برای هر دو طرف |
| منطق تخصیص | نزدیک‌ترین راننده‌ی آزاد | زمان تخمینی رسیدن، امتیاز، صف‌بندی و توازن ناوگان |
| قیمت‌گذاری | نرخ ثابت بر اساس مسافت و زمان | ضریب پویا بر اساس منطقه، ساعت و عرضه و تقاضا |
| پرداخت | نقدی و درگاه آنلاین | کیف پول، تسویه‌ی خودکار، کد تخفیف و حسابداری |
| نقشه و مسیریابی | استفاده از سرویس آماده با هزینه‌ی هر درخواست | زیرساخت مسیریابی اختصاصی و بهینه‌سازی داده |
| ایمنی و نظارت | احراز هویت و امتیازدهی | پایش زنده، تشخیص تقلب و ابزار اضطراری کامل |
| مقیاس و پایداری | یک شهر و ترافیک محدود | چند شهر، ترافیک بالا و دسترس‌پذیری مداوم |
فراموش نکنید که هزینه‌ی این نوع محصول بعد از انتشار تمام نمی‌شود. سرور و سرویس نقشه و پیامک هزینه‌ی ماهانه‌ی وابسته به حجم دارند، اپ‌ها باید با نسخه‌های جدید سیستم‌عامل سازگار بمانند و تیم پشتیبانی و عملیات بخش ثابت هزینه‌ی کسب‌وکار است. اگر طراحی را هم جداگانه برآورد می‌کنید، مقاله‌ی جداگانه‌ی ما درباره‌ی هزینه طراحی UI/UX به شما کمک می‌کند.
از کجا شروع کنیم؟ رویکرد دییر
تجربه‌ی ما در کار روی محصولاتی با میلیون‌ها کاربر ایرانی، مثل آنچه در نمونه‌کارهای دییر می‌بینید، برای هر کسی که به ساخت اپلیکیشنی مثل اسنپ فکر می‌کند یک درس روشن دارد: محصولات پرکاربرد با «همه‌ی ویژگی‌ها» شروع نمی‌شوند، با حل دقیق یک مسئله برای یک گروه مشخص شروع می‌شوند. در پروژه‌های پلتفرمی، ما معمولاً از نقشه‌ی سفر هر سه نقش (مسافر، راننده، اپراتور) شروع می‌کنیم، نسخه‌ی اول را با پروتوتایپ و تست کاربردپذیری روی کاربران واقعی می‌سنجیم و بعد سراغ توسعه می‌رویم.
اگر هنوز در مرحله‌ی ایده هستید، خدمات طراحی محصول و UI/UX کمک می‌کند دامنه و اولویت‌ها روشن شوند؛ اگر طرح آماده دارید، تیم توسعه وبسایت و اپلیکیشن دییر می‌تواند ساخت اپ‌ها، بک‌اند و پنل را انجام دهد.
سؤالات متداول
آیا می‌شود اسکریپت آماده‌ی تاکسی اینترنتی خرید و راه‌اندازی کرد؟
اسکریپت‌های آماده برای آزمودن سریع ایده مناسب‌اند، اما معمولاً با نقشه، پرداخت و پیامک داخلی سازگار نیستند و تغییر منطق تخصیص یا قیمت در آن‌ها دشوار است. اگر قصد رشد جدی دارید، دیر یا زود به بازنویسی بخش‌های اصلی می‌رسید.
ساخت اپلیکیشن تاکسی اینترنتی چقدر زمان می‌برد؟
به دامنه‌ی نسخه‌ی اول بستگی دارد. یک MVP محدود به یک شهر و یک خدمت خیلی سریع‌تر از نسخه‌ی چندشهری با کیف پول و قیمت‌گذاری پویا آماده می‌شود. زمان‌بندی دقیق فقط پس از تعریف ویژگی‌ها و اولویت‌ها قابل ارائه است.
اپ مسافر و راننده را باید جدا ساخت یا یک اپ با دو حالت کافی است؟
در بیشتر موارد دو اپ جدا بهتر است، چون کاربر، سناریو، دسترسی‌ها و چرخه‌ی به‌روزرسانی متفاوتی دارند. یک اپ دوحالته در ابتدا ساده‌تر به نظر می‌رسد، اما تجربه‌ی هر دو گروه را شلوغ و نگهداری را سخت‌تر می‌کند.
برای نقشه در ایران از چه سرویسی استفاده کنیم؟
گزینه‌های رایج سرویس‌های نقشه‌ی داخلی مثل نشان و Map.ir یا زیرساخت مبتنی بر OpenStreetMap است. انتخاب را بر اساس دقت جست‌وجوی آدرس فارسی در شهر هدف، هزینه‌ی هر درخواست و نیاز به مسیریابی انجام دهید و پیش از تصمیم نهایی آن‌ها را آزمایش کنید.
مهم‌ترین ریسک یک اپلیکیشن درخواست خودرو چیست؟
بیشتر از ریسک فنی، ریسک شروع سرد است: نبودن راننده‌ی کافی در روزهای اول باعث انتظار طولانی و رفتن مسافر می‌شود. برنامه‌ی جذب راننده پیش از راه‌اندازی، به اندازه‌ی خود محصول اهمیت دارد.
اگر ایده‌ی یک سرویس درخواست لحظه‌ای را در ذهن دارید و می‌خواهید بدانید نسخه‌ی اول آن واقعاً به چه چیزی نیاز دارد، خوشحال می‌شویم درباره‌اش صحبت کنیم. برای شروع گفت‌وگو، فرم درخواست همکاری را پر کنید.
