عصر البرمجيات الشخصية: تطبيقات مصممة لك ولسبعة من أصدقائك
تُقضي البرامج الشخصية، والتطبيقات المصممة خصيصًا من قِبل شخص واحد لعشرة أشخاص، على برامج SaaS الموجهة للسوق الجماهيري في حالات استخدام متخصصة. إليكم ما يجب على المصممين فعله الآن.

البرمجيات الموجهة للجماهير مرحلة عابرة، وليست حالة دائمة. لقد كانت السنوات العشرون الماضية من انتشار برمجيات SaaS الموجهة للسوق الجماهيري بمثابة تحول مؤقت نتيجة لارتفاع تكلفة التوزيع، وهذا التحول يقترب من نهايته.
لأول مرة منذ فجر الحوسبة، يستطيع شخص واحد كتابة تطبيق عملي يوم الأحد لتسعة أشخاص محددين ونشره قبل النوم. هذا ليس مجرد هواية جانبية، بل هو تحول جذري في هوية مطوري البرمجيات، ولمن تُصمم، وحتى في مفهوم التصميم نفسه.
ما هي البرمجيات الشخصية؟
البرمجيات الشخصية هي برمجيات يصممها شخص واحد، غالبًا لنفسه، وأحيانًا لعشرة أشخاص محددين، ونادرًا ما تُصمم لسوق معين. إنها مصممة خصيصًا عن قصد، لا عن طريق الصدفة. يعرف المطور كل مستخدم بالاسم.
يكتب جيفري ليت منذ سنوات عن البرمجيات المرنة، وهي فكرة مفادها أن مستخدمي الأداة يجب أن يكونوا قادرين على إعادة تشكيلها. لينوس لي يصمم أدوات صغيرة لأفكاره الخاصة. ابتكرت ماغي أبلتون مصطلح "المطورين الحفاة" لوصف موجة غير المهندسين الذين بات بإمكانهم الآن إطلاق برامج عاملة بكفاءة عالية، وذلك بفضل انخفاض تكلفة تطويرها بشكل كبير.
بجمع هذه العوامل، نحصل على فئة جديدة من البرامج. برامج تستهدف المطور نفسه بالإضافة إلى عدد قليل من الأصدقاء أو العائلة أو الزملاء، وتكمن قيمتها في ملاءمتها لهذه المجموعة الصغيرة بدقة متناهية.
لماذا الآن، ولماذا لم يكن الحال كذلك في عام ٢٠١٥؟
تغير أمران في آن واحد. فقد جعلت مساعدات الذكاء الاصطناعي من الممكن اقتصاديًا لشخص واحد بناء تطبيق حقيقي في غضون ساعات قليلة. وانخفضت تكاليف التوزيع والاستضافة والنشر والدفع والمصادقة إلى الصفر أو ما يقاربها.
في عام ٢٠١٥، كان بناء تطبيق متخصص يتطلب ستة أشهر من العمل ليلاً ونهارًا، وتكاملًا مع منصة Stripe يستغرق ثلاثة أيام، وعملية نشر تستغرق أسبوعًا كاملًا. لم تكن هذه الحسابات مجدية لأي شركة أصغر من شركة ناشئة. وكان الوصول إلى شريحة واسعة من حالات الاستخدام أمرًا مستحيلاً.
في عام ٢٠٢٦، سيقتصر استخدام التطبيق نفسه على نافذة واحدة، ونشر واحد لـ Vercel، ومخطط Convex. انخفض الحد الأدنى للجمهور المستهدف من عشرات الآلاف إلى "أنت وسبعة من أصدقائك". هذا ليس تحسينًا في الأدوات، بل هو فتح آفاق جديدة في هذا المجال.
العامل الثالث هو الذوق. نشأ جيل من المصممين والمطورين على البرمجيات، وتكونت لديهم آراء راسخة حول عيوب التطبيقات التي استخدموها يوميًا، والآن يملكون القدرة على إصلاحها بأنفسهم دون الحاجة إلى إذن أحد.

