SaaS أم نظام مخصص؟ كيف تختار قبل ما تدفع تكلفة التطوير؟

شركة توصل لمرحلة إن Excel والـChat Messages والـTools المنفصلة ما بقوش كفاية.

هنا السؤال يظهر:

نشتري SaaS موجودة ولا نبني System خاصة بينا؟

ده مش Software Question فقط. ده سؤال Ownership وEconomics.

شراء SaaS يعطيك Product شخص آخر بالفعل بيشغلها ويطورها.

بناء Custom Software يعطيك Control على System أنت بعد كده مسؤول عن امتلاكها وتشغيلها.

ولا واحدة فيهم أفضل تلقائيًا.

السؤال المفيد:

أنهي أجزاء من تشغيل الشركة Commodity، وأنهي أجزاء مهمة بما يكفي إننا نمتلكها؟

ابدأ بالـWorkflow مش Feature List

عملية الشراء كثيرًا ما تبدأ بمقارنة مئات Features.

وده ممكن يخفي Requirement الحقيقية.

ارسم Workflow الأول:

Trigger → Data → Decision → Approval → Action → Record → Reporting

وبعدها حدد أنهي Steps Standard وأنهي فعلًا Specific لشركتك.

لو Process عندك تقريبًا مثل آلاف الشركات، Mature SaaS قد تكون بتحلها بالفعل بشكل ممتاز.

لو ميزتك تعتمد على Workflow المنتجات الموجودة باستمرار تجبرك تعمل لها Compromise، Custom Software تبدأ تبقى أكثر إثارة للاهتمام.

إمتى SaaS غالبًا تكون اختيار قوي؟

SaaS ممكن تكون اختيار ممتاز لما المشكلة Common ومفهومة كويس.

أمثلة تشمل Commodity Capabilities مثل Email وAccounting في الأسواق المدعومة وProject Management وIdentity وBasic CRM وSupport Ticketing وFile Collaboration — حسب Requirements شركتك.

SaaS جذابة خصوصًا لما:

• محتاج تطلق بسرعة.
• الـWorkflow أغلبها Standard.
• Configuration تغطي الاحتياجات المهمة.
• Existing Integrations كافية.
• الـCapability ليست Competitive Differentiator.
• لا تريد تشغيل Product إضافية داخليًا.

أنت فعليًا تشتري سنوات من Product Development وMaintenance وOperational Experience كSubscription.

أنت بتشتري إيه فعلًا مع SaaS؟

مش Features فقط.

Mature SaaS ممكن توفر:

• Hosting.
• Security Maintenance.
• Backups.
• Product Updates.
• Mobile Applications.
• APIs.
• Integrations.
• Support.
• Documentation.
• Reliability Work.

إعادة بناء كل ده فقط لتجنب Subscription ممكن تكون صفقة سيئة.

التكلفة المخفية للـSaaS: إنك تغير الشركة علشان تناسب الـProduct

Subscription Price مش هي التكلفة كلها.

SaaS ممكن تصبح غالية تشغيليًا لما الموظفين طول الوقت يعملوا Workarounds حولها.

مثلًا:

1. CRM لا تمثل Sales Process الحقيقية.
2. الموظفون يعملون Excel Sheet بجانبها.
3. Managers يطلبوا Reports يدوية.
4. Automation Tool أخرى تنسخ Data بين Systems.
5. Approvals المهمة تحصل في WhatsApp.

تقنيًا "عندك System"، لكن الـWorkflow الحقيقية عايشة خارجها.

Operational Friction دي لازم تدخل Cost Calculation.

إمتى Custom Software تصبح جذابة؟

Custom Software تستحق الفحص لما الـWorkflow نفسها لها Strategic Importance.

علامات مثل:

• Process عندك مختلفة فعلًا عن Standard Products.
• Systems متعددة تحتاج Orchestration Layer واحدة.
• Existing SaaS تحتاج Workarounds كثيرة.
• Permissions وApproval Logic خاصة.
• الشركة تملك Proprietary Data أو Business Logic.
• Customer Experience تعتمد على Capabilities Standard Software لا توفرها.
• Automation للـWorkflow قد تخلق Operational Leverage حقيقية.
• System ممكن تصبح Asset أو Product Capability، مش مجرد Internal Tool.

