سایت‌ساز برای پروژه بزرگ؛ Fit، TCO، Lock-in و Exit

یک شرکت در سه هفته پورتال نمایندگی خود را با سایت‌ساز راه می‌اندازد. Demo موفق است؛ اما در Rollout معلوم می‌شود Roleهای لازم قابل تعریف نیستند، Webhook تکراری سفارش دوباره می‌سازد، Audit log خروجی ندارد و Export شامل رابطه‌های داده نیست. بازنویسی اختصاصی هم از قبل بودجه نگرفته است. انتخاب اولیه «اشتباه مطلق» نبود؛ Pilot فقط مسیر خوش را آزمایش کرده بود.

سایت‌ساز برای پروژه بزرگ زمانی مناسب است که قابلیت‌های استاندارد پلتفرم با بخش غیرمتمایز کسب‌وکار Fit باشد و محدودیت‌های Data، Workflow، Integration، Security، Accessibility و Exit پیش از قرارداد آزموده شوند. «بزرگ» فقط تعداد بازدید نیست. ممکن است یک سایت کم‌ترافیک با چند Tenant، Role، Approval، زبان، Integration و الزام Audit از یک فروشگاه پرترافیک پیچیده‌تر باشد.

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

Website builder معمولاً سرویس میزبانی‌شده‌ای است که Template، Editor، انتشار، Hosting و مجموعه‌ای از Component/App را یکجا ارائه می‌کند. اما بازار چند خانواده متفاوت دارد:

پس «سایت‌ساز یا کدنویسی» دوگانه ناقصی است. پروژه می‌تواند Marketing site را Managed، Checkout را Commerce SaaS و هسته محصول را Custom نگه دارد.

پروژه بزرگ را با Complexity تعریف کنید

پیش از مقایسه Vendor، ابعاد زیر را امتیاز دهید:

• Audience/Tenant: چند گروه و سازمان با داده جدا؟
• Identity: چند Role، SSO/SCIM، Approval و Delegation؟
• Data: حجم، رابطه، تاریخچه، Retention و Residency؟
• Workflow: چند State، Exception و Human handoff؟
• Integration: ERP/CRM/Accounting/PSP/Logistics و جهت Sync؟
• Content: چند زبان، بازار، Brand، Author و Release cadence؟
• Traffic: میانگین، Peak، Flash event و Background jobs؟
• Risk: پرداخت، PII، قرارداد، Audit و Availability؟
• Change: چند تیم مستقل و چند Release در هفته؟
• Exit: داده، URL، Media، Theme، Logic و History چگونه خارج می‌شوند؟

اگر پیچیدگی فقط در Content و کمپین است، یک Platform managed می‌تواند Fit عالی باشد. اگر مزیت رقابتی در Workflow یا Algorithm اختصاصی است، فشردن آن داخل Appهای پراکنده ممکن است TCO و Risk را بالا ببرد.

Decision contract: چه تصمیمی می‌خواهید بگیرید؟

یک سند یک‌صفحه‌ای بنویسید:

• Outcome کسب‌وکار و تاریخ لازم؛
• Scope فاز اول و Non-goalها؛
• Must-have، Nice-to-have و Differentiator؛
• Volume/Peak/Latency/Availability مفروض؛
• داده حساس و تعهد قراردادی/قانونی؛
• توان تیم در Build، Operate و Vendor management؛
• افق تصمیم: Pilot، ۱۲ ماه یا ۳ سال؛
• Trigger بازنگری یا مهاجرت.

بدون این قرارداد، تیم یک Editor زیبا را با یک Platform عملیاتی مقایسه می‌کند.

Capability map: Commodity را از Differentiator جدا کنید

قاعده مفید: Commodity را نخرید اگر Platform آن را با کیفیت و هزینه بهتر اداره می‌کند؛ Differentiator را داخل Constraint شکننده Vendor دفن نکنید.

Option ladder: از Managed تا Custom

