هزینه ساخت نرم‌افزار سفارشی چقدر است؟ راهنمای واقعی برآورد قیمت

اگر فقط یک عدد می‌خواهید، پاسخ کوتاه این است:

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

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

پاسخ سریع: بازه تقریبی هزینه انواع نرم‌افزار در ۱۴۰۵

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

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

چرا نمی‌شود از روی یک جمله قیمت دقیق داد؟

در شروع بسیاری از درخواست‌ها فقط شکل بیرونی محصول مشخص است:

• «یک برنامه شبیه اسنپ می‌خواهیم.»
• «یک CRM اختصاصی لازم داریم.»
• «یک پلتفرم هوش مصنوعی می‌خواهیم.»
• «یک اپ برای سفارش و پخش مواد غذایی می‌خواهیم.»

اما برای برآورد باید جزئیات عملیاتی روشن شوند:

• چند نوع کاربر و سطح دسترسی وجود دارد؟
• جریان اصلی هر کاربر چیست؟
• اپ موبایل لازم است یا وب‌اپ کافی است؟
• پرداخت، کیف پول، اشتراک یا تسویه چندطرفه وجود دارد؟
• محصول باید به حسابداری، انبار، پیامک، نقشه یا سرویس دیگری متصل شود؟
• داده از کجا می‌آید و چه کیفیتی دارد؟
• گزارش‌ها ثابت‌اند یا گزارش‌ساز پویا لازم است؟
• چند کاربر هم‌زمان و چه حجم تراکنشی پیش‌بینی شده؟
• چه سطحی از امنیت، ثبت رویداد، پشتیبان‌گیری و دسترس‌پذیری لازم است؟
• چه کسی محتوا، داده اولیه و دسترسی APIها را تأمین می‌کند؟

تا این سؤال‌ها پاسخ داده نشوند، عدد دقیق بیشتر شبیه حدس فروش است تا برآورد مهندسی.

فرمول ساده برآورد هزینه نرم‌افزار

روش پایه این است:

هزینه ساخت = تلاش تیم × نرخ تیم + هزینه سرویس‌های بیرونی + ذخیره ریسک

تلاش تیم معمولاً با ساعت، نفرـماه یا تیمـماه سنجیده می‌شود. برای پروژه‌های واقعی، تیم فقط برنامه‌نویس نیست و می‌تواند این نقش‌ها را شامل شود:

• تحلیل کسب‌وکار و محصول؛
• طراحی UX و UI؛
• توسعه Front-end؛
• توسعه Back-end؛
• توسعه موبایل، در صورت نیاز؛
• تست و تضمین کیفیت؛
• DevOps و استقرار؛
• مدیریت پروژه و بازبینی فنی.

در پروژه کوچک ممکن است یک نفر چند نقش را پوشش دهد. در پروژه حساس یا بزرگ، نقش‌ها تخصصی‌تر می‌شوند. بنابراین مقایسه صرف «نرخ یک برنامه‌نویس» با «قیمت یک تیم مسئول تحویل» مقایسه دقیقی نیست.

یک نمونه محاسبه

فرض کنید یک MVP به ۳.۵ تیمـماه کار نیاز دارد و هزینه واقعی تیم تحویل‌دهنده، با طراحی، توسعه، تست و مدیریت، ماهانه ۲۵۰ میلیون تومان باشد:

• تلاش تیم: ۸۷۵ میلیون تومان؛
• سرویس‌ها، زیرساخت اولیه و هزینه‌های مستقیم: ۵۰ میلیون تومان؛
• ذخیره ریسک ۱۵ درصدی: حدود ۱۳۹ میلیون تومان؛
• بودجه اولیه: حدود ۱.۰۶ میلیارد تومان.

این مثال فقط روش محاسبه را نشان می‌دهد. نرخ و تلاش واقعی با ترکیب تیم و پیچیدگی پروژه تغییر می‌کند.

۱۰ عامل اصلی که قیمت را تغییر می‌دهند