Custom Software تخلي System تتبع Business بدل ما Business تتبع Product.

لكن المرونة دي تأتي مع Ownership.

Ownership معناها إيه فعلًا؟

لما تبني Custom System، شخص أو فريق لازم يملك مسؤولية:

• Product Decisions.
• Architecture.
• Development.
• Testing.
• Security Updates.
• Infrastructure.
• Monitoring.
• Backups.
• Incident Response.
• Documentation.
• Future Changes.

وده ممكن يكون الاستثمار الصحيح.

لكن القرار لازم يعترف بالمسؤوليات دي من البداية.

"نبني مرة ونخلص" غالبًا Mental Model غلط للBusiness Software المهمة.

قارن Total Cost of Ownership مش Subscription مقابل Development Invoice

مقارنة ضعيفة تقول:

SaaS تكلف X شهريًا، وCustom Development تكلف Y مرة واحدة.

المقارنة الحقيقية أوسع.

SaaS TCO قد تشمل

• Subscription Fees.
• Per-user أو Usage-based Charges.
• Add-ons.
• Integration Tools.
• Implementation وConfiguration.
• Training.
• Data Migration.
• Manual Workarounds.
• Switching Cost بعدين.

Custom Software TCO قد تشمل

• Discovery وDesign.
• Development.
• Infrastructure.
• Maintenance.
• Monitoring.
• Security.
• Support.
• Ongoing Product Changes.
• Engineering Ownership.

قارن الاثنين على Time Horizon لها معنى بالنسبة لشركتك.

ما تفترضش إن Custom تصبح أرخص عند عدد Users معين

مفيش Universal Threshold.

Simple Internal Application لعدد كبير من الموظفين ممكن تكون رخيصة في التشغيل.

Highly Available أو Regulated أو Integration-heavy System لعدد Users قليل ممكن تكون غالية في البناء والصيانة.

User Count مجرد Variable واحدة.

Architecture وWorkflow Complexity أهم.

Integration ممكن تغير القرار بالكامل

الاختيار مش دائمًا:

Buy Everything OR Build Everything.

فيه Third Option قوية جدًا:

اشتري Commodity Systems وابنِ Business Layer اللي بينهم.

مثلًا:

WhatsApp → Custom Workflow → CRM → ERP → Payment Provider → Analytics

CRM تفضل SaaS.

Accounting تفضل SaaS.

Payments تفضل Managed Service.

لكن Unique Workflow والPermissions والOrchestration تعيش في Custom Application.

Hybrid Architecture دي كثيرًا ما تحافظ على مزايا Mature Products بدون التضحية بالWorkflow التي تميز Business.

ابنِ الـDifferentiator واشتري الـCommodity

دي من أكثر Heuristics المفيدة.

اسأل عن كل Component:

هل امتلاك الحاجة دي يخلق Strategic Value؟

غالبًا مش محتاج تبني Email Delivery Infrastructure بنفسك لمجرد إنك بتبني Custom Software.

وممكن ما تحتاجش Authentication Protocol أو Payment Processor أو Object Storage خاصة بك.

استخدم Mature Infrastructure لما Capability Commodity.

وحط Engineering Effort في المكان اللي Business فعلًا مختلفة فيه.

احسب تكلفة الخروج

SaaS ممكن تكون سهلة جدًا في البداية وصعبة في الخروج.

قبل Adoption عميق، اسأل:

• نقدر Export كل Data؟
• بأي Format؟
• Relationships وHistory هتفضل موجودة؟
• API تخرج Data اللي محتاجينها؟
• Integrations قابلة للنقل؟
• Attachments وAudit History يحصل لهم إيه؟
• قد إيه من Workflow هتعتمد على Provider-specific Behavior؟

Vendor Lock-in مش تلقائيًا حاجة سيئة.

كل Architecture تعمل Dependencies.

الهدف إنك تفهمها قبل ما تتحول لمفاجأة غالية.

Custom Software عندها Lock-in برضه

امتلاك Code مش معناه Freedom تلقائيًا.

ممكن تعتمد على:

• Developer واحد.
• Architecture بدون Documentation.
• Framework قديمة.
• Proprietary Infrastructure Choices.
• Automated Tests غير موجودة.
• Credentials شخص واحد فقط يتحكم فيها.

