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