۱. محدوده قابلیت‌ها

بیشترین اثر معمولاً از تعداد صفحه‌ها نمی‌آید؛ از تعداد جریان‌های کاری و قواعد پشت آن‌ها می‌آید.

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

۲. تعداد نقش‌ها و سطوح دسترسی

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

۳. پلتفرم‌ها

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

۴. طراحی تجربه کاربری

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

۵. یکپارچگی با سرویس‌های دیگر

درگاه پرداخت استاندارد معمولاً قابل‌پیش‌بینی‌تر از اتصال به ERP قدیمی، بانک، سرویس دولتی یا API ناقص است. نبود مستندات، محیط آزمایشی و پشتیبانی سرویس بیرونی می‌تواند برآورد را تغییر دهد.

۶. پیچیدگی داده و گزارش

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

۷. بلادرنگ، نقشه و بهینه‌سازی

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

۸. هوش مصنوعی

اضافه‌کردن API یک مدل زبانی ممکن است ساده باشد، اما ساخت قابلیت قابل‌اتکا هزینه دیگری دارد: آماده‌سازی داده، ارزیابی خروجی، کنترل خطا، مدیریت هزینه مصرف، امنیت داده و طراحی Human-in-the-loop.

۹. مقیاس، امنیت و الزامات سازمانی

محصولی برای ۵۰ کاربر داخلی با سامانه‌ای برای صدها هزار کاربر یا تراکنش مالی یکسان طراحی نمی‌شود. SSO، Audit Log، سطوح دسترسی دقیق، رمزنگاری، تست نفوذ، High Availability و الزامات قراردادی هزینه را افزایش می‌دهند.

۱۰. کیفیت کد و فرایند تحویل

تست خودکار، Code Review، مستندات، CI/CD، لاگ، مانیتورینگ و برنامه بازیابی در قیمت اولیه دیده نمی‌شوند، اما نبودشان بعداً خودش را به شکل باگ، توقف سرویس و بازنویسی نشان می‌دهد.

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

چهار نمونه برآورد برای درک بهتر

سناریو اول: ابزار داخلی محدود

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

• دو نقش کاربری؛
• فرم ثبت درخواست؛
• وضعیت و اعلان؛
• پنل گزارش ساده؛
• بدون اپ موبایل و اتصال پیچیده.

اگر فرایندها روشن باشند، چنین محصولی ممکن است در محدوده ۲۵۰ تا ۵۵۰ میلیون تومان قرار بگیرد.

سناریو دوم: MVP یک SaaS

یک محصول اشتراکی اولیه با این محدوده:

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

بسته به کیفیت طراحی و منطق محصول، بودجه می‌تواند حدود ۵۰۰ میلیون تا ۱.۲ میلیارد تومان باشد.

سناریو سوم: سیستم سفارش و پخش

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

نسخه اولیه کنترل‌شده چنین سامانه‌ای می‌تواند از حدود ۱.۵ تا ۳.۵ میلیارد تومان شروع شود. اپ‌های Native جدا، بهینه‌سازی پیشرفته مسیر، اتصال ERP و حجم عملیات بالا می‌توانند بودجه را بیشتر کنند.

سناریو چهارم: پلتفرم داده یا هوش مصنوعی

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

برای نسخه اولیه قابل‌اتکا، بازه ۱.۲ تا ۴ میلیارد تومان یا بیشتر دور از انتظار نیست. عامل تعیین‌کننده، عبارت «هوش مصنوعی» نیست؛ کیفیت داده، سطح اتوماسیون، حساسیت تصمیم و معیار دقت است.

چه چیزهایی معمولاً داخل قیمت اولیه نیست؟

پیش از مقایسه پیشنهادها، مشخص کنید هر عدد دقیقاً چه اقلامی را پوشش می‌دهد:

دو پیشنهاد ۷۰۰ میلیون تومانی و یک میلیارد تومانی را فقط وقتی می‌توان مقایسه کرد که محدوده، کیفیت و مسئولیت‌هایشان یکسان باشد.