لو Ownership مهمة، صمم Actual Ownership:

• Code Repository تحت Control الشركة.
• Infrastructure Access.
• Documentation.
• Automated Deployment حيث يكون عمليًا.
• Backups.
• Dependency Visibility.
• Intellectual-property Terms واضحة.

Code Ownership بدون Operational Ownership ناقصة.

Security: Managed مش معناها Safe تلقائيًا وCustom مش معناها Unsafe تلقائيًا

مع SaaS، Provider تتعامل مع جزء كبير من Platform Security، لكن شركتك تظل مسؤولة عن Configuration وAccess Control وUser Lifecycle وطريقة استخدام البيانات.

مع Custom Software، مسؤوليتك أوسع لأن فريقك يملك جزءًا أكبر من Stack.

قيّم Requirements الفعلية:

• Authentication.
• Authorization.
• Audit Logs.
• Encryption.
• Tenant Isolation.
• Backups.
• Data Retention.
• Incident Handling.
• Compliance أو Contractual Constraints عند الحاجة.

اختار بناءً على System تستطيع تشغيلها بمسؤولية، مش Generic Security Label.

Data Ownership تستحق نقاش منفصل

اسأل Operational Data بتاعتك فين ومين يتحكم فيها.

أسئلة مهمة:

• نقدر نأخذ Complete Copy؟
• نقدر نحذف Data عند الحاجة؟
• Systems بتاعتنا تقدر توصل لها Programmatically؟
• Source of Truth فين؟
• هل بنكرر Sensitive Information عبر Integrations؟

وده مهم سواء Buy أو Build.

SaaS يمكن تخصيصها — لكن اعرف الـBoundary

SaaS Products كثيرة توفر Custom Fields وWorkflows وPlugins وAPIs وAutomation.

وده ممكن يطول عمرها المفيد جدًا.

السؤال هل أنت بتعمل Configuration للProduct ولا بتحاربها؟

لو كل Release تعتمد على Workarounds أكثر هشاشة، المؤسسة قد تكون عدت النقطة اللي Configuration أرخص من Ownership.

قِس Ongoing Friction بدل مناقشتها فلسفيًا.

Custom Software ما تبدأش Giant ERP Replacement

بعد قرار Build، يظهر خطأ آخر:

"يلا نعيد بناء كل حاجة."

وده يرفع Risk جدًا.

ابدأ بالWorkflow التي تعمل أكبر Measurable Friction.

مثلًا:

Lead → Qualification → Proposal → Approval

أو:

Request → Assignment → Execution → Completion

اربط Existing Systems حولها.

اثبت Operating Improvement.

وبعدها وسع.

والـLow-code وNo-code؟

دي Options إضافية، مش أعداء Custom Development.

Workflow Tool قد تكون ممتازة لما:

• Process بسيطة نسبيًا.
• Integrations موجودة بالفعل.
• Scale وPermissions قابلين للإدارة.
• Workflow ما زالت في مرحلة Validation.

لو Complexity كبرت، تقدر بعدين تنقل الأجزاء التي تحتاج Control أقوى إلى Custom Software.

Architecture لازم تناسب Stage الـBusiness.

والـAI؟

AI لا تغير Buy-vs-Build Fundamentals.

تقدر تشتري AI SaaS Product.

تقدر Integrate AI API داخل Existing Systems.

تقدر تبني Custom AI Workflow.

وتقدر Self-host أجزاء من AI Stack لما Requirements تبرر ده.

نفس السؤال يظل:

أنهي Capability تخلق قيمة تكفي إننا نمتلكها؟

مثلًا Generic Meeting Summarizer قد تكون Commodity SaaS Purchase.

لكن AI Workflow تفهم Proprietary Operational Process وتعمل Retrieval من Internal Knowledge وتنفذ Controlled Actions عبر Systems قد تبرر Custom Layer.

مثال: Sales Operation

تخيل Leads تدخل من Website وWhatsApp وCampaigns.

الشركة تستخدم CRM لكن Qualification والApprovals تحصل خارجها.

Option A: Configure CRM

أفضل لو Workflow Engine في CRM تستطيع تمثيل Process بشكل كافٍ.

Option B: Add Automation

أفضل لو CRM كويسة لكن Systems تحتاج تبادل المعلومات تلقائيًا.

