سایت‌ساز برای کسب‌وکار بزرگ؛ انتخاب پلتفرم با TCO و برنامه خروج

یک شرکت بزرگ می‌تواند روی سایت‌ساز، WordPress، CMS سازمانی، معماری Headless یا کد سفارشی هم تصمیم خوبی بگیرد و هم تصمیم بد. اندازه شرکت پاسخ را تعیین نمی‌کند؛ Criticality سفر کاربر، پیچیدگی Integration، حساسیت داده، سرعت تغییر، توان تیم و هزینه خروج تعیین می‌کنند. سایت کمپین سه‌هفته‌ای و Portal سفارش‌گذاری نمایندگان، حتی زیر نام یک شرکت، مسئله‌های یکسانی نیستند.

پاسخ کوتاه این راهنما این است: سایت‌ساز SaaS را نه به‌خاطر Drag-and-drop رد کنید و نه به‌خاطر Launch سریع بخرید. Requirementها را به سناریو و معیار پذیرش تبدیل کنید، دو یا سه گزینه را با Proof of Concept روی سخت‌ترین Flow بیازمایید، TCO سه‌ساله و Exit را قیمت‌گذاری کنید و سپس کوچک‌ترین معماری‌ای را برگزینید که Risk قابل‌قبول را پوشش می‌دهد.

دامنه و تاریخ: این چارچوب در ۱۸ مرداد ۱۴۰۵ (۹ اوت ۲۰۲۶) بازبینی شده و Vendor-neutral است. قابلیت، قیمت، کشور قابل ارائه، SLA و شرایط Export هر فروشنده تغییر می‌کند؛ ادعای Sales deck را فقط پس از بررسی Contract، Documentation و آزمون حساب/Plan واقعی بپذیرید.

سایت‌ساز دقیقاً چیست؟ مرزها را پیش از مقایسه روشن کنید

«سایت‌ساز» یک دسته همگن نیست. یک Landing-page builder بسته، SaaS CMS چندسایتی، فروشگاه‌ساز Managed، Low‑Code application platform و Visual front-end متصل به Headless CMS می‌توانند همگی همین برچسب را بگیرند، اما مدل داده، Runtime، API، Governance و قابلیت خروج متفاوتی دارند.

در تعریف NIST از SaaS، مصرف‌کننده زیرساخت پایه را مدیریت نمی‌کند، اما می‌تواند برخی تنظیمات مخصوص برنامه را کنترل کند. همین مرز نکته اصلی است: واگذاری عملیات Platform، مسئولیت شما برای هویت، پیکربندی، داده، Integration، محتوای منتشرشده و تداوم کسب‌وکار را حذف نمی‌کند.

اگر مسئله شما فراتر از وب‌سایت و شامل Workflow و Application داخلی است، راهنمای انتخاب No‑Code و Low‑Code بر پایه TCO و Exit مرز دقیق‌تری می‌دهد.

واحد تصمیم «شرکت» نیست؛ Journey و Blast radius است

یک RFP کلی برای «پلتفرم وب شرکت» معمولاً نیازها را مخلوط می‌کند و سنگین‌ترین معماری را به همه صفحات تحمیل می‌کند. Inventory را به Property و Journey بشکنید: سایت شرکتی، Newsroom، Careers، Investor relations، Product catalog، فروشگاه، Portal نماینده، پشتیبانی، Documentation، Campaign و Event.

برای هر Property دو عدد تعیین کنید: Impact در صورت شکست و Difficulty of reversal. خرابی صفحه خبر شاید قابل تحمل باشد، اما انتشار اشتباه گزارش مالی، نشت فرم استخدام یا قیمت‌گذاری غلط ریسک دیگری دارد. هرچه Impact و برگشت‌ناپذیری بالاتر است، شواهد، کنترل و Contract باید سخت‌تر شود؛ نه اینکه صرفاً عبارت «Enterprise» به نام محصول اضافه شود.

Decision brief: پیش از دیدن Demo چه بنویسیم؟

Demo با سناریوی خوش‌مسیر فروشنده شروع می‌شود؛ Decision brief باید با دشوارترین سناریوی شما شروع شود. یک سند دوصفحه‌ای کافی است:

1. Outcome: کدام نتیجه تجاری/خدمت عمومی باید بهتر شود و Baseline چیست؟
2. Users: کاربر نهایی، Editor، Reviewer، مترجم، Developer، Support و Auditor چه Jobی دارند؟
3. Critical journeys: سه تا پنج Flow که شکستشان بیشترین اثر دارد.
4. Non-functional requirements: Availability، Latency، Accessibility، Security، Privacy، SEO، Scale و Recovery.
5. Constraints: کشور، زبان، RTL، بودجه، Deadline، Procurement، Skill و سیستم‌های Legacy.
6. Decision horizon: عمر مورد انتظار، تغییرات محتمل و هزینه برگشت.
7. Evidence: کدام ادعا با Doc، Contract، PoC، Reference call یا Test اثبات می‌شود؟
8. Owner: چه کسی تصمیم، Risk acceptance و عملیات پس از Launch را مالک است؟

هدف را «خرید CMS» ننویسید. مثلاً بنویسید: «کاهش Median زمان انتشار صفحه فارسی/انگلیسی از چهار روز به هشت ساعت، بدون افزایش خطای حقوقی، با Rollback زیر ۱۵ دقیقه.» این Outcome اجازه می‌دهد Platform، Process و Team را با هم بسنجید.

Capability map بسازید؛ Feature checklist کافی نیست

تیک‌زدن «SSO دارد»، «API دارد» یا «چندزبانه است» درباره کیفیت اجرا چیزی نمی‌گوید. هر قابلیت را به Scenario، Scope Plan، محدودیت و معیار پذیرش تبدیل کنید.

ده Gate برای انتخاب سایت‌ساز سازمانی

۱. مدل محتوا و عملیات Editorial

Drag-and-drop برای Editor خوب است، اما صفحه‌محور بودن می‌تواند Reuse، Governance و مهاجرت را سخت کند. بررسی کنید Content به‌صورت Structured type قابل مدل است یا در Blockهای Presentation قفل می‌شود؛ Reference، Validation، Taxonomy، Localization، Scheduled publish، Revision، Diff، Rollback، Preview و Bulk operation چگونه کار می‌کنند.

ده Editor هم‌زمان، هزاران Page و چند Brand فقط مسئله UI نیست. حق ویرایش Field یا Locale، جداسازی Draft/Publish، Approval چندمرحله‌ای، Content expiry، Legal hold، مالک Content و Audit trail را با کار واقعی بیازمایید. «Unlimited editor» در Pricing تضمین Workflow مناسب نیست.

۲. Integration و API به‌عنوان Contract

وجود REST یا GraphQL کافی نیست. Authentication، Authorization سطح Object/Field، Rate limit، Pagination، Filter، Bulk، Webhook signature، Retry، Ordering، Idempotency، Versioning، Sandbox و Deprecation policy را بخوانید. محدودیت API را با پیک هم‌زمان و Backfill بسنجید، نه میانگین روزانه.

برای هر Integration جدول System of record بسازید: کدام سیستم مالک Customer، Product، Price، Inventory، Consent و Order است؟ Sync یک‌طرفه/دوطرفه، Conflict resolution، Latency هدف، Dead-letter، Reconciliation و Manual recovery را مشخص کنید. راهنمای امنیت API، OAuth، JWT و Webhook معیار فنی عمیق‌تر را پوشش می‌دهد.

۳. Performance و Scale با SLO، نه شهرت Vendor

«Cloud است، پس مقیاس‌پذیر است» و «Builder است، پس کند است» هر دو استدلال ناقص‌اند. Runtime ممکن است CDN جهانی، Cache و Auto-scaling خوبی داشته باشد، اما Template، App، Tag، Image و API شما گلوگاه بسازند. از فروشنده Architecture و Limit بخواهید و از تیم خود Performance budget.

• پیک هم‌زمان، Request rate، حجم Media، تعداد Page/SKU/Locale و نرخ Publish را مدل کنید.
• Cold cache، Cache invalidation، Origin/API failure و Traffic spike را تست کنید.
• LCP/INP/CLS و Task completion را با Device و شبکه هدف بسنجید؛ Score تک‌مرحله‌ای کافی نیست.
• Quota و Rate limit، Overage، Throttling و رفتار Graceful degradation را قراردادی کنید.
• SLO سرویس خودتان را از SLA فروشنده جدا کنید؛ SLA ممکن است فقط بخش محدودی را پوشش دهد.