1. Configure: قابلیت استاندارد بدون App سفارشی؛
2. Extend: App/Function/Webhook محدود و مستند؛
3. Compose: چند SaaS با API و Integration layer؛
4. Headless: Frontend مستقل روی Backend managed؛
5. Hybrid: Marketing/CMS managed، Core domain سفارشی؛
6. Custom: ساخت و عملیات کامل‌تر برای Capability متمایز.

از پایین‌ترین پله‌ای شروع کنید که Acceptance criteria را پاس می‌کند. Headless و Custom «بالغ‌تر» نیستند؛ فقط مسئولیت بیشتری به تیم منتقل می‌کنند. برای مقایسه عمیق‌تر مدل‌ها، راهنمای وردپرس، سایت‌ساز یا توسعه اختصاصی را ببینید.

مزایا: چه چیزی واقعاً به Vendor منتقل می‌شود؟

• Provisioning زیرساخت پایه و Patch بخشی از Platform؛
• Editor و Componentهای استاندارد؛
• CDN/Hosting/Certificate و بخشی از Availability؛
• Release قابلیت‌های عمومی و سازگاری Ecosystem؛
• Backoffice استاندارد برای Content یا Commerce؛
• Support و Documentation متمرکز؛
• کاهش Time-to-first-version در Scope مناسب.

اما Security، Uptime، Backup و Compliance «کامل» منتقل نمی‌شوند. IAM، Configuration، Data، Content، Appهای ثالث، Integration، Domain و Incident coordination هنوز مسئولیت مشتری‌اند.

Managed infrastructure مساوی Zero operations نیست

تیم همچنان باید این موارد را اداره کند:

• Owner/MFA/Role و Offboarding حساب‌ها؛
• Domain، DNS، Registrar lock و Recovery؛
• App/Plugin/Theme/Script inventory و Permission؛
• Webhook secret، API key و Rotation؛
• Backup/Export مستقل و Restore test؛
• Analytics/Consent/Privacy؛
• Incident runbook و تماس Vendor؛
• Release QA و Regression؛
• Data quality و Reconciliation.

CISA Secure by Design بر کاهش بار امنیتی مشتری و Secure defaults تأکید می‌کند؛ در Procurement بررسی کنید Vendor این اصل را چگونه عملی می‌کند، اما آن را جای مسئولیت Customer-side نگذارید. چک‌لیست امنیت سایت‌سازها نیز حساب، دامنه و افزونه را پوشش می‌دهد.

Constraint register: محدودیت را قبل از Roadmap ثبت کنید

برای هر Limit این فیلدها را نگه دارید: مقدار، Scope plan، Burst، رفتار هنگام عبور، امکان افزایش، هزینه، Alert، Owner و تاریخ تأیید. نمونه‌ها:

• API rate/concurrency و Bulk operation؛
• تعداد Product/Variant/Field/Locale/User/Role؛
• Storage/Bandwidth/Build minute/Function execution؛
• Webhook retry/retention/order guarantee؛
• Search/index/filter/redirect limit؛
• Export row/file/history؛
• Checkout/Theme/URL/Schema customization؛
• Audit log retention/export؛
• Environment و Collaborator seat.

Marketing page «Unlimited» کافی نیست؛ Contract، plan-specific docs و تست واقعی ملاک‌اند.

Integration readiness: API داشتن کافی نیست

یک API ممکن است فقط Read محدود بدهد. برای هر Integration بررسی کنید:

• Authentication/Authorization و least privilege؛
• Versioning و Deprecation notice؛
• Pagination، Filter، Bulk و historical access؛
• Rate/concurrency، Retry-after و quota visibility؛
• Webhook delivery، signature، replay، retry و ordering؛
• Idempotency و duplicate handling؛
• Sandbox/staging و test fixture؛
• Error taxonomy و correlation ID؛
• Backfill/Reconciliation پس از outage؛
• Support SLA برای integration incident.

