راهنمای کاملپاسخ صریح به پرسشهای کارفرمایان — از تفاوت اپلیکیشنساز آماده با طراحی اپلیکیشن اختصاصی تا هزینه، انتشار در مارکتها و مالکیت سورسکد.
اپلیکیشنساز آماده — همان ابزارهای no-code که با انتخاب یک قالب و پرکردن چند فرم، خروجی اپ میسازند — و طراحی اپلیکیشن اختصاصی، دو محصول متفاوت با دو مدل مالکیت کاملاً متفاوتاند. در اپلیکیشنساز، شما در عمل مستأجر یک پلتفرم هستید: اپ روی زیرساخت سرویسدهنده اجرا میشود، قابلیتها محدود به چیزی است که آن پلتفرم از قبل پیشبینی کرده و تا وقتی اشتراک را پرداخت میکنید، اپ زنده میماند. در طراحی اپلیکیشن اختصاصی، کد از صفر برای فرایند کسبوکار شما نوشته میشود، سورس و داده در اختیار خودتان است و سقف قابلیتها را نیاز شما تعیین میکند، نه فهرست امکانات یک ابزار.
بگذارید صادق باشیم، چون این صداقت به نفع تصمیم شماست: اپلیکیشنساز آماده برای بخشی از کسبوکارها واقعاً انتخاب درستی است و ما آن را نفی نمیکنیم. اگر میخواهید یک کاتالوگ محصول، یک اپ سادهٔ معرفی خدمات یا نسخهٔ موبایلی یک سایت محتوایی را با کمترین هزینه و در کوتاهترین زمان روی گوشی مخاطب ببرید و هنوز مطمئن نیستید کاربرانتان اصلاً اپ نصب میکنند یا نه، شروع با یک اپلیکیشنساز منطقی است. چند میلیون تومان و چند روز زمان، در برابر چند ده میلیون تومان و چند ماه توسعه — اپساز ابزار اعتبارسنجی ایده است، نه دشمن آن.
اما سقف این ابزارها جایی است که اغلب کسبوکارهای جدی دیر یا زود به آن میرسند: وقتی اپ باید به انبار، حسابداری و CRM فعلی شما وصل شود؛ وقتی منطق قیمتگذاری، تخفیف یا رزرو شما با هیچ قالب آمادهای نمیخواند؛ وقتی به Push Notification هدفمند بر اساس رفتار کاربر نیاز دارید؛ وقتی دادهٔ مشتریانتان نباید روی زیرساخت شخص ثالث بماند؛ یا وقتی سرعت و تجربهٔ کاربری، خودش بخشی از برند شماست. آن روز، مهاجرت از اپساز به اپ اختصاصی یعنی پرداخت دوبارهٔ بخشی از هزینه — و دقیقاً به همین دلیل بهتر است پیش از شروع بدانید کدام مسیر را میروید.
|
| مالکیت سورسکد | سورس در اختیار شما نیست؛ اپ روی زیرساخت سرویسدهنده اجرا میشود | سورس و مستندات مطابق شرایط قرارداد تحویل داده میشود |
| محدودیت امکانات | محدود به قالبها و افزونههای همان پلتفرم | هر قابلیتی که فرایند کسبوکار لازم دارد، قابل پیادهسازی است |
| هزینهٔ اولیه | پایین؛ معمولاً اشتراک ماهانه یا سالانه | بالاتر؛ در برتینا شروع از ۸۰ میلیون تومان و قیمت نهایی پس از نیازسنجی |
| هزینهٔ بلندمدت | اشتراک تا هر زمانی که اپ زنده است؛ توقف پرداخت یعنی توقف اپ | پس از تحویل فقط نگهداری و توسعه؛ نگهداری ماهانه از ۱۰ میلیون تومان |
| سرعت راهاندازی | چند روز تا چند هفته | چند هفته تا چند ماه؛ زمانبندی دقیق در پروپوزال مشخص میشود |
| اتصال به سیستمهای داخلی | محدود به اتصالهای ازپیشآمادهٔ همان سرویس | اتصال به CRM، انبار، حسابداری، درگاه پرداخت و API اختصاصی |
| مقیاسپذیری | محدود به سقف فنی پلتفرم و پلن اشتراک | با معماری و سرور اختصاصی همراه رشد کسبوکار بالا میرود |
| طراحی و برند | قالب مشترک با سایر کاربران همان ابزار | رابط کاربری کاملاً اختصاصی و منطبق بر هویت بصری شما |
| وابستگی به شخص ثالث | توقف یا تغییر سیاست سرویسدهنده، اپ شما را متوقف میکند | زیرساخت، دامنه و دیتابیس در اختیار خودتان است |
اگر این سه شرط همزمان برقرار است، پولتان را برای اپ اختصاصی خرج نکنید: محتوای اپ عمدتاً نمایشی است (کاتالوگ محصول، وبلاگ، معرفی خدمات، منوی رستوران)، بودجهٔ فعلی شما در محدودهٔ چند میلیون تومان است، و هنوز هیچ شاهدی ندارید که مخاطبتان حاضر است اپ شما را نصب کند و نگه دارد. در این حالت با یک اپساز شروع کنید، چند ماه داده جمع کنید و اگر نصب و بازگشت کاربر معنادار بود، همان داده بهترین ورودی ممکن برای نیازسنجی نسخهٔ اختصاصی خواهد بود. تصمیم بد، خرید اپساز نیست؛ تصمیم بد، ماندن روی اپساز بعد از رسیدن به سقف آن است.
وقتی اپ قرار است بخشی از عملیات کسبوکار باشد، نه بروشور آن. اپ فروشگاهی با خرید تکرارشونده، کیف پول و باشگاه مشتریان؛ اپ رزرو و نوبتدهی با منطق ظرفیت و تقویم اختصاصی؛ اپ کارکنان و نمایندگان میدانی؛ سامانهٔ سازمانی متصل به فرایندهای داخلی؛ یا هر محصولی که خودِ اپ، محصول اصلی شرکت است — اینها با قالب آماده ساخته نمیشوند. معیار سادهٔ تصمیمگیری این است: اگر نبودِ اپ جلوی درآمد یا جلوی یک فرایند عملیاتی را میگیرد، طراحی اپلیکیشن اختصاصی سرمایهگذاری است؛ اگر اپ صرفاً «خوب است داشته باشیم»، همان اپساز کافی است.
در برتینا ساخت اپلیکیشن از ۸۰ میلیون تومان شروع میشود و این عدد، کفِ قیمت است نه قیمت نهایی. هیچ مجموعهٔ صادقی نمیتواند پیش از نیازسنجی، عدد قطعی بدهد؛ چون قیمت ساخت اپلیکیشن تابع حجم کاری است که هنوز مشخص نشده. مسیر ما این است: ابتدا ایده و نیاز کسبوکار بررسی میشود، سپس کاربران، سناریوها و User Flow مشخص میشوند، و در نهایت در قالب یک Specification و پروپوزال، دامنهٔ دقیق کار و برآورد هزینه ارائه میشود. تا پیش از آن مرحله، هر عددی که بشنوید — از هر کسی — حدس است، نه قیمت.
در عمل، هفت عامل زیر هستند که هزینه ساخت اپلیکیشن را میسازند و اختلاف قیمت پیشنهادها هم تقریباً همیشه در همینها پنهان است:
- دامنهٔ قابلیتها: هر صفحه، هر فرم و هر قانون کسبوکار، ساعت توسعه و ساعت تست جداگانه دارد — بیشترین اثر روی قیمت را همین یک عامل میگذارد
- تعداد پلتفرمها: فقط طراحی اپ اندروید، فقط طراحی اپ iOS، یا هر دو؛ توسعهٔ همزمان با کدپایهٔ مشترک از دو پروژهٔ جداگانه ارزانتر تمام میشود
- پیچیدگی طراحی UI/UX: رابط اختصاصی با انیمیشن و مسیرهای چندمرحلهای، پرهزینهتر از رابط ساده و استاندارد است
- اتصالها و APIها: درگاه پرداخت، پیامک، CRM، انبار و حسابداری — هر اتصال یک قرارداد فنی مستقل با تست و سناریوهای خطای خودش است
- بکاند و پنل مدیریت: اپ بدون API و پنل مدیریت، چیزی برای نمایشدادن ندارد؛ این بخشِ نامرئی گاهی نیمی از کار پروژه است
- زیرساخت و انتشار: سرور، دیتابیس، گواهی SSL، سرویس Push Notification و آمادهسازی بستههای انتشار در مارکتها
- نگهداری پس از انتشار: هزینهای که تقریباً همیشه از برآورد اولیه جا میماند و بعداً کارفرما را غافلگیر میکند
تفکیک قیمتها کمک میکند تصمیم درستتری بگیرید: در برتینا طراحی سایت از ۷۰ میلیون تومان، ساخت اپلیکیشن از ۸۰ میلیون تومان و پروژهٔ کامل — سایت و اپلیکیشن با بکاند و پنل مدیریت مشترک — از ۱۸۰ میلیون تومان شروع میشود. یعنی ساختن همزمانِ این دو، از دو پروژهٔ کاملاً مستقل کمهزینهتر است، چون بکاند، API و پنل مدیریت یکبار طراحی و نوشته میشوند و هر دو کلاینت از همان تغذیه میکنند. پرداخت تا چهار مرحله قابل تقسیم است و در طول پروژه چهار مرحله بازبینی و اصلاح، مطابق محدودهٔ قرارداد، در نظر گرفته شده است. همهٔ این اعداد «شروع از» هستند و قیمت نهایی پس از نیازسنجی اعلام میشود.
اگر پیشنهادی گرفتید که چند برابر ارزانتر است، پیش از خوشحالشدن سه سؤال بپرسید: سورسکد اپ و بکاند تحویل داده میشود یا فقط فایل نصبی؟ بکاند و پنل مدیریت داخل همین قیمت است یا آیتم جداگانهای که بعداً به فاکتور اضافه میشود؟ و پس از تحویل، وقتی نسخهٔ جدید اندروید یا iOS منتشر شد و اپ از کار افتاد، اصلاح آن با چه هزینهای انجام میشود؟ اختلاف قیمت در بازار، معمولاً در پاسخ همین سه سؤال پنهان است — نه در حاشیهٔ سود مجموعهٔ توسعهدهنده.
اندروید سهم بزرگی از گوشیهای کاربران ایرانی را در اختیار دارد و به همین دلیل در بیشتر پروژهها، طراحی اپ اندروید نقطهٔ شروع است. اپ اندروید میتواند بهصورت Native (با Kotlin) یا با کدپایهٔ چندسکویی نوشته شود — انتخاب بین این دو را در بخش بعدی باز کردهایم. آنچه در هر دو حالت یکسان است، مسیر آمادهسازی برای انتشار است: ساخت بستهٔ نهایی، امضای دیجیتال با کلید اختصاصی، تهیهٔ آیکون و اسکرینشاتها و متنهای فروشگاهی، و تطبیق اپ با سیاستهای محتوایی و حریم خصوصی هر مارکت.
یک نکتهٔ فنی که بیتوجهی به آن بعدها گران تمام میشود: کلید امضای اپ (keystore) عملاً هویت اپ شماست. اگر آن را از دست بدهید یا اصلاً در اختیار نداشته باشید، دیگر نمیتوانید برای همان اپ بهروزرسانی منتشر کنید و مجبور میشوید اپ را با هویت جدید و از صفر منتشر کنید — یعنی همهٔ نصبهای قبلی و کاربران فعلی جا میمانند. پیش از امضای هر قراردادی مطمئن شوید کلید امضا و حساب مارکت به نام خودِ کسبوکار شماست یا در پایان پروژه به شما تحویل میشود.
دربارهٔ انتشار کاملاً شفاف باشیم: برتینا اپ را برای انتشار در کافهبازار، مایکت و Google Play آماده میکند و فرایند ارسال را انجام میدهد، اما انتشار قطعی در همهٔ مارکتها تضمین نمیشود؛ نتیجهٔ بررسی به قوانین هر مارکت، وضعیت حساب توسعهدهنده، نوع اپلیکیشن و محتوای آن بستگی دارد. مارکتهای داخلی معمولاً احراز هویت توسعهدهنده و اسناد کسبوکار میخواهند و برای اپهای دارای پرداخت، الزامات بیشتری تعریف کردهاند. هر مارکتی این اختیار را دارد که اپی را رد کند یا بعداً از فهرست بردارد، و این تصمیم بیرون از کنترل هر تیم توسعهای است.
- حساب توسعهدهنده به نام کسبوکار شما ثبت شود، نه به نام پیمانکار
- کلید امضای اپ (keystore) در اختیار شما و در یک محل امن با نسخهٔ پشتیبان باشد
- سیاست حریم خصوصی، منتشرشده روی دامنهٔ خودتان و قابل دسترس از داخل اپ
- آیکون، اسکرینشات و توضیحات، بهینهشده برای جستوجوی داخل مارکت (همان ASO)
- مجوزهای درخواستی اپ دقیقاً با کاری که واقعاً انجام میدهد بخواند — مجوز اضافی، یکی از دلایل رایج رد شدن است
- تست روی چند دستگاه و چند نسخهٔ اندروید، نه فقط روی گوشی توسعهدهنده
طراحی اپ آیفون بیش از آنکه تصمیمی فنی باشد، تصمیمی تجاری است: اگر بخشی از مشتریان شما از آیفون استفاده میکنند، نبودِ نسخهٔ iOS یعنی آن بخش از مخاطب اصلاً به اپ شما دسترسی ندارد. سهم واقعی کاربران آیفون در میان مخاطبان شما را میتوان از آمار سایت فعلیتان بیرون کشید؛ همان عدد، بهترین راهنما برای این تصمیم است، نه حدس و سلیقه. از نظر فنی، اپ iOS با Swift بهصورت Native یا با یک کدپایهٔ مشترک چندسکویی توسعه داده میشود و روی آیفون و آیپد اجرا میشود.
شرایط App Store سختگیرانهتر از مارکتهای اندرویدی است. انتشار نیازمند حساب توسعهدهندهٔ اپل با هزینهٔ اشتراک سالانه است، هر نسخه پیش از انتشار توسط تیم بازبینی اپل بررسی میشود، و راهنماهای اپل دربارهٔ حریم خصوصی، محتوای کاربرساخته، پرداخت درونبرنامهای و کیفیت رابط کاربری، دقیق و بدون اغماض اجرا میشوند. اپی که در عمل «فقط یک وبسایت بستهبندیشده» باشد و ارزش بومی به کاربر ندهد، معمولاً رد میشود — و این یکی از تفاوتهای جدی طراحی اپ iOS با اندروید است.
و بخش سختِ ماجرا برای کسبوکارهای ایرانی: ثبت و نگهداری حساب توسعهدهندهٔ اپل به دلیل محدودیتهای بینالمللی ساده نیست و انتشار در App Store برای هر پروژهای عملی نخواهد بود. ما این را از ابتدا و پیش از قرارداد میگوییم، چون انتشار قطعی در همهٔ مارکتها تضمین نمیشود و به قوانین هر مارکت، حساب توسعهدهنده و نوع اپ بستگی دارد. اگر انتشار در App Store برای پروژهٔ شما میسر نبود، دو مسیر جایگزین واقعی روی میز است: ارائهٔ نسخهٔ PWA که کاربر آیفون میتواند مستقیم از مرورگر روی صفحهٔ اصلی گوشی خود نصب کند، یا توزیع محدود نسخهٔ iOS برای گروه مشخصی از کاربران. هر دو محدودیتهای خودشان را دارند و در جلسهٔ نیازسنجی، بدون تعارف دربارهٔ آنها صحبت خواهیم کرد.
- حساب توسعهدهندهٔ اپل: اشتراک سالانه دارد و شرایط احراز هویت خاص خودش را میطلبد
- بازبینی انسانی اپل: هر نسخه پیش از انتشار بررسی میشود و رد شدن، بخش طبیعی فرایند است
- الزام شفافیت داده: اپ باید دقیقاً اعلام کند چه دادهای جمع میکند و با آن چه میکند
- کیفیت رابط کاربری: اپل به تجربهٔ کاربری بومی iOS حساس است و کپی مستقیم رابط اندروید را نمیپسندد
- جایگزین PWA برای آیفون: نصب از مرورگر، بدون عبور از App Store — با محدودیت در نوتیفیکیشن و دسترسی سختافزاری
هیچکدام از این سه، «بهترین» مطلق نیستند؛ هر کدام چیزی میگیرند و چیزی میدهند. Native یعنی نوشتن دو اپ جداگانه با ابزار رسمی هر پلتفرم (Kotlin برای اندروید و Swift برای iOS): بیشترین روانی، کاملترین دسترسی به سختافزار و امکانات سیستمعامل، و بالاترین هزینه — چون عملاً دو پروژه دارید. Cross-platform یعنی یک کدپایهٔ مشترک که خروجی هر دو پلتفرم را میدهد: زمان و هزینهٔ کمتر و انتشار همزمان، با کمی سربار در سناریوهای بسیار سنگین. PWA هم وباپلیکیشنی است که مثل اپ روی صفحهٔ اصلی نصب میشود اما در دل مرورگر اجرا میشود.
|
| عملکرد و روانی | بالاترین؛ مناسب گرافیک و پردازش سنگین | برای اغلب اپهای کسبوکاری کافی است | وابسته به مرورگر و کیفیت شبکهٔ کاربر |
| دسترسی به سختافزار | کامل: دوربین، بلوتوث، سنسورها | گسترده؛ گاهی نیازمند افزونهٔ بومی | محدود؛ بخشی از قابلیتها روی آیفون در دسترس نیست |
| Push Notification | پشتیبانی کامل در هر دو پلتفرم | پشتیبانی کامل با یک پیکربندی مشترک | روی اندروید بله؛ روی iOS محدودتر |
| هزینهٔ نسبی | بالاترین (در عمل دو پروژه) | متوسط؛ صرفهجویی از محل کد مشترک | کمترین هزینه در میان سه گزینه |
| زمان توسعه | طولانیترین مسیر | کوتاهتر از Native برای دو پلتفرم | کوتاهترین مسیر تا نسخهٔ قابل استفاده |
| انتشار در مارکت | بله؛ بستهٔ جداگانه برای هر مارکت | بله؛ خروجی هر دو پلتفرم از یک کدپایه | خیر؛ کاربر مستقیم از مرورگر نصب میکند |
| بهروزرسانی | هر نسخه نیازمند بازبینی مارکت است | انتشار همزمان، باز هم با بازبینی مارکت | آنی؛ بدون انتظار برای تأیید مارکت |
| کار در حالت آفلاین | پشتیبانی کامل و بومی | پشتیبانی کامل با ذخیرهٔ محلی | محدود؛ در حد کش مرورگر |
| مناسب برای | محصولات سنگین و شرکتهای اپمحور | اپهای فروشگاهی، خدماتی، رزروی و سازمانی | MVP، کاتالوگ و پنلهای تحت وب |
برای اکثر پروژههای کسبوکاری که به برتینا میرسند — فروشگاهی، رزرو و نوبتدهی، باشگاه مشتریان، اپ کارکنان و نمایندگان — طراحی اپ اندروید و iOS با کدپایهٔ مشترک نقطهٔ تعادل درستی است: یکبار طراحی و توسعه، خروجی برای هر دو پلتفرم، و بودجهای که بهجای دوبرابر شدن، صرف قابلیتهای بیشتر میشود. Native را وقتی پیشنهاد میکنیم که واقعاً لازم باشد: پردازش تصویر یا ویدئوی سنگین، کار مداوم با سنسورها و بلوتوث، بازی، یا اپی که خودش محصول اصلی شرکت است. PWA هم برای اعتبارسنجی سریع ایده یا پنلهای تحت وب سازمانی، گزینهای کاملاً معقول و کمهزینه است.
تصمیم نهایی را بر اساس حدس نمیگیریم: در مرحلهٔ نیازسنجی، فهرست قابلیتها، مخاطب هدف، بودجه، زمان مطلوب و برنامهٔ نگهداری کنار هم گذاشته میشود و معماری پیشنهادی همراه با دلیلش در پروپوزال نوشته میشود. اگر جایی کدپایهٔ مشترک برای نیاز شما جواب ندهد، همانجا و پیش از قرارداد میگوییم — نه شش ماه بعد و وسط توسعه.
آنچه کاربر روی گوشی میبیند، نوک کوه یخ است. زیر هر اپلیکیشن کسبوکاری یک سامانهٔ کامل سمت سرور کار میکند: یک API که اپ با آن حرف میزند، یک دیتابیس که کاربران و محصولات و سفارشها و تراکنشها را نگه میدارد، یک پنل مدیریت که تیم شما هر روز با آن کار میکند، سرویس Push Notification، فضای ذخیرهٔ فایل و تصویر، گواهی SSL برای رمزنگاری ارتباط، و سازوکار بکاپ و بازیابی. اپ بدون اینها یک صفحهٔ خالی است، و نادیدهگرفتن همین لایه، رایجترین دلیل ترکیدن بودجه در پروژههای اپلیکیشن است.
اینجا دقیقاً همان نقطهای است که برتینا با یک آژانس صرفاً نرمافزاری فرق میکند: زیرساخت را خودمان داریم. هاست، سرور مجازی، سرور اختصاصی، ثبت دامنه، گواهی SSL و ایمیل سازمانی همگی سرویسهای خودِ برتیناست و اپلیکیشن شما لازم نیست بین چند پیمانکار و چند فروشندهٔ زیرساخت معلق بماند. یعنی وقتی API کند میشود یا سرویس نیمهشب میخوابد، شرکت توسعهدهنده و شرکت هاستینگ توپ را در زمین هم نمیاندازند؛ یک قرارداد، یک تیم و یک نقطهٔ پاسخگویی وجود دارد — با پشتیبانی ۲۴/۷ و آپتایم ۹۹.۹٪ زیرساخت.
انتخاب محل سرور هم تصمیم فنی مهمی است که مستقیم روی تجربهٔ کاربر اثر میگذارد: اگر کاربران اپ شما در ایران هستند، سرور ایران کمترین تأخیر را به آنها میدهد؛ اگر اپ به سرویسهای خارجی وابسته است، سرور خارج از کشور دسترسی پایدارتری فراهم میکند و معماری ترکیبی هم گزینهٔ رایجی است. در پروژههای سایت و اپلیکیشن، هر دو کلاینت به یک بکاند و یک پنل مدیریت مشترک وصل میشوند تا محصول، سفارش، کاربر و محتوا از یک نقطه مدیریت شوند و کسبوکار شما دو انبار داده و دو حقیقت متفاوت نداشته باشد.
- سرور مجازی یا اختصاصی برای اجرای API و پنل مدیریت اپلیکیشن
- دیتابیس با بکاپ منظم و مسیر بازیابی تستشده — نه فقط بکاپی که گرفته میشود و هرگز بازگردانده نمیشود
- دامنه و زیردامنهٔ اختصاصی برای API و پنل مدیریت
- گواهی SSL؛ بدون آن، اپهای امروزی اصلاً اجازهٔ اتصال به سرور را نمیدهند
- سرویس Push Notification و مدیریت توکن دستگاههای کاربران
- ایمیل سازمانی برای پیامهای تراکنشی: فعالسازی حساب، بازیابی رمز، ارسال فاکتور
- پایش زیرساخت و پشتیبانی ۲۴/۷ برای لحظهای که سرویس در نیمهشب دچار اختلال میشود
صادقانه: هیچ عدد قطعیای وجود ندارد، و هر کس بدون دیدن دامنهٔ کار به شما «دو ماهه تحویل میدهم» گفت، یا کار را ندیده یا بعداً هزینهٔ بیشتری خواهد خواست. زمانبندی واقعی پس از تدوین Specification و در پروپوزال مشخص میشود — بهصورت مرحلهای و با تحویلهای میانی، تا شما در هر مرحله ببینید پروژه کجاست. آنچه از پیش میتوانیم بگوییم ترتیب مراحل است: بررسی ایده و نیاز، تعیین کاربران و سناریوها، طراحی UI/UX، پروپوزال و Spec، توسعهٔ Front و Back، تست و چهار مرحله بازبینی، آمادهسازی و انتشار در مارکت، و در نهایت نگهداری.
چیزی که در هیچ نمودار زمانبندیای دیده نمیشود اما زمان واقعی پروژه را میسازد، سرعت تصمیمگیری کارفرماست. رایجترین علتهای تأخیر در پروژههای اپلیکیشن اصلاً فنی نیستند: تأخیر در تأیید طرحهای رابط کاربری، آمادهنبودن محتوا و تصاویر و متنها، دیرکرد در تحویل دسترسی به سیستمهای داخلی (CRM، انبار، درگاه پرداخت) و تغییر دامنهٔ کار در میانهٔ توسعه. هر بازبینی خارج از چهار مرحلهٔ توافقشده، هم زمان میبرد و هم روی هزینه اثر میگذارد؛ به همین دلیل نهاییکردن فهرست قابلیتها پیش از شروع کدنویسی، بیشترین صرفهجویی زمانی ممکن است.
- نهاییکردن فهرست قابلیتها پیش از شروع توسعه — بزرگترین عامل کوتاهشدن زمان
- وجود یک تصمیمگیرندهٔ مشخص از سمت کارفرما، با اختیار تأیید طرحها
- آمادهبودن محتوا، تصاویر، متنها و دسترسیهای فنی از همان روز اول
- انتشار فاز اول با قابلیتهای ضروری و افزودن بقیه در فازهای بعدی توسعه
- افزودن قابلیت جدید در میانهٔ توسعه، مسیر را طولانی و هزینه را بیشتر میکند
- انتظار برای آمادهشدن حسابهای توسعهدهنده و اسناد کسبوکار، مرحلهٔ انتشار را عقب میاندازد
- زمان بازبینی مارکتها بیرون از کنترل تیم توسعه است و باید در برنامهریزی دیده شود
پیش از امضای هر قراردادی یک جمله را از خودتان بپرسید: «اگر فردا رابطهام با این پیمانکار تمام شود، چه چیزی دستم را میگیرد؟» پاسخ در سه دارایی خلاصه میشود: سورسکد و مستندات، حسابهای توسعهدهندهٔ مارکتها به همراه کلید امضای اپ، و زیرساخت — یعنی دامنه، سرور و دیتابیسی که دادهٔ مشتریان شما روی آن نشسته است. اگر این سه به نام شما نباشد، شما مالک اپلیکیشن نیستید؛ فقط از آن استفاده میکنید. این تفاوت، روزی که بخواهید تیم را عوض کنید یا کسبوکار را بفروشید، خودش را بهشکل گرانقیمتی نشان میدهد.
در برتینا شرایط تحویل سورسکد و مستندات بهصورت صریح در قرارداد مشخص میشود — نه شفاهی و نه با وعدهٔ «بعداً حل میکنیم». توصیهٔ فنی ما هم این است که حسابهای توسعهدهندهٔ کافهبازار، مایکت، Google Play و App Store از ابتدا به نام کسبوکار شما ساخته شوند و دسترسی تیم توسعه بهعنوان همکار به آن اضافه شود. این کار دو نتیجه دارد: مالکیت شما از روز اول تثبیت میشود و روز جدایی — که در هر رابطهٔ کاری ممکن است برسد — بدون درد و بدون گروگانگیری دیجیتال میگذرد. همین قاعده دقیقاً دربارهٔ دامنه و سرور هم صدق میکند.
- سورسکد کامل (اپ، بکاند و پنل مدیریت) تحویل داده میشود؟ در چه مرحلهای از پروژه؟
- مستندات فنی و راهنمای استقرار، همراه سورس تحویل میشود یا باید جداگانه سفارش داد؟
- حسابهای مارکت و کلید امضای اپ به نام چه کسی ثبت میشود؟
- دامنه، سرور و دیتابیس به نام چه کسی است و دسترسی مدیریتی آن دست کیست؟
- اگر بخواهم ادامهٔ کار را به تیم دیگری بسپارم، دقیقاً چه چیزی تحویل میگیرم؟
- کتابخانهها و سرویسهای شخص ثالثِ استفادهشده، هزینهٔ دورهای یا محدودیت لایسنس دارند؟
اپلیکیشن، برخلاف بروشور چاپی، «تحویل داده» نمیشود که تمام شود. زیر پای اپ شما زمین مدام تکان میخورد: گوگل و اپل هر سال نسخهٔ جدید سیستمعامل و الزامات تازهٔ SDK منتشر میکنند و مارکتها اپهایی را که خود را با این الزامات بهروز نکردهاند، از فهرست کنار میگذارند یا نصب آنها را برای کاربران جدید محدود میکنند. کتابخانهها منسوخ میشوند، درگاه پرداخت API خود را عوض میکند و گوشیهای تازه با اندازهٔ صفحهٔ جدید از راه میرسند. اپی که دو سال دستنخورده بماند، معمولاً دیگر درست کار نمیکند — نه چون بد نوشته شده، بلکه چون دنیای اطرافش جلو رفته است.
به همین دلیل نگهداری در برتینا یک سرویس تعریفشده است، نه لطف جانبی: نگهداری ماهانه از ۱۰ میلیون تومان و با حداقل تعهد ششماهه شروع میشود و شامل بهروزرسانی، رفع اشکال، سازگاری با نسخههای جدید سیستمعامل و قوانین مارکتها، و پشتیبانی مطابق قرارداد است. اگر اپ روی زیرساخت برتینا اجرا شود، پایش سرور و پشتیبانی ۲۴/۷ زیرساخت هم در همان مسیر قرار میگیرد و لازم نیست برای یک قطعی نیمهشب، بین دو شرکت پیام رد و بدل کنید و منتظر بمانید تا هرکدام تقصیر را گردن دیگری بیندازد.
و یک واقعیت اقتصادی که بهتر است از امروز در بودجهتان بنشیند: هزینهٔ نگهداری همیشه از هزینهٔ احیای یک اپ رهاشده کمتر است. اپلیکیشنی که چند سال بهروزرسانی نشده، اغلب باید بخش بزرگی از آن بازنویسی شود — یعنی پرداخت دوبارهٔ بخشی از همان سرمایهگذاری اولیه. نگهداری را از روز اول در برنامه بیاورید؛ نه بهعنوان هزینهٔ اضافه، بلکه بهعنوان محافظت از سرمایهای که برای ساخت اپلیکیشن گذاشتهاید.
- بهروزرسانی اپ برای سازگاری با نسخههای جدید اندروید و iOS
- رفع اشکالهای گزارششده توسط کاربران و پایش خطاهای زنده
- بهروزرسانی کتابخانهها و اعمال وصلههای امنیتی
- تطبیق اپ با تغییر قوانین کافهبازار، مایکت، Google Play و App Store
- پایش سرور و دیتابیس، بکاپگیری منظم و تمدید بهموقع گواهی SSL
- افزودن قابلیتهای جدید در قالب فازهای توسعه — خارج از نگهداری پایه و با برآورد جداگانه
برتینا از سال ۱۳۸۳ در حوزهٔ زیرساخت و خدمات وب فعال است و تا امروز بیش از ۱۰۰٬۰۰۰ مشتری را پشتیبانی کرده است. این پیشینه دو چیز به پروژهٔ اپلیکیشن شما اضافه میکند که یک تیم توسعهٔ تازهتأسیس نمیتواند: نخست، زیرساختی که خودمان میسازیم و نگه میداریم — سرور، دامنه، SSL و ایمیل سازمانی — و دوم، ساختار پشتیبانی ۲۴ ساعتهای که برای سرویسهای زندهٔ در حال اجرا طراحی شده، نه برای پروژههایی که پس از تحویل فراموش میشوند. اپلیکیشن شما یک سرویس زنده است، نه یک فایل تحویلی.
در کنار آن، برتینا دارای گواهی ISO 9001 از SGS، گواهی ISO 20000-1 از EGScert، عضویت در نظام صنفی رایانهای و پارتنری رسمی گوگل است. اما آنچه بیش از هر گواهینامهای اهمیت دارد، صداقت در محدودهٔ کار است: ما تضمین انتشار در همهٔ مارکتها نمیدهیم، زمان تحویل قطعی را پیش از نیازسنجی اعلام نمیکنیم، و قیمتها را «شروع از» مینویسیم چون قیمت نهایی به دامنهٔ کار شما بستگی دارد. اگر میخواهید ایدهٔ اپ خود را با ما بررسی کنید، فرم برآورد را پر کنید یا با شمارهٔ ۰۲۱۴۹۱۳۵ تماس بگیرید تا کارشناسان، پلتفرم مناسب و برآورد هزینه را با شما مرور کنند.
کافهبازار
مایکت
Google Play
App Store
