هزینهٔ ساخت اپلیکیشن در ایران عدد ثابتی ندارد و از دامنهٔ پروژه می‌آید: تعداد قابلیت‌ها، تعداد پلتفرم‌ها، بکاند، پنل مدیریت و نگهداری بعد از انتشار. برآورد اولیه فقط یک بازهٔ فرض‌محور است؛ تنها پیشنهاد مالیِ مبتنی بر بریف مکتوب قیمتی است که شرکت می‌تواند به آن متعهد شود.
این راهنما برای صاحب کسبوکاری است که می‌خواهد بودجهٔ اولیه را بر پایهٔ دامنهٔ پروژه تخمین بزند، هزینه‌های پنهان را بشناسد و با یک بریف درست، استعلام‌هایی بگیرد که بشود کنار هم گذاشتشان. در پایان می‌دانید برآورد اولیه کجا تمام میشود و پیشنهاد نهایی کجا شروع.
چرا برای ساخت اپلیکیشن یک قیمت واحد وجود ندارد؟
همین سؤال برای یک کسبوکار کوچک و یک سازمان بزرگ یک جواب ندارد
صاحب یک آرایشگاه یا آموزشگاه که فقط می‌خواهد مشتری‌ها نوبت بگیرند، با سازمانی که اپ را به سیستم حسابداری، CRM و احراز هویت داخلی وصل میکند، دربارهٔ یک محصول حرف نمی‌زنند. هر دو می‌گویند «اپ می‌خواهم»، ولی اولی چند صفحه و یک پنل ساده لازم دارد و دومی الزام امنیتی، یکپارچگی و مستندات.
به همین دلیل مقاله‌ای که یک تعرفهٔ واحد برای طراحی اپ بدهد، یا حدس می‌زند یا گمراه میکند. ما اینجا تعرفهٔ واحد و زمان تحویل قطعی نمی‌دهیم؛ آنچه می‌دهیم روشی است که با آن بودجهٔ خودتان را می‌سازید.
برآورد اولیه چیست و پیشنهاد مالی نهایی چه فرقی دارد
این دو را معمولاً یکی می‌گیرند و همین‌جا دعوا شروع میشود. تفاوتشان در ورودی، دقت و تعهد است.
| ویژگی | برآورد اولیه | پیشنهاد مالی نهایی |
|---|---|---|
| ورودی | توضیح شفاهی یا چند خطی از ایده | بریف مکتوب با فهرست قابلیت‌ها |
| شکل عدد | بازه، بر پایهٔ فرض‌ها | مبلغ مشخص با شرح کار |
| تعهد | ندارد | دارد، با شرایط پرداخت و تحویل |
| کاربرد | تصمیم برای ادامه‌دادن یا نه | انتخاب شرکت و بستن قرارداد |
قاعدهٔ عملی ساده است: تا وقتی بریف مکتوب ندارید، هر عددی که می‌شنوید برآورد است. وقتی قابلیت‌ها، پلتفرم و سرویس‌های بیرونی را نوشتید، وقتش است که از برآورد به پیشنهاد نهایی برسید.
یک نکتهٔ شفافیت: بازهٔ تومانی فقط وقتی معتبر است که منبعش، تاریخ جمع‌آوری و دامنهٔ خدماتش مشخص باشد. چنین داده‌ای فعلاً در اختیار ما نیست، پس در این مقاله عددی نمی‌آید. هر بازه‌ای که بعداً کنارش می‌گذارید باید واحد (تومان یا ریال)، تاریخ و دامنهٔ خدمات داشته باشد، وگرنه قابل‌اتکا نیست.
هزینهٔ یک اپ از چه بخشهایی ساخته میشود؟
اشتباه رایج این است که «قیمت اپ» را برابر قیمت کدنویسی بگیریم. در عمل شش بخش جدا وجود دارد: طراحی، توسعه، انتشار، زیرساخت، نگهداری و توسعهٔ بعدی. اگر استعلامی فقط دو بخش اول را پوشش دهد، بقیه بعداً از جیب شما درمی‌آید.
طراحی و توسعه: چه چیزی کجا حساب میشود
طراحی یعنی تحقیق کاربر، جریان صفحه‌ها و رابط کاربری؛ کار تیم خدمات طراحی UI/UX که گاهی جدا از توسعه قیمت می‌خورد. توسعه شامل کدِ اپ روی گوشی، بکاند و API، و پنل مدیریت است. بکاند همان بخشی است که دادهٔ کاربران، سفارش‌ها و پرداخت‌ها را نگه می‌دارد و بیشتر وقت‌ها از نظر کاربر دیده نمی‌شود، اما از نظر هزینه سنگین است. تست و تضمین کیفیت (QA) هم باید در شرح کار باشد، نه یک «لطف» پایان پروژه.
انتشار، زیرساخت و نگهداری: بخشهایی که در تصویر کلی جا نمی‌افتند
انتشار در کافه‌بازار، مایکت و اپاستور هرکدام فرایند و الزام خودشان را دارند و اگر کسی آن را انجام ندهد، اپ به دست کاربر نمی‌رسد. زیرساخت یعنی سرور و هاستینگ (برای مقایسهٔ گزینه‌ها به خدمات سرور و هاستینگ نگاه کنید)، و سرویس پیامک و اعلان (Push Notification) که معمولاً هزینهٔ دوره‌ای دارند.
نگهداری هم تمام‌شدنی نیست. با هر تغییر سیستم‌عامل گوشی، اپ باید بهروزرسانی شود؛ سرور هر ماه یا سال تمدید میشود؛ و باگ‌هایی که بعد از انتشار پیدا می‌شوند باید کسی رفعشان کند. هیچ‌کدام از بکاند، زیرساخت، پشتیبانی و تغییرات آینده را از تصویر کل بودجه حذف نکنید.
رفع اشکال یا قابلیت جدید؟ تفاوتی که دعوای بعدی را پیش‌گیری میکند
رفع اشکال یعنی اصلاح چیزی که طبق شرح کار باید کار می‌کرد و نمی‌کند. افزودن قابلیت یعنی چیزی که در شرح کار نبود. اگر در قرارداد نوشته نشده باشد، هر درخواستی بین این دو مرز دعوا میشود. در عمل دیده‌ایم بیشتر اختلاف‌های بعد از تحویل از همین‌جا شروع میشود: مشتری «باگ» می‌گوید و شرکت «قابلیت جدید». قرارداد پشتیبانی یا SLA باید دورهٔ گارانتی و تعریف رفع اشکال را روشن کند.
کدام تصمیم‌های فنی بیشترین اثر را بر هزینه دارند؟
قابلیت‌ها، پنل مدیریت و اتصال به سرویس‌ها
هر قابلیت را با سه سؤال بسنجید: چند صفحه دارد، چه منطقی در بکاند لازم دارد، و به چه سرویس بیرونی وصل است. یک دکمهٔ «پرداخت» ساده به‌نظر می‌رسد، ولی پشتش درگاه پرداخت، ثبت تراکنش، بازگشت وجه و مدیریت خطا هست. پیامک تأیید، نقشه و اعلان هم هرکدام ادغام و گاهی هزینهٔ جداگانه دارند.
پنل مدیریت را هم نادیده نگیرید. بدون آن، هر تغییر محتوا یا هر سفارش باید به برنامه‌نویس برگردد.
نیتیو یا کراس‌پلتفرم: چه چیزی را جابه‌جا میکند و چه چیزی را نه
نیتیو یعنی کدِ جدا برای اندروید و iOS؛ کراس‌پلتفرم یعنی یک کدبیس برای هر دو، با ابزارهایی مثل Flutter یا React Native. این انتخاب چند چیز را تغییر می‌دهد: تعداد کدبیسی که باید نگه دارید، تخصصی که تیم لازم دارد، دسترسی به قابلیتهای سخت‌افزاری مثل دوربین و حسگرها، و شیوهٔ نگهداری.
اما ما نمی‌گوییم یکی همیشه ارزان‌تر است. اگر اپ به قابلیتهای سخت‌افزاری سنگین نیاز داشته باشد، صرفهٔ کراس‌پلتفرم کم میشود؛ اگر منطق ساده و مشترک باشد، می‌تواند بیشتر شود. برای مقایسهٔ شرکت‌ها، صفحهٔ برنامه‌نویسی Flutter و برنامه‌نویسی React Native را ببینید.
دربارهٔ پلتفرم، «قیمت طراحی اپلیکیشن اندروید» با iOS لزوماً یک رابطهٔ ثابت ندارد. اگر مخاطب شما بیشتر در بازار ایران است، اندروید و مارکتهای ایرانی معمولاً اولویت دارند؛ فهرست شرکت‌ها در طراحی و توسعه اپ اندروید و برای نسخهٔ اپل در اپ آیفون است. هر پلتفرم اضافه یعنی تست و انتشار بیشتر، حتی اگر کد مشترک باشد.
پیچیدگی طراحی، امنیت و تست
رابط کاربریِ سفارشی با انیمیشن و جریان‌های متعدد زمان طراحی و توسعه را بالا می‌برد. الزام امنیتی (احراز هویت، رمزنگاری داده، دسترسی نقش‌محور) هم همین‌طور؛ برای پروژه‌هایی با دادهٔ حساس، به خدمات امنیت سایبری فکر کنید. تست هم هرچه دستگاه و نسخهٔ سیستم‌عامل بیشتری پوشش دهد، سنگین‌تر میشود. این‌ها را باید در بریف صریح بنویسید، نه اینکه ضمنی بماند.
سه سناریو برای تخمین اولیهٔ بودجه: MVP ساده، اپ خدماتی، محصول پیچیده
جدول سناریوها: فرض‌ها، موارد شامل، موارد خارج از برآورد
MVP یعنی کوچک‌ترین نسخه‌ای که مسئلهٔ اصلی کاربر را حل میکند و میشود با آن بازار را آزمود. جدول زیر سه سناریو را با فرض‌هایشان کنار هم می‌گذارد. ستون قیمت عمداً عدد ندارد، چون داده‌ای با منبع و تاریخ معتبر در دست نیست.
| ردیف | MVP ساده | اپ خدماتی | محصول پیچیده |
|---|---|---|---|
| دامنهٔ قابلیت‌ها | چند قابلیت اصلی، ثبت‌نام و یک جریان کلیدی | ثبت‌نام، سفارش یا رزرو، پرداخت، اعلان | نقش‌های متعدد، یکپارچگی با سیستم‌های دیگر، گزارش‌گیری |
| پلتفرم | معمولاً یک پلتفرم | یک یا دو پلتفرم | چند پلتفرم، گاهی وب هم |
| بکاند و پنل | بکاند ساده، پنل حداقلی | بکاند کامل، پنل مدیریت سفارش و کاربر | بکاند مقیاس‌پذیر، پنل چندنقشی |
| شامل برآورد | طراحی پایه، توسعه، انتشار اولیه | طراحی، توسعه، درگاه، پنل، انتشار | طراحی، توسعه، یکپارچگی، تست گسترده |
| خارج از برآورد | نگهداری، سرور، تغییرات بعدی | هزینهٔ دوره‌ای سرور و پیامک، قابلیتهای جدید | مجوزها، زیرساخت اختصاصی، پشتیبانی بلندمدت |
| ریسک رایج | افزودن قابلیت در میانهٔ کار | ناهمسانی در تعهد بکاند و پنل | دامنهٔ مبهم و تغییر پیاپی نیازها |
| قیمت | نیازمند داده معتبر | نیازمند داده معتبر | نیازمند داده معتبر |
وقتی دو استعلام برای یک پروژه فاصلهٔ زیاد دارند، معمولاً چه اتفاقی افتاده است
صاحب یک کسبوکار خدماتی، مثلاً یک مجموعهٔ نظافت و تعمیرات، برای اپ رزرو دو استعلام می‌گیرد. یکی خیلی ارزان‌تر است و او تصمیم می‌گیرد همان را بپذیرد. چند هفته بعد معلوم میشود پیشنهاد ارزان‌تر فقط ظاهر اپ را شامل می‌شد. بکاند، پنل مدیریت و پشتیبانی در آن نبود.
فاصلهٔ دو قیمت از ارزانیِ یکی نیامده بود؛ از تفاوت تعهد آمده بود. نشانه‌های عینی این ناهمسانی را میشود قبل از امضا دید:
- در یکی از پیشنهادها اسمی از بکاند، API یا پنل مدیریت نیست.
- سرور و هاستینگ مشخص نشده که شامل است یا جدا.
- دورهٔ گارانتی و تعریف رفع اشکال نوشته نشده.
- تعداد صفحه‌ها یا قابلیت‌ها یک‌طرف کلی است («اپ فروشگاهی») و طرف دیگر فهرست‌شده.
- مالیات، ارزش افزوده و فاکتور رسمی ذکر نشده.
- مالکیت سورس‌کد روشن نیست.
اینجا مقاله از توضیح به عمل می‌رسد. سناریوی خودتان را روی جدول بگذارید: اگر کاربر باید ثبت‌نام کند و سفارش بدهد و پرداخت کند، در ستون «اپ خدماتی» هستید. حالا ردیف «خارج از برآورد» همان ستون را بخوانید و ببینید کدام موارد هنوز در بریف شما جواب ندارد. هر مورد بی‌جواب یک هزینهٔ پنهان بالقوه است.
چطور پیشنهادهای مالی را قابل‌مقایسه کنیم و چه چیزهایی بپرسیم؟
قیمت دو پیشنهاد فقط وقتی قابل‌مقایسه است که امکانات و تعهدات یکسان باشد. اگر یکی بکاند دارد و دیگری ندارد، مقایسهٔ مبلغ‌ها بی‌معناست؛ اول باید هم‌ترازشان کنید، یعنی از شرکت ارزان‌تر بخواهید همان دامنه را قیمت بزند. ارزان‌ترین پیشنهاد به‌خودیِ‌خود بهترین گزینه نیست.
پرسش‌های مالیات، خدمات جانبی و شرایط پرداخت
- آیا مبلغ شامل ارزش افزوده است و فاکتور رسمی صادر میشود؟
- بکاند و سرور شامل است یا جدا حساب میشود؟
- مالکیت سورس‌کد و دسترسی به مخزن بعد از تحویل با کیست؟
- دورهٔ گارانتی چند ماه است و چه چیزی رفع اشکال محسوب میشود؟
- تغییرات بعد از قرارداد چطور قیمتگذاری میشود؟
شرایط پرداخت هم مهم است. پرداخت مرحله‌ای (Milestone) با تحویل‌های قابل‌سنجش، مثلاً طراحی تأییدشده، نسخهٔ آزمایشی و انتشار، ریسک شما را کم میکند، چون هر پرداخت به چیزی دیدنی گره خورده است.
نشانه‌هایی که می‌گوید دو پیشنهاد قابل‌مقایسه نیستند
اگر تعداد قابلیت‌ها فرق دارد، پلتفرم‌ها یکی نیست، یا یکی از پیشنهادها اصلاً گزینهٔ نگهداری ندارد، مقایسه را متوقف کنید. اعتبار شرکت را هم بسنجید؛ در وانوریکس این کار با روش رتبه‌بندی، شرکت‌های تأییدشده و نظرهای راستی‌آزمایی‌شده انجام میشود، و برای دیدن فهرست می‌توانید به شرکت‌های طراحی و توسعه اپ موبایل سر بزنید.
چطور بدون حذف نیازهای اساسی هزینه را کنترل کنیم و بریف استعلام را بنویسیم؟
اولویت‌بندی قابلیت‌ها و ساخت MVP
قابلیت‌ها را به دو دسته تقسیم کنید: «بدون این اپ کار نمی‌کند» و «خوب است داشته باشیم». دستهٔ اول MVP شماست. دستهٔ دوم را برای نسخه‌های بعد بگذارید و در بریف جدا بنویسید. ما وعدهٔ صرفه‌جویی درصدی نمی‌دهیم، چون بدون دامنهٔ مشخص چنین عددی ساختگی است؛ اما محدودکردن دامنه تنها اهرمی است که بدون حذف نیاز اساسی روی بودجه اثر می‌گذارد. اگر هنوز با مفاهیم برنامه‌نویسی غریبه‌اید، راهنمای برنامه‌نویسی برای مدیران کسبوکار کمک میکند.
قالب بریف برای دریافت پیشنهاد قابل‌مقایسه
اگر این فیلدها در بریف نباشد، پیشنهادها قابل‌مقایسه نمی‌شوند:
- هدف کسبوکاری: اپ چه مسئله‌ای را حل میکند.
- کاربران: چه کسانی و در چه نقش‌هایی از آن استفاده میکنند.
- قابلیت‌ها: فهرست مشخص، با اولویت (ضروری یا بعداً).
- پلتفرم: اندروید، iOS یا هر دو، و رویکرد نیتیو یا کراس‌پلتفرم اگر ترجیحی دارید.
- بکاند و پنل مدیریت: چه کسی چه چیزی را مدیریت میکند.
- سرویس‌های بیرونی: درگاه پرداخت، پیامک، نقشه، اعلان.
- تست: چه دستگاه‌ها و چه سطحی از تست.
- انتشار: کدام مارکتها و چه کسی مسئول است.
- نگهداری: دورهٔ گارانتی، SLA و هزینهٔ تغییرات.
- شرایط پرداخت: مراحل، تحویل‌ها و مالیات.
فردا صبح چه کنید
امروز یک بریف یک‌صفحه‌ای با همین ده فیلد بنویسید و فقط برای شرکت‌هایی بفرستید که با همین ساختار پاسخ می‌دهند؛ اگر پاسخ‌شان بند به بند همان فیلدها را پوشش نداد، پیشنهادشان را کنار بگذارید. اگر در سایت امکان استعلام بر پایهٔ بریف فعال است، همان‌جا بریف را ثبت کنید؛ در غیر این صورت از صفحهٔ تماس درخواست بدهید. و هر عدد تومانی‌ای که شنیدید را تا وقتی تاریخ، دامنهٔ خدمات و منبعش را ندارد، فقط یک برآورد بدانید.
پرسش‌های متداول
به جای اپلیکیشن، وباپ یا PWA بسازم هزینه و کارکردش فرق میکند؟
پرداخت درون‌برنامه‌ای در اپ ایرانی از چه مسیری انجام میشود؟
انتشار در گوگلپلی و اپاستور برای کسبوکار ایرانی عملی است؟
بعد از انتشار از کجا بفهمم اپ ارزش سرمایهگذاری را داشته است؟
اگر اپ را MVP بسازم، نسخهٔ بعدی روی همان کد ساخته میشود یا باید از نو شروع کرد؟
به این مقاله امتیاز دهید
اولین نفری باشید که امتیاز می‌دهد
درباره نویسنده