الگوی Sync دوطرفه را روی کاغذ و Failure test اجرا کنید. مرجع طراحی API، قرارداد و قابلیت اطمینان برای این Acceptance مفید است.

Data model و Portability

«مالک داده هستید» با «می‌توانید سیستم را بازسازی کنید» یکسان نیست. Export نمونه بگیرید و بررسی کنید:

• شناسه پایدار، رابطه، Variant و Custom field؛
• کاربر، Consent، Role و History؛
• Order، Payment reference، Refund و Fulfillment state؛
• Content، Revision، Author، Media metadata و Alt؛
• URL، Redirect، Canonical، SEO metadata و Structured data؛
• Theme/Template/Component و منطق Automation؛
• Audit log و timestamps؛
• فرمت، API/bulk، زمان Export و هزینه خروج.

Export را Import آزمایشی کنید. فایل CSV ناقص Exit plan نیست.

Vendor lock-in صفر نمی‌شود؛ باید اندازه‌گیری شود

هدف Portability رایگان نیست؛ باید Recovery time، هزینه و Data loss قابل قبول باشد.

TCO: اشتراک فقط یک سطر است

3-year TCO =
  license + seats + usage + transaction fees
  + apps/themes/extensions
  + integration/build/QA
  + content/data migration
  + security/privacy/accessibility/compliance
  + support/operations/training
  + incident/downtime expected cost
  + exit/replatform reserve
  + opportunity cost

برای Low/Base/High سناریو بسازید و Currency/FX، رشد Usage و قیمت Vendor را Range کنید. هزینه Custom نیز فقط Developer salary نیست؛ Cloud، On-call، Patch، Security، QA و Product ownership را اضافه کنید.

اقتصاد App ecosystem

App سریع Gap را پر می‌کند، اما هر App یک Vendor، Script، Permission، Subscription، API و Incident path تازه است. Registry بسازید:

• Business owner و Use case؛
• Permission و Data access؛
• Frontend/Checkout performance impact؛
• Subprocessor/privacy terms؛
• Dependency/version/change log؛
• Cost و renewal؛
• Outage fallback و removal test؛
• جایگزین و Exit.

سه App برای یک Workflow ممکن است از یک Extension محدود یا Service مستقل پرهزینه‌تر و شکننده‌تر شوند.

Security و Supply-chain procurement

گواهی یا Badge به‌تنهایی Security را اثبات نمی‌کند. NIST SP ۱۳۰۵ برای C-SCRM بر تعریف الزامات تأمین‌کننده در Agreement/SLA و مدیریت ریسک زنجیره تأمین تأکید دارد. در ارزیابی بپرسید:

• MFA/SSO/SCIM/RBAC و audit eventهای قابل خروج؛
• Encryption/key/secret و tenant isolation؛
• Vulnerability disclosure، patch و breach notification؛
• Backup، restore، RPO/RTO و disaster exercise؛
• Subprocessor و data location؛
• Admin/support access و customer-managed controls؛
• App marketplace review و permission model؛
• Status/history، incident report و escalation؛
• Deletion/retention پس از termination.

پاسخ «ما امن هستیم» Acceptance نیست؛ Evidence، Scope و تاریخ لازم است.

Identity و Operating model سازمانی

پروژه بزرگ به Owner مشترک یا Account شخصی نباید متکی باشد. نیازها:

• Organization-owned tenant و billing؛
• SSO/SCIM یا حداقل lifecycle قابل کنترل؛
• Role تفکیک‌شده برای Content، Theme، App، Domain، Billing و Support؛
• Break-glass با نگهداری و مانیتورینگ امن؛
• Approval برای تغییر Domain/Payment/App؛
• Access review و Offboarding؛
• Audit log با Actor/action/object/time/result.

Environment، Release و Rollback

Editor ساده گاهی Production را مستقیم تغییر می‌دهد. برای تیم بزرگ بررسی کنید:

