وداعاً Lovable: بنينا athr21.com إزاي

قفلت حساب Lovable الشهر ده. مش عشان الأداة وحشة. عشان بطلت أحتاجها، والفاتورة بطلت تبقى منطقية.

الحسبة اللي خلتني أقفله بسيطة. Lovable بياخد فلوس على البناء، وبعدين بياخد تاني على كل تعديل. وبعدين Lovable Cloud بيحاسبك لما الموقع يكبر، وهو أصلاً مبني فوق Supabase اللي ليه tier مجاني تقدر تستخدمه بنفسك. وفي نفس الوقت أنا دافع فعلاً في اشتراك AI يقدر يعمل الكلام ده كله. Claude Cowork في حالتي، بس ChatGPT أو Manus بيشتغلوا بنفس الطريقة. إنك تدفع مرتين على قدرة واحدة، ده بالظبط نوع التسريب اللي الشركات بتأجرني عشان ألاقيه عندها.

فبنيت athr21.com بنفسي. وأنا مش مبرمج. الموقع اللي بتقرأ فيه دلوقتي عدّى النسخة العاشرة، وفاتورة الاستضافة صفر. النسخة العاشرة اتعملت في يوم واحد: ٣٠ commit يوم ١٧ أغسطس، ما بين الساعة ٢:٣٠ الفجر و٩:١٥ بالليل. دي الطريقة، بالترتيب اللي حصل فعلاً، وبتفاصيل كفاية إنك تمشي عليها كدليل تركيب.

الخطوة صفر: العقل التاني جه الأول

الموقع مكانش أول حاجة اتبنت. الموقع كان ناتج من حاجة أقدم منه: عقل تاني شغال، مشروع فيه أهدافي وتموضعي والبراند والسياق كله عايشين كملفات، الـ AI بيقرأها قبل ما يعمل أي حاجة.

عملياً، قبل ما أول جلسة موقع تتفتح، العقل كان فيه أربع ملفات عملوا أغلب الشغل:

دي الخطوة اللي الناس بتفوّتها، وهي كل السر. لما الـ AI يبقى عارف الكلام ده كله من الأول، جملة «اعملّي موقع» بتبطل تبقى طلب مبهم وتبقى عملية تجميع. الكلام اللي على الصفحة الرئيسية متكتبش في جلسة الموقع. كان قاعد جاهز في العقل التاني، مستني سطح يظهر عليه.

ولما الطبقة دي بتتبني، التطبيقات مش بتقف عند المواقع. نفس ملفات السياق دي طلعت بعد كده عروض، وتقارير، ومقالات زي اللي بتقرأه ده، والأتوميشن اليومي اللي هتقابله في الخطوة أربعة. ابني العقل مرة واحدة، وكل حاجة بعده بتبقى أرخص.

الخطوة واحد: البراند قبل الكود

قبل أي سطر كود، جلسة واحدة طلّعت نظام براند كامل: بنفسجي على أسود مع لمسة lime، خط واحد لكل لغة، علامة من تسع خلايا، وليستة قصيرة من الكلمات الممنوعة. النظام ده عايش كملف في العقل التاني. وكل جلسة لمست الموقع بعد كده كانت بتقرأه الأول.

عشان كده بعد عشر نسخ الموقع لسه شكله واحد وواضح إن شخص واحد عمله. الثبات مش بييجي من ذوق بتطبقه كل مرة. بييجي من معيار مكتوب بيتطبق أوتوماتيك.

التعليمة العملية لو ماشي معايا: متخليش الـ AI يفتح code editor قبل ما يعمل معاك مقابلة ويكتب الملف ده. عشر دقايق أسئلة. هتحس إنها بطيئة. هي أسرع حاجة هتعملها في الأسبوعين.

الخطوة اتنين: الـ stack المجاني

الـ stack مقصود يكون ممل، وكل حتة فيه ببلاش:

تلات تفاصيل في الجدول ده شايلين وزن أكتر من شكلهم.

الفورم مقفول بالطريقة الصح. جدول Supabase عليه row-level security بسياسة واحدة بالظبط: المفتاح العام اللي جوه الصفحة يقدر يضيف صف واحد للفورم، ومايقدرش يقرأ أي حاجة خالص. نشر المفتاح ده مبيكشفش حاجة. البيانات بتتقري من الداشبورد، عمرها من الموقع. اطلب من الـ AI بتاعك «insert-only row-level security على جدول الفورم» وخليه يشرحلك السياسة قبل ما تنشر.

الـ footer بيكتب نسخته بنفسه. ثابت VERSION ومعاه hash الكوميت، بيتحطوا وقت البناء. انزل لآخر الصفحة دي وهتشوفه. لما حاجة تبان غلط، الـ footer بيقولك إيه اللي لايف فعلاً قبل ما تضيع ساعة بتصلّح مشكلة caching.

النشر طقس، مش مهارة. كل حاجة عن الإصدار عايشة في ملف واحد الـ AI كتبه اسمه PUSH.md: التلات أوامر، خطوات التأكيد، والأعطال المعروفة وحلولها. الإصدار هو:

git push
npm run build && npx wrangler deploy
وبعدين اتأكد: افتح الموقع بـ ?cb=1، بص على نسخة الـ footer،
جرّب الفورم، واتأكد إن الصف وصل قاعدة البيانات.

الكلام ده شكله تقني. عملياً كل حتة كانت تعليمة واحدة للـ AI، وهو اللي ظبط الحسابات وكتب الإعدادات وسابلي الملف اللي بيشرح أنشر إزاي. أنا براجع وأدوس enter. الحسابات اللي محتاج تعملها بنفسك، مرة واحدة: GitHub وCloudflare وSupabase. كلهم ببلاش.

