نمونه قرارداد طراحی سایت (Word)؛ با بندهایی که بیشتر قراردادها جا انداخته‌اند

قرارداد طراحی سایت معمولاً در بدترین لحظه بسته می‌شود؛ وقتی هر دو طرف عجله دارند، رابطه گرم است و هیچ‌کس دلش نمی‌خواهد درباره‌ی روز اختلاف حرف بزند. برای همین خیلی‌ها «نمونه قرارداد طراحی سایت» را جست‌وجو می‌کنند، اولین فایل Word را برمی‌دارند، اسم‌ها را عوض می‌کنند و امضا می‌کنند. ایراد کار اینجاست که بیشتر این نمونه‌ها دقیقاً همان بندهایی را ندارند که روز اختلاف به کارت می‌آید: سورس‌کد مال کیست، دامنه به نام کیست و اگر وسط کار جدا شدید، چه چیزی دستت می‌ماند.

ما در فراکو، استودیوی طراحی و توسعه‌ی سایت با پایگاه اهواز، هم قراردادهای خودمان را می‌نویسیم و هم گاهی قراردادهایی را می‌خوانیم که مشتری‌ها از پروژه‌ی قبلی‌شان می‌آورند و می‌پرسند «حالا چه کار کنم؟». از دل همین تجربه یک نمونه‌ی کامل نوشته‌ایم که رایگان دانلود می‌شود: بیست ماده و پنج پیوست، با جای خالی برای پر کردن. این مقاله می‌گوید چطور پرش کنی، هر بند چرا آنجاست و پیش از امضا چه چیزهایی را چک کنی.

پیش از هر چیز: این فایل یک نمونه‌ی عمومی است، نه مشاوره‌ی حقوقی، و ما وکیل نیستیم. هر پروژه شرایط خودش را دارد؛ متن نهایی را پیش از امضا به یک وکیل یا مشاور حقوقی نشان بده. هزینه‌ی یک جلسه مشاوره معمولاً در برابر مبلغ خود پروژه کوچک است.

دانلود نمونه قرارداد طراحی سایت (Word) و ترتیب درست پر کردنش

فایل را از این لینک بگیر: دانلود نمونه قرارداد طراحی سایت (Word). راست‌چین است، فونت فارسی دارد و در Word و نرم‌افزارهای مشابه باز و ویرایش می‌شود. داخلش این‌هاست:

• متن اصلی در بیست ماده: طرفین، تعاریف، موضوع، مدت، مبلغ و پرداخت مرحله‌ای، تعهدات دو طرف، تحویل و پذیرش، اصلاحات، مالکیت فکری و سورس‌کد، دامنه و میزبانی، پشتیبانی، سئو، محرمانگی، وجه التزام، فسخ و تحویل اطلاعات، قوه‌ی قهریه، حل اختلاف، اقامتگاه و نسخ قرارداد.
• پیوست ۱، شرح کار: جدول صفحه‌ها و قابلیت‌ها با ستون «شامل است؟»، فهرست کارهای خارج از قرارداد، و جدول قالب‌ها، افزونه‌ها و فونت‌های پولی.
• پیوست ۲: محتوا و موادی که کارفرما تحویل می‌دهد و موعد هرکدام.
• پیوست ۳: جدول مراحل، مهلت‌ها و سهم پرداخت هر مرحله.
• پیوست ۴: چک‌لیست تحویل نهایی و خروج؛ همان چیزی که در صورت فسخ هم پر می‌شود.
• پیوست ۵: شرایط پشتیبانی، اگر پشتیبانی ماهانه می‌خواهی.

ترتیب پر کردن مهم است. از صفحه‌ی اول شروع نکن؛ از پیوست ۱ شروع کن. تا وقتی معلوم نباشد دقیقاً چه چیزی ساخته می‌شود، نه مبلغ معنا دارد، نه مهلت. بعد پیوست ۳ را پر کن تا معلوم شود کار در چند مرحله و با چه خروجی‌ای جلو می‌رود. آخر سر سراغ متن اصلی برو: جاهای خالی را پر کن، از گزینه‌های داخل کروشه یکی را نگه دار و کادرهای خاکستری راهنما را پیش از امضا پاک کن.

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

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