• Draft/preview/staging واقعاً چه چیزهایی را جدا می‌کند؟
• Data و integration در تست چگونه ایزوله‌اند؟
• Change قابل Diff، Review و Approve است؟
• Theme/App/config rollback ممکن است؟ تا چه مدت؟
• Content publish scheduled/atomic است؟
• Release marker و audit trail دارید؟
• Feature flag یا staged rollout ممکن است؟

Backup محتوا با Rollback کل Platform یا Integration state یکسان نیست.

Performance و Scale را با Journey بسنجید

CDN و ترافیک بالا فقط بخشی از Scale هستند. Vertical slice را در Peak آزمایش کنید: Login، Search، Add-to-cart، Checkout، Publish، Import و Webhook burst. معیارها:

• Field LCP/INP/CLS بر Template و Device؛
• API p95/p99، error و throttle؛
• Build/publish queue؛
• Search indexing lag؛
• Webhook delay/duplicate/missing؛
• Bulk import/export duration؛
• Third-party script failure؛
• Recovery پس از rate limit/outage.

برای RUM و تفکیک Lab/Field از راهنمای Core Web Vitals استفاده کنید. Benchmark فروش Vendor را جای workload خود نگذارید.

SEO: Platform class رتبه تعیین نمی‌کند

ادعای «سایت‌ساز فقط SEO پایه دارد» یا «همه قابلیت‌ها حل شده‌اند» هر دو بیش‌ازحد کلی‌اند. خروجی و Control را تست کنید:

• URL، status، redirect، canonical و robots/noindex؛
• Title/meta، heading، alt و internal link؛
• Sitemap و مدیریت حذف/تغییر URL؛
• SSR/HTML اولیه یا Render قابل اتکا؛
• Pagination/filter/faceted navigation؛
• hreflang و locale URL؛
• Structured data منطبق با محتوای visible؛
• Product/price/availability freshness؛
• Search Console verification و log/diagnostic access؛
• CWV و JavaScript failure.

حداقل الزامات فنی Google Search Platform خاصی را ترجیح نمی‌دهد: Googlebot نباید Block باشد، URL باید ۲۰۰ بدهد و محتوای Indexable داشته باشد؛ Indexing تضمین نیست. راهنمای JavaScript SEO نیز Rendering، لینک crawlable، Title/Canonical و status معنادار را توضیح می‌دهد.

Accessibility را وارد قرارداد خرید کنید

Template demo یا VPAT قدیمی به‌تنهایی کافی نیست. Authoring tool باید به تیم در ساخت محتوای Accessible کمک کند و Frontend، App/Widget، Checkout و Error state نیز تست شوند. W3C WAI Planning توصیه می‌کند Accessibility در Procurement، Responsibility، Budget و Acceptance testing وارد شود.

• WCAG target و Scope/exception؛
• Keyboard/focus/name/role/value؛
• Zoom/reflow/contrast/motion؛
• Form/error/status؛
• Content editor guardrail برای Heading/Alt/Label؛
• Third-party essential flow و fallback؛
• Remediation SLA و release regression.

تست خودکار کافی نیست؛ ممیزی دسترس‌پذیری WCAG را با کاربر و سناریوی واقعی تکمیل کنید.

Content operations و Governance

پروژه بزرگ فقط Frontend نیست. CMS باید نقش، Draft، Approval، Schedule، Version، Locale، Asset rights، Expiry و Audit را پشتیبانی کند. نمونه Content type واقعی را در PoC بسازید:

• Field و validation ساخت‌یافته؛
• Relationship و reusable component؛
• Preview با داده/Locale صحیح؛
• Workflow و separation of duties؛
• Bulk edit/import/export؛
• Translation status و fallback؛
• Archive/unpublish/redirect؛
• Media rights/alt/caption.

اگر معماری محتوا قبل از Platform روشن نیست، Editor جذاب فقط Taxonomy ضعیف را سریع‌تر منتشر می‌کند. راهنمای معماری اطلاعات و Taxonomy نقطه شروع است.

