관리자 없이 사용자용 화면만 있는 경우에 적합합니다. 로그인/결제/연동이 붙으면 공수가 늘어납니다.

• 랜딩+문의
• 콘텐츠 웹
• 간단한 예약 폼

대부분의 서비스는 관리자 화면이 꼭 필요합니다(회원/콘텐츠/주문/예약 관리 등).

• 콘텐츠 업로드/승인
• 회원 관리
• 예약/주문 관리

일반적인 서비스(커머스/예약/커뮤니티)는 RN/Flutter로 충분한 경우가 많습니다. 고성능 그래픽/특수 센서 기능이 많으면 네이티브가 유리할 수 있어요.

• 커머스 앱
• 예약/매칭 앱
• 콘텐츠 앱

앱만 만들면 운영이 어려운 경우가 많습니다. 운영자가 데이터/주문/예약/회원/공지 등을 관리할 관리자 화면이 함께 필요한 케이스입니다.

• 주문/예약/환불 처리
• 공지/이벤트 관리
• 회원/리뷰 관리

아주 고성능/특수 기능이 많거나, 네이티브 SDK 의존성이 큰 경우에 선택합니다. 일반 서비스는 크로스플랫폼이 더 효율적인 경우가 많아요.

• 고성능 카메라/편집
• AR/3D
• 디바이스 센서/백그라운드 고급 제어

서비스를 웹과 앱 모두로 제공하면 화면/테스트/배포가 늘어납니다. MVP 단계에선 앱만 또는 웹만으로 시작하는 경우도 많습니다.

• 앱 중심 + 웹 보조
• 웹 쇼핑몰 + 앱
• B2B 웹 + B2C 앱

완성도보다 '출시'가 우선입니다. 디자인/운영 도구/자동화는 최소화하고, 필요한 기능만 넣는 방식이에요.

• 베타 출시
• 투자/검증용
• 런칭 일정이 매우 촉박한 경우

대부분의 서비스에 가장 적합합니다. QA/로그/관리자 기능 등을 포함해 운영 가능한 수준으로 맞춥니다.

• 운영/유지보수 전제 서비스
• 고객 대응 필요
• 일반 외주 개발

권한 체계, 감사 로그, 고급 모니터링, 다중 환경 배포 등 운영 품질 요구가 높은 경우에 선택합니다.

• 금융/헬스케어/민감데이터
• 대규모 운영
• 내부 보안 규정 강함

단순 랜딩/소개/문의 폼 같은 형태입니다. 데이터 저장이나 사용자별 기능이 필요하면 백엔드가 필요합니다.

• 회사 소개
• 이벤트 랜딩
• 간단 문의 폼

속도가 빠르고 비용 효율이 좋습니다. 다만 복잡한 정산/고급 권한/특수 레거시 연동이 많으면 커스텀이 필요할 수 있어요.

• 일반 앱 MVP
• 커뮤니티/콘텐츠
• 간단 예약/알림

예: 인증은 Firebase, 결제/정산/특수 로직은 서버로 처리하는 형태입니다. 실제 서비스에서 자주 쓰는 구성입니다.

• PG/정산 연동
• 외부 API 2~3개
• 복잡한 데이터 처리

정교한 권한/정산/복잡한 비즈니스 로직이 있거나, 향후 확장성이 중요하면 이 구성이 유리합니다.

• 복잡한 정산/수수료
• 권한 레벨 다수
• 데이터 규모/성능 요구

• 완성된 UI 시안 제공
• 디자인팀이 있음

화면 구성은 대략 정해져 있고, 스타일/컴포넌트/시안 작업이 필요한 경우입니다.

• 와이어는 있음
• 레퍼런스 확실
• 디자인 가이드 필요

사용자 흐름/정보 구조를 설계하고 그 위에 UI까지 만드는 방식입니다. 결과물 품질은 좋아지지만 공수는 증가합니다.

• 서비스 구조가 아직 불명확
• 처음 만드는 서비스
• 사용자 경험이 핵심

대부분의 외주에서 필요한 단계입니다. 애매한 부분을 정리해 개발 리스크를 줄입니다.

기획이 없거나 매우 러프한 경우에 적합합니다. 요구사항을 구조화하는 데 시간이 듭니다.