1인 SaaS
getPersona.md를 왜 만드는가 — AI에게 '나'를 맡기려면 프롬프트만으로는 부족하다
프롬프트만으로는 '나'를 넘길 수 없다. getPersona.md가 PERSONA.md 패키지로 그 문제를 풀려는 이유와, 지금까지의 검증을 정리했습니다.
1인 SaaS
프롬프트만으로는 '나'를 넘길 수 없다. getPersona.md가 PERSONA.md 패키지로 그 문제를 풀려는 이유와, 지금까지의 검증을 정리했습니다.
● goodtek
Day 2에서 DB·인증·시크릿을 깔았다면, Day 3는 MinIO·Redis·GitLab CI·Docker Compose·공유 Zod까지 — 카탈로그는 아직 없지만 고객에게 팔 서비스가 버틸 인프라·검증·계약 바닥을 한 번에 깔았습니다. Build in Public로, 화면 0개인 주에 왜 이 작업을 먼저 했는지 정리합니다.
1인 SaaS
Day 1에서 모노레포와 DESIGN.md를 잡았다면, Day 2는 Postgres·API·Web·Better Auth OAuth·Infisical까지 보이지 않는 바닥을 깔았습니다. 카탈로그는 아직 없지만 /dashboard가 텅 비어 보이는 이유와, 그래도 지금 Foundation을 먼저 닫아 둔 이유를 정리했습니다.
1인 SaaS
Product Hunt 출시를 준비하며 Arcade AI를 활용해 영어 데모 영상을 제작한 과정을 공유합니다. 기능 설명보다 문제를 먼저 전달하는 스토리 구성과 One Shot으로 영상을 완성한 경험을 담았습니다.
1인 SaaS
GitHub Actions 무료 사용량 한계에 도달하면서 Podman, Caddy, Infisical 기반 무중단 배포 환경을 GitLab CI/CD로 이전한 기록입니다.
1인 SaaS
AI와 함께 코딩하면 계획, 프롬프트, 문서, 실제 코드가 쉽게 섞입니다. 이번 TASK-013에서는 공개 상태 페이지를 만들려 했지만, 실제로 ship된 것은 실시간 대시보드, 알림 테스트 상태 추적, 디자인 정합 작업이었습니다. 이번 글에서는 TASK 이름보다 머지된 코드를 기준으로 사실을 검증한 과정과, Realtime 아키텍처·비동기 상태 모델·공통 계약 관리 등 AI와 함께 개발할 때 놓치기 쉬운 기준들을 정리합니다. Build in Public 관점에서 ‘만들려던 것’과 ‘실제로 만든 것’을 구분하는 방법을 공유합니다.
OAuth
vibePulse TASK-005에서는 OAuth 로그인 흐름을 구현했습니다. 처음에는 이메일, 카카오, 네이버까지 함께 고려했지만, 초기 타겟인 바이브코더와 개발자에게 가장 빠르게 닿는 Google·GitHub 로그인에 집중하기로 결정했습니다. 인증 범위를 줄이는 과정, Better Auth 구현, allowlist, 온보딩 연결, i18n UX와 로그인 화면 개선까지 실제 시행착오를 정리했습니다.
Build in Public
goodtek은 Build in Public 방식으로 vibePulse SaaS를 만들고 있습니다. TASK-003에서는 기능을 하나씩 붙이기 전에, 출시까지 필요한 전체 화면의 흐름을 먼저 그렸습니다. DESIGN.md로 일관성을 유지하면서도 기능 범위와 연결 구조를 더 선명하게 확인한 프론트 구현 기록입니다.