۴. Reliability، Backup و Disaster Recovery

Uptime درصدی بدون تعریف Service، Region، Maintenance و Remedy مبهم است. Availability هدف را از Business impact analysis بگیرید و RTO/RPO را برای Content، Media، Form submission، Order و Configuration جدا کنید. Backup فروشنده با Recovery شما یکی نیست.

نسخه‌ای از Content، Asset، Domain/DNS، Integration config و Secret inventory را طبق Scope مجاز خارج از Platform نگه دارید. Restore drill اجرا کنید: آیا فقط Page برمی‌گردد یا URL، Metadata، Version و رابطه‌ها هم؟ برای Outage Vendor، اختلال DNS، Publish اشتباه، حذف Admin و فساد Integration Runbook داشته باشید.

۵. امنیت و مدل مسئولیت مشترک

زیرساخت Managed می‌تواند Patch و DDoS defense را بهتر از تیم کم‌ظرفیت انجام دهد، اما Misconfiguration، Account takeover، دامنه، App ثالث، Script، API token و انتشار داده همچنان در Scope شماست. OWASP ASVS 5.0 را به Requirementهای مرتبط Procurement و آزمون فنی تبدیل کنید؛ داشتن Logo گواهی جای Scope و Evidence را نمی‌گیرد.

حداقل این موارد را بسنجید: SSO استاندارد، MFA/Passkey، SCIM/Offboarding، Role و Separation of duties، Audit export، Secret rotation، Encryption و Key scope، Vulnerability disclosure، Patch SLA، Pentest summary، Subprocessor، Incident notification، Data deletion و Tenant isolation. راهنمای NIST برای ریسک زنجیره تأمین سایبری توصیه می‌کند Requirementهای تأمین‌کننده را با Outcomeهای سازمان تعریف و ارتباط دهید.

برای Threat map حساب، Domain، App marketplace، JavaScript و پاسخ به رخداد، چک‌لیست امنیت سایت‌ساز SaaS را اجرا کنید.

۶. Privacy، Data residency و Compliance

نام مقررات را به‌عنوان Checkbox نپذیرید. Data inventory و Flow بسازید: چه داده‌ای، برای چه هدفی، از کدام کشور/کاربر، در کدام Region و Subprocessor، با چه Retention و دسترسی‌ای پردازش می‌شود؟ Controller/Processor، DPA، Transfer، Consent، Cookie، DSAR، Legal hold، Deletion و Breach notification را با متخصص حوزه قضایی خود تعیین کنید.

PCI، سلامت، مالی، استخدام یا داده کودک Scope تخصصی دارند. «Vendor compliant است» به معنای compliant شدن Implementation شما نیست. اگر Platform Field حساس را در Log، Notification یا Integration منتقل می‌کند، Scope ممکن است بزرگ‌تر شود. Data minimization و Tokenization را پیش از ابزارهای بیشتر بررسی کنید.

۷. SEO، Rendering و URL lifecycle

SEO سایت‌ساز را با برچسب خوب/بد ارزیابی نکنید. امکان Title/Meta، Heading، Alt، Status code، Canonical، noindex، Redirect، Sitemap، hreflang، Structured data، Pagination، Facet، Internal link و Log/Analytics را روی Template و Scale واقعی آزمایش کنید.

اگر Content با JavaScript ساخته می‌شود، HTML اولیه و Rendered را مقایسه کنید. راهنمای JavaScript SEO گوگل فرایند Crawl، Render و Index و اهمیت URL، Status و لینک قابل‌خزش را توضیح می‌دهد. این سند تضمین ایندکس نیست؛ Test با URL Inspection، Crawl و Log لازم است.

مهاجرت آینده را از امروز مدل کنید: Stable ID، URL inventory، Redirect mapping، Media URL، Canonical/hreflang، Metadata، تاریخ انتشار، Author و Internal link باید Export یا بازسازی‌پذیر باشند. Export فقط متن Body، Exit SEO نیست.

