Docs

Documentação do Framework

Central de conhecimento da metodologia Forestbit para construir micro-SaaS. Conteúdo de negócio vive em pastas por área; metodologia e operação no Cursor ficam na raiz de docs/ (PLAYBOOK, CURSOR).

Fluxo de ponta a ponta: PLAYBOOK.md — ideia + benchmark → preencher todos os docs (docs/) → specs técnicas por módulo (specs/, Spec Kit) → desenvolver → lançar (GTM/Hotjar) → vender → medir.

O que é o Framework?

Framework é um boilerplate completo para micro-SaaS — metodologia + monorepo + templates de documentação. Não é um produto único nem um nicho fixo.

PeçaO que é
Metodologia (BDFU)Como pensar, documentar, especificar e shippar um micro-SaaS
Boilerplate (código)Auth, billing, multi-tenant, deploy — já prontos em apps/, cloud/
Docs (docs/)Templates com instrução do que escrever em cada trecho — você preenche para o seu produto
Specs (specs/)Spec Kit — requisitos técnicos, plano e tasks por feature (Fase 3)

Status do template (plataforma vs specs): development/00-boilerplate-status.md.

Como ler os arquivos em docs/

Cada arquivo numerado (01-, 02-, …) é um template em duas camadas:

CamadaOndeNo fork
GuiaBloco > O que documentar aqui: no topoManter — diz o que pensar e escrever
ConteúdoSeções e tabelas abaixo (TBD, comentários <!-- … -->)Substituir pelo seu negócio

Preserve a estrutura de pastas e os READMEs de cada área.

O que vai em docs/ vs specs/

PerguntaResposta em
Por que existimos? Quem é o ICP? Quanto cobramos?docs/strategy/, docs/product/, docs/sales/
Como posicionamos e vendemos?docs/marketing/, docs/sales/
Módulos, regras de negócio, statusdocs/product/04-features-modules.md
Arquitetura, apps, fluxo de dadosdocs/development/01-architecture-stack.md
Identidade, tema, @framework/branddocs/development/10-brand-kit.md
APIs, Hasura, webhooks, contratosdocs/development/04-api-integrations.md
Deploy, testes, convençõesdocs/development/ (demais arquivos)
Como implementar o módulo X (FR, plano, tasks)?specs/NNN-nome/ (Spec Kit)

BDFU como modelo de MVP (deliberadamente anti-ágil)

Big Design Upfront (BDFU) é o coração do Framework: definir ideia, benchmark, documentação, specs e backlog completos antes de escrever código de produto.

Isso contraria o agile clássico (sprint curta → ship mínimo → iterar no escuro). Aqui o MVP não é “código incompleto rápido” — é produto v1 completo conforme specs, lançado de uma vez, com GTM e Hotjar para iterar depois com dados.

Agile clássico (MVP)Framework (BDFU + MVP)
Escopo emerge nas sprintsEscopo congelado na Fase 3 (specs/)
Documentação mínimadocs/ completo antes de codar
Infra acoplada ao produtoInfra já vem no boilerplate
Validação contínua pré-launchLaunch → dados (GTM/Hotjar) → ajustes pontuais
Time descobre fazendoTime projeta inteiro, agentes executam em paralelo

Por que funciona para micro-SaaS Forestbit: o custo de “descobrir no código” é alto quando auth, billing e deploy já estão resolvidos — o risco migra para clareza de escopo, não para reinventar stack.

Quando não usar: produto altamente incerto sem boilerplate, muitos stakeholders conflitantes, ou mercado que muda semanalmente. Ver PLAYBOOK — Por que BDFU.

Três camadas

CAMADA 1 — Estratégia     strategy/        por que existimos, mercado, metas
CAMADA 2 — Go-to-market   product/ marketing/ sales/   oferta e aquisição
CAMADA 3 — Entrega        development/ operations/    construir e sustentar

Cada camada alimenta a seguinte. Não pule camadas — BDFU exige preenchimento integral antes da Fase 4 (código de produto).

Pastas

PastaConteúdoAudiência
strategy/Visão de empresa, modelo de negócio, mercado, riscos, decisões, OKRsFundadores
product/ICP, pilares, funcionalidades, roadmap, pricing, métricas de produtoProduto, engenharia
marketing/Posicionamento, canais, conteúdo, brand, campanhasMarketing
sales/Qualificação, pipeline, proposta, objeçõesVendas
development/Arquitetura, specs, API, deploy, testes, changelogEngenharia, DevOps
operations/Suporte, CS, legal, financeiro, parceirosCS, ops, fundadores

Cada pasta tem um README com índice dos arquivos numerados (01-, 02-, …).

Como organizar

1. Um assunto = um arquivo numerado

  • Nome: NN-short-name-in-kebab-case.md (ex.: 03-pillars-criteria.md)
  • Numeração = ordem de leitura e prioridade de preenchimento
  • 00- reservado para glossário e referências transversais

2. Comece pelo README da área

Antes de criar ou editar, leia o README da pasta.

3. Links cruzados

  • strategy/ define direção → product/ detalha oferta → development/ implementa
  • marketing/ e sales/ comunicam e convertem com base em product/
  • operations/ assume após a venda (handoff desde sales/04)
  • Pricing em product/07 espelha em sales/03

4. O que não entra em docs/

ConteúdoOnde fica
Spec de featurespecs/NNN-nome/
Spec Kit (templates, scripts).specify/
Help público (cliente)apps/app/public/docs/ (inglês)
Infra operacionalcloud/dokploy/
Constitution de engenharia.specify/memory/constitution.md

5. Idioma

  • Pastas e nomes de arquivo: inglês
  • Conteúdo dos docs: português (pt-BR)
  • Código, UI, APIs, help in-app: inglês

Fluxo sugerido de preenchimento (BDFU — completo)

Preencha todos os arquivos numerados antes de implementar. Ordem recomendada:

Fase 1 — Ideia + benchmark
  strategy/01 (one-pager) + strategy/03 (benchmark concorrentes)

Fase 2 — Documentação completa
  strategy/00–06     →  estratégia, mercado, riscos, OKRs
  product/01–07      →  proposta, ICP, pilares, módulos (04), roadmap integral (05), pricing
  marketing/01–08    →  posicionamento, canais, conteúdo, brand, campanhas, métricas, economia de canais, playbook operacional
  sales/01–07        →  qualificação, pipeline, proposta, onboarding, retenção, métricas, simulação comercial
  development/01–09  →  arquitetura, convenções, deploy, testes, changelog, Cursor multi-agent
  operations/01–05   →  suporte, CS, legal (rascunho), financeiro, parceiros

Fase 3 — Specs (fora de docs/)
  docs/product/04  →  cada módulo vira specs/NNN-nome/ (índice em specs/README.md)

Fase 4+ — Só após gates das Fases 1–3
  PLAYBOOK Fase 4 em diante — desenvolver, cloud, launch, vender, medir

Métricas (*/06): metas v0 na Fase 2; números reais após launch (PLAYBOOK Fase 8).

Mapa entre áreas

strategy/01–02
    ↓
product/01–02 + sales/01        (quem servimos)
    ↓
product/03–04 + development/01  (o que entregamos)
    ↓
sales/02–03 + marketing/02–05   (como vendemos e divulgamos)
    ↓
product/06 + marketing/06 + sales/06  (como medimos)
    ↓
product/05 + development/03 + operations/*  (como evoluímos e sustentamos)

Índice rápido