الخطوة تلاتة: اتعلم بالتكرار

النسخة الأولى طلعت لايف في جلسة واحدة: صفحة، وفورم شغال، وصف اتأكدنا إنه وصل قاعدة البيانات. مكانتش عظيمة. ومكانش مطلوب منها تبقى.

ده تاريخ النسخ الحقيقي، من سجل الـ repository، عشان تشوف «حاجة واحدة في النسخة» يعني إيه عملياً:

عادتين خلوا الجلسات تتراكم بدل ما تتوه.

كل نسخة كان ليها هدف متسمّي قبل ما الجلسة تبدأ. مش «حسّن الموقع». كان «الـ hero مش بيشرح المنتج، صلّح الـ hero». لو مقدرتش أسمّي الحاجة الواحدة الغلط، مكنتش بفتح جلسة.

التغييرات الكبيرة كان ليها spec من صفحة واحدة الأول. أي حاجة هيكلية، الـ AI كان بيكتبلها مستند قصير بالمشكلة وشرايح الشغل في فولدر specs قبل ما يلمس كود، وكل شريحة تنفع تطلع لوحدها. ولما جلسة كانت بتقف في النص، اللي بعدها كانت بتبدأ من brief جاهز بدل ما أعيد الشرح. كده الـ ١٥ جلسة اتصرفوا كأنهم جلسة واحدة طويلة.

الإيقاع ده هو الدرس الحقيقي بتاع المقال. أنا ماتعلمتش web development. أنا اتعلمت أكرر: طلّع نسخة، بص لها، سمّي أوحش حاجة فيها، صلّحها، طلّع تاني. كل نسخة كانت صغيرة كفاية تتراجع في دقايق. لو تعرف تلف اللفة دي، حاجز المهارة خلص.

الخطوة أربعة: الموقع بقى بيحسّن نفسه

الجزء اللي مكنتش هشتريه من أي أداة بناء مواقع. فيه مهمة متجدولة بتشتغل كل يوم جوه الـ workspace بتاعي وبتلف اللفة دي:

ملف الطابور هو العقد. فيه القواعد اللي التشغيلة لازم تمشي عليها (تغيير واحد في المرة، ماتلمسش أسعار ولا أسامي عملا، عمرك ما تنشر)، والطابور مترتّب، وقسم متركن للقرارات اللي بتاعتي أنا مش بتاعة اللفة، وسجل مؤرّخ لكل اللي اتعمل. المهمة المتجدولة بتقرأه، بتلتزم بيه، وبتضيف عليه. آخر حاجات نزلت منها أنا مكتبتش منها سطر: صورة Open Graph، ملف robots، schema للمقالات، لينكات داخلية، ومقالات drafts.

الطابور ده عايش من غير انتباهي. في الأيام اللي مبفكرش فيها في الموقع خالص، الموقع بيتحسن فعلاً. الموقع بطل يبقى مشروع وبقى عملية شغالة.

اعملها بنفسك

لو شغلك أصلاً ماشي جوه workspace فيه AI، انسخ ده وابدأ:

I want to build and run my company website the way athr21.com was built.
Work through these stages in order, one at a time, and wait for my review
between stages:

1. SECOND BRAIN FIRST. Before any code, interview me and write my context
   as files in this project: what the company does, who it serves, the
   offer structure, decisions already made, and how I write. Read
   athr21.com/writing/build-your-second-brain-in-7-steps/ for the method.
2. BRAND FILE. From that context, write a brand system file: colours,
   type, voice, banned words. Every later session must read it first.
   Do not open a code editor before this file exists.
3. FREE STACK. Scaffold a static site (Astro or similar, vanilla CSS).
   Set up: a free GitHub repository for the code, Cloudflare's free tier
   for hosting, a free Supabase project for the contact form with
   row-level security allowing insert only (explain the policy to me
   before shipping), and Wrangler for deployment. Add a VERSION constant
   stamped in the footer with the commit hash. Write me a PUSH.md with
   the exact release commands, the verification steps (cache-busted URL,
   footer version, form test, database row), and known failure modes.
4. ITERATE. Ship version one in this session: one page, working form,
   confirmed database row. Then improve one named thing per session,
   I name the thing before the session starts. For structural changes,
   write a one-page spec with shippable slices first. Never redesign
   everything.
5. DAILY LOOP. Create an ENHANCEMENTS.md holding: the rules a run must
   obey, an ordered queue, a parked section for my decisions, and a
   dated log. Then create a daily scheduled task that completes the top
   item, one small reviewable change per run, logs it, and never
   deploys. I ship manually after review.

Rules: never publish or deploy without showing me first. Never invent
claims, pricing, or client names. Keep every change small enough to
review in two minutes.

الـ prompt ده هو النسخة المضغوطة من الـ ١٥ جلسة بتوعي. مش هيوفرلك التكرار، ومش المفروض يوفره. التكرار هو اللي بتتعلم منه النظام كفاية إنك تثق فيه.

والنقطة الأعمق قايمة من غير أي موقع أصلاً. اكتب سياقك مرة واحدة برة دماغك، وكل حاجة بعده، مواقع وعروض وتقارير وأتوميشن، هتبقى تجميع مش خلق من الصفر. ودي نفس الفكرة اللي The Brain بيركّبها جوه الشركات، بس على مقاس شركة كاملة.