화면에 쓰지 않습니다.왈로그 · 오늘도냥어디서 온 말인지 화면마다 적고, 원문을 그 자리에서 열 수 있게 합니다. 병원이 정할 일은 앱이 판단하지 않습니다.
사용자의 것입니다.러볼브 · 오늘도냥커플의 대화는 종단간 암호화로 두 사람 외에는 읽을 수 없고, 고양이 건강 기록은 계정 없이 사용자의 기기와 iCloud에만 저장합니다.
시작입니다.세 제품 모두출시일부터 매일 지표를 보고 개선합니다. 개발비 대신 성과를 배분하는 모델이 성립하는 근거입니다.
만든 것
세 시장에서 검증한 방식입니다.
다음 시장은 당신이 아는 곳일 수 있습니다.
싸움은 줄고,
대화는 드라마가 돼요.
둘만 볼 수 있는 대화방에서 시작합니다. 메시지는 암호화되어 두 사람 말고는 아무도 읽지 못합니다.
오해가 싸움이 되기 전에, 케어모드
대화가 예민해지는 순간 케어모드를 켜면, 같은 말을 다른 관점으로 볼 수 있게 도와줍니다. 이유를 설명하기 전에 마음을 먼저 전하게요.
나눈 대화가 둘만의 러브스토리로
스냅샷, 타임라인, 캐릭터, 그리고 러브 드라마. 지나간 대화가 두고두고 꺼내 보고 싶은 이야기로 남습니다.
함께한 시간이 쌓이는 게 보여요
처음 만난 날부터의 D-day, 다가오는 기념일, 한 주의 대화를 정리한 러브 위클리. 관계가 자라는 과정을 눈으로 봅니다.
어떻게 사랑하면
우리 강아지가 더 행복할까.
사랑하는 마음은 넘치는데, 뭘 해줘야 하는지는 아무도 알려주지 않습니다. 그래서 오늘 이 아이에게 필요한 것 하나만 꺼내 드립니다.
오늘 할 일은 하나예요
순서를 외우지 않아도 됩니다. 첫날 잠자리부터 노령기 검진까지, 이 아이의 나이와 접종 기록에 맞춰 때가 되면 하나씩 올라옵니다.
급한 일은 첫 줄에서
밤에 깨서 울어요, 토했어요, 손을 물어요. 지금 벌어진 일을 고르면 대처 방법과 함께 「이럴 땐 병원에」 기준을 알려드립니다.
매번 다시 설명하지 않아도, 우리 아이를 아는 채로 답해요
몇 살인지, 몇 kg인지, 무슨 사료를 먹는지를 매번 처음부터 적지 않아도 됩니다. 적어둔 기록을 질문에 같이 붙여 드리고, 무엇이 나가는지는 보내기 전에 줄 단위로 보여드립니다. 답은 AI가 쓰고, 병원 진료를 대신하지는 않습니다.
고양이는 아파도
티를 잘 안 내요.
야생에서 아픈 티를 내면 잡아먹히니까요. 그 습성은 우리 집 거실에도 남아 있고, 티가 날 무렵엔 이미 늦습니다. 그래서 매일 한 번만 묻습니다. 오늘 어땠는지.
처음 2주는 우리 고양이를 알아가요
원래 어떤지도 모르면서 「오늘 이상해요」라고 할 수는 없으니까요. 15일째부터 평소와 다른 날을 알려드립니다 — 「우리 고양이치고 물을 많이 마신 지 사흘째예요」처럼.
별일 없던 날은 버튼 하나
「좀 이상했어요」를 눌렀을 때만 적을 칸이 열립니다. 멀쩡한 날에 여섯 칸을 채우게 하지 않습니다.
진단하지 않고, 독촉하지 않고, 가져가지 않아요
병명을 말하지 않고 있었던 일과 출처만 적습니다. 알림은 저녁에 한 번. 계정이 없어서 기록은 집사님 폰과 iCloud에만 남습니다.
Claude와 만드는 법
코드는 마지막에 씁니다.
개발비 없이 시작할 수 있는 이유가 이 순서에 있습니다. 기획에 가장 많은 시간을 쓰고, 개발은 검증된 모듈로 짧게 끝냅니다. 파트너의 시간도 기획 단계에 집중되며, 개발 중에는 현장 검증과 피드백이 주된 역할입니다. 단계별 역할을 적었습니다.
기획에 가장 오래 머뭅니다
누가 어떤 순간에 이 제품을 열지부터 문서로 정의합니다. 무엇을 만들지보다 무엇을 만들지 않을지에 더 오랜 시간을 씁니다. 여기서 정한 것이 이후 모든 판단의 기준이 됩니다.
현장을 설명합니다 — 누가, 언제, 무엇에 막히고, 지금은 어떻게 해결하는지. 파트너의 시간이 가장 많이 드는 단계이며, 여기서 중단하는 것도 유효한 결론입니다.
기능 하나하나, 그리고 기능 사이까지 점검합니다
개발 계획을 기능 단위로 나눠 검토하고, 이어서 기능이 만나는 지점을 점검합니다. 알림과 결제가 겹치는 곳, 오프라인과 동기화가 충돌하는 곳 — 사고는 대개 기능 안이 아니라 기능 사이에서 납니다.
계획을 검토하고 「현장에서는 그렇게 하지 않는다」를 짚습니다. 그 한 줄이 개발 몇 주를 절약합니다.
타겟 유저를 조사하고, 레드팀이 공격합니다
타겟 사용자가 실제로 쓰는 언어와 상황을 조사하고, 계획을 레드팀에 넘겨 빈틈을 찾습니다. 만든 사람이 보지 못하는 것을 만들기 전에 봅니다.
실제 사용자를 소개하고 레드팀에 함께 참여합니다. 그 시장을 아는 사람의 반론이 가장 정확합니다.
검증된 모듈로 빠르게 만듭니다
로그인, 결제, 알림, 동기화처럼 이미 출시되어 검증된 모듈을 조립합니다. 한 번 검증된 것은 다시 만들지 않습니다. 기획에 쓴 시간을 여기서 회수하며, 개발비 없이 시작할 수 있는 이유입니다.
첫 버전을 현장에서 사용해 보고 어긋난 지점을 짚습니다. 이 단계에서 파트너의 시간은 그 정도입니다.
출시 뒤에도 매일 숫자를 읽습니다
출시로 끝내지 않습니다. 매일 지표를 보고 사용자가 멈추는 지점을 찾아 개선합니다. 제품은 출시일이 아니라 그다음 날부터 만들어집니다.
사용자 반응을 듣고, 지표를 함께 보고, 다음 개선을 함께 정합니다. 수익 배분도 이 시점부터 시작됩니다.
협업 조건
개발비는 없습니다.성과에 비례해 배분합니다.
납품 후 종료되는 외주 개발은 하지 않습니다. 그 시장을 아는 전문가와 파트너로 시장에 필요한 제품을 만들고, 제품이 낸 수익을 착수 전에 합의한 비율로 배분합니다. 배분 비율과 소유 구조는 분야와 역할에 따라 다르며, 착수 전에 문서로 확정합니다.
분야 · 사용자가 막히는 지점 · 현재의 해결 방식. 이 세 가지면 검토를 시작할 수 있습니다.
적합한 파트너같은 문제를 겪는 사용자를 매일 만나는 전문가. 그 사용자에게 직접 닿을 수 있는 분. 제품이 없어서 발생하는 비용이 무엇인지 아는 분.
하지 않는 것개발비를 받고 납품하는 외주. 확정된 명세를 대신 구현하는 일. 제품이 없어도 되는 문제에 제품을 만드는 일.
검증에 실패하면개발비가 없으므로 양쪽의 리스크는 시간입니다. 그래서 기획 단계에서 성립하지 않는 가설을 먼저 거릅니다. 거기서 중단하는 것도 유효한 결론입니다.