أمثلة واقعية، وليست افتراضية
هذه ليست تجربة فكرية. فالبرامج الشخصية تعمل بالفعل على العديد من أجهزة الكمبيوتر المحمولة.
يستخدم الناس Notion كنظام إدارة محتوى مصغر خاص بعائلاتهم، مع واجهات وقوالب قد لا يفهمها أي شخص خارج نطاق الأسرة. تُطلق مشاريع Replit وLovable الجانبية في أمسية واحدة، ويستخدمها عشرة زملاء عمل، وتؤدي مهامًا حقيقية بكفاءة لسنوات. تطبيقات لتنظيم جداول العائلة، ومولدات فواتير مخصصة، ومخططات وجبات مصممة خصيصًا على غرار تطبيقات food-plan-pi ذات الغرض الواحد، جميعها موجهة لجمهور يتراوح بين أربعة وخمسة عشر مستخدمًا.
تُنتج حركة البرمجيات المرنة أدوات يكون فيها المستخدم هو نفسه المُحرر. يُمكّن تطبيق Tana المستخدمين من بناء أنظمة معلوماتهم الخاصة بدلًا من الاقتصار على قالب جاهز. ويُقدم تطبيق Capacities عملًا مشابهًا. أما نظام Obsidian البيئي للملحقات فهو عبارة عن اقتصاد متكامل من الأدوات الشخصية التي يتم تبادلها بين الأشخاص ذوي التفكير المتقارب.
النمط: مُطور واحد، جمهور صغير، ملاءمة دقيقة. لا يتم توسيع نطاق أي شيء. لا يتم تسويق أي شيء. البرنامج موجود ببساطة، للأشخاص الذين صُمم من أجلهم، وهذا هو الهدف الأساسي.
كيف يختلف عن البرمجة بدون كتابة أكواد
البرمجة بدون كتابة أكواد كانت تعتمد على قوالب جاهزة. أما البرمجيات الشخصية فهي برمجيات مصممة خصيصًا. الفرق يكمن في الهدف.
تُقدّم لك أداة البرمجة بدون كتابة أكواد مجموعة ليغو وتطلب منك بناء منزل يُشبه المنزل الموجود في الكتالوج. الفكرة الأساسية هي أن آلاف الأشخاص سيبنون منازل مُشابهة على نفس المنصة، فالجدوى الاقتصادية تعتمد على ذلك.
أما البرامج الشخصية، فتبدأ من سؤال مُختلف. ليس "أيّ قالب يُناسب احتياجاتي؟" بل "ما الذي يتطلبه وضعي الفعلي، وكيف أُبرمجه؟". لا يختار المُطوّر من بين خيارات مُتاحة، بل يصف الغرض، غالبًا بلغة إنجليزية بسيطة، لمساعد ذكاء اصطناعي، ويحصل على كود يُناسب احتياجاته تمامًا.
هذا مُهم لأن الأدوات القائمة على القوالب لها حدود. أي شيء لا يُناسب القالب يتم تعديله أو حذفه، بينما لا توجد حدود للأدوات المُخصصة. إذا احتاج نظام المحاسبة الخاص بك إلى عمود لـ "المبلغ الذي يتقاضاه كايل هذا الشهر بنسبة 10% ثابتة"، فما عليك سوى إضافته. لا حاجة لطلب من مُورّد، ولا تراكم للميزات، ولا انتظار.
الذيل الطويل يصل أخيرًا إلى القاع
وصف كريس أندرسون مفهوم الذيل الطويل في عام 2004، لكن البرمجيات لم تصل إليه فعليًا. يمكن لبرامج SaaS الموجهة للسوق الشامل أن تخدم بشكل مربح شريحة المستخدمين الرئيسية والمتوسطة العليا. أما ما عدا ذلك، فهو عبارة عن فراغ من الاحتياجات غير الملباة التي لا تبرر وجود شركة.
تملأ البرامج الشخصية هذا الفراغ. حالات الاستخدام التي لم تكن كافية لدعم شركة ناشئة، وسير العمل المتخصص، والخصوصيات المنزلية، وأدوات فرق العمل المكونة من ستة أفراد، أصبحت الآن بيئة طبيعية لتطبيقات المستخدم الواحد.

