طراحی سایت ارزان؛ کاهش هزینه بدون افت کیفیت و ریسک

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

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

سایت ارزان با سایت کم‌کیفیت چه تفاوتی دارد؟

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

قیمت پایین نه مانع سئو است و نه نشانه کیفیت. یک سایت ساده با محتوای مفید، HTML قابل Crawl و تجربه سریع می‌تواند بهتر از سامانه گران و پیچیده عمل کند. در مقابل، هیچ افزونه یا قالبی کیفیت را بدون معماری، محتوا و نگهداری تضمین نمی‌کند.

اول مسئله کسب‌وکار را به یک Brief یک‌صفحه‌ای تبدیل کنید

بزرگ‌ترین اهرم کاهش هزینه پیش از شروع طراحی است. اگر هدف، مخاطب و تصمیم‌گیر روشن نباشند، تیم نسخه‌های متعدد می‌سازد و هزینه در Feedbackهای متناقض مصرف می‌شود. Brief باید حداقل این هشت سؤال را پاسخ دهد:

1. کاربر اصلی کیست و در چه موقعیتی وارد سایت می‌شود؟
2. مهم‌ترین مسئله‌ای که باید حل کند چیست؟
3. اقدام موفق چیست: تماس، رزرو، خرید، ثبت درخواست یا مطالعه؟
4. کدام جریان اگر خراب شود به فروش یا اعتماد آسیب جدی می‌زند؟
5. چه محتوا، داده، سامانه یا حسابی از قبل وجود دارد؟
6. چه چیزی صریحاً در نسخه اول نیست؟
7. یک نفرِ پاسخ‌گو برای تأیید محتوا و تصمیم کیست؟
8. تا ۹۰ روز پس از انتشار کدام Outcome سنجیده می‌شود؟

«سایتی مدرن مثل رقبا» Brief نیست. «افزایش درخواست مشاوره واجدشرایط از صاحبان فروشگاه، با یک صفحه خدمت، سه Case و فرم کوتاه» تصمیم‌پذیر است. برای برآورد جزئی‌تر، راهنمای برآورد هزینه پروژه سایت را کنار این Brief قرار دهید.

هزینه طراحی سایت دقیقاً از کجا می‌آید؟

هزینه فقط ساعت کدنویسی نیست. هر بخش، ورودی، خروجی، مسئول و معیار پذیرش دارد. حذف نام یک بخش از Proposal به‌معنای حذف نیاز آن نیست؛ ممکن است هزینه به عهده کارفرما یا مرحله بعد منتقل شده باشد.

برای مقایسه واقعی، از هر پیشنهاد بخواهید Effort و Deliverable این بخش‌ها را نشان دهد. «طراحی سایت کامل» یا «سئو پایه» بدون تعریف، قابل قیمت‌گذاری و پذیرش نیست.

MVP را با جریان کامل بسازید، نه مجموعه‌ای از نصفه‌قابلیت‌ها

نسخه اول باید یک Vertical slice کامل باشد: کاربر وارد شود، تصمیم بگیرد، اقدام کند؛ کسب‌وکار درخواست را دریافت و پیگیری کند؛ و تیم بتواند نتیجه را بسنجد. صفحه زیبا بدون پیام تأیید، اعلان تیم، ذخیره Lead و امکان پیگیری، MVP کامل نیست.

نمونه برای سایت خدماتی

نمونه برای فروشگاه کوچک

فهرست و جزئیات محصول، جست‌وجو یا فیلتر ضروری، سبد، Checkout، پرداخت، تأیید سفارش، مدیریت موجودی و مسیر پشتیبانی یک زنجیره‌اند. حذف تست Callback یا Order state برای ارزان‌شدن، نسخه کوچک نمی‌سازد؛ جریان ناقص می‌سازد. اتصال درگاه باید Verify سمت سرور، State روشن سفارش، Idempotency و Reconciliation داشته باشد.

