قبل از کدنویسی؛ آیا ایده ارزش ساخته‌شدن دارد؟

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

یعنی فکر می‌کنن اگه یه برنامه‌نویس خوب داشته باشن، یا React بلد باشن، یا Node بلد باشن، یا بخوان بک‌اند قوی‌تر کار کنن مثلاً Go بلد باشن، دیگه مسیر اصلی حل شده.

الان هم که AI اومده، این ذهنیت شدیدتر شده.

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

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

خیلی وقتا پروژه از کد نمی‌خوره زمین.

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

من می‌خوام این پادکست رو از همین‌جا شروع کنم.

نه از آموزش یه تکنولوژی.
نه از اینکه کدوم فریم‌ورک بهتره.
نه از اینکه AI قراره برنامه‌نویس‌ها رو نابود کنه یا نه.

از یه سؤال ساده‌تر ولی مهم‌تر:

و اونم این که قبل از اینکه شروع کنیم به ساختن، از کجا بفهمیم اصلاً چیزی که می‌خوایم بسازیم، ارزش ساخته شدن داره یا نه؟

یه زمانی راه انداختن یه استارتاپ واقعاً اینقدر راحت نبود.

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

یکی طراحی بلد بود.
یکی برنامه‌نویسی بلد بود.
یکی شاید فروش بلد بود.
یکی ارائه‌اش خوب بود.
یکی هم شاید فقط انرژی می‌داد، ولی همونم لازم بود.

خلاصه باید یه جوری تیم جمع می‌کردی که اون ایده روی هوا نمونه.

دوران جالبی بود.

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

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

از اون طرف، از نظر فنی هم همه‌چیز اینقدر راحت نبود.

یه باگ می‌خوردی که نمی‌ذاشت شب بخوابی.
تا صبح Stack Overflow رو زیر و رو می‌کردی.
نه AI بود که برات توضیح بده، نه Copilot بود که وسط کد حدس بزنه چی می‌خوای، نه این همه ابزار آماده بود.

ولی با همه سختی‌ها، یه چیزی داشت که جذاب بود.

چون برای محصولی که می‌ساختی واقعاً بها می‌دادی.

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

همین باعث می‌شد به محصولت وابسته بشی.

این وابستگی یه بدی داشت؛ ممکن بود روی ایده‌ات زیادی تعصب پیدا کنی.

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

یادم برای رسوندن D-Pay به MVP، حدود شیش ماه واقعاً فشار کشیدیم.

شیش ماهی که خیلی از روزها ۱۴ ساعت کار می‌کردیم.
بدون تعطیلی درست.
بدون خواب منظم.
بدون استراحت واقعی.

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

ولی همون مسیر باعث شد یه چیز رو خوب بفهمم:

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

با تصمیم ساخته می‌شه.
با فشار ساخته می‌شه.
با تست بازار ساخته می‌شه.
با اشتباه و اصلاح ساخته می‌شه.
با تیم، مشتری، فروش، پشتیبانی و هزار تا جزئیات دیگه ساخته می‌شه.

اما الان خیلی چیزها عوض شده.

الان با AI خیلی از مسیرها کامپرس‌تر شده.

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

شاید دیگه لازم نباشه برای هر بخش پروژه بری دنبال یه نفر.
شاید دیگه برای هر باگ، یه روز کامل تو Stack Overflow گیر نکنی.
شاید AI خیلی از کدها رو برات بنویسه.
شاید حتی بدون اینکه خیلی عمیق بدونی یه فریم‌ورک دقیقاً داره چیکار می‌کنه، بتونی یه خروجی قابل نمایش بسازی.

این قسمت ماجرا خوبه.

واقعاً خوبه.

من اصلاً مخالفش نیستم.

AI سرعت داده.
ابزارها بهتر شدن.
ساختن راحت‌تر شده.
هزینه رسیدن به نسخه اولیه کمتر شده.

ولی خب کل ماجرا این نیست.

چون یه طرف مهم استارتاپ هنوز همون‌قدر سخت مونده، حتی شاید سخت‌تر هم شده.

و اونم ورود به بازاره.