چند نمونه‌ی پربازدیدی را که این روزها بالای نتایج جست‌وجو هستند خواندیم. مشکلشان بی‌دقتی نیست؛ این است که برای یک نوع پروژه‌ی خاص نوشته شده‌اند و بقیه را جا انداخته‌اند. سه الگو تقریباً در همه‌شان تکرار می‌شود.

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

پیش‌پرداخت بزرگ و جریمه‌ای که جریمه نیست. الگوی رایج، پنجاه درصد پیش‌پرداخت است؛ یعنی نصف پول پیش از دیدن حتی یک صفحه. کنارش هم معمولاً جریمه‌ی تأخیری با مبلغی نمادین برای هر روز آمده. این عدد کوچک بی‌خطر نیست: طبق ماده‌ی ۲۳۰ قانون مدنی، وقتی مبلغ خسارتِ تخلف در قرارداد شرط شده باشد، «حاکم نمی‌تواند او را به بیشتر یا کمتر از آن چه که ملزم شده است محکوم کند». یعنی عدد نمادین، در عمل سقف ادعای توست.

ابهام در مالکیت. جمله‌هایی از این دست که مجری می‌تواند طرح را امضا کند، یا اینکه اگر دامنه از طریق مجری ثبت شده باشد هزینه‌ی تمدیدش با کارفرماست، در این نمونه‌ها زیاد است. هیچ‌کدام جواب دو سؤال اصلی را نمی‌دهند: دامنه به نام چه کسی ثبت می‌شود، و سورس‌کد کِی و به چه شکلی به کارفرما می‌رسد.

شرح کار را پیوست کن، نه یک جمله در متن قرارداد

جمله‌ی «طراحی یک سایت شرکتی حرفه‌ای» در متن قرارداد تقریباً هیچ چیزی را تعیین نمی‌کند. تو از آن پنج صفحه با وبلاگ و فرم سفارش می‌فهمی، طراح سه صفحه‌ی ساده؛ هر دو هم با حسن‌نیت. جای جزئیات، متن اصلی نیست؛ یک پیوست جداست به اسم شرح کار که جزء جدایی‌ناپذیر قرارداد اعلام می‌شود. مزیتش این است که اگر وسط کار چیزی اضافه شد، یک الحاقیه‌ی امضاشده به همین پیوست اضافه می‌کنی و لازم نیست کل قرارداد را از نو بنویسی.

در پیوست ۱ فایل، هر صفحه یک ردیف است و هر قابلیت یک ردیف، با ستونی به اسم «شامل است؟». قاعده ساده است: چیزی که اینجا نیامده، جزو قرارداد نیست. سطح جزئیات هم مهم است. «درگاه پرداخت» کافی نیست؛ «درگاه پرداخت به نام کارفرما با تأیید پرداخت سمت سرور» کافی است. «ورود کاربر» کافی نیست؛ «ورود با کد پیامکی و نمایش سوابق سفارش» کافی است.

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

دو جدول دیگر هم در همین پیوست هست که کمتر کسی پرشان می‌کند ولی بعداً پول نگه می‌دارند: کارهایی که صراحتاً جزو قرارداد نیست (مثلاً عکاسی محصول یا نوشتن متن‌ها)، و قالب‌ها، افزونه‌ها و فونت‌های پولی با نوع مجوز و اینکه تمدید دوره‌ای دارند یا نه؛ هزینه‌ی پنهان خیلی از سایت‌ها همین تمدیدهای سالانه است.

حتی پلن‌های قیمت‌گذاری هم جای شرح کار را نمی‌گیرند. پلن نقره‌ای سایت شرکتی ما ۴۰ میلیون تومان است، تا ۸ صفحه با وبلاگ، سئوی فنی و پنل پیامکی؛ ولی «هشت صفحه» هنوز نمی‌گوید کدام هشت صفحه. فهرست کامل پلن‌ها در صفحه‌ی قیمت طراحی سایت آمده است.

