عندك فكرة SaaS؟ ما الذي يجب اختباره قبل أن تدفع في البرمجة؟

Founder عنده فكرة، يفتح Document ويبدأ يكتب Features.

Dashboard.

Subscriptions.

Teams.

Notifications.

AI Assistant.

Mobile App.

Admin Panel.

وبعدها السؤال يصبح:

هتكلف كام علشان نبني كل ده؟

لكن فيه سؤال قبله ممكن يوفر فلوس أكثر بكثير:

إيه اللي لازم يكون صحيح علشان الـProduct دي تستحق أصلًا إننا نبنيها؟

قبل ما تدفع في شهور Development، اختبر الافتراضات اللي ممكن تقتل الـBusiness حتى لو Software نفسها شغالة Perfectly.

لأن Technical Execution مجرد نوع واحد من المخاطر.

Product شغالة مش دليل على Business شغال

Software ممكن تكون سريعة وآمنة وتصميمها ممتاز، وفي نفس الوقت تحل مشكلة محدش مهتم يدفع علشانها.

SaaS Business تحتاج أكثر من Functioning Code.

على الأقل لازم يكون فيه علاقة منطقية بين:

Problem → Buyer → Value → Acquisition → Usage → Revenue → Retention

Development تثبت إن Software ممكن تتبني.

مش تلقائيًا تثبت باقي السلسلة.

اكتب المشكلة بدون ذكر الـProduct

جرب تكمل الجملة دي:

[شخص/شركة محددة] بيعاني بشكل متكرر من [مشكلة محددة]، وده حاليًا بيسبب [نتيجة قابلة للقياس].

مثلًا:

Operations Managers في Service Companies بيراجعوا Job Status يدويًا بين WhatsApp وSpreadsheets، فبيبقى صعب يعرفوا إيه المتأخر ومين مسؤول عن الخطوة التالية.

دي جملة قابلة للاختبار.

قارنها بـ:

الشركات محتاجة AI-powered Operations Platform.

الجملة الثانية افترضت Solution من البداية.

مش هتعرف Validate المشكلة لو عرفتها باستخدام Product بتاعتك.

اختبر مين عنده المشكلة فعلًا

"الشركات" مش Customer Segment.

و"Startups" مش Segment كفاية برضه.

ضيّق First Buyer بما يكفي إنك تقدر تلاقي Real People عندهم ظروف متشابهة.

ممكن تحددهم حسب:

• Industry.
• Company Size.
• Role.
• Workflow.
• Existing Software.
• Geography لو فعلًا تؤثر على المشكلة.
• Trigger Event.

Early Segment المفيدة مش لازم تكون Final Market.

هي المجموعة اللي Learning منها أسهل والمشكلة عندها أوضح.

افصل User عن Buyer وDecision Maker

الشخص اللي يستخدم Software مش لازم يكون هو اللي يدفع.

Employee ممكن يستخدم Product كل يوم.

Department Manager يملك Budget.

IT أو Security توافق على Integration.

Finance توافق على Contract.

في B2B SaaS ارسم على الأقل:

User → Champion → Buyer → Approver

أحيانًا شخص واحد يعمل الأربع Roles.

وأحيانًا كل Role شخص مختلف.

وده يؤثر على Product وSales Process وPricing.

اسأل بيحلوا المشكلة إزاي دلوقتي

من أقوى Signals مش اللي الشخص يقول إنه عايزه.

لكن اللي هو بالفعل بيعمله.

اسأل:

• بتتعاملوا مع المشكلة دي إزاي حاليًا؟
• أنهي Tools داخلة في العملية؟
• مين بيعمل الشغل؟
• بتحصل كل قد إيه؟
• إيه اللي بيبوظ؟
• لما يبوظ، إيه النتيجة؟
• حاولتوا تصلحوها قبل كده؟

Excel Sheet عايشة خمس سنين ممكن تكون شكلها سيئ، لكنها Competitor.

وعدم فعل أي شيء Competitor برضه.

Product بتاعتك لازم تكسب Current Behavior، مش مجرد SaaS Logo ثانية.

دور على Evidence للألم مش مجاملات

الناس مؤدبة لما تعرض عليهم أفكار.

"فكرة مفيدة" Evidence ضعيفة.

Signals أقوى تشمل:

• هم بالفعل بيدفعوا فلوس لحل المشكلة.
• Employees يستهلكوا وقت متكرر كبير فيها.
• بنوا Internal Workaround.
• يجمعوا أكثر من Tool علشان يحلوها.
• المشكلة تعمل Delays أو Lost Opportunities أو Operational Risk.
• فيه شخص مسؤول عن تحسين Metric متأثرة بالمشكلة.
• بيدوروا فعليًا على Alternatives.