۸. دسترس‌پذیری و طراحی چندزبانه/RTL

Template آماده ممکن است شروع خوبی باشد، اما Component سفارشی، App، Form، Cookie banner و محتوای Editor می‌توانند Accessibility را بشکنند. WCAG 2.2 معیارهای آزمون‌پذیر و Technology-neutral دارد؛ ادعای Compliance فروشنده را روی Page کامل و Stateهای واقعی بررسی کنید.

Keyboard، Focus، Name/Role/Value، Error، Status message، Zoom/Reflow، Contrast، Target size، Reduced motion، Caption/Transcript و Screen reader را دستی بیازمایید. برای فارسی، Direction در Component تو‌در‌تو، اعداد/تاریخ/تومان، Line breaking، Font fallback، Search و فرم دوزبانه را تست کنید. راهنمای طراحی فراگیر و WCAG برای وب فارسی Definition of Done کامل‌تری می‌دهد.

۹. Domain، Email و دارایی‌های بیرون از Platform

دامنه را در Registrar سازمان و تحت دسترسی کنترل‌شده نگه دارید؛ آن را به حساب شخصی آژانس یا Employee گره نزنید. DNS، Certificate، Email authentication، Analytics، Tag manager، Search Console، DAM و Repository باید Owner و Recovery مستقل داشته باشند. Exit وقتی ممکن است که Control plane اصلی نزد سازمان بماند.

TTL، DNSSEC/DS، CAA، Cutover و Rollback را پیش از Migration تمرین کنید. راهنمای مدیریت و مهاجرت امن DNS دامنه Runbook فنی این بخش است.

۱۰. پشتیبانی، Roadmap و سلامت Vendor

Support «۲۴/۷» را با Severity، Response، Time to engage، زبان/Timezone، کانال، Escalation، Named contact و Resolution target باز کنید. در Trial یک Ticket فنی واقعی بفرستید. Status history، Incident postmortem نمونه، Maintenance policy و اطلاع Deprecation را ببینید.

Roadmap قول قراردادی نیست. قابلیت Mission-critical باید اکنون وجود داشته یا Gap آن با Cost/Risk پذیرفته شود. تغییر مالکیت، افزایش قیمت، End-of-life App، حذف API و خروج Vendor را در Scenario register بگذارید. Escrow در SaaS همیشه عملی یا کافی نیست؛ Data/Config export و Alternative route اهمیت بیشتری دارد.

RFP خوب از سؤال‌های قابل اثبات ساخته می‌شود

راهنمای Secure by Demand سازمان CISA نیز Procurement را محل مطالبه امنیت و سؤال‌کردن از روش توسعه، پیش‌فرض‌ها و پاسخ به آسیب‌پذیری می‌داند. سؤال‌ها را با Context خود تطبیق دهید و پاسخ Sales را به Contract/Evidence متصل کنید.

Proof of Concept را روی Happy path اجرا نکنید

PoC باید پرریسک‌ترین فرضیه را ارزان و سریع باطل کند. Homepage زیبا چیزی را درباره Workflow، Migration یا Failure نشان نمی‌دهد. یک Vertical slice واقعی انتخاب کنید: Content type پیچیده، دو Locale از جمله فارسی RTL، Approval، Integration، Search، Form، Analytics، Accessibility، Load و Export.

1. Success criteria را پیش از شروع بنویسید: زمان انجام Task، Error، Latency، Export fidelity و Recovery.
2. از داده مصنوعی اما واقع‌نما استفاده کنید: حجم، Relation، Media و Edge case نزدیک Production.
3. Roleهای واقعی را وارد کنید: Editor، Translator، Legal reviewer، Developer، Security و Support.
4. Failure injection محدود انجام دهید: API کند، Webhook تکراری، Publish اشتباه، App قطع و Cache stale.
5. Exit test را در همان PoC اجرا کنید: داده را خارج و در یک مخزن/Renderer موقت بازسازی کنید.
6. Gap register بسازید: Configuration، Extension، Process workaround، Vendor roadmap یا Unresolved.

PoC موفق به معنی «همه چیز شدنی است» نیست؛ نشان می‌دهد Requirementهای منتخب با Effort و Risk مشاهده‌شده شدنی‌اند. هزینه Workaroundها را وارد TCO کنید.