Localization و ایران

برای بازار ایران، Demo انگلیسی کافی نیست:

• RTL واقعی در Editor، Theme، Table، Form و Email؛
• Persian/Arabic characters، half-space و search/sort؛
• Jalali/Gregorian و timezone؛
• تومان/ریال، precision و source/effective date؛
• PSP، Invoice، shipping و accounting integration محلی؛
• فونت، media و performance در شبکه/دستگاه واقعی؛
• قابلیت Export/backup در اختلال؛
• قیمت ارزی، روش پرداخت و renewals؛
• Eligibility/Terms/Support رسمی برای کشور و تیم.

اگر Vendor یا قابلیت برای ایران پشتیبانی رسمی ندارد، راهکار دورزدن کشور/هویت/آدرس را وارد معماری نکنید. گزینه واجد شرایط یا Plan خروج انتخاب کنید و وضعیت را در تاریخ خرید دوباره تأیید کنید.

قرارداد و Procurement checklist

Terms عمومی جای مذاکره Enterprise را نمی‌گیرد؛ اگر Vendor بند حیاتی را نمی‌پذیرد، Risk acceptance باید صریح و امضاشده باشد.

PoC درست: Vertical slice پرریسک

PoC نباید فقط Hero و Blog post بسازد. یک Journey واقعی انتخاب کنید:

1. User/role واقعی ایجاد و SSO/MFA/approval را تست کنید.
2. Data پیچیده با Locale/Relationship وارد کنید.
3. یک Integration با Webhook duplicate/outage/retry اجرا کنید.
4. Peak و quota را با حجم نماینده آزمایش کنید.
5. Keyboard/WCAG و Mobile/RTL را تست کنید.
6. Title/status/canonical/schema/render را عمومی QA کنید.
7. تغییر و Rollback را تمرین کنید.
8. Export کامل بگیرید و در مقصد بی‌طرف Import کنید.
9. Incident/Support ticket واقعی آزمایشی باز کنید.

Pass/fail و Evidence را قبل از Demo ثبت کنید. Vendor score بدون تست Failure mode اعتماد کاذب می‌سازد.

Scorecard وزنی، بدون Precision ساختگی

Weighted fit =
  Capability fit × 0.20
  + Data/portability × 0.15
  + Integration/reliability × 0.15
  + Security/governance × 0.15
  + Operations/release × 0.10
  + Accessibility/SEO/performance × 0.10
  + TCO/commercial × 0.10
  + Vendor/exit viability × 0.05

وزن نمونه است. Must-have شکست‌خورده را با جمع امتیاز Nice-to-have پنهان نکنید؛ ابتدا Gateها، سپس Score. Confidence و Evidence هر نمره را ثبت کنید.

Hybrid architecture را با مرز Domain بسازید

Hybrid موفق «چسباندن تصادفی ابزارها» نیست. مرزها:

• System of record هر Entity مشخص؛
• مالک URL/Content/Customer/Order روشن؛
• Integration contract و failure/reconciliation؛
• Identity و Consent هماهنگ؛
• Design tokens/Navigation/Analytics مشترک؛
• Domain/subdomain و SEO ownership؛
• Incident RACI و Vendor escalation؛
• Deployment مستقل بدون شکستن Journey.

مثلاً Marketing site روی Builder، Product app روی Custom domain surface و Help center روی SaaS می‌تواند منطقی باشد، اگر Identity، Navigation، Analytics، Accessibility و Content ownership هماهنگ شوند.

Migration و Strangler plan

1. Inventory داده، URL، integration، App و workflow؛
2. Destination model و ID mapping؛
3. Export/transform/import با reconciliation؛
4. Parallel run یا slice migration؛
5. Redirect/canonical/sitemap و analytics continuity؛
6. Read-only/freeze window و delta sync؛
7. Cutover/rollback criteria؛
8. Hypercare و decommission؛
9. Deletion/export evidence از Vendor قدیمی.

