پیام کوتاه است و همیشه در بدترین زمان می‌رسد: «سایت بالا نمی‌آید.» چند ساعت بعد معلوم می‌شود دامنه منقضی شده، ایمیل یادآوری تمدید به جیمیل شخصی فریلنسری رفته که دو سال پیش سایت را ساخت، و او دیگر جواب تلفن نمی‌دهد. یا نسخه‌ی آرام‌تر همین ماجرا: می‌خواهید با تیم تازه‌ای کار را ادامه دهید و تیم جدید اولین سؤالش را می‌پرسد — «سورس‌کد کجاست؟» — و شما برای اولین بار می‌فهمید جوابش را نمی‌دانید.
این یادداشت درباره‌ی پرسشی است که اغلب کسب‌وکارها تا روز بحران نمی‌پرسند: دارایی‌های دیجیتال شما دقیقاً به نام چه کسی است؟ موضع ما صریح است. سایت، محصول و داده‌ای که پولش را داده‌اید، تا وقتی دامنه، هاست، کد و دسترسی‌های اصلی‌اش در اختیار خودتان نیست، متعلق به شما نیست؛ فقط از آن استفاده می‌کنید. و استفاده‌ی امروز هیچ تضمینی برای فردا نیست.
مخاطب این متن دو تصویر آشناست. امیرحسین، صاحب کسب‌وکاری کوچک یا متوسط که سایتش را با اعتماد به یک آشنا یا فریلنسر ساخته و هرگز فرصت نکرده بپرسد «پنل هاست به نام کیست؟». و سارا و رضا، مدیرانی در شرکتی رو به رشد که چند تیم و چند پیمانکار عوض کرده‌اند و حالا کلیدهای زیرساخت میان ایمیل کارمندان سابق، آژانس قبلی و یک فایل اکسل قدیمی پخش شده است. گرین‌لبز استودیوی تحویل محصول دیجیتال، نرم‌افزار و وب، اتوماسیون و هوش مصنوعی است و این مسئله را بارها در نقطه‌ی شروع همکاری‌های تازه دیده‌ایم: پیش از آن‌که بتوان چیزی ساخت، باید معلوم شود چه چیزی واقعاً مال مشتری است.
دارایی دیجیتال فقط «سایت» نیست
وقتی از مالکیت سایت حرف می‌زنیم، بیشتر مدیران به طراحی صفحه‌ها فکر می‌کنند. اما آنچه سایت یا محصول را زنده نگه می‌دارد، زنجیره‌ای از حساب‌ها و دسترسی‌هاست که هرکدام می‌تواند نقطه‌ی گروگان‌گیری باشد:
- دامنه و DNS: حساب ثبت‌کننده‌ی دامنه (برای دامنه‌های .ir در ایرنیک) و جایی که رکوردهای DNS مدیریت می‌شود.
- هاست یا زیرساخت ابری: پنل هاست، حساب سرویس ابری، سرور مجازی و صورت‌حساب آن.
- سورس‌کد: مخزن کد (GitHub، GitLab یا هر جای دیگر)، شاخه‌ی اصلی، و مستند استقرار.
- پنل مدیریت و پایگاه داده: حساب ادمین اصلی سایت یا محصول و نسخه‌ی پشتیبان داده.
- ایمیل سازمانی: دامنه‌ی ایمیل و حسابی که ایمیل‌های بازیابی رمز همه‌ی سرویس‌ها به آن می‌رود.
- داده‌ی رشد: Google Analytics، Search Console، پیکسل‌های تبلیغاتی و حساب‌های تبلیغات.
- سرویس‌های عملیاتی: درگاه پرداخت، پنل پیامک، نماد اعتماد، کلیدهای API سرویس‌های بیرونی و حساب‌های فروشگاه اپلیکیشن.
هر حلقه‌ای از این زنجیره که به نام شخص دیگری باشد، کل زنجیره را به اندازه‌ی همان حلقه ضعیف می‌کند. مهم نیست طراحی چقدر زیباست؛ اگر دامنه به نام دیگری است، برند شما روی زمین اجاره‌ای ایستاده است.
چرا این اتفاق تقریباً همیشه می‌افتد
هیچ‌کس تصمیم نمی‌گیرد دارایی‌اش را به نام دیگری ثبت کند. این وضعیت محصول سه عادت بی‌سروصداست.
اول، سرعت در شروع. روز اول پروژه همه عجله دارند. ساده‌ترین راه این است که پیمانکار با حساب خودش دامنه بخرد، هاست بگیرد و مخزن کد را در فضای شخصی‌اش بسازد. قرار است «بعداً منتقل شود». آن بعداً معمولاً هیچ‌وقت نمی‌رسد، چون تا وقتی همه‌چیز کار می‌کند، انتقال اولویت هیچ‌کس نیست.
دوم، اعتماد شخصی به‌جای فرآیند. در کسب‌وکارهای کوچک، همکاری اغلب با یک آشنا شروع می‌شود و رابطه جای قرارداد را می‌گیرد. اعتماد چیز خوبی است، اما اعتماد جایگزین مالکیت نیست. آدم‌ها جابه‌جا می‌شوند، مهاجرت می‌کنند، شغل عوض می‌کنند یا صرفاً گرفتار می‌شوند. دسترسی‌ای که به یک آدم وابسته است، با تغییر زندگی همان آدم از دست می‌رود.
سوم، وابستگی به‌عنوان مدل درآمد. همه‌ی آژانس‌ها چنین نیستند، اما بعضی آگاهانه دسترسی را نگه می‌دارند، چون مشتری‌ای که کلید ندارد نمی‌تواند برود. در این مدل، تمدید سالانه، هاست اختصاصی گران و «هزینه‌ی تحویل کد» راه نگه داشتن مشتری است، نه کیفیت کار. اگر تجربه‌ی کار با چند آژانس پراکنده را داشته‌اید، احتمالاً نسخه‌ای از این ماجرا را در چند ایجنسی، یک دردسر هم شناخته‌اید.
هزینه‌ی واقعی را کجا می‌پردازید
مسئله‌ی مالکیت تا روز جدایی نامرئی است. درست به همین دلیل خطرناک است: وقتی دیده می‌شود که دیگر قدرت چانه‌زنی ندارید.
روز قطع همکاری
رایج‌ترین سناریو ساده است. رابطه با پیمانکار تمام می‌شود — به خوبی یا به بدی — و شما می‌خواهید با تیم دیگری ادامه دهید. حالا هر دسترسی باید «درخواست» شود. اگر طرف مقابل همکاری کند، هفته‌ها صرف انتقال می‌شود؛ اگر نکند، گاهی بازسازی از صفر ارزان‌تر از پس گرفتن است. در هر دو حالت، پروژه‌ای که فکر می‌کردید تمام شده، دوباره هزینه می‌خواهد. همین الگو را در پروژه‌ات تمام شده؛ پس چرا هنوز کسی جوابگو نیست؟ از زاویه‌ی مسئولیت بعد از تحویل بررسی کرده‌ایم؛ مالکیت دارایی‌ها روی دیگر همان سکه است.
روز رفتن یک کارمند
در شرکت‌های رو به رشد، خطر بیشتر از درون است. توسعه‌دهنده‌ای که سرور را راه انداخت، مدیر بازاریابی‌ای که حساب تبلیغات را با ایمیل شخصی ساخت، یا مدیر فنی‌ای که رمزها را فقط در ذهن خودش نگه می‌داشت. وقتی این آدم‌ها می‌روند، بخشی از زیرساخت با آن‌ها می‌رود. نه از سر بدجنسی؛ از آن رو که هیچ‌کس آن دسترسی را سازمانی تعریف نکرده بود.
روز رشد، فروش یا سرمایه‌گذاری
سرمایه‌گذار، خریدار یا حتی شریک تجاری جدی دیر یا زود می‌پرسد مالکیت فکری و زیرساخت کجاست. شرکتی که نمی‌تواند نشان دهد کدش در مخزن خودش است و دامنه‌اش به نام خودش ثبت شده، در بهترین حالت با تأخیر و در بدترین حالت با تخفیف سنگین روبه‌رو می‌شود. دارایی‌ای که سند ندارد، در هیچ ارزش‌گذاری‌ای کامل حساب نمی‌شود.
هزینه‌ی خاموش امنیت
دسترسی‌های پراکنده فقط مشکل مالکیت نیستند؛ مشکل امنیت هم هستند. هر حساب فراموش‌شده با رمز قدیمی و بدون احراز هویت دومرحله‌ای، دری باز است که هیچ‌کس مراقبش نیست. سازمانی که نمی‌داند چه کسانی به پنل‌هایش دسترسی دارند، نمی‌تواند ادعا کند امن است.
پنج پرسش برای امروز
لازم نیست منتظر بحران بمانید. پاسخ این پنج پرسش را همین هفته پیدا کنید. اگر برای هرکدام مکث کردید، همان‌جا مسئله دارید.
- اگر فردا ایمیل تمدید دامنه برسد، به صندوق چه کسی می‌رسد؟
- آیا می‌توانید بدون تماس با هیچ‌کس، وارد پنل هاست یا حساب ابری شوید و صورت‌حساب را ببینید؟
- آیا مخزن سورس‌کد در حساب یا سازمانی است که خودتان مالک آن هستید — و آخرین نسخه‌ی کد واقعاً همان است که روی سرور اجرا می‌شود؟
- آیا در Google Analytics و Search Console نقش «مالک» دارید، یا فقط کسی شما را به‌عنوان کاربر اضافه کرده است؟
- اگر کسی که سایت را ساخته امروز در دسترس نباشد، چه کسی می‌داند سایت چگونه مستقر و پشتیبان‌گیری می‌شود؟
پرسش چهارم را دست‌کم نگیرید. در سرویس‌های گوگل، تفاوت میان «مالک» و «کاربر» تفاوتی اساسی است؛ راهنمای مدیریت مالکان و کاربران Search Console به‌روشنی نشان می‌دهد که مالک می‌تواند دیگران را حذف کند و کاربر نمی‌تواند. اگر شما کاربرید، دیگری مالک است.
اصل ساده: شرکت مالک است، پیمانکار دسترسی دارد
راه‌حل پیچیده نیست، فقط انضباط می‌خواهد. یک اصل را بپذیرید و همه‌چیز را با آن بسنجید: هر دارایی به نام کسب‌وکار ثبت می‌شود و هر پیمانکار یا کارمند فقط دسترسی محدود و قابل لغو می‌گیرد. مالکیت و دسترسی دو چیز متفاوت‌اند و بیشتر بحران‌ها از یکی دانستن این دو شروع می‌شود.
در عمل، این اصل به چند تصمیم مشخص ترجمه می‌شود:
- یک ایمیل نقش‌محور بسازید. حسابی مثل it@ یا admin@ روی دامنه‌ی خود شرکت، که مالک همه‌ی سرویس‌هاست و به یک نفر خاص وابسته نیست. ایمیل‌های بازیابی و تمدید باید به این‌جا بیایند، نه به جیمیل هیچ فرد.
- دامنه را به نام حقوقی کسب‌وکار ثبت کنید. اگر امروز به نام شخص دیگری است، انتقالش را در اولویت بگذارید. این کم‌هزینه‌ترین بیمه‌ای است که می‌خرید.
- کد را در سازمان خودتان نگه دارید. مخزن باید در Organization متعلق به شرکت باشد و پیمانکار به‌عنوان عضو با نقش محدود اضافه شود. اگر کد در حساب شخصی کسی است، انتقال مخزن در GitHub کاری چنددقیقه‌ای است؛ فقط باید خواست.
- رمزها را در یک گاوصندوق سازمانی نگه دارید. یک password manager تیمی که مالکش شرکت است، با احراز هویت دومرحله‌ای که به دستگاه یا شماره‌ی شخص خاصی گره نخورده است.
- استقرار را مستند کنید. یک سند یک‌صفحه‌ای کافی است: کد کجاست، چگونه روی سرور می‌رود، پشتیبان کجا ذخیره می‌شود و چگونه بازیابی می‌شود. سندی که فقط در ذهن یک نفر است، سند نیست.
قرارداد را از همین زاویه بخوانید
بسیاری از مشکلات مالکیت را می‌شد در یک بند قرارداد حل کرد. پیش از امضای هر قرارداد طراحی، توسعه یا نگهداری، این موارد را صریح بنویسید:
- مالکیت فکری کد، طراحی و محتوا پس از تسویه به کارفرما منتقل می‌شود.
- همه‌ی حساب‌ها از روز اول به نام کارفرما ساخته می‌شوند و پیمانکار فقط دسترسی اجرایی دارد.
- در پایان هر فاز، تحویل شامل کد کامل، مستند استقرار و فهرست همه‌ی حساب‌ها و دسترسی‌هاست — نه فقط لینک سایت.
- در صورت پایان همکاری، پیمانکار ظرف مدت مشخصی همه‌ی دسترسی‌ها را تحویل می‌دهد و دسترسی خودش را حذف می‌کند.
اگر پیمانکاری با این بندها مشکل دارد، همین مقاومت پاسخ شماست. شریک تحویل‌محور از شفافیت مالکیت نمی‌ترسد، چون مشتری را با کیفیت کار نگه می‌دارد، نه با کلیدهایی که پس نمی‌دهد. همین منطق را درباره‌ی شروع درست همکاری در پروژه‌ی دیجیتال از امضای قرارداد شروع نمی‌شود نوشته‌ایم: روشن کردن دسترسی‌ها جزو کار است، نه کاغذبازی اضافه.
برای امیرحسین: از کجا شروع کنیم
اگر کسب‌وکار کوچکی دارید و این متن نگرانتان کرده، لازم نیست همه‌چیز را یک‌شبه درست کنید. ترتیب درست ساده است: اول دامنه، بعد ایمیل سازمانی، بعد هاست و پشتیبان، و در آخر کد و داده‌ی رشد. دامنه را اول بگذارید چون از دست دادنش برند شما را می‌برد؛ بقیه را می‌توان بازسازی کرد، اما نامی که مشتری‌ها با آن شما را می‌شناسند جایگزین ندارد.
یک فایل ساده بسازید و جلوی هر دارایی سه ستون بنویسید: به نام کیست، ایمیل بازیابی‌اش چیست، و چه کسانی دسترسی دارند. همین فهرست یک‌صفحه‌ای، از هر قرارداد پشتیبانی‌ای که امضا کرده‌اید ارزشمندتر است. و اگر پیمانکار فعلی‌تان همکاری می‌کند، از او بخواهید انتقال را همین ماه انجام دهد. این درخواست بی‌اعتمادی نیست؛ حرفه‌ای بودن است.
برای سارا و رضا: مالکیت را فرآیند کنید
در شرکتی رو به رشد، مسئله فقط انتقال یک‌باره نیست، بلکه جلوگیری از پراکندگی دوباره است. سه فرآیند کوچک کافی است تا این وضعیت تکرار نشود:
- ورود و خروج افراد را به دسترسی‌ها گره بزنید. هر ورود یک فهرست دسترسی دارد و هر خروج همان فهرست را برعکس اجرا می‌کند. offboarding بدون حذف دسترسی، نیمه‌کاره است.
- بازبینی دوره‌ای دسترسی‌ها. هر سه ماه یک‌بار فهرست کسانی را که به پنل‌های حیاتی دسترسی دارند مرور کنید و هرچه دیگر لازم نیست حذف شود.
- وابستگی به یک نفر را بسنجید. برای هر سیستم حیاتی بپرسید اگر فلانی فردا نباشد، چه کسی می‌تواند آن را اداره کند؟ اگر پاسخ «هیچ‌کس» است، ریسک شما نه فنی، بلکه سازمانی است.
این‌ها کار تیم فنی به‌تنهایی نیست؛ تصمیم مدیریتی است. وقتی مالکیت دارایی‌های دیجیتال را به سلیقه‌ی هر تیم واگذار می‌کنید، هر جابه‌جایی کوچک می‌تواند به بحران بزرگ تبدیل شود. ساختار درست تیم و نقش‌ها همان‌قدر در این مسئله سهم دارد که ابزار.
نشانه‌های شریکی که می‌شود به او اعتماد کرد
اگر قرار است با تیم یا آژانس تازه‌ای کار کنید، چند نشانه‌ی ساده نشان می‌دهد طرف مقابل مالکیت شما را جدی می‌گیرد:
- پیش از شروع کار، خودش می‌پرسد حساب‌ها به نام چه کسی ساخته شود.
- کد را در مخزن شما می‌سازد یا در پایان هر فاز به مخزن شما منتقل می‌کند.
- تحویل را با فهرست دسترسی‌ها و مستند استقرار انجام می‌دهد، نه فقط با لینک نهایی.
- درباره‌ی پایان همکاری، بدون حالت دفاعی، صریح حرف می‌زند.
ما در گرین‌لبز این نشانه‌ها را حداقل استاندارد هر همکاری جدی می‌دانیم، نه امتیاز ویژه. اگر در حال ساخت یا بازسازی سایت و محصولتان هستید، می‌توانید درباره‌ی خدمات طراحی و توسعه‌ی نرم‌افزار و وب گرین‌لبز بیشتر بخوانید؛ و اگر در حال تصمیم‌گیری درباره‌ی ساخت محصول اختصاصی هستید، نرم‌افزار سفارشی برای کسب‌وکار ایرانی؛ کی ارزش دارد و کی بودجه می‌سوزاند نقطه‌ی شروع خوبی است.
پرسش‌های رایج
اگر دامنه به نام فریلنسر قبلی است و او پاسخ نمی‌دهد، چه کنیم؟ اول همه‌ی مدارک پرداخت و مکاتبات را جمع کنید. سپس از طریق ثبت‌کننده‌ی دامنه و، برای دامنه‌های .ir، از مسیرهای رسمی ایرنیک پیگیری کنید. هرچه زودتر شروع کنید، پیش از رسیدن تاریخ انقضا گزینه‌های بیشتری دارید.
آیا سپردن دسترسی کامل به پیمانکار اشتباه است؟ خیر. پیمانکار برای کار کردن به دسترسی نیاز دارد. اشتباه این است که مالکیت را به او بسپارید. دسترسی قابل لغو بدهید و مالکیت را نزد خودتان نگه دارید.
از کجا بفهمیم کد روی سرور همان کدی است که تحویل گرفته‌ایم؟ از تیم بخواهید فرآیند استقرار را از مخزن شما اجرا کند و مستند کند. اگر استقرار فقط از روی سیستم شخصی یک نفر ممکن است، کد واقعی هنوز در دست شما نیست.
آیا این موضوع برای کسب‌وکار کوچک هم اهمیت دارد؟ بیشتر از هر جای دیگر. شرکت بزرگ شاید بتواند بازسازی را تحمل کند؛ کسب‌وکار کوچک معمولاً یک دامنه، یک سایت و یک فرصت دارد.
جمع‌بندی
مالکیت سایت و دارایی‌های دیجیتال موضوعی فنی به نظر می‌رسد، اما در اصل تصمیمی مدیریتی است: آیا آنچه ساخته‌اید واقعاً مال شماست، یا فقط تا وقتی رابطه خوب است در اختیارتان قرار دارد؟ دامنه، هاست، سورس‌کد و دسترسی‌های اصلی را امروز به نام خودتان کنید، نه روزی که کسی دیگر پاسخ نمی‌دهد. کسب‌وکاری که کلیدهای خودش را دارد، شریکش را بر اساس کیفیت انتخاب می‌کند، نه از سر ناچاری.