Scorecard وزنی، اما بدون دقت کاذب

وزن‌ها را قبل از Demo با Business owner، Product، Content، IT، Security، Legal/Privacy، SEO/Analytics و Operations تعیین کنید. ابتدا Gateهای Pass/Fail را جدا کنید؛ امتیاز بالا نباید فقدان Data export یا Eligibility قانونی را جبران کند.

این وزن‌ها نسخه عمومی نیستند. برای Investor site، Workflow و Governance محتوا مهم‌تر؛ برای فروشگاه، Revenue flow و Integration؛ و برای پورتال، Identity/Authorization و Audit حیاتی‌تر است. امتیاز ۳٫۸۷ از ۵ دقت واقعی ایجاد نمی‌کند؛ Assumption، Confidence و Deal-breaker را کنار امتیاز ثبت کنید.

TCO سه‌ساله: Subscription فقط یک ردیف است

Managed platform می‌تواند هزینه Patch/Hosting را کاهش دهد، اما License، Usage و Vendor skill اضافه کند. Custom می‌تواند License را کم کند، اما Build، On-call و Upgrade را به شما منتقل می‌کند. مقایسه درست باید Scope و Service level یکسان داشته باشد.

TCO₃₆ = Acquisition + Implementation + Migration + Integration + License/Usage + People + Operations + Security/Compliance + Change + Downtime risk + Exit − Residual value

سه سناریو Base/High growth/Exit early بسازید. هزینه ارزی را با نرخ، تورم، Billing cycle و Buffer سناریویی مدل کنید. چارچوب ROI و Business case طراحی سایت کمک می‌کند TCO را با Contribution و منفعت افزایشی مقایسه کنید؛ و راهنمای کاهش هزینه طراحی سایت نشان می‌دهد Scope کوچک چگونه بدون حذف استاندارد پایه هزینه را کم می‌کند.

Vendor lock-in را صفر نمی‌کنید؛ قابل‌اندازه‌گیری می‌کنید

Custom نیز Lock-in دارد: Framework، Cloud، آژانس، دانش فردی و Data model. هدف، صفرکردن وابستگی نیست؛ شناخت Coupling، کاهش Blast radius و حفظ گزینه خروج است. مستند NIST درباره Cloud نیز Portability را وابسته به Interface و Format استاندارد و Vendor-specific بودن بعضی Resource definitionها می‌داند.

Exit package حداقلی

• Content ساخت‌یافته با Stable ID، Relation، Locale، تاریخ و وضعیت انتشار
• Media اصل، Variant، Alt، Credit، License و Mapping استفاده
• URL inventory، Redirect، Canonical، hreflang، Metadata و Internal link graph
• Form definition و داده مجاز، Consent evidence و Retention state
• User/Role map، Audit موردنیاز و فهرست Integration/Secret بدون افشای Secret در Export
• Design token، Component contract، Template behavior و Content rule
• Domain/DNS/TLS/Email ownership و Runbook Cutover/Rollback
• تعهد حذف داده Vendor و Subprocessor پس از Termination

Export را فقط تحویل نگیرید؛ Parse، شمارش، Hash، Link و Media را Validation کنید و نمونه را در مقصد موقت Restore کنید. برای Property حیاتی، این Drill را دوره‌ای تکرار کنید تا API و Schema بی‌خبر تغییر نکرده باشند.

داده و Analytics را از Migration جا نگذارید

تعویض Platform می‌تواند Client ID، Consent state، Checkout event، Referral، Attribution و تعریف Conversion را بشکند. Measurement plan را قبل از Cutover Freeze کنید: Event contract، Parameter، Identity، Currency/Timezone، UTM، Cross-domain، Consent، Server/client source و Reconciliation.

Baseline قبل، Annotation زمان Launch، Parallel QA و Guardrail پس از آن لازم است. افت Session ممکن است اصلاح Consent یا Bot filter باشد؛ رشد Conversion ممکن است Duplicate event باشد. راهنمای تحلیل داده بازاریابی و ساخت Source of truth برای آشتی‌دادن Analytics با CRM/Order مناسب است.

شرایط ایران: Availability فروشنده یک Requirement است

