ساختن یا خریدن، مسئله این است!

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

اما AI پارامتر جدیدی وارد این معادله کرده.

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

این رو هم تأکید کنم که یک developer که با AI توی تعطیلات آخر هفته یک SaaS می‌سازه با تیمی که قبلا صد microservice رو در production مدیریت می‌کرده یکی نیست. تیم دوم تجربه معماری، تست، observability و امنیت رو داره. اگر چنین تیمی استفاده درست از coding agentها رو یاد بگیره، ظرفیتش در بعضی بخش‌های تولید نرم‌افزار می‌تونه چند برابر بشه، چون تخصص قبلی حالا اهرم خیلی بزرگ‌تری داره.

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

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

برای مثال، من دنبال سرویس یا ابزاری بودم که بتونم ارسال ایمیل از طریق چند provider SMTP رو مدیریت کنم. گزینه‌ها یا پولی بودن یا دقیقا چیزی نبودن که می‌خواستم. با استفاده از Claude نسخه اولیه قابل‌استفاده SMTP-Switch رو در چند ساعت ساختم و حالا تیم ما داره ازش استفاده می‌کنه. پروژه هنوز alpha هست و باید در مقیاس بزرگ‌تری آزمایش بشه، ولی نیاز فعلی ما رو برطرف کرده.

نکته اینه که LLMها فقط هزینه ساخت SaaS رو پایین نمی‌آرن، هزینه جایگزین کردنش رو هم پایین می‌آرن. برای همین احتمالا در آینده سؤال اصلی مشتری این نیست که «آیا می‌تونیم این رو خودمون بسازیم؟» سؤال اینه که «چرا باید این محصول رو از شما بخریم؟»