قابلیت‌ها را با Value، Risk و Effort اولویت‌بندی کنید

رأی بلندترین فرد جلسه نباید Backlog را تعیین کند. برای هر قابلیت یک امتیاز ساده بسازید:

Priority = (Business value × User reach × Confidence + Risk reduction) ÷ Effort

این فرمول علمی یا عمومی نیست؛ ابزار تصمیم داخلی است. مقیاس‌ها را مثلاً از ۱ تا ۵ تعریف و فرض‌ها را کنار امتیاز ثبت کنید. کنترل امنیتی ضروری یا الزام قانونی را صرفاً به‌دلیل Reach کم حذف نکنید؛ آن‌ها Gate انتشارند، نه Feature رقابتی.

پلتفرم ارزان‌تر را از روی Fit انتخاب کنید

WordPress، SaaS، No-Code/Low-Code و توسعه اختصاصی هیچ‌کدام ذاتاً ارزان‌ترین نیستند. هزینه به میزان انطباق نیاز با قابلیت استاندارد، Integration، تغییر آینده و خروج بستگی دارد.

اگر نیاز با قابلیت استاندارد پوشش داده می‌شود، ساخت نسخه اختصاصی معمولاً اتلاف است. اگر هر ماه با محدودیت پلتفرم می‌جنگید، «ارزان‌بودن شروع» دیگر مزیت نیست. ماتریس کامل Fit، TCO و Exit در راهنمای No-Code و Low-Code آمده است.

قالب و افزونه آماده چه زمانی واقعاً هزینه را کم می‌کنند؟

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

Gate انتخاب Component آماده

• منبع، مجوز و مالکیت حساب خرید روشن است.
• تاریخ Update، Changelog، پشتیبانی و سازگاری نسخه بررسی شده‌اند.
• نیاز واقعی را بدون افزونه‌های مکمل متعدد پوشش می‌دهد.
• روی محتوای فارسی، RTL، موبایل و Keyboard آزمایش شده است.
• بار CSS/JS، Query و Script ثالث اندازه‌گیری شده است.
• داده در قالب قابل انتقال ذخیره می‌شود و مسیر جایگزینی وجود دارد.
• نسخه Nulled یا فایل از منبع نامعتبر استفاده نمی‌شود.

پکیج «رایگان» ممکن است هزینه لایسنس را صفر کند اما Update، امنیت، Integration و خروج را گران کند. برای Due diligence از راهنمای قالب و افزونه رایگان وردپرس استفاده کنید.

Design system کوچک، تنوع را بدون طراحی دوباره حفظ می‌کند

لازم نیست هر صفحه Art direction مستقل داشته باشد. مجموعه‌ای محدود از Token و Component—رنگ، تایپوگرافی، فاصله، Button، Form، Card، Navigation، Hero و Section—سرعت طراحی، توسعه و QA را بالا می‌برد. تفاوت صفحه‌ها از ترتیب، محتوا و داده می‌آید.

• سه سطح تایپوگرافی کاربردی به‌جای ده Style نزدیک؛
• یک Button component با Variantهای مشخص؛
• دو یا سه الگوی Landing و Article؛
• یک الگوی فرم با Label، Error و Success استاندارد؛
• Tokenهای Responsive و RTL به‌جای Override صفحه‌ای؛
• حالت Loading، Empty، Error و Disabled از ابتدا.

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

محتوا را پیش از UI آماده کنید

Lorem ipsum و تصویر موقت تصمیم طراحی را ارزان نمی‌کنند؛ هزینه اصلاح را عقب می‌اندازند. طول عنوان فارسی، جدول، رقم، قیمت، فرم، تصویر عمودی/افقی و متن خطا روی Layout اثر دارند.