برای سازمان ایرانی، فقط RTL و درگاه مهم نیست. پیش از قرارداد بررسی کنید شخص/نهاد و کشور استفاده طبق Terms و قوانین جاری واجد شرایط‌اند؛ Billing، Payment، Support، Region، Subprocessor و Export عملاً در دسترس‌اند. از هویت، نشانی، حساب یا واسطه صوری برای دورزدن محدودیت استفاده نکنید. اگر Eligibility روشن نیست، گزینه مجاز دیگر یا نظر حقوقی معتبر لازم است.

اگر بازار هدف خارج ایران است، Location و Device همان بازار را هم جدا بسنجید. CDN جهانی خوب الزاماً Route داخل ایران را بهبود نمی‌دهد و Hosting داخلی نیز الزاماً تجربه خارج را خوب نمی‌کند. تصمیم باید با Field data هر Segment گرفته شود.

Architecture decision record: چرا این گزینه انتخاب شد؟

نتیجه را در ADR ثبت کنید تا شش ماه بعد «چرا این محدودیت را پذیرفتیم؟» پاسخ داشته باشد:

• Context و Property/Journeyهای داخل و خارج Scope
• Requirement، SLO و Gateهای غیرقابل‌مذاکره
• گزینه‌های بررسی‌شده و Evidence هرکدام
• تصمیم و Trade-offهای پذیرفته‌شده
• Risk، Mitigation، Owner و Review date
• TCO سناریویی و Assumptionهای اصلی
• Exit trigger و Exit package
• شرایط بازکردن دوباره تصمیم: رشد، مقررات، Incident، Price یا Product change

برنامه ۳۰روزه انتخاب پلتفرم

1. روز ۱ تا ۵: Property/Journey inventory، Impact، Users، Baseline، Constraint و Owner را ثبت کنید.
2. روز ۶ تا ۱۰: Requirementها را به Scenario و معیار پذیرش، Gate و Weight تبدیل کنید؛ Data flow و Integration map بسازید.
3. روز ۱۱ تا ۱۴: سه گزینه معماری و Shortlist محدود بسازید؛ Documentation، Contract، Limit و Country eligibility را بخوانید.
4. روز ۱۵ تا ۲۱: PoC Vertical slice با فارسی/RTL، Workflow، Integration، SEO، Accessibility، Load/Failure و Export اجرا کنید.
5. روز ۲۲ تا ۲۵: Security/Privacy/Supplier review، Support ticket و Incident tabletop را تکمیل کنید.
6. روز ۲۶ تا ۲۸: TCO36 و سناریوی رشد/FX/Exit را بسازید؛ Gap و Workaround را قیمت‌گذاری کنید.
7. روز ۲۹ تا ۳۰: Scorecard، Confidence، ADR، Contract redline، Pilot scope و Kill/Scale gate را تصویب کنید.

چک‌لیست نهایی

• Property و Journeyها به‌جای برچسب کلی «سایت شرکت بزرگ» تفکیک شده‌اند.
• Outcome، Baseline، Criticality، RTO/RPO و SLO مشخص‌اند.
• Requirementها Scenario، Owner، Evidence و معیار پذیرش دارند.
• Gateهای Legal/Eligibility، Data، Security و Export از Score وزنی جدا هستند.
• Content model، Workflow، Locale/RTL و Bulk operation با داده واقعی تست شده‌اند.
• API/Webhook، Limit، Failure، Retry، Idempotency و Reconciliation بررسی شده‌اند.
• Performance/Scale در Peak و Failure و روی شبکه/Device هدف آزموده شده‌اند.
• SSO/SCIM/Role/Audit، App/Script، Incident و Shared responsibility روشن‌اند.
• Data flow، DPA، Region/Subprocessor، Retention و Deletion بازبینی شده‌اند.
• SEO، URL lifecycle، Rendered HTML، Redirect و Migration test پاس شده‌اند.
• WCAG، Keyboard، Screen reader، فارسی/RTL و Stateها تست دستی شده‌اند.
• Domain، DNS، Analytics و حساب‌های اصلی مالکیت سازمانی و Recovery دارند.
• SLA/Support با Severity، Escalation، Scope و Remedy قراردادی است.
• TCO36 شامل Usage، People، Operations، FX، Risk و Exit است.
• Export واقعی Parse/Validate/Restore و Data deletion پس از Exit تعریف شده است.
• ADR، Risk owner، Review trigger و Pilot Kill/Scale gate تصویب شده‌اند.