من توی مشاوره‌هایی که می‌دم، هنوز زیاد می‌بینم تیم‌هایی رو که ایده دارن، تیم دارن، حتی یه نسخه اولیه هم ساختن، شاید نشستن تو چند روز با Claude یا ChatGPT یه خروجی جمع کردن، ولی تو ورود به بازار حسابی لنگ می‌زنن.

نه بازار رو درست بررسی کردن.
نه ریسک ورود به بازار رو می‌شناسن.
نه می‌دونن مشتری دقیقاً کیه.
نه می‌دونن چرا این ایده باید جواب بده.
نه می‌دونن محصولشون دقیقاً کجای زندگی یا کسب‌وکار مشتری کاربرد داره.

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

اینجاست که مشکل شروع می‌شه.

چون سرعت ساخت بالا رفته، ولی کیفیت تصمیم‌گیری لزوماً بالا نرفته.

الان خیلی‌ها سریع‌تر از قبل می‌سازن؛ ولی خیلی وقتا سریع‌تر وارد مسیر اشتباه می‌شن.

قبلاً شاید شیش ماه طول می‌کشید بفهمی یه ایده جواب نمی‌ده.
الان ممکنه تو یه هفته MVP بزنی، ولی باز هم نفهمی مشتری کیه.

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

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

و این خطرناکه.

یه چیز دیگه هم هست که کمتر درباره‌اش حرف زده می‌شه.

مسیر سخت قبلی فقط محصول نمی‌ساخت؛ خود آدم رو هم می‌ساخت.

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

شخصیت فاندر ساخته می‌شد.

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

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

خروجی داره، ولی هنوز اون تکامل رو طی نکرده.

نه خودش، نه تیمش، البته اگه اصلاً تیمی وجود داشته باشه.

اینجاست که باید حواسمون باشه:

AI ساختن رو سریع‌تر کرده، ولی الزاماً تو رو تبدیل به فاندر بهتر نمی‌کنه.

AI می‌تونه کد بده.
می‌تونه UI بده.
می‌تونه ساختار اولیه بده.
می‌تونه حتی ایده بده.

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

پس مسئله این نیست که با AI می‌شه ساخت یا نه.

تقریباً خیلی چیزها رو می‌شه ساخت.

مسئله اینه:

آیا چیزی که داریم می‌سازیم، واقعاً باید ساخته بشه؟

این سؤال ساده‌ست، ولی خیلی از پروژه‌ها همین رو جواب نمی‌دن.

معمولاً وقتی یه برنامه‌نویس یا یه تیم فنی ایده‌ای به ذهنش می‌رسه، سریع می‌ره سراغ اجرا.

می‌گه دیتابیس چی باشه؟
فرانت با چی بزنیم؟
بک‌اند با چی بزنیم؟
از اول microservice بریم یا monolith؟
پرداخت داشته باشه یا نه؟
اپلیکیشن هم بزنیم یا نه؟

این سؤال‌ها مهمن.
ولی سؤال اول نیستن.

سؤال اول اینه:

کی قراره برای این محصول پول بده؟

نه چه کسی ممکنه خوشش بیاد.
نه چه کسی ممکنه بگه ایده جالبیه.
نه چه کسی ممکنه تو یه جمع دوستانه تشویقت کنه.

واقعاً کی حاضره برای این محصول زمان، پول، اعتبار، دیتا یا توجه خودش رو بده؟

اگه این سؤال جواب نداشته باشه، انتخاب تکنولوژی خیلی مهم نیست.

ممکنه بهترین کد دنیا رو بزنی، ولی برای مسئله‌ای که بازار حاضر نیست بابتش هزینه بده.

اینجا خیلی از پروژه‌ها گیر می‌کنن.

از بیرون خروجی دارن.
یه دمو هست.
یه پنل هست.
یه ویدیو معرفی هم شاید هست.

ولی مشتری نیست.
فروش نیست.
استفاده واقعی نیست.

بعد تازه تیم می‌فهمه مشکل از کد نبود.
مشکل از قبل از کد شروع شده بود.

بازار هم فقط این نیست که بگی این حوزه بزرگه.