Migration را به «وقتی لازم شد» نسپارید. Triggerهایی مثل Limit نزدیک، TCO crossover، Feature block، SLA failure یا policy change از ابتدا تعریف شوند.

برنامه ۹۰روزه انتخاب

روز ۱ تا ۳۰: Requirement و Baseline

• Decision contract، Capability map و Complexity profile بسازید.
• Must-have gate، volume، risk و ownership را ثبت کنید.
• TCO/Exit assumptions و Shortlist خانواده‌ها را تعیین کنید.
• PoC script و Evidence format را قبل از تماس فروش نهایی کنید.

روز ۳۱ تا ۶۰: Vertical slice و Failure test

• Journey واقعی را در دو گزینه اجرا کنید.
• API/webhook/quota/peak، security و rollback را تست کنید.
• SEO/CWV/WCAG/RTL و content workflow را QA کنید.
• Export/import و Support escalation را تمرین کنید.

روز ۶۱ تا ۹۰: Contract و Decision

• Gate، Score، Confidence و Risk acceptance را جمع‌بندی کنید.
• TCO سه‌ساله و سناریوهای FX/usage/price را اصلاح کنید.
• SLA/Data/Security/Accessibility/Exit را در قرارداد ببندید.
• Rollout، Monitoring، trigger مهاجرت و Plan B را تصویب کنید.

پرسش‌های متداول

آیا سایت‌ساز برای پروژه بزرگ مناسب است؟

گاهی بله. اگر نیازها عمدتاً استاندارد، Limitها پذیرفتنی، Integration/Export قابل اتکا و Operating model روشن باشند، Managed platform می‌تواند ریسک و زمان را کم کند. پیچیدگی متمایز باید با PoC واقعی سنجیده شود.

بزرگ‌ترین محدودیت سایت‌ساز چیست؟

یک پاسخ جهانی وجود ندارد. برای یک پروژه Data model، برای دیگری Checkout، Role، API quota، Release یا Portability گلوگاه است. Constraint register و Vertical slice محدودیت واقعی شما را نشان می‌دهد.

آیا سایت‌ساز برای SEO ضعیف است؟

کلاس Platform تعیین‌کننده نیست. URL/status/canonical/render/sitemap/schema/CWV و کنترل عملی را آزمایش کنید. ممکن است یک Builder نیازها را کامل پاس کند و پلتفرم دیگری—even custom—به‌دلیل اجرای بد شکست بخورد.

هزینه سایت‌ساز کمتر از توسعه اختصاصی است؟

در Scope استاندارد و شروع کار اغلب ممکن است، اما نتیجه به Usage، App، Fee، Integration، Staff، Risk و Exit بستگی دارد. TCO سه‌ساله Low/Base/High را با هزینه عملیات Custom مقایسه کنید.

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

Data export دوره‌ای و Import test، ID map، Adapter برای API، منطق متمایز خارج از Platform، Contract خروج، Documentation و مهاجرت تمرینی. Lock-in صفر نمی‌شود؛ Recovery time، هزینه و Data loss باید قابل قبول شوند.

جمع‌بندی

سایت‌ساز نه میان‌بُر همیشگی است و نه تله ذاتی. ارزش آن در سپردن Capability استاندارد به Platformی است که آن را بهتر اداره می‌کند؛ ریسک آن زمانی بالا می‌رود که منطق متمایز، داده حیاتی و Exit شما پشت Constraintهای آزمایش‌نشده قفل شوند.

تصمیم را از Demo و فهرست Feature جدا کنید: Capability map، Must-have gate، Vertical slice، Failure test، TCO و Exit rehearsal بسازید. برای پروژه فروشگاهی، معیارهای Catalog/Checkout/Payment/Fulfillment را با راهنمای انتخاب سایت‌ساز فروشگاهی تکمیل کنید؛ برای کیفیت Theme و Component نیز راهنمای انتخاب قالب سایت را ببینید.