انقلبت المعادلة الاقتصادية رأسًا على عقب. حالة استخدام لثمانية مستخدمين كانت في السابق مستحيلة التنفيذ، أما الآن فهي سهلة التنفيذ للغاية. تخيل تطبيق ذلك على مليون فئة متخصصة، وستحصل على اقتصاد برمجيات لا يشبه بأي حال من الأحوال قوائم التطبيقات الأكثر رواجًا في متجر التطبيقات.
ما يندثر، وما يبقى، وما ينمو
لن تستحوذ البرامج الشخصية على جميع برامج SaaS. التحول غير متساوٍ، ويمكن التنبؤ بالفائزين والخاسرين إذا نظرنا إلى مكان وجود القيمة الحقيقية.
أول ما يندثر هو برمجيات SaaS الموجهة لجمهور واسع، والتي تستهدف حالات استخدام متخصصة. فئة "نحن العلامة التجارية رقم 10 لمُدربي الكلاب". أي شخص يقدم منتجًا متخصصًا بشكل طفيف على أساس أساسي عام، سيجد نفسه الآن في منافسة مع عصر يوم أحد ورسالة نصية. هذه المنافسة محسومة.
أما ما يبقى وينمو فهو المنصات والأساسيات والبنية التحتية. مثل العلامات التجارية رقم 12 و4 وSupabase و7 وClerk ومزودي الذكاء الاصطناعي وReplit وLovable. تتوسع طبقة الأدوات والتقنيات مع ازدياد عدد مطوري البرمجيات، لا تتقلص. وينطبق الأمر نفسه على أساسيات نظام التصميم ومكتبات واجهة المستخدم ومجموعات الرموز وآليات المصادقة التي يعيد الجميع استخدامها.
أما ما يبقى أيضًا فهو برمجيات السوق الشامل الحقيقية، حيث تكون حالة الاستخدام عالمية بالفعل. البريد الإلكتروني، والتقاويم، والمتصفحات، وأنظمة التشغيل، والبحث، وشبكات التواصل الاجتماعي. لا يحلّ البرنامج الشخصي محلّ واتساب، بل يحلّ محلّ أداة إدارة المشاريع التي كانت وكالة تضمّ خمسة عشر شخصًا تدفع مقابلها 800 دولار شهريًا.