أنت محتاج Evidence إن المشكلة تغير Behavior.

ما تسألش: "هتستخدم المنتج ده؟"

Hypothetical Questions تعمل Hypothetical Enthusiasm.

اسأل عن Past وCurrent Behavior بدلها.

ضعيف:

ممكن تدفع في Tool تعمل Automation للحاجة دي؟

أقوى:

آخر مرة المشكلة دي حصلت إمتى؟

عملتوا إيه؟

أخدت وقت قد إيه؟

مين شارك فيها؟

بتدفعوا حاليًا كام في Tools المستخدمة في Process دي؟

إيه اللي منعكم تحلوها بالفعل؟

Past Behavior تديك حاجة Concrete تبحث فيها.

اختبر الـUrgency

مشكلة مؤلمة ممكن تظل SaaS Opportunity سيئة كبداية لو محدش محتاج يحلها دلوقتي.

اسأل إيه اللي بيخلق Urgency.

Triggers ممكن تشمل:

• Growth خلت Manual Process تقع.
• Team أو Location جديدة بتفتح.
• Existing Software بيتم استبدالها.
• Customer Volume زاد.
• Compliance أو Contractual Requirements تغيرت.
• Key Employee مش قادر يشيل Process يدويًا بعد كده.
• Management حددت Operational Target معينة.

سؤال مفيد:

ليه الشركة دي تغير دلوقتي بدل بعد 6 شهور؟

لو مفيش إجابة، Sales قد تكون أصعب كثيرًا من Product Development.

اختبر الاستعداد للتغيير مش الدفع فقط

الفلوس مش Switching Cost الوحيدة.

SaaS جديدة ممكن تحتاج Customer:

• يعمل Import للData.
• يدرب Employees.
• يغير Workflows.
• يربط Systems.
• يأخذ Approval من IT.
• يغير Customer Behavior.
• يوقف Tool متعود عليها.

Product ممكن يكون لها Positive ROI ومع ذلك تفشل لأن Migration Cost تبدو عالية.

Validation لازم تسأل إيه اللي لازم يتغير علشان Adoption تحصل.

افهم الـAlternatives الحالية

ابحث عن Products العميل ممكن يستخدمها بدل منتجك.

لكن ضيف Non-software Alternatives برضه:

• Excel.
• WhatsApp.
• Email.
• Assistant.
• Agency.
• Internal Developer.
• Manual Process.
• Feature داخل Platform أكبر.

وبعدها اسأل:

ليه الـAlternative الحالية مش كفاية للSegment دي بالتحديد؟

لو مش قادر تجاوب بوضوح، بناء Tool أخرى قد لا يخلق سببًا كافيًا للتغيير.

الـCompetitor ممكن تكون Feature مش Company

تخيل عايز تبني Standalone Reporting SaaS.

Customer قد يكون عنده Reporting "كويسة بما يكفي" داخل CRM أصلًا.

Product بتاعتك إذًا تنافس Existing Feature Bundled في Software هو بالفعل بيدفع لها.

وده يغير Acquisition وPricing جدًا.

Competitive Research لازم تتبع Workflow، مش Category Names فقط.

اختبر Acquisition Path قبل اكتمال الـProduct

Products قوية تقنيًا كثيرة تفشل لأن Founders يكتشفوا Distribution بعد Development.

اسأل:

أول 20 Customer مناسبين هيسمعوا عن Product دي إزاي؟

مش أول مليون.

أول 20.

Paths محتملة:

• Existing Network.
• Direct Outbound.
• Search Demand.
• Communities.
• Partnerships.
• Existing Audience.
• Marketplace Distribution.
• Open-source Adoption.
• Content.
• Paid Acquisition.

مش محتاج Perfect Scalable Channel دلوقتي.

لكن محتاج Believable Way توصل بها للناس اللي عايز تتعلم منهم.

اختبر Distribution يدويًا

لو Planned Acquisition Channel هي Outbound، جرب تكلم Prospects قبل بناء Product.

لو Search، شوف الناس فعلًا بتبحث عن المشكلة ولا لأ وإيه اللي متوقعين يلاقوه.

لو Marketplace، افهم Listing Requirements والAlternatives الموجودة.

لو Audience، انشر حول المشكلة وشوف مين يتفاعل.

Distribution نفسها Assumption قابلة للاختبار.

اختبر الـPromise قبل الـInterface

Landing Page ممكن تكون مفيدة قبل وجود Complete Product.