1. Content inventory URLهای موجود و تصمیم Keep/Rewrite/Merge/Remove بسازید.
2. برای هر Template فیلدهای لازم، محدودیت طول و Owner تعریف کنید.
3. صفحه اصلی، خدمت/محصول کلیدی و اعتماد را زودتر آماده کنید.
4. تصویرها را با منبع، مجوز استفاده، Crop و Alt تحویل دهید.
5. متن فرم، خطا، خالی، تأیید و پیام عملیاتی را جزو محتوا بدانید.
6. ورود اطلاعات را دسته‌ای انجام دهید و نمونه را پیش از Scale تأیید کنید.

کارفرما می‌تواند Draft خام و اطلاعات تخصصی را تهیه کند، اما «خودمان محتوا می‌دهیم» باید Owner، Template و Deadline داشته باشد. محتوای دیررس یکی از رایج‌ترین علت‌های توقف و دوباره‌کاری است.

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

هوش مصنوعی می‌تواند در خلاصه‌سازی مصاحبه، Variant متن، Alt اولیه، Test case، مستندسازی و تبدیل داده ساخت‌یافته کمک کند. اما خروجی باید با Source، Brand voice، واقعیت محصول، فارسی/RTL و ریسک ادعا بازبینی شود.

• داده مشتری، رمز، قرارداد محرمانه یا Source خصوصی را بدون مجوز وارد ابزار نکنید.
• مجوز استفاده از Code، تصویر، فونت و محتوای خروجی را بررسی کنید.
• کد AI-generated را Review، Dependency scan و Test کنید.
• برای صفحه‌های متعدد، نام شهر یا محصول را مکانیکی عوض نکنید.
• صرفه‌جویی را با زمان بازبینی و نرخ خطا بسنجید، نه تعداد خروجی.

سایت‌ساز AI ممکن است برای سایت استاندارد مناسب باشد، اما هزینه خروج، Ownership و محدودیت Integration را باید دید. مقایسه عملی در راهنمای طراحی سایت با هوش مصنوعی آمده است.

بازخورد و تغییر Scope را کنترل کنید

Revision نامحدود معمولاً هم برای کارفرما و هم مجری پرهزینه است. پیش از شروع هر مرحله، ورودی و Decision owner مشخص شود؛ در پایان نیز بازخوردها یک‌جا، اولویت‌بندی‌شده و غیرمتناقض تحویل شوند.

تعریف ساده Change request

هر درخواست تازه باید شامل مسئله، کاربر، دلیل، اثر بر Scope/زمان/هزینه، وابستگی و تصمیم باشد. اگر تغییری پذیرفته شد، یکی از این سه اهرم باید جابه‌جا شود: بودجه، زمان یا دامنه. عبارت «فقط یک تغییر کوچک» واحد برآورد نیست.

پیشنهادهای قیمت را Apples-to-apples مقایسه کنید

هر Vendor باید یک Scope comparable پر کند. در غیر این صورت اختلاف قیمت معنای روشنی ندارد.

Proposal باید Assumption و Exclusion هم داشته باشد. اگر «هاست و پشتیبانی» خارج از قیمت است، بد نیست؛ نامشخص‌بودن آن بد است. پیش از امضا، Scope، Acceptance، پرداخت، مالکیت و تحویل را با چک‌لیست قرارداد طراحی سایت کنترل کنید.

کجا می‌توان هزینه را با ریسک کم کاهش داد؟

تخفیف سالم غالباً یک Trade است: «این قابلیت به Release دوم می‌رود»، «زمان تحویل منعطف‌تر می‌شود»، «کارفرما محتوا را طبق Template می‌دهد» یا «پشتیبانی با SLA پایین‌تر انتخاب می‌شود». کاهش قیمت بدون تغییر هیچ فرضی، باید توضیح فنی داشته باشد.

کجا نباید صرفه‌جویی کرد؟

مالکیت و دسترسی

دامنه، DNS، Hosting، Analytics، Search Console، Repository، Design file و حساب لایسنس باید زیر کنترل سازمان یا با دسترسی انتقال‌پذیر باشند. تحویل رمز در پیام‌رسان جای Access governance را نمی‌گیرد. MFA، نقش‌ها و فرایند قطع دسترسی هم لازم‌اند.