مالکیت سورس‌کد، طراحی و محتوا را صریح بنویس

شاید شنیده باشی که «قانون خودش سورس‌کد را به کارفرما می‌دهد». این حرف نیمه‌درست است و همان نیمه‌ی غلطش دردسر می‌سازد. قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای (مصوب ۱۳۷۹) در بند «ب» ماده‌ی ۶ می‌گوید اگر هدف قرارداد پدید آوردن نرم‌افزار باشد، «حقوق مادی مربوط به حق تغییر و توسعه نرم‌افزار متعلق به استخدام کننده یا کارفرما است، مگر اینکه در قرارداد به صورت دیگری پیش‌بینی شده باشد».

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

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

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

خودمان همه‌ی سایت‌ها را با Next.js و React اختصاصی می‌نویسیم و سورس‌کد کامل را به مشتری تحویل می‌دهیم؛ سایت مال کسی است که پولش را داده. ولی این بند را از هر مجری‌ای که انتخاب می‌کنی بخواه، نه فقط از ما.

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

دامنه نشانی کسب‌وکار توست و از همه‌ی تکه‌های سایت دیرتر عوض می‌شود. برای دامنه‌های ‎.ir، موافقت‌نامه‌ی ثبت ایرنیک «دارنده امتیاز ثبت» را این‌طور تعریف می‌کند: «شخص حقیقی یا حقوقی که امتیاز دامنه به نام وی ثبت شده است». رابط‌های اداری، فنی و مالی هم کسانی‌اند که از سوی همین دارنده منصوب می‌شوند؛ مثلاً رابط فنی مسئول «نگهداری فنی کارگزار نام دامنه» است، نه صاحب آن.

دو بند دیگرِ همان موافقت‌نامه تکلیف را روشن‌تر می‌کند. بند ۴.۹ می‌گوید اگر استفاده از دامنه به شخص دیگری واگذار شود، مسئولیت همچنان با دارنده می‌ماند، «مگر اینکه انتقال رسمی ثبت انجام گیرد». و بند ۱۸.۱ می‌گوید انتقال «با توافق انتقال‌دهنده» انجام می‌شود. ترجمه‌ی عملی‌اش ساده است: اگر طراح دامنه را به نام خودش ثبت کرده باشد، برای گرفتنش رضایت او را لازم داری. اگر رضایت ندهد، طبق ماده‌ی ۳ سیاست‌نامه‌ی حل اختلاف ایرنیک، مرکز ثبت بر اساس دستور دارنده، دستور دادگاه یا مرجع داوری صالح، یا تصمیم هیئت رسیدگی اداری اقدام می‌کند؛ یعنی کار به مراجع رسمی می‌کشد.

یک نکته‌ی دیگر را هم خیلی‌ها نمی‌دانند: طبق سیاست کیست ایرنیک، از ژانویه‌ی ۲۰۲۳ (دی ۱۴۰۱) مشخصات دارنده و رابط‌ها در جست‌وجوی عمومی کیست (WHOIS) نمایش داده نمی‌شود. پس از بیرون نمی‌شود فهمید دامنه به نام کیست. تنها راه مطمئن این است که دامنه را در پنل ایرنیک خودت و زیر شناسه‌ی خودت ببینی.

ماده‌ی ۱۱ فایل همین را می‌نویسد: دامنه به نام کارفرما و با کارفرما به‌عنوان دارنده ثبت می‌شود و مجری اگر لازم باشد فقط رابط فنی است. برای دامنه‌های بین‌المللی هم حساب کاربری نزد ثبت‌کننده‌ی دامنه باید به نام و ایمیل خودت باشد؛ همین‌طور هاست، درگاه پرداخت، پنل پیامک و حساب‌های گوگل.

پرداخت مرحله‌ای، نه پیش‌پرداخت بزرگ

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

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