لكن الجزء المهم مش Design.

هو الـPromise.

Early Landing Page قوية لازم توضح:

1. لمين؟
2. بتحل أنهي Painful Outcome؟
3. Approach مختلفة بما يكفي في إيه؟
4. Visitor يعمل إيه بعد كده؟

CTA ممكن تكون:

• Join Waitlist.
• Request Early Access.
• Book Discovery Call.
• Start Pilot.
• Submit Workflow for Evaluation.

الـCTA الصح تعتمد على مستوى Commitment اللي محتاج تختبره.

Waitlist مش Product-Market Fit

Email Addresses Evidence مفيدة للاهتمام.

لكن مش دليل إن الناس هتعمل Adoption أو تدفع أو تستمر.

كل ما Test تقرب من Real Behavior، Evidence تصبح أقوى.

Evidence Ladder تقريبية:

Page View → Email Signup → Conversation → Workflow/Data Shared → Pilot Commitment → Payment → Repeated Use → Renewal

كل Step تطلب من Customer شيء أغلى: Attention أو Time أو Access أو Money أو Behavior Change.

اختبر Willingness to Pay بحذر

Pricing Research صعبة لأن السؤال المباشر قد ينتج إجابات غير موثوقة.

بدل كده افهم Economics المشكلة.

Customer بيدفع إيه حاليًا؟

Employee Time قد إيه؟

إيه Revenue أو Delay أو Error أو Risk المتأثر؟

Alternatives بتكلف كام؟

مين يملك Budget؟

وبعدها اختبر Actual Offer لما يكون مناسب.

Pilot Proposal حقيقية تعلمك أكثر من سؤال Survey عن Hypothetical Price.

ما تبدأش Giant Pricing Page

Early Pricing Experiment.

محتاج Structure كفاية تختبر Business Model، مش 10 Plans وFeature Gates معقدة.

في B2B SaaS قد تحتاج أولًا تفهم هل Value تكبر مع:

• Users.
• Locations.
• Transactions.
• Usage.
• Data Volume.
• Revenue Managed.
• Workflow Volume.

اختار Pricing Unit Customer يفهمها ولها علاقة ما بالقيمة التي تخلقها.

وبعدين اتعلم.

حدد أخطر Assumption

دي من أهم التمارين.

اكتب Assumptions مثل:

• Customers عندهم المشكلة باستمرار.
• Buyer يقدر يوافق على Budget.
• هيوافقوا يربطوا CRM.
• AI تقدر تعمل Classification بدقة كافية.
• هيثقوا في Automation للAction دي.
• نقدر نجيب Customers من Search.
• هيدفعوا بما يكفي لتغطية Operating Cost.

وبعدها اسأل:

أنهي Assumption لو طلعت غلط تقتل الـBusiness أسرع؟

اختبرها بدري.

ما تصرفش 3 شهور تثبت إن Feature Technically Possible بينما أكبر Risk هل حد هيغير أصلًا.

الـMVP المفروض تختبر Assumption

MVP مش معناها:

ابنِ كل Feature بشكل ضعيف.

معناها بناء أصغر Product أو Process Credible تختبر Important Uncertainty.

لو Risk هي Demand، MVP قد تكون Landing Page وManual Service.

لو Risk هي Workflow Adoption، MVP قد تكون One End-to-End Workflow.

لو Risk هي AI Quality، MVP قد تكون Evaluation Pipeline قبل Customer-facing UI.

لو Risk هي Integration، MVP قد تكون One Production Connector.

Scope تتبع Uncertainty.

الـMVP ممكن يكون وراءها Manual Work

تخيل Future Product هتحلل Company Data تلقائيًا وتقترح Actions.

لأول Customers، جزء من Process ممكن يكون Manual طالما Customer Experience نفسها تختبر Core Value.

ده أحيانًا يسمى Concierge Approach.

الهدف تعرف هل Outcome مهمة قبل Automation لكل Internal Step.

ما تدعيش Capabilities غير موجودة أو تضلل Customers عن إيه Automated.

لكن كمان ما تبنيش Infrastructure لمجرد Automation لProcess لسه ما اتعمل لها Validation.

Version One تحتوي إيه فعلًا؟

سؤال مفيد:

إيه أصغر Complete Journey تنتج Promised Outcome؟

مش أقل عدد Screens.

Customer لازم يقدر يتحرك من Problem إلى Outcome.

مثلًا:

Connect Source → Import Leads → Qualify → Review → Send to CRM

ده ممكن يحتاج Authentication وIntegration واحدة وReview Screen وBackground Job.