مقارنة بين برامج SaaS الموجهة للجمهور العام والبرامج الشخصية
يتضح الفرق جليًا عند وضع النموذجين في جدول واحد.
| الأبعاد | برامج SaaS الموجهة للجمهور العام | البرامج الشخصية |
|-----------|------------------|-------------------|
| الجمهور المستهدف | من آلاف إلى ملايين | من شخص واحد إلى بضع عشرات |
| التموضع | "للفرق التي تقوم بـ X" | "لي ولسبعة من أصدقائي" |
| التوزيع | إعلانات مدفوعة، تحسين محركات البحث، فريق المبيعات | إرسال في دردشة جماعية |
| التسعير | اشتراك شهري لكل مستخدم | رسوم ثابتة، تبرع، أو مجانًا بين الأصدقاء |
| أولوية التصميم | تعريف مستخدم جديد في ستين ثانية | ملاءمة مثالية لشخص معروف |
| التخصيص | قائمة الإعدادات، علامات الميزات | تعديل المصدر، طلب تغييره من الذكاء الاصطناعي | | هدف العمر الافتراضي | غير محدد، مع ميزات جديدة باستمرار | طالما استمرت حالة الاستخدام، ثم يُحفظ في الأرشيف |
| حافز المُصنِّع | الاستحواذ على سوق | حل مشكلة محددة |
لاحظ صف أولوية التصميم. هنا يتغير دور المصمم بشكل ملحوظ.
وظيفة المصمم الجديدة
إذا كنت مصممًا، فإن العمل ينتقل من تحتك. تصميم المنتجات الموجهة للسوق الشامل يركز على تسهيل استخدام المنتج للمستخدمين الجدد، وتقليل العقبات في أسوأ الحالات، وعدم افتراض أي سياق. أما تصميم البرامج الشخصية فيفترض السياق، ويحدد المستخدمين، ويُحسِّن الملاءمة، لا العمومية.
يتضمن العمل التصميمي الجديد ثلاث خطوات أساسية: تحديد السياق، وإبداء الذوق، والتحرير.
تحديد السياق هو تزويد مساعد الذكاء الاصطناعي أو فريق صغير بمعلومات كافية حول الفئة المستهدفة من هذا المنتج لضمان ملاءمة الناتج. ليس المقصود "تصميم مُخطط وجبات"، بل "تصميم مُخطط وجبات لعائلة مكونة من أربعة أفراد، أحدهم نباتي، والأطفال لا يفضلون القوام المختلف، والطاهي لديه ثلاثون دقيقة فقط في ليالي الأسبوع". الموجز هو التصميم.
الذوق هو المعيار. عندما يكون الكود رخيصًا والإرشادات مجانية، فإن العقبة الرئيسية تكمن في جودة الناتج. مهمة المصمم هي معرفة ما يُعتبر جيدًا لهذه الفئة من المستخدمين تحديدًا، ورفض كل ما لا يتوافق معها. قلّ الرسم، وزد التقييم.
التعديل هو التكرار. لا تُسلّم البرامج الشخصية للمهندسين وتُشحن، بل تُصقل بمرور الوقت، وغالبًا أثناء التشغيل، على يد المصمم الذي هو أيضًا المُنشئ أو يعمل بجانبه. لم يعد ملف Figma هو المنتج النهائي، بل التطبيق قيد التشغيل.
كيفية التصميم لجمهور من 10 أشخاص
التصميم لعشرة أشخاص ليس نسخة مصغرة من التصميم لعشرة آلاف. إنه تخصص مختلف. إليك سبعة مبادئ أساسية:
- حدد أسماء جميع المستخدمين. جهّز قائمة. اعرف احتياجات كل شخص، وما يكرهه، وما يتحمله. إذا لم تستطع كتابة هذه القائمة، فأنت لا تزال تصمم لمفهوم مجرد.
٢. تجاوز مرحلة الإعداد الأولي. لا يحتاج المستخدمون إلى جولة تعريفية، فهم أصدقاؤك. أدخلهم إلى التطبيق مُهيأً لهم مسبقًا. اعرض الإجابة مباشرةً بدلًا من السؤال.
٣. ركز على المستخدم المُحدد، لا على المستخدم المتوسط. لا وجود لمستخدم متوسط عندما يكون هناك عشرة مستخدمين. يوجد فقط آرون، الذي يُفضل الوضع الداكن، وسيرينا، التي تحتاج إلى اختصار لوحة المفاتيح. كلاهما يحصل على ما يُريد.
٤. دع التصميم يبدو غير مُتقن في الأماكن المُناسبة. لا يحتاج البرنامج الشخصي إلى موقع تسويقي، أو صفحة أسعار، أو صورة رئيسية جذابة. يُمكن أن تكون الشاشة الرئيسية قائمة، والإعدادات ملف JSON. ركز على اللمسة الجمالية حيث يشعر المستخدم بها، لا حيث يتوقعها.
٥. اجعله قابلاً للتعديل. سيرغب المستخدمون في إجراء تغييرات. صممه بطريقة تُسهل هذه التغييرات، حتى لو كان ذلك يعني واجهة أقل صقلًا. المرونة أهم من الصقل في هذا النطاق.
٦. صمّم لجهاز واحد، وليس لجميع الأجهزة. إذا كان جمهورك يستخدم التطبيق على جهاز كمبيوتر محمول، فتجاهل الهواتف المحمولة. وإذا كانوا يستخدمونه على الهواتف، فتجاهل أجهزة الكمبيوتر المكتبية. التصميم المتجاوب الشامل هو تفكير موجه للسوق الجماهيري.
٧. خطط للأرشفة، لا للخلود. لا يحتاج هذا البرنامج إلى البقاء للأبد. يكفي أن يعمل طالما استمرت الحاجة إليه. وعند انتهاء الحاجة، قم بأرشفته ببساطة.

