از آنجایی که یکی از مهم‌ترین اهداف فازِ استارتاپ، اثباتِ منطقی‌بودن ادامه‌ی پروژه می‌باشد، لازم است که حداقل، یک معماری بالقوه در اختیار داشته باشیم که بتوان به وسیله‌ی آن سیستمی با هزینه‌ی منطقی و میزان قابل قبولی از ریسک‌ها ایجاد نمود. به عنوان مثال، ممکن است برای ایجاد یک معماری client/server سه آلترناتیو در نظر داشته باشیم؛ با تحلیل کارکِردها و وظیفه‌مندی‌های مطلوب در نسخه‌ی اول و همچنین نسخه‌های بعدی سیستم، قابلیت تطابق با سایر سیستم‌ها و نیازمندی‌های خاص عملیاتی و نگهداری سیستم، ممکن است هر کدام از این سه آلترناتیو را انتخاب نماییم.
برای اطمینان از این موضوع، طرح پرسش‌های زیر مهم است:
- آیا سیستم‌های مشابه دیگری ساخته شده‌اند، در این صورت این سیستم‌ها کدام‌اند و از چه معماری یا فناوری‌هایی بهره گرفته‌اند؟ هزینه‌ی شما برای استفاده از هریک از این فناوری‌ها چه مقدار می‌باشد؟
- در ارتباط با یک سیستمِ درحالِ تکامل، آیا معماری فعلی پاسخگوی نیازهای جدید می‌باشد یا اینکه باید معماری را متحوّل نمود؟
- چه فناوری‌هایی را باید در توسعه‌ی سیستم به‌کار گرفت؟ آیا فناوری‌های جدیدی را باید تهیه نمود؟ هزینه و ریسک‌های مرتبط با هریک از انتخاب‌های موجود چیست؟
- چه مؤلفه‌های نرم‌افزاری (بانک اطلاعاتی، میان‌افزارها، و مانند آن) در سیستم لازم است؟ آیا باید آنها را خریداری نمود؟ آیا می‌توان از پروژه‌های موجودِ فعلی، آنها را موردِ استفاده‌ی مجدد قرار داد؟ هزینه‌ی تخمینی چه میزانی است؟ چه ریسک‌هایی در این رابطه وجود خواهد داشت؟
در برخی از موارد، برای درک بهتر آلترناتیوهای موجود و ریسک‌های مرتبط، لازم خواهد بود که بعضی از عناصر کلیدی معماری و یا حتی معماری‌های پیشنهادی مختلف، پیاده‌سازی شود. در پروژه‌هایی که تصوّر محصول نهایی برای ذینفعان آن مشکل است، باید پیش‌الگوهایی (پروتوتایپ‌هایی) که دارای قابلیت‌های عملیاتی هستند، تهیه شود.
در پایانِ فازِ استارتاپ باید اطلاعات کافی درباره‌ی ریسک‌هایی که با آنها روبرو خواهیم شد، داشته باشیم. خصوصاً در رابطه با ریسک‌های مرتبط با فناوری و دارایی‌های قابل استفاده‌ی مجدد، مانند چارچوب‌های معماری و بسته‌های نرم‌افزاری. در فازِ بعدی که آن‌را فازِ معماری (تشریح) می‌نامند، جزئیات مرتبط با معماری (راهکار) تشریح و تثبیت خواهد شد.