هزینه پس از انتشار: قیمت ساخت، کل بودجه نیست

هزینه واقعی محصول را با هزینه کل مالکیت یا TCO بسنجید:

TCO = ساخت اولیه + زیرساخت + سرویس‌های مصرفی + نگهداری + پشتیبانی + امنیت + توسعه‌های بعدی + هزینه توقف و خطا

برای برنامه‌ریزی اولیه، معمولاً منطقی است علاوه بر بودجه ساخت:

• ۱۰ تا ۲۰ درصد برای عدم‌قطعیت و تغییرات محدود کنار بگذارید؛
• برای ۳ تا ۶ ماه پس از انتشار بودجه مستقل نگهداری، زیرساخت و بهبود داشته باشید؛
• رشد ترافیک و مصرف سرویس‌هایی مثل پیامک، نقشه و AI را سناریونویسی کنید.

در پروژه پایدار و کم‌تغییر، هزینه نگهداری کمتر است. در محصولی که تازه وارد بازار می‌شود، تغییرات پس از بازخورد کاربران بخشی از مسیر طبیعی محصول‌اند و نباید با «رفع باگ رایگان» اشتباه گرفته شوند.

مدل‌های قرارداد و اثر آن‌ها بر قیمت

قیمت ثابت

برای دامنه کوچک و روشن مناسب است. خروجی، معیار پذیرش و فرایند تغییر باید دقیق باشد.

ریسک آن این است که اگر ابهام زیاد باشد، پیمانکار حاشیه ریسک را روی قیمت می‌گذارد یا اختلاف بر سر «داخل یا خارج محدوده» شکل می‌گیرد.

زمان و مواد (Time & Material)

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

این مدل چک سفیدامضا نیست. سقف بودجه دوره‌ای، بک‌لاگ اولویت‌بندی‌شده، گزارش مصرف و دموی منظم باید وجود داشته باشد.

تیم اختصاصی

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

مدل ترکیبی

در بسیاری از پروژه‌ها مدل ترکیبی منطقی‌تر است:

1. Discovery با قیمت و خروجی مشخص؛
2. ساخت نسخه اول با برآورد مرحله‌ای؛
3. توسعه و بهبود با Time & Material یا تیم اختصاصی.

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

چرا ارزان‌ترین پیشنهاد ممکن است گران تمام شود؟

مشکل، «قیمت پایین» به‌خودی‌خود نیست. یک تیم کوچک و حرفه‌ای ممکن است به‌دلیل هزینه سربار کمتر پیشنهاد مناسبی بدهد. خطر زمانی است که اختلاف قیمت از حذف بخش‌های ضروری یا درک ناقص دامنه آمده باشد.

نشانه‌های پیشنهاد پرریسک:

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

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

معیار درست این است:

کدام پیشنهاد با کمترین ریسک، هسته ارزش محصول را در سطح کیفیت موردنیاز تحویل می‌دهد؟

چطور هزینه نسخه اول را واقعاً کاهش دهیم؟

۱. یک جریان اصلی را کامل کنید

به‌جای ده جریان ناقص، مسیری را بسازید که کاربر از شروع تا دریافت ارزش طی می‌کند.

۲. نقش‌های غیرضروری را حذف یا دستی کنید

در MVP بعضی عملیات می‌تواند از پنل مدیر یا حتی فرایند دستی انجام شود. اتوماسیون زمانی ارزش دارد که فرایند و حجم آن اثبات شده باشد.

۳. با وب‌اپ شروع کنید

اگر قابلیت Native مثل Bluetooth، پردازش سنگین دستگاه یا تجربه ویژه موبایل لازم نیست، وب‌اپ واکنش‌گرا ممکن است نسخه اول را سریع‌تر و ارزان‌تر کند.

۴. اتصال‌های بیرونی را اولویت‌بندی کنید

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

۵. داده و مسئولیت‌ها را پیش از شروع آماده کنید