امنیت و حریم خصوصی

اعتبارسنجی Server-side، احراز هویت، سطح دسترسی، Update، Secret management، Logging، محدودیت Rate و Dependency management را حذف نکنید. OWASP ASVS یک مبنای قابل ارجاع برای تعریف و آزمون کنترل‌های امنیتی در خرید و قرارداد است؛ سطح و Requirement متناسب با ریسک پروژه انتخاب شود.

برای WordPress، استفاده از نسخه و منبع رسمی، Update و Hardening بخشی از عملیات است. راهنمای Hardening وردپرس نیز تأکید می‌کند نسخه‌های قدیمی در برابر مسائل شناخته‌شده بازترند. هزینه نگهداری را صفر فرض نکنید.

Backup و Restore

Backup روی همان سرور، بدون Retention و Restore test، برنامه بازیابی نیست. دیتابیس، فایل، تنظیمات و Secretهای لازم را با نسخه خارج از محیط اصلی نگه دارید؛ RPO/RTO متناسب تعیین و بازیابی را دوره‌ای اجرا کنید. مستندات رسمی به‌روزرسانی WordPress نیز Backup پیش از Update را توصیه می‌کند.

مسیر درآمد و داده

فرم، تماس، رزرو، Login، سبد، پرداخت، Callback، موجودی و اعلان سفارش نقاط حذف QA نیستند. برای این Flowها Owner، State، خطا، Retry، Idempotency، Log و پیام کاربر تعریف کنید.

موبایل، عملکرد و دسترس‌پذیری

نسخه موبایل «مرحله بعد» نیست اگر کاربران امروز با موبایل می‌آیند. داده واقعی LCP، INP و CLS را بسنجید؛ راهنمای رسمی Core Web Vitals آن‌ها را معیارهای تجربه واقعی بارگذاری، پاسخ‌گویی و ثبات بصری معرفی می‌کند. برای فرایند کامل QA از راهنمای موبایل‌فرندلی استفاده کنید.

دسترس‌پذیری با Plugin overlay یا یک تست خودکار کامل نمی‌شود. WCAG 2.2 مرجع پایدار معیارهای دسترس‌پذیری وب است؛ سطح هدف، دامنه و روش آزمون را در Acceptance بنویسید.

SEO و مهاجرت

در بازطراحی، URL inventory، Redirect مستقیم، Canonical، Metadata، Robots، Sitemap، Structured data و Tracking باید منتقل شوند. حذف این کارها ممکن است قیمت پروژه را کم کند اما افت Organic و از دست‌رفتن داده را به کسب‌وکار تحمیل کند.

QA را براساس ریسک طراحی کنید

تست همه چیز در همه دستگاه‌ها ممکن نیست؛ حذف تست هم قابل قبول نیست. Flowها را Tier کنید.

Definition of Done کوچک اما واقعی

• Acceptanceهای قابلیت پاس شده و Evidence پیوست است.
• موبایل، RTL، Keyboard و خطاهای فرم آزموده شده‌اند.
• Performance و Script ثالث نسبت به Budget کنترل شده‌اند.
• Dependency و دسترسی بحرانی ثبت شده‌اند.
• Analytics داده شخصی یا Secret ارسال نمی‌کند.
• Backup و یک Restore نمونه موفق است.
• Redirect و SEO migration در Staging/Production کنترل شده‌اند.
• Runbook، آموزش و Access handover تحویل شده‌اند.

هزینه کل مالکیت را برای ۳۶ ماه حساب کنید

قیمت Build فقط هزینه ورود است. یک مدل ساده و نسخه‌دار بسازید:

TCO36 = Discovery + Design + Build + Content + Migration + 36 × (Hosting + License + Maintenance + Support + Usage) + Expected change + Risk reserve + Exit