موجة المطورين المبتدئين
يلخص مصطلح ماغي أبلتون "المطورين المبتدئين" جانبًا كان يغيب عن صناعة البرمجيات. فالموجة القادمة من مطوري البرمجيات ليست من المهندسين الذين تعلموا التصميم، بل من المصممين والكتاب والباحثين والمحاسبين والمعلمين والمشغلين الذين تعلموا كيفية إطلاق المنتجات.
لم يكن هؤلاء الأشخاص ليحصلوا على وظيفة هندسية براتب عالٍ من خلال دورات تدريبية مكثفة. لديهم وظائفهم اليومية وحياتهم الخاصة ومشاكل محددة يسعون لحلها. ما يملكونه الآن هو القدرة على وصف ما يريدونه باللغة الإنجليزية، والحصول على كود برمجي جاهز للعمل، وتشغيله على حاسوب محمول أو منصة مجانية.
هؤلاء هم من يُطوّرون البرامج الشخصية في الغالب، وليس المؤسسين المتفرغين. إنهم أشخاص ذوو معرفة واسعة بالمجال، ومهارات هندسية متواضعة، وصبرٌ كافٍ للتجربة والتطوير المستمر مع مساعد ذكاء اصطناعي حتى يعمل البرنامج بكفاءة. والنتيجة هي برامج صاغها أشخاص يفهمون المشكلة فعلاً، وهو نوع من البرامج افتقر إليه هذا القطاع بشدة.
والنتيجة الثانوية هي أن ذوق التصميم في البرامج الشخصية يميل إلى أن يكون أكثر دقةً منه في برامج SaaS الموجهة للجمهور العام. فالمطور ليس مدير منتج مبتدئًا لديه خطة عمل يدافع عنها، بل هو الشخص الذي يعيش المشكلة. عندما يرى شيئًا قبيحًا أو خاطئًا، يُصلحه في نفس الساعة. حلقة التغذية الراجعة سريعة جدًا لدرجة أن التصميم السيئ لا يمكنه البقاء لأكثر من عطلة نهاية أسبوع.
ما الذي يتغير في صناعة البرمجيات
عندما يكون الجمهور صغيرًا والمطور قريبًا، تتغير صناعة البرمجيات. تتغير الإعدادات الافتراضية، وتختلف المفاضلات.
تصبح الموثوقية أكثر تسامحًا. إذا تعطل التطبيق لعشرة مستخدمين، يسمع المطور بذلك في دردشة جماعية ويقوم بإصلاحه. لا يوجد اتفاقية مستوى خدمة، ولا نظام مناوبة للدعم، ولا تصعيد للمشاكل. يبدو هذا سيئًا حتى تدرك أن مظهر موثوقية برامج SaaS الموجهة للسوق الشامل هو في الغالب ضريبة على المستخدم.
يصبح التخصيص هو الإعداد الافتراضي بدلًا من كونه ميزة. تتعامل برامج السوق الشامل مع التخصيص كقائمة إعدادات، أو قائمة من الخيارات التي أضافها المطور على مضض، بينما تتعامل معه البرامج الشخصية كعنصر أساسي. إذا أردت إضافة عمود، يضيفه المطور، وإذا أردت تغيير الألوان، يتم تغييرها. لا يمتلك المنتج بنية جامدة تُعاد صياغتها دوريًا.
يختلف شكل التوثيق. فملف README لأداة يستخدمها عشرة مستخدمين عبارة عن فقرة تعريفية، ولقطة شاشة، ورقم هاتف الشركة المُصنِّعة. أما قاعدة المعرفة المكونة من ثلاثين صفحة، والجولة التعريفية داخل التطبيق، ومقالات المساعدة، وأداة الدردشة، فكلها تُعدّ عبئًا إضافيًا لا يحتاجه هذا الجمهور الصغير.
تتغير خيارات الأداء. يمكنك إطلاق تطبيق أبطأ لعشرة مستخدمين تثق بهم لأنهم سيُخبرونك عندما يُعيقهم. لكن لا يمكنك إطلاق تطبيق بطيء لمليون شخص غريب. البرامج الشخصية تتجاوز الكثير من التحسينات المُبكرة.
ما يعنيه ذلك للأخلاقيات، والمحافظ الاستثمارية، والتسعير
تُثير البرامج الشخصية تساؤلات حقيقية حول ملكية البيانات، والتقييد، واستمرارية الاستخدام، والإجابات في معظمها أفضل مما قدمته لنا برامج SaaS. تبقى البيانات حيثما تُخزِّنها، غالبًا في قاعدة بياناتك الخاصة أو ملف تتحكم فيه. ويقل التقييد لأن الشركة المُصنِّعة موجودة، وليست مجرد بائع لديه أسباب لإبقائك مُقيَّدًا.
يُعدّ ضمان استمرارية البرامج الشخصية التحدي الأكبر. تتوقف البرامج الشخصية عن العمل عندما يتوقف مطوروها عن صيانتها، وهذا أمرٌ وارد. والجواب الصريح هو أن هذا أمرٌ طبيعي. فمعظم البرامج لا ينبغي أن تدوم إلى الأبد، ومقابل ملاءمة البرنامج وملكيته، عليك أن تتقبل فكرة أن التطبيق قد يستمر لمدة عامين ثم يختفي.
يتغير نموذج التسعير بتغير وحدة القيمة. فالاشتراكات الشهرية لكل مستخدم تفترض وجود سوق. أما البرامج الشخصية فلها عملاء، وليس مجرد زبائن، والعملاء يدفعون بطرق مختلفة.
رسوم ثابتة للمشاريع، وعقود صيانة دورية للتعديلات المستمرة، واقتصاد الهدايا بين الأصدقاء، ومكافآت مقابل ميزات محددة. المطور لا يدير منصة SaaS، بل يدير ورشة عمل صغيرة متخصصة، أو يبني برامج مجانية لأشخاص يهتم لأمرهم. وكلا الخيارين مجدٍ اقتصاديًا في الوقت الراهن.
بالنسبة للمصممين الذين يقدمون خدماتهم، فإن التحول يكمن في الانتقال من "تصميم نظام لإطلاق SaaS" إلى "تصميم وبناء أداة مخصصة لفريق أو عائلة محددة". المنتج النهائي هو التطبيق قيد التشغيل، وليس ملف Figma. التسعير يعتمد على قيمة المشكلة التي تم حلها، وليس على عدد الساعات المدفوعة.
بالنسبة لمحفظة الأعمال، سيبدو العمل أكثر غرابة. مواقع تسويقية أقل احترافية، ولقطات شاشة أكثر لأدوات داخلية مبتكرة تُحل مشاكل حقيقية لمجموعات حقيقية. لن تكون دراسة الحالة "أعدنا تصميم لوحة تحكم لشركة ناشئة في جولة التمويل الثانية"، بل "أنشأنا أداة لتنظيم الرحلات المدرسية لثلاثين ولي أمر، وقد استُخدمت بالفعل".
ما يجب على المصممين فعله هذا العام
التغيير قادم سواء شاركت فيه أم لا. إليك ما يبدو عليه التوجه الذكي في عام ٢٠٢٦.
ابدأ بالبناء لنفسك. اختر مشكلة تواجهها بالفعل، في حياتك أو عملك، وابنِ الأداة باستخدام Replit أو Lovable أو Cursor، أو ببساطة Claude Code وحساب Vercel. ليس الهدف هو تعلم الأدوات، بل الشعور بتجربة العمل ضمن فريق كامل لتطوير برنامج.
ابدأ بتطوير برنامج لعشرة أشخاص تعرفهم. بعد تطوير أداة شخصية، طوّر أداة لمجموعة صغيرة، كعائلة، أو نادٍ، أو فريق عمل. لاحظ كيف تتغير قرارات التصميم عندما تعرف كل مستخدم بالاسم.
توقف عن حصر تصميمك في معايير الجودة المُصممة للسوق الجماهيري. غيّر وجهة نظرك. لم يعد السوق يبحث عن "تجربة استخدام سلسة لجمهور واسع"، بل يبحث عن "الملاءمة، والذوق، والقدرة على إطلاق المنتج النهائي". أظهر ذلك في ملف أعمالك.
انتبه إلى أساليب كتابة البرامج المرنة. ليت، لي، أبلتون، رواد Ink and Switch، مطورو الأدوات الصغيرة على تويتر وThreads. تُصاغ مفردات وأنماط ولغة تصميم البرامج الشخصية في هذه النقاشات حاليًا. أتقنها.
يُعدّ عصر البرامج الشخصية أهم ما شهده تصميم البرامج خلال الخمسة عشر عامًا الماضية. ستستمر برامج SaaS الموجهة للجمهور العام في الوجود ضمن الفئات التي تُناسبها. لكنّ سوق المنتجات المتخصصة قد انفتح للتو، والذين سيُبادرون بالوصول إليه سيُحددون معنى تصميم المنتجات لجمهور من عشرة أشخاص. كن واحدًا منهم.
hero:
key: hero
prompt: "Voxel illustration. A small house-sized app glowing warmly, with 10 little floating screens around it, each tailored to a different person. Soft pastel. Editorial. The composition does not include any human figures."
alt: "Voxel illustration of a small house-sized app glowing warmly with ten tiny tailored screens floating around it"
width: 1600
height: 900
inline-1:
key: mass-vs-personal
prompt: "Voxel split illustration: left, a giant generic SaaS dashboard. Right, ten tiny bespoke apps, each warm and specific. Soft pastel. The composition does not include any human figures."
alt: "Voxel split image showing one giant generic SaaS dashboard on the left and ten tiny bespoke apps on the right"
width: 1400
height: 900
inline-2:
key: distribution-collapse
prompt: "Voxel illustration showing a long-tail curve labeled 'use cases' with tiny apps populating the previously-empty tail. Soft pastel."
alt: "Voxel long-tail curve labeled use cases with tiny apps filling the previously empty tail"
width: 1400
height: 900
inline-3:
key: design-for-ten
prompt: "Voxel illustration of a designer's workspace tuned for an audience of 10: name tags on the wall, context notes, an obvious local fit. Soft pastel. The composition does not include any human figures."
alt: "Voxel designer workspace with name tags and context notes tuned for an audience of ten"
width: 1400
height: 900
inline-4:
key: what-dies-what-survives
prompt: "Voxel illustration: on one side, generic SaaS dashboards crumbling into mist. On the other, infrastructure platforms growing taller. Soft pastel. The composition does not include any human figures."
alt: "Voxel illustration of generic SaaS dashboards crumbling on one side and infrastructure platforms growing on the other"
width: 1400
height: 900
Want help designing software for ten people instead of ten thousand? Brainy ships personal software with the same craft as our biggest brand work.
Get Started