Option C: Custom Workflow Layer

أفضل لو Qualification أو Routing أو Pricing أو Approval Logic مختلفة بما يكفي ومهمة.

Option D: Replace CRM

فقط تستحق التفكير لو CRM نفسها أصبحت Wrong System، مش لمجرد Workflow واحدة غير مريحة.

اختبر Smallest Effective Intervention أولًا.

مثال: Operations Platform

تخيل Service Business تنسق Jobs باستخدام Excel وWhatsApp وAccounting Software.

ممكن ما تحتاجش Complete Custom ERP.

Custom Operations Layer قد تملك:

• Requests.
• Assignment.
• Status.
• Approval.
• Customer Communication.
• Operational Reporting.

بينما Accounting تظل في Existing Financial System.

ده ممكن يقلل Scope جدًا.

Decision Scorecard عملية

قيّم الاختيارين بنفس الأسئلة.

Workflow Fit

هل System تمثل طريقة عمل الشركة طبيعيًا؟

Speed

قد إيه الشركة تقدر توصل لـUsable Production State؟

Integration

هل تستطيع الربط بثبات مع Systems المهمة؟

Ownership

أنهي Capabilities وData وRoadmap Decisions تحتاج تتحكم فيها؟

Operations

مين هيصون ويدعم System؟

Security

هل Architecture تحقق Access وData Requirements الحقيقية؟

Economics

إيه Total Cost خلال الفترة المهمة لك؟

Exit

قد إيه Migration صعبة لو القرار اتغير؟

ما تحطش Arbitrary Weights قبل فهم أي Factors فعلًا مهمة للBusiness.

أسئلة قبل شراء SaaS

1. أنهي أجزاء من Workflow تحتاج Workarounds؟
2. أنهي Integrations Native وأنهي تحتاج Tool إضافية؟
3. هل نقدر Export كل Important Data؟
4. إيه اللي يحصل مع نمو Users أو Usage؟
5. أنهي Capabilities تحتاج Higher Plans أو Add-ons؟
6. Permissions وAudit History بيتداروا إزاي؟
7. إيه Exit Path بتاعتنا؟

أسئلة قبل بناء Custom Software

1. إيه Measurable Problem اللي بنحلها؟
2. ليه Configuration أو Integration مش كفاية؟
3. Version One المفروض تملك أنهي Workflow؟
4. أنهي Existing Systems المفروض تفضل؟
5. مين يملك Product Decisions بعد Launch؟
6. مين يشغل ويصون System؟
7. إيه Smallest Production Scope تقدر تثبت Business Case؟

لو الأسئلة دي مش لها إجابات واضحة، Project غالبًا مش جاهزة لـLarge Build.

القرار ممكن يتغير مع الوقت

Startup ممكن تبدأ بـSaaS لأن Speed أهم من Customization.

بعدين Volume وProcess Maturity قد تبرر Custom Layer.

Large Company ممكن تتحرك في الاتجاه العكسي وتستبدل Internal Commodity Systems غالية بـSaaS.

Architecture لازم تتبع Business Stage.

مفيش جائزة لامتلاك Code أكثر.

قاعدة بسيطة تفتكرها

اشتري اللي Standard. اربط اللي شغال. وابنِ اللي يميز شركتك.

وبعدها راجع القرار لما Economics أو Requirements تتغير.

ده أكثر فائدة من التعامل مع SaaS وCustom Development كأنهم معسكرين متعارضين.

محتار بين SaaS وCustom Software؟

ارسم Real Workflow واحدة قبل ما تطلب Development Estimates أو توقع Long Software Contract.

حدد إيه Standard وإيه Unique، Data موجودة فين، أنهي Integrations مهمة، وإيه Ownership اللي هتخلق Value.

بعدها قارن SaaS وIntegration وAutomation وCustom Development على نفس Business Case.

ناقش Software Architecture مع فادى مندي.

أساعد الشركات تقرر إيه اللي تشتريه، إيه اللي تربطه، وإيه اللي يستحق البناء — وبعدها أصمم وأنفذ الـCustom Layer عندما Ownership تخلق قيمة حقيقية.

---

مرتبط: Custom Software Development، SaaS Development، من Excel وWhatsApp إلى نظام متكامل، Digital Transformation، AI Integration، AI Automation وAI ROI.