یک قدم جلوتر هم می‌شود رفت: دیدن چیزی واقعی پیش از امضا. ما در فراکو صفحه‌ی اصلی سایت را ظرف ۴۸ ساعت و پیش از هر قراردادی طراحی می‌کنیم. طراحی این پیش‌نمایش رایگان است و ۶۸۰ هزار تومان فقط بابت تولید تصاویر و بنرهای اختصاصی همان پیش‌نمایش گرفته می‌شود. اگر نپسندیدی، تعهدی برای ادامه نداری. اگر پسندیدی، بعد از یک گفت‌وگوی کوتاه قیمت ثابت می‌شود و پرداخت مرحله‌ای است؛ جلوتر از کاری که انجام شده، پرداختی نداری.

وجه التزام را هم همین‌جا واقعی کن. به‌جای عدد نمادین روزانه، درصدی از مبلغ همان مرحله برای هر روز کاری تأخیر بنویس و برایش سقف بگذار. برای دیرکرد پرداخت از طرف کارفرما هم تکلیف روشن کن؛ مثلاً حق مجری برای توقف کار تا زمان پرداخت. قراردادی که فقط یک طرف را جریمه می‌کند، معمولاً به امضای طرف دیگر نمی‌رسد.

دور اصلاحات و زمان‌بندی واقعی

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

دو چیز را از هم جدا کن. ایراد — یعنی چیزی که با شرح کار نمی‌خواند یا درست کار نمی‌کند — اصلاح حساب نمی‌شود و رفعش سقف ندارد. ولی هر چیزی که شرح کار را تغییر می‌دهد، مثل اضافه شدن صفحه یا قابلیت، «درخواست تغییر» است و مجری باید پیش از شروع، مبلغ و زمانش را کتبی بگوید. این بند جلوی دو دعوای همیشگی را می‌گیرد: «این که جزو کار بود!» و «این را که از اول نگفته بودید!».

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

برای اینکه حس عدد داشته باشی: ما سایت شرکتی را ۷ تا ۱۰ روز کاری و فروشگاه اینترنتی را ۱۰ تا ۱۴ روز کاری تحویل می‌دهیم، از زمانی که مواد اولیه دست تیم باشد. اگر کسی برای یک سایت چهارصفحه‌ای چند ماه وقت می‌خواهد، یا برای یک فروشگاه کامل سه روز، از هر دو بپرس این عدد از کجا آمده.

پشتیبانی، نسخه‌ی پشتیبان و بند خروج

بعد از تحویل، دو چیز متفاوت معمولاً با هم قاطی می‌شوند. یکی «دوره‌ی رفع اشکال» است: مدتی که مجری ایرادهای ناشی از کار خودش را بدون هزینه رفع می‌کند. دیگری «پشتیبانی» است: کار تازه و نگهداری که هزینه دارد و باید اختیاری باشد. اگر این دو یکی شوند، یا تو برای رفع ایراد پول می‌دهی یا مجری کار تازه را مجانی انجام می‌دهد. ماده‌ی ۱۲ فایل این دو را جدا کرده و پیوست ۵ برای شرایط پشتیبانی جا دارد: ساعات پاسخ‌گویی، زمان پاسخ به درخواست عادی و خطای جدی، و کارهایی که شامل نمی‌شود.

نسخه‌ی پشتیبان را هم با اسم و عدد بنویس: چه کسی، هر چند وقت یک‌بار و کجا. یک نسخه‌ی کامل هم همیشه باید دست خودت باشد.

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

پیوست ۴ فهرست همین تحویل است: سورس‌کد، پایگاه داده، فایل‌های طراحی، پنل دامنه و هاست، درگاه، پیامک و حساب‌های گوگل. درباره‌ی سرچ کنسول دقیق باش. طبق راهنمای گوگل، «مالک تأییدشده» کسی است که با یک نشانه‌ی تأیید، مثل فایل HTML روی سایت، مالکیتش را ثابت کرده؛ و مالک تأییدشده می‌تواند مالک دیگری را با حذف نشانه‌هایش کنار بگذارد. پس در تحویل، تو باید مالک تأییدشده باشی، نه کاربری که طراح اضافه‌اش کرده.