تأخیر در محتوا، قوانین قیمت‌گذاری، دسترسی API و تصمیم‌گیری کارفرما، زمان تیم را مصرف می‌کند و هزینه را بالا می‌برد.

۶. Discovery را حذف نکنید

حذف تحلیل برای صرفه‌جویی، اغلب فقط ابهام را به مرحله گران‌تر توسعه منتقل می‌کند. Discovery باید متناسب باشد، نه طولانی و تشریفاتی.

۷. کیفیت را بر اساس ریسک تنظیم کنید

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

برای دریافت برآورد قابل‌اعتماد چه اطلاعاتی آماده کنیم؟

پیش از درخواست قیمت، یک Brief دو تا پنج‌صفحه‌ای آماده کنید:

1. مسئله کسب‌وکار و نتیجه مورد انتظار؛
2. کاربران، خریدار و نقش‌ها؛
3. جریان اصلی هر نقش؛
4. قابلیت‌های ضروری نسخه اول؛
5. مواردی که عمداً به نسخه بعد منتقل می‌شوند؛
6. سیستم‌ها و APIهای لازم؛
7. داده موجود و مسئول تأمین آن؛
8. حجم تقریبی کاربر و تراکنش؛
9. محدودیت امنیتی، حقوقی یا زمانی؛
10. بازه بودجه و اولویت بین زمان، دامنه و کیفیت.

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

فرایند درست برآورد پروژه

یک برآورد حرفه‌ای معمولاً این مراحل را دارد:

1. جلسه کشف و فهم مسئله؛
2. مشخص‌کردن نقش‌ها و جریان‌ها؛
3. شکستن محصول به قابلیت‌ها و کارهای فنی؛
4. ثبت فرض‌ها، وابستگی‌ها و موارد خارج از محدوده؛
5. تخمین تلاش هر بخش؛
6. انتخاب ترکیب تیم و مدل همکاری؛
7. افزودن هزینه‌های مستقیم و ذخیره ریسک؛
8. ارائه بازه یا بودجه مرحله‌ای؛
9. بازبینی دامنه برای رسیدن به بودجه هدف.

هرچه عدم‌قطعیت بیشتر باشد، بهتر است برآورد به‌صورت بازه ارائه شود، نه عدد دقیق نمایشی.

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

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

جمع‌بندی

قیمت نرم‌افزار سفارشی از روی عنوان پروژه تعیین نمی‌شود. سه متغیر بیشترین اثر را دارند:

1. دامنه: چند جریان و قابلیت واقعاً باید ساخته شود؟
2. پیچیدگی: منطق، داده، اتصال‌ها، امنیت و مقیاس چقدر دشوارند؟
3. سطح تحویل: نمونه آزمایشی می‌خواهید یا محصول عملیاتی قابل‌نگهداری؟

برای یک تصمیم اولیه در مرداد ۱۴۰۵، می‌توان از حدود ۱۵۰ تا ۴۰۰ میلیون تومان برای نسخه‌ای بسیار محدود، ۴۰۰ میلیون تا ۱.۲ میلیارد تومان برای MVP متمرکز و ارقام بالاتر برای محصولات چندنقشی و سازمانی در نظر گرفت. اما عدد قابل‌اتکا فقط بعد از تعریف محدوده به دست می‌آید.

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

منابع و یادداشت قیمت

• بازه‌های این مقاله برای تصمیم اولیه در مرداد ۱۴۰۵ نوشته شده‌اند و به‌دلیل تورم، نرخ ارز، دستمزد و تفاوت کیفیت تیم باید دوره‌ای بازبینی شوند.
• مفهوم هزینه کل مالکیت، هزینه‌های مستقیم و غیرمستقیم چرخه عمر محصول را در کنار قیمت خرید یا ساخت می‌سنجد: راهنمای Total Cost of Ownership از IBM.
• در پروژه‌های چابک، تعیین دامنه و قیمت با عدم‌قطعیت و تعریف نقطه پایان ارتباط مستقیم دارد: Scoping and Pricing Agile Software Development.