مثلاً بگی بازار آموزش بزرگه.
بازار کریپتو بزرگه.
بازار AI بزرگه.
بازار فروشگاه آنلاین بزرگه.

خب باشه، ولی این کافی نیست.

بازار یعنی یه گروه مشخص از آدم‌ها که یه مسئله مشخص دارن و برای حل اون مسئله حاضرن اقدام کنن.

نه فقط بگن خوبه.
نه فقط بگن ایده جالبیه.

اقدام کنن.

یعنی وقت بذارن.
پول بدن.
دیتا بدن.
از راه‌حل فعلی‌شون جابه‌جا بشن.
ریسک تغییر رو قبول کنن.

مثلاً اگه می‌گی می‌خوام یه سیستم نوبت‌دهی بسازم، باید دقیق بدونی برای کی.

برای آرایشگاه؟
برای کلینیک؟
برای باشگاه؟
برای مشاور؟
برای آموزشگاه؟
برای یه مجموعه چند شعبه‌ای؟

هر کدوم از اینا رفتار، بودجه، درد و فرایند فروش متفاوت دارن.

پس قبل از ساخت، باید بازار رو ریز کنی.

یکی از خطرناک‌ترین جمله‌ها اینه که می‌گیم:

«همه می‌تونن ازش استفاده کنن.»

وقتی می‌گی همه می‌تونن استفاده کنن، معمولاً یعنی هنوز نمی‌دونی دقیقاً کی باید استفاده کنه.

محصول خوب معمولاً برای همه شروع نمی‌شه.

از یه گروه مشخص شروع می‌شه.
از یه درد مشخص.
از یه استفاده مشخص.
از یه مشتری مشخص.

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

یه نکته دیگه هم هست:

کاربر و مشتری همیشه یکی نیستن.

کاربر کسیه که استفاده می‌کنه.
مشتری کسیه که پول می‌ده.

گاهی این دو تا یکی‌ان، ولی خیلی وقتا یکی نیستن.

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

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

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

هر دو خطرناکه.

برای همین قبل از ساخت باید بدونی:

کی درد داره؟
کی استفاده می‌کنه؟
کی تصمیم می‌گیره؟
کی پول می‌ده؟
کی روی انتخاب اثر می‌ذاره؟

تو بازار واقعی، اینا همیشه یکی نیستن.

مدل درآمد هم چیزی نیست که همیشه بشه انداختش برای بعد.

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

این جمله همیشه غلط نیست، ولی برای خیلی از پروژه‌ها خطرناکه.

چون مدل درآمد روی طراحی محصول اثر می‌ذاره.

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

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

تو پروژه واقعی، سؤال فقط این نیست که:

«می‌شه ساخت؟»

تقریباً خیلی چیزها رو می‌شه ساخت.

سؤال بهتر اینه:

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

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

اینجا می‌رسیم به MVP.

خیلی‌ها MVP رو اشتباه می‌فهمن.

فکر می‌کنن MVP یعنی یه محصول ناقص، زشت، نصفه‌نیمه و عجله‌ای.

نه.

MVP یعنی کوچک‌ترین نسخه‌ای که بتونه مهم‌ترین فرضیه محصول رو تست کنه.

فرضیه یعنی چی؟

یعنی اون چیزی که اگه غلط باشه، کل محصول زیر سؤال می‌ره.

مثلاً:

آیا مشتری واقعاً این مسئله رو داره؟
آیا حاضر می‌شه برای حلش پول بده؟
آیا این راه‌حل براش قابل فهمه؟
آیا بدون توضیح زیاد می‌تونه ازش استفاده کنه؟
آیا حاضر می‌شه دوباره برگرده؟

اگه MVP اینا رو تست نکنه، فقط یه نسخه کوچک‌شده از خیال خودمونه.

خیلی از تیم‌ها MVP نمی‌سازن؛ فقط نسخه اول بزرگ می‌سازن، با امکانات کمتر.

فرقش مهمه.

MVP باید به یادگیری سریع کمک کنه، نه فقط به لانچ سریع.

اگه نسخه اولت چیزی بهت یاد نده، MVP نیست.