اشتباه‌های رایج

• رد یا انتخاب پلتفرم فقط با برچسب «سایت‌ساز» یا «Enterprise».
• فرض اینکه شرکت بزرگ حتماً توسعه سفارشی می‌خواهد.
• فرض اینکه SaaS ذاتاً مقیاس‌پذیر، امن، سریع یا بدون نگهداری است.
• مقایسه Subscription SaaS با هزینه Build اولیه Custom و حذف Operations/Exit.
• PoC روی Homepage و Happy path به‌جای Workflow، Failure و Export.
• قبول «API/SEO/Compliance دارد» بدون Scope، Limit و Test.
• دادن دامنه، Analytics یا Owner account به شخص/آژانس بیرونی.
• ساخت یک DXP پیچیده برای Property ساده یا Builder ساده برای Flow بحرانی.
• تکیه بر Roadmap برای Requirement حیاتی.
• برنامه‌ریزی مهاجرت پس از اعلام افزایش قیمت یا توقف سرویس.

سؤالات متداول

آیا سایت‌ساز برای کسب‌وکار بزرگ مناسب است؟

ممکن است مناسب باشد، حتی برای Property عمومی مهم، اگر Workflow، Scale، Security، Integration، SEO، Accessibility، SLA و Exit لازم را با Evidence پاس کند. برای Flow بسیار سفارشی یا داده حساس ممکن است Hybrid، CMS دیگر یا Custom مناسب‌تر باشد. اندازه شرکت به‌تنهایی پاسخ نمی‌دهد.

توسعه سفارشی از سایت‌ساز امن‌تر و مقیاس‌پذیرتر است؟

نه به‌صورت ذاتی. Custom کنترل بیشتری می‌دهد، اما Secure development، Patch، Observability، On-call و Capacity engineering را هم بر عهده سازمان می‌گذارد. SaaS بخشی از عملیات را واگذار می‌کند، اما Configuration، Identity، Data، App و Vendor risk باقی می‌مانند. معماری و تیم واقعی را بیازمایید.

مهم‌ترین معیار انتخاب سایت‌ساز سازمانی چیست؟

یک معیار واحد وجود ندارد. ابتدا Gateهای غیرقابل‌جبران مانند Eligibility، Data/Compliance، Critical security، Required integration و Export را بررسی کنید؛ سپس Fit سفر و محتوا، Reliability/Performance، Operations، Experience تیم، TCO و Exit را وزن دهید.

چگونه Vendor lock-in را کم کنیم؟

دامنه و حساب‌های اصلی را مستقل نگه دارید، Content را ساخت‌یافته مدل کنید، Interface و Data format را مستند کنید، URL/Metadata/Media/Relation را Export بگیرید، Integration را کم‌Couple بسازید و دوره‌ای Restore drill انجام دهید. وابستگی صفر نیست؛ هزینه و زمان خروج باید معلوم باشد.

برای انتخاب سایت‌ساز چه PoCای اجرا کنیم؟

یک Vertical slice از سخت‌ترین Journey: Content type واقعی، فارسی/RTL، Role/Approval، Integration، Failure، SEO/Rendered HTML، Accessibility، Load و Export. Success criteria و Timebox را پیشاپیش بنویسید و Workaroundها را به TCO انتقال دهید.

جمع‌بندی

پرسش حرفه‌ای این نیست که «آیا سایت‌ساز برای شرکت بزرگ بد است؟»؛ این است که «برای این Journey، با این Impact، داده، Integration، SLO و توان تیم، کدام مرز Build/Buy کمترین TCO و Risk قابل‌قبول را دارد؟» Managed builder می‌تواند انتخابی بالغ برای Property مناسب باشد و Custom می‌تواند برای منطق متمایز ضروری شود. تصمیم زمانی قابل دفاع است که Requirement آزمون‌پذیر، PoC دشوار، Contract روشن، TCO سناریویی و Exit تمرین‌شده داشته باشد.