همه اقلام ماهانه نیستند؛ فرمول را براساس قرارداد اصلاح کنید. Expected change را از Roadmap واقعی و Risk reserve را از عدم‌قطعیت بسازید، نه درصد جادویی. درآمد یا صرفه‌جویی مورد انتظار را جداگانه در Business case بیاورید تا هزینه با منفعت قاطی نشود.

برای سرویس خارجی، نوسان ارز، امکان تمدید و دسترسی عملی را Scenario کنید. برای سرویس داخلی نیز SLA، Export و استمرار کسب‌وکار را بررسی کنید. هزینه نگهداری، Update و Incident را با راهنمای پیش‌بینی هزینه نگهداری سایت کامل کنید.

هزینه را با سه سناریو مقایسه کنید

به‌جای یک عدد قطعی، سه سناریوی هم‌دامنه بسازید:

هر سه باید Baseline غیرقابل حذف را پاس کنند. Lean به‌معنای نبود Backup یا Accessibility نیست؛ یعنی صفحه و قابلیت کمتر.

سه مثال برای کسب‌وکار ایرانی

شرکت خدمات B2B با بودجه محدود

نسخه اول: صفحه اصلی، دو خدمت، سه Case، درباره، تماس، فرم Lead، Analytics و CRM دستی. صرفه‌جویی: حذف پنل مشتری، انیمیشن اختصاصی و تولید ۲۰ مقاله. خط قرمز: مالکیت دامنه، ارسال مطمئن Lead، نسخه موبایل و Backup.

فروشگاه با ۱۵۰ محصول

نسخه اول: دسته، محصول، جست‌وجو/فیلتر ضروری، سبد، پرداخت، ارسال، موجودی، سفارش و پشتیبانی. صرفه‌جویی: ورود دسته‌ای با CSV، یک Template محصول، حذف باشگاه مشتریان و Recommendation هوشمند تا داده کافی. خط قرمز: State پرداخت، قیمت/موجودی، Callback، Refund و تست بازگشت از درگاه.

استارتاپ دارای Workflow اختصاصی

به‌جای ساخت پلتفرم کامل، Landing و Concierge MVP با عملیات نیمه‌دستی راه‌اندازی می‌شود تا تقاضا و گلوگاه‌ها سنجیده شوند. صرفه‌جویی: اتوماسیون دیرتر. خط قرمز: رضایت داده، امنیت، Log و عدم وعده قابلیتی که عملیات دستی نمی‌تواند تحویل دهد.

چگونه درباره قیمت مذاکره کنیم؟

مذاکره مفید درباره Trade-off است، نه فقط درصد تخفیف.

• بپرسید حذف کدام Deliverable بیشترین کاهش هزینه و کمترین اثر را دارد.
• دو گزینه Scope با Baseline یکسان بگیرید.
• پرداخت را به Milestone و Acceptance قابل اثبات متصل کنید، نه تعداد روز.
• Dependency و کارِ کارفرما را با Deadline در قرارداد بنویسید.
• قیمت Change، Support و تمدید را پیش از Launch روشن کنید.
• برای ابهام زیاد، Discovery محدود و پولی پیش از Fixed quote انجام دهید.
• مالکیت، Exit و Handover را با تخفیف معاوضه نکنید.

پیشنهاد بسیار پایین ممکن است استراتژی ورود Vendor باشد، اما باید مدل درآمد بعدی روشن شود: لایسنس، Hosting اجباری، سهم فروش، تغییرات، تبلیغ یا هزینه خروج. هیچ‌کدام ذاتاً بد نیستند اگر شفاف و قابل مقایسه باشند.

برنامه ۳۰روزه برای کاهش هزینه پیش از عقد قرارداد

چک‌لیست طراحی سایت مقرون‌به‌صرفه