ممکنه یه خروجی باشه، یه دمو باشه، یه نمونه اولیه باشه، ولی MVP واقعی نیست.

MVP واقعی باید یه سؤال مهم رو جواب بده.

آیا بازار این رو می‌خواد یا نه؟
آیا این مدل فروش جواب می‌ده یا نه؟
آیا این بخش از محصول ارزش اصلیه یا نه؟
آیا مشتری حاضر می‌شه برای این خروجی پول بده یا نه؟

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

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

یه عده از روز اول می‌خوان microservice، Kubernetes، چند تا دیتابیس، چند تا queue و کلی ابزار راه بندازن؛ در حالی که هنوز مشتری اول هم ندارن.

این معمولاً پروژه رو کند و شکننده می‌کنه.

از اون طرف، یه عده هم همه‌چیز رو سریع و بی‌ساختار می‌سازن و می‌گن بعداً درستش می‌کنیم.

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

پس معماری یعنی تصمیم درست متناسب با مرحله.

نه ساده‌سازی بی‌فکر.
نه پیچیدگی نمایشی.

برای یه MVP، شاید یه monolith تمیز خیلی بهتر از microservice زودهنگام باشه.

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

برای یه سیستم داده، ساختار ذخیره‌سازی و متریک‌ها از اول مهمه.

برای یه بازی real-time، latency از همون اول مسئله جدیه.

معماری خوب یعنی بدونی کجا باید ساده شروع کنی و کجا از اول نباید اشتباه کنی.

این تشخیص با خوندن مستندات به‌تنهایی نمیاد.

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

حالا برگردیم به AI.

AI سرعت می‌ده، ولی جهت نمی‌ده.

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

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

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

پس سؤال درست این نیست که:

«با AI می‌شه این رو ساخت؟»

سؤال درست اینه:

«آیا چیزی که با AI سریع‌تر می‌سازیم، اصلاً باید ساخته بشه؟»

چون AI هزینه ساخت رو کم کرده، ولی هزینه اشتباه استراتژیک رو حذف نکرده.

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

فقط ممکنه این بار سریع‌تر ببازی.

پس قبل از اولین خط کد، یا حتی قبل از اولین پرامپت جدی به AI، چند تا سؤال باید جواب داشته باشه.

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

این سؤال‌ها شاید ساده به نظر برسن، ولی جواب ندادن به همین‌ها می‌تونه چند ماه زمان، انرژی و پول رو از بین ببره.

من زیاد دیدم تیم‌هایی رو که به جای جواب دادن به این سؤال‌ها، رفتن فیچر ساختن.

ولی هیچ‌کس نپرسیده:

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

این‌ها سؤال‌های سخت‌تری هستن.

ولی محصول از همین‌جا جدی می‌شه.

اگه بخوام کل این اپیزود رو تو یه جمله جمع کنم، می‌گم:

مشکل اصلی خیلی از پروژه‌ها این نیست که نمی‌تونن کد بزنن؛ مشکل اینه که نمی‌دونن چرا، برای کی، با چه مدل درآمدی و با چه مسیر رشدی دارن کد می‌زنن.

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

ولی همه این‌ها باید در خدمت یه چیز باشن:

ساخت محصولی که برای یه بازار واقعی، یه مسئله واقعی رو حل کنه و بتونه زنده بمونه.

نه فقط ساخته بشه.
نه فقط لانچ بشه.
نه فقط یه دمو قشنگ داشته باشه.

زنده بمونه.

یعنی مشتری داشته باشه.
استفاده بشه.
درآمد بسازه.
قابل نگهداری باشه.
قابل رشد باشه.

برای همین این پادکست رو از این نقطه شروع کردیم.

چون من نمی‌خوام اینجا فقط درباره ابزار حرف بزنیم.

قراره درباره مسیر واقعی ساخت محصول حرف بزنیم.

از ایده تا بازار.
از معماری تا مشتری.
از تیم تا درآمد.
از AI تا تصمیم درست.
از MVP تا رشد.

تو اپیزودهای بعدی دقیق‌تر می‌ریم سراغ همین موضوع‌ها.

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

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

اول باید مسیرت رو بررسی کنی.

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

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