거절에도 기준이 있습니다
저희 상담에는 견적보다 먼저 하는 일이 있습니다. 이 프로젝트를 지금 시작하는 것이 타당한가를 판단하는 것입니다. 타당하지 않다고 보이면 그렇게 말씀드리고, 더 현실적인 방향을 권합니다.
어떤 경우에 그런 답이 나가는지 8가지로 정리했습니다. 발주를 검토 중이라면 자가 진단 리스트로 써 보셔도 좋습니다.
맡기지 않는 게 나은 8가지
1. 기성 솔루션으로 충분한 표준 프로젝트. 표준 쇼핑몰, 소개 사이트, 예약 페이지라면 검증된 솔루션이 더 싸고 빠르고 안정적입니다. 맞춤 개발은 솔루션의 틀이 사업의 발목을 잡기 시작할 때 필요한 것입니다.
2. 아이디어 검증 전의 첫 MVP. 아직 고객 반응을 본 적 없는 아이디어라면, 개발 계약보다 검증이 먼저인 경우가 많습니다. 랜딩 페이지 하나로 수요를 재어 보고, 설문이나 사전 신청으로 지불 의사를 확인하고, 노코드로 핵심 흐름만 흉내 내 보는 것. 이런 검증은 며칠이면 됩니다. 검증 안 된 가설을 수천만 원짜리 시스템으로 굳히는 것이 초기 창업에서 가장 비싼 실수가 되기 쉽습니다.
3. 한 플랫폼의 정책에 운명이 걸린 프로젝트. 특정 기기 생태계나 배달·커머스 플랫폼에 붙어야만 성립하는 제품이 있습니다. 제품의 핵심 기능이 남의 플랫폼에 종속돼 있으면, 그쪽에서 정책 하나만 바꿔도, API 유료화든 기능 제한이든, 프로젝트 전체가 끝날 수 있습니다. 플랫폼 위에 짓는 것 자체가 잘못은 아닙니다. 다만 대체 경로 없이 하나에만 묶여 있다면 개발보다 리스크 설계가 먼저입니다.
4. 제작비만 있고 운영비가 없는 예산. 시스템은 만든 날부터 비용이 듭니다. 런칭 이후 계획이 0원이라면, 그 프로젝트는 완성되는 순간부터 방치가 예정돼 있습니다.
5. 결정권자가 없는 프로젝트. 방향을 정할 사람이 회의체뿐이라면 어떤 개발사가 맡아도 일정과 범위가 표류합니다. 내부 합의가 먼저입니다.
6. "일단 싸게 만들고 잘되면 제대로" 계획. 임시로 만든 시스템 위에 사업이 올라타면, '제대로'의 시점엔 갈아엎는 비용이 처음보다 커져 있습니다. 싸게 갈 거라면 도구로, 제대로 갈 거라면 처음부터 구조를 잡는 게 결과적으로 쌉니다.
7. 요구사항이 매주 바뀌는 탐색 단계. 탐색은 잘못이 아닙니다. 다만 고정 범위·고정 견적 계약과는 상성이 최악입니다. 이 단계라면 계약 형태 자체를 다르게 설계해야 서로 불행하지 않습니다.
8. 사람만 빌려 가는 파견형 요청. "개발자 한 분 상주로 보내주세요"는 저희 방식이 아닙니다. 저희는 문제를 받아서 시스템으로 답하는 회사이지, 인력을 대는 회사가 아닙니다.
순서의 문제일 뿐입니다
이 8가지는 "나쁜 프로젝트"가 아니라 아직 순서가 오지 않은 프로젝트입니다. 솔루션으로 시작해 한계를 확인하고, 검증을 끝내고, 운영까지 예산에 넣고, 결정권자가 정해진 뒤에 오는 프로젝트는 성공 확률이 완전히 다릅니다.
지금이 그 순서인지 확인하고 싶다면 상담에서 같이 판단해 드리겠습니다. 아니라는 답이 나와도, 그 답이 아끼는 것은 비용만이 아닙니다. 잘못된 프로젝트에 들어갔을 몇 달, 창업자에게는 젊음이라고 불러도 될 그 시간을 아껴 드리는 일이라 믿습니다.