قرارداد طراحی سایت و سئو: چه چیزی هرگز نباید تضمین شود

وقتی طراحی و سئو در یک قرارداد می‌آیند، یک جمله‌ی خطرناک هم معمولاً همراهشان است: تضمین رتبه. رتبه در گوگل به رقابت آن عبارت، سابقه‌ی دامنه، محتوایی که منتشر می‌کنی و ده‌ها عامل دیگر بستگی دارد که هیچ‌کدامشان دست مجری نیست. کسی که «رتبه‌ی یک» را تضمین می‌کند، یا نمی‌داند چه می‌گوید یا می‌داند و راستش را نمی‌گوید. ما هم هیچ‌وقت رتبه تضمین نمی‌کنیم.

تضمین بازدید و فروش هم همین حکم را دارند. به‌جایشان، تعهدات سئو را به شکل کارهای قابل اندازه‌گیری بنویس: عنوان و توضیح اختصاصی برای هر صفحه، ساختار درست سرتیترها، نقشه‌ی سایت، داده‌ی ساختاریافته، نشانی‌های خوانا، سرعت قابل قبول روی موبایل، تعداد مشخص مقاله و یک گزارش دوره‌ای. این‌ها را روز تحویل می‌شود یکی‌یکی چک کرد؛ رتبه را نمی‌شود.

پیشنهادم این است که قرارداد ساخت و قرارداد سئوی ماهانه جدا باشند؛ اولی یک‌بار انجام می‌شود و تحویل مشخص دارد، دومی ادامه‌دار است و باید بشود ماه‌به‌ماه درباره‌اش تصمیم گرفت. در فراکو هم سئوی فنی پایه در ساخت هر سایت هست و خدمات سئوی ماهانه سرویسی جداست که می‌توانی بگیری یا نگیری.

اگر سایت فروشگاهی سفارش می‌دهی، این بندها را اضافه کن

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

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

چک‌لیست پیش از امضای قرارداد طراحی سایت

پیش از امضا این فهرست را یکی‌یکی تیک بزن. هر ردیفی که جوابش «نمی‌دانم» است، همان‌جایی است که باید سؤال بپرسی:

• شرح کار پیوست شده و ستون «شامل است؟» برای همه‌ی ردیف‌ها پر است.
• روش ساخت و هر قالب یا افزونه‌ی پولی، با نوع مجوز، نوشته شده است.
• مبلغ ثابت است و هزینه‌های جانبی مثل دامنه، هاست و کارمزدها جدا مشخص شده‌اند.
• پرداخت مرحله‌ای است و پیش‌پرداخت از سهم مرحله‌ی اول بیشتر نیست.
• تاریخ شروع، مهلت هر مرحله و تعداد دورهای اصلاحات روشن است.
• بند مالکیت می‌گوید سورس‌کد، فایل‌های طراحی و محتوا با پرداخت هر مرحله به تو منتقل می‌شود.
• دامنه به نام تو به‌عنوان دارنده ثبت می‌شود و هاست، درگاه، سرچ کنسول و پیامک هم به نام تو باز می‌شوند.
• بند فسخ برای هر دو طرف هست و تحویل اطلاعات در صورت فسخ نوشته شده است.
• هیچ‌جا رتبه یا فروش تضمین نشده و وجه التزام واقعی، سقف‌دار و دوطرفه است.
• یک وکیل متن نهایی را خوانده است.

اگر هنوز در مرحله‌ی انتخاب مجری هستی، دوازده سؤال پیش از سفارش طراحی سایت را هم ببین.

قدم بعدی

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

اگر خواستی با فراکو جلو بروی، مسیر از دیدن شروع می‌شود، نه از امضا: پیش‌نمایش صفحه‌ی اصلی سایتت را درخواست کن تا ظرف ۴۸ ساعت ببینی کار چه شکلی می‌شود، و برای دیدن روند کامل همکاری، مراحل سفارش طراحی سایت را بخوان. قرارداد ما را هم که دیدی، با همین چک‌لیست بسنجش.