• Outcome، مخاطب، Journey و تصمیم‌گیر در Brief نوشته شده‌اند.
• Scope نسخه اول و فهرست صریح Not now وجود دارد.
• جریان اصلی از ورود تا پیگیری کسب‌وکار کامل است.
• پلتفرم براساس Fit، TCO و Exit انتخاب شده، نه Demo.
• قالب/افزونه Source، License، Update و QA دارد.
• محتوا Owner، Template و Deadline دارد.
• Componentهای مشترک و حالت Loading/Error/Empty تعریف شده‌اند.
• Proposalها Deliverable و Exclusion یکسان دارند.
• Change request و تعداد دور بازخورد روشن است.
• دامنه، DNS، Repository، داده و حساب‌ها انتقال‌پذیرند.
• Security، Backup/Restore، موبایل و Accessibility حذف نشده‌اند.
• مسیرهای P0 با Failure/Retry و دستگاه واقعی تست می‌شوند.
• SEO migration، Analytics و Baseline در Scope هستند.
• TCO سه‌ساله شامل تمدید، Usage، تغییر، ریسک و خروج است.
• پرداخت به Milestone و Acceptance قابل اثبات متصل است.
• پس از انتشار Owner، SLA، Runbook و بودجه نگهداری وجود دارد.

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

آیا طراحی سایت ارزان برای سئو بد است؟

نه. قیمت، فاکتور مستقیم کیفیت سئو نیست. سایت کوچک می‌تواند محتوای مفید، URL و لینک قابل Crawl، Metadata درست، سرعت مناسب و تجربه موبایل سالم داشته باشد. مشکل زمانی است که برای کاهش قیمت، محتوا، قابلیت Index، مهاجرت یا نگهداری حذف شود.

قالب آماده بهتر است یا طراحی اختصاصی؟

اگر نیاز و محتوا با ساختار قالب هماهنگ‌اند و Source، Update، Performance، RTL، Accessibility و خروج تأیید شده‌اند، قالب معتبر اقتصادی است. اگر برای هر بخش باید Override و افزونه اضافه شود، طراحی Component هدفمند ممکن است TCO کمتری داشته باشد.

حداقل امکانات نسخه اول سایت چیست؟

حداقل به مدل بستگی دارد، اما باید Journey اصلی را کامل کند: محتوای تصمیم، اقدام کاربر، دریافت و پیگیری توسط کسب‌وکار، پیام خطا/تأیید، سنجش، امنیت پایه، Backup، موبایل و مالکیت. تعداد صفحه به‌تنهایی MVP را تعریف نمی‌کند.

چرا دو شرکت برای یک سایت قیمت‌های بسیار متفاوت می‌دهند؟

ممکن است Scope، Template، محتوا، Integration، سطح Custom، QA، لایسنس، Hosting، پشتیبانی، مالکیت و Exit متفاوت باشند. یک RFP و Comparison matrix یکسان بفرستید و Deliverable، Assumption و Exclusion را مقایسه کنید.

قیمت اولیه مهم‌تر است یا هزینه نگهداری؟

هیچ‌کدام جدا کافی نیستند. قیمت راه‌اندازی، هزینه تکرارشونده، Usage، تغییر، ریسک و خروج را در TCO سی‌وشش‌ماهه ببینید. سپس آن را با Outcome و سناریوی رشد مقایسه کنید.

جمع‌بندی

برای طراحی سایت ارزان، استاندارد پایه را ارزان نکنید؛ Scope را کوچک کنید. یک هدف، یک Journey کامل، چند Template مشترک و پلتفرم متناسب انتخاب کنید. محتوا و تصمیم را زود آماده، تغییر را کنترل، Proposalها را هم‌سطح و هزینه سه‌ساله را شفاف کنید.

امنیت، مالکیت، Backup/Restore، موبایل، دسترس‌پذیری، مسیر درآمد، SEO migration و سنجش، هزینه‌های تزئینی نیستند. اگر بودجه به Baseline نمی‌رسد، انتشار را مرحله‌بندی کنید یا مدل ساده‌تری برگزینید؛ سایتی که کم‌تر انجام می‌دهد اما همان کار را درست انجام می‌دهد، واقعاً مقرون‌به‌صرفه است.

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