لكن قد لا يحتاج:

• 10 Integrations.
• Native Mobile Apps.
• Advanced Analytics.
• Team Permissions لكل Enterprise Scenario.
• White Labeling.
• Public API.

دول ينتظروا لحد Evidence تطلبهم.

افصل Table Stakes عن Differentiation

Capabilities معينة ضرورية لعمل Product لكنها لا تثبت الفكرة.

Authentication مهمة.

Password Reset مهمة.

Billing مهمة لما تبدأ Charge Customers.

لكن صرف معظم First Build على Polish لـCommodity Infrastructure ممكن يؤخر Learning عن Unique Value.

استخدم Mature Frameworks وServices للCommodity Components حيث يناسب.

وحط Custom Engineering في Risky أو Differentiating Workflow.

ما تعملش Overbuild للArchitecture — لكن ما تبنيش Dead End برضه

"دي MVP بس" مش تصريح تتجاهل Basic Engineering.

ما زلت محتاج Reasonable Decisions حول:

• Data Ownership.
• Security.
• Backups.
• Deployment.
• Observability.
• Migrations.
• Core Domain Model.

لكن غالبًا مش محتاج Architecture لملايين Users قبل ما يكون عندك 10.

ابنِ للNext Credible Stage وخلي Boundaries نظيفة بما يكفي للتطور.

Multi-tenancy محتاجة قرار بدري

في SaaS، Tenant Separation تؤثر على Data Model وAuthorization وTesting.

مش لازم تعمل Most Sophisticated Multi-tenant Architecture من أول يوم.

لكن لازم تعرف إيه هو Tenant وإزاي Data معزولة قبل ما Customer Data تبدأ تتراكم.

ده أرخص كثيرًا من اكتشاف Boundary بعدين.

Billing لازم تتبع Business Model

ما تعملش Integration لكل Billing Scenario قبل ما تعرف Customers بتشتري إيه.

لكن لو Payment واحدة من Assumptions المطلوب اختبارها، ما تخبيهاش لآخر المشروع برضه.

Product Architecture لازم تدعم Pricing Experiment اللي فعلًا بتعملها.

AI SaaS عندها Validation Questions إضافية

لو Product تعتمد على AI، ضيف Risk Layer أخرى.

اسأل:

• هل Model تقدر تنفذ Task على Representative Real Data؟
• Failure Rate كام؟
• يحصل إيه لما تكون Uncertain؟
• هل Human لازم يراجع Result؟
• Inference Cost per Successful Task كام؟
• هل Data تحتاج Private Architecture؟
• هل Users هيثقوا في AI في Decision أو Action دي؟

ابنِ Evaluation Set بدري.

ما تعملش Validation لـAI Product بخمس Demos مبهرة.

قِس Outcome مش Demo Quality

Demo ممكن تخلي الناس تقول "واو".

Product محتاجة تخليهم يرجعوا.

حدد Success لأول Pilot معناها إيه.

أمثلة:

• Time to Complete Workflow.
• Number of Manual Handoffs Removed.
• Percentage of Cases Completed Without Intervention.
• Qualified Leads Produced.
• Errors Caught.
• Tasks Completed per Employee.

اختار Metrics مرتبطة بالمشكلة التي ادعيت إنك بتحلها.

Retention هي المكان اللي الحقيقة تظهر فيه أكثر

Acquisition تقول إن شخص اهتم بما يكفي يجرب.

Retention تقول هل Product تظل مهمة.

Retention Period المناسبة تعتمد على Workflow.

Daily Operations Tool وQuarterly Compliance Tool مش المفروض يكون عندهم نفس Usage Expectations.

اسأل:

Customer ناجح المفروض طبيعيًا يرجع إمتى؟

وبعدها قِس Behavior حول Cycle دي.

اتكلم مع اللي وقفوا استخدام Product

Early Founders طبيعي يقضوا وقت مع Happy Users.

Churned أو Inactive Users غالبًا عندهم Information أهم.

اسأل:

• كنت بتحاول تعمل إيه؟
• Workflow وقفت فين؟
• استخدمت إيه بدلها؟
• المشكلة كانت أقل أهمية من المتوقع؟
• Switching كان صعب؟
• Stakeholder آخر منع Adoption؟

ما تحولش Conversation لـSales Call.

أنت بتحقق في Failure Mode.

خليك واعي من Custom Development متنكرة في شكل SaaS

Early B2B Product قد تحتاج Configuration للعملاء.

ده طبيعي.

لكن لو كل New Customer يحتاج أسابيع Unique Code، ممكن تكون بتدير Software Consultancy بـShared Codebase أكثر من Scalable SaaS.

وده ممكن يظل Business ممتازة.

بس افهم Economics.

تابع Requirements هل هي:

• Configuration.
• Integration.
• Product Feature.
• Customer-specific Development.

الفرق يصبح مهم جدًا مع Scale.

اختبر Support وOnboarding Cost

Customer يدفع Subscription ممكن يظل Unprofitable لو Onboarding وSupport يستهلكوا Human Time كثير.

قِس:

• Time to Onboard.
• Number of Implementation Calls.
• Data Cleanup Required.
• Support Requests.
• Manual Operations فريقك ينفذها.

دي جزء من Product Economics.

Pre-development Checklist عملية

قبل الالتزام بـSubstantial Build، أنا أحب يكون فيه Evidence معقولة للأسئلة دي:

Problem

• مين عنده المشكلة؟
• بتحصل كل قد إيه؟
• بتكلفه إيه؟
• بيعمل إيه حاليًا؟

Buyer

• مين يستخدم Product؟
• مين يدفع؟
• مين يقدر يمنع Adoption؟

Urgency

• ليه يتغير دلوقتي؟

Competition

• إيه Software وNon-software Alternatives؟

Distribution

• هنوصل لأول Relevant Customers إزاي؟

Economics

• Product ممكن تخلق Value إيه؟
• Customers ممكن يدفعوا إيه؟
• Delivery تكلفنا إيه؟

Product

• إيه Smallest End-to-End Outcome؟

Technology

• إيه Technical Assumption فعلًا Risky؟

Evidence

• إيه اللي Potential Customers الحقيقيين عملوه فعلًا ويدعم Assumptions؟

مش محتاج Certainty.

محتاج Evidence كفاية تبرر Next Investment.

Sequence منطقية لكثير من SaaS Ideas

Progression عملية ممكن تكون:

Problem Interviews → Manual Research → Offer → Landing Page → Conversations → Prototype → Pilot → MVP → Paid Usage → Retention → Expansion

مش كل Product تمشي بنفس الترتيب بالضبط.

المبدأ إن Investment تزيد كل ما Evidence تزيد.

إمتى تبدأ Coding؟

Coding تبدأ لما Software تكون Cheapest Credible Way تجاوب بها على Next Important Question.

أحيانًا ده يكون بدري جدًا لأن Technical Feasibility نفسها أكبر Risk.

وأحيانًا تقدر تتعلم أسابيع بدون Production Code لأن Demand هي Uncertainty الأكبر.

Milestone الصح مش:

"خلصنا Validation، دلوقتي نبني."

Validation تستمر بعد Launch.

السؤال الأفضل:

إيه اللي محتاجين نتعلمه بعد كده، وإيه أرخص Reliable Experiment يعلمنا؟

إيه اللي أتجنب بناءه قبل أول Evidence حقيقية؟

إلا لو Use Case تتطلبه، هكون حذر من استثمار كبير في:

• Multiple Native Applications.
• Complex Enterprise Permissions.
• Large Integration Catalogs.
• Advanced Analytics.
• Multi-region Infrastructure.
• Sophisticated AI Orchestration.
• Large Admin Systems.
• Extensive Customization Engines.

كل Feature لازم تكسب مكانها في Roadmap من Real Requirement أو Tested Hypothesis.

شغل الـFounder قبل Development

قبل ما تطلب من Engineer يحول Idea لـCode، حول Idea لمجموعة Testable Statements.

مثلًا:

نعتقد إن Operations Managers في X type of company بيخسروا Y kind of value بسبب Z workflow.

نعتقد إنهم حاليًا بيحلوها باستخدام A وB.

نعتقد إننا نقدر نوصل لهم عن طريق C.

نعتقد إن Product تحقق D outcome هتبرر تغيير Current Process.

دلوقتي كل Statement قابلة للتحدي.

وده أفيد كثيرًا من Specification فيها 70 Feature.

عندك فكرة SaaS ومحتار تبني إيه الأول؟

هات Idea وTarget Customer والAssumptions الحالية.

نقدر نحدد Riskiest Assumptions، نصمم Smallest Useful Experiment، ونقرر هل Next Step Research أو Prototype أو MVP أو Production Development.

ناقش SaaS أو MVP بتاعتك مع فادى مندي.

أساعد Founders ينتقلوا من Idea إلى Evidence إلى Production — بدون صرف First Budget على Features لسه ما كسبتش حقها في الوجود.

---

مرتبط: MVP Development، SaaS Development، SaaS vs Custom Software، Product Engineering، Custom Software Development وAI ROI.