اگر امروز برای ابزارهای ساخت اپلیکیشن بدون کد هزینه پرداخت میکنید، احتمالاً متوجه شدهاید که اعتبار شما بسیار سریعتر از حد انتظار تمام میشود. تصور کنید یک پرامپت ساده برای طراحی اپلیکیشنی با ۱۰ صفحه، میتواند ۱۰ برابر بیشتر از آنچه پیشبینی کرده بودید، از موجودی شما کم کند. در بازار فعلی ابزارهای بدون کد مبتنی بر هوش مصنوعی، عدد کلی اعتباری که در صفحه قیمتگذاری نمایش داده میشود، اغلب هزینه واقعی تولید را پنهان میکند.
این ساختار جدید، بازتاب یک روند گستردهتر در نرمافزارهای سازمانی است. طبق گزارش سال ۲۰۲۵ شرکت فورستر (Forrester)، پیشبینی میشود قیمتگذاری مبتنی بر مصرف تا پایان سال ۲۰۲۵ به ۱۰٪ از کل هزینههای نرمافزاری سازمانها برسد. دلیل این چرخش ساده است: تولید کد توسط هوش مصنوعی، عملیاتی با هزینه متغیر و شدید در مصرف منابع است و اشتراکهای ماهانه با قیمت ثابت نمیتوانند این هزینهها را در مقیاس بزرگ پوشش دهند. این تغییر رویکرد را میتوان در تحول مدلهای پرداخت ابزارهای توسعه کد مشاهده کرد که در آن اشتراکهای ثابت جای خود را به سیستمهای انعطافپذیرتر میدهند.
همانطور که در تحلیل قبلی ما دربارهی دلیل جهش قیمتها در مدلهای توکن-محور اشاره کردیم، ابزارهای بدون کد نمونهای ملموس از این تنش اقتصادی هستند. قیمتگذاری سنتی بر اساس تعداد کاربر (Seat-based) زمانی جواب میداد که هزینهٔ سرویسدهی به هر فرد پیشبینیپذیر بود. اما وقتی هزینه اصلی، محاسبات (Compute) باشد — که با هر خط کد تولید شده افزایش مییابد — فروشندگان ناچارند سیستم صورتحساب را به رویدادهای خاصِ مصرف متصل کنند. این حالت شبیه کرایهٔ یک آشپزخانه صنعتی است که هرچه دستور پخت سنگینتر باشد، هزینه هر وعده بیشتر میشود. در واقع، این تناقض باعث شده تا هزینههای کلی هوش مصنوعی در سازمانها علیرغم کاهش قیمت هر توکن، به دلیل افزایش حجم مصرف، روند صعودی داشته باشد.
سازوکار شکاف اعتباری
اکثر سازندههای اپلیکیشن با هوش مصنوعی، سیستم پرداخت خود را از طریق دو سازوکار اصلی مدیریت میکنند: سیستمهای اعتباری (Credit) و سیستمهای توکنی. اعتبارها واحدهای گسستهای هستند که توسط خود پلتفرم تعریف میشوند، در حالی که توکن (Token) — تکههای کوچکی از متن، مثل برشهای یک کیک طولانی که مدل تکهتکه میخورد — قیمت را مستقیماً به حجم دادههای پردازش شده توسط مدل هوش مصنوعی زیربنایی متصل میکند.
بسیاری از پلتفرمها از یک مدل ترکیبی استفاده میکنند. آنها یک «کفِ قیمتی» (Subscription Floor) برای ایجاد پیشبینیپذیری در هزینهها قرار میدهند و در کنار آن، یک لایهی مبتنی بر مصرف برای جذب هزینههای مربوط به فعالیتهای با حجم بالا اضافه میکنند. مشکل اصلی برای خریدار در اینجا «دانهبندی» یا جزئیات این اعتبارهاست: دقیقاً یک اعتبار چه چیزی میخرد و چه خدماتی را پوشش میدهد؟
۶ متغیری که باعث شوک در فاکتور ماهانه میشوند
بر اساس تحلیلها، ۶ متغیر خاص زیر معمولاً عامل اصلی هزینههای غیرمنتظره در پایان ماه هستند:
- تعداد تولیدات هوش مصنوعی (AI Generation Count): خریداران تصور میکنند هر پرامپت برابر با یک اعتبار است. در واقعیت، بسیاری از پلتفرمها هزینه را بر اساس «تعداد صفحات تولید شده» محاسبه میکنند، نه تعداد درخواستهای ارسالی.
- خروجی برای چند پلتفرم (Multi-platform Export): کاربران اغلب فکر میکنند یک بار خروجی گرفتن، تمام مقاصد را پوشش میدهد. اما استخراج کد برای iOS و اندروید بهصورت جداگانه، اغلب دو رویداد اعتباری مجزا محسوب میشود.
- بازتولید صفحات (Screen Regeneration): ویرایش یک صفحه بهندرت رایگان است. هر بار اصلاح، تغییر جزئی یا تولید مجدد که بر اثر بازبینی (Review) تحریک شود، معمولاً اعتبارهای جدیدی مصرف میکند.
- ظرفیت پروژه (Project Capacity): پلنهای سطح پایین (Entry tiers) اغلب تعداد پروژههای فعال را محدود میکنند. این امر کاربر را مجبور میکند پیش از شروع ساختهای جدید، کارهای قدیمی خود را پاک کند.
- تعداد صندلیهای کاری (Workspace Seats): در حالی که یک حساب تکنفره پوشش داده شده است، اضافه کردن حتی یک همکار به فضای کاری، اغلب باعث فعال شدن هزینه جداگانه بر اساس تعداد کاربر (Seat-based fee) میشود.
- فرمت خروجی (Export Format): استخراج کدهای Native (بومی) معمولاً اعتبار بیشتری نسبت به خروجیهای سادهی فایلهای طراحی مصرف میکند.
محاسبه بر اساس تعداد صفحه، رایجترین دلیل شوک در فاکتورهاست. برای مثال، کاربری با پلن ۱۰۰۰ اعتباری ممکن است تصور کند میتواند ۱۰۰۰ اپلیکیشن بسازد، اما اگر هر اپلیکیشن ۱۰ صفحه داشته باشد، در واقع تنها میتواند ۱۰۰ اپلیکیشن ایجاد کند.
کامل بودن خروجی؛ معیاری برای ارزش
پیشبینی واقعی هزینه به مفهوم «میزان کامل بودن خروجی» (Output Completeness) بستگی دارد. پلتفرمی که تنها مجموعهای از فایلهای طراحی صفحه را تحویل میدهد، برای رسیدن به یک وضعیت قابل استقرار (Deployable)، به گامهای میانی بسیار بیشتر و در نتیجه اعتبارهای بیشتری نیاز دارد تا پلتفرمی که یک پروژه کامل را تحویل میدهد.
Sketchflow.ai از مدلی استفاده میکند که بر محور «تحویل کامل خروجی» است. در این پلتفرم، یک گردش کارِ تولید (Generation Workflow) بهطور همزمان کد iOS، اندروید و وب را به همراه ساختار پروژه (Scaffolding) و منطق ناوبری (Navigation Logic) تولید میکند. طبق اعلام این شرکت، پلنهای آنها از ۲۵ دلار ماهانه برای ۱۰۰۰ اعتبار (پلن Plus) شروع شده و تا ۶۰ دلار برای ۳۰۰۰ اعتبار (پلن Pro) ادامه مییابد.
این رویکرد تفاوت بنیادی با پلتفرمهایی دارد که هر تکرارِ تکصفحه را میسنجند. وقتی پلتفرمی یک اپلیکیشن کامل و قابل کامپایل (Compilable) را در هر گردش کار تحویل میدهد، ارزش هر اعتبار افزایش یافته و هزینه برای کاربر پیشبینیپذیرتر میشود.
شکاف دید در کسبوکارهای کوچک
شرکت گارتنر (Gartner) اشاره کرده است که کسبوکارهای کوچک و متوسط (SMB) سهم بیشتری از بازار پلتفرمهای کم-کد (LCAP) پیدا کردهاند. برخلاف خریداران سازمانی بزرگ، این کاربران اغلب تجربه کافی در مواجهه با قراردادهای پیچیده نرمافزاری ندارند.
این بدان معناست که تعداد رو به افزایشی از خریداران، برای نخستین بار تنها پس از دریافت اولین فاکتور با این ساختارهای پیچیده سنجش (Metering) مواجه میشوند. گزارش ۲۰۲۵ شرکت Metronome درباره وضعیت قیمتگذاری مبتنی بر مصرف تأیید کرد که «پیشبینیناپذیری هزینهها»، عامل اصلی نارضایتی خریداران در بخش SaaS است.
برای شما به عنوان کاربر، این یعنی «قیمت ماهانه» یک معیار درجه دو است. معیار اصلی، «هزینه برای هر محصول قابل استقرار» (Cost per deployable artifact) است. اگر بودجهای برای یک پروژه میبندید، حتماً تعریف کنید که اعتبارات شما یک پرامپت را میپوشاند، یک صفحه را، یا یک اپلیکیشن کامل را.
اگر خروجی صرفاً یک فایل طراحی باشد، شما در واقع دارید برای یک «قطعه» (Fragment) هزینه پرداخت میکنید. اما اگر خروجی کد Swift و Kotlin در سطح تولید (Production-grade) همراه با تنظیمات ساخت (Build Configurations) باشد، اعتبار شما یک «محصول نهایی» را پوشانده است. این تفاوت تعیین میکند که بودجه ماهانه شما پایدار است یا مانند ساعتی تیکتیک میکند تا شما را به یک جریمه سنگین برای مصرف بیش از حد (Overage fee) برساند.
برای جلوگیری از این تلهها، خریداران باید پیش از تعهد به یک پلن، «تعریف واحد» (Unit Definition) اعتبارات آن پلتفرم را ممیزی کنند. بهطور مشخص بپرسید: آیا یک رویداد تولید، یک صفحه مستقل میسازد یا یک پروژه منسجم و چندپلتفرمی؟
گام بعدی شما
- لیست تمام «نقاط مصرف اعتبار» (Credit Trigger) را از مستندات پلتفرم استخراج کنید.
- هزینه هر اپلیکیشن را بر اساس تعداد صفحات پیشبینی شده محاسبه کنید، نه تعداد ایدهها.
- اولویت را به پلتفرمهایی بدهید که خروجی کامل (Full-stack) ارائه میدهند تا از هزینههای پنهان تکرار صفحات دور بمانید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو