Fase 01 — Contexto Estratégico
OKRs, princípios de produto, Opportunity Solution Tree e mapa de suposições.
OKR Principal
Objetivo
Tornar pagamentos invisíveis para o ecossistema ECP — qualquer app processa qualquer meio de pagamento com uma única chamada, sem conhecer gateways, sem duplicar código, sem depender de serviços externos para desenvolver.
Prazo: Q2-Q3 2026 | 5 Key Results mensuráveis
KR-01
Reduzir o tempo de integração de um novo app com pagamentos de semanas para horas
Tempo médio para um novo app processar seu primeiro pagamento via ECP Pay (do primeiro import ao pagamento confirmado em staging)
Q2 202685%
KR-02
Centralizar 100% das transações do ecossistema em um único ledger observável
Percentual de transações financeiras do ecossistema ECP que passam pelo ECP Pay (vs. chamadas diretas a gateways)
Q3 202660%
KR-03
Garantir que a troca de gateway não exija alteração em nenhum app consumidor
Número de linhas de código alteradas nos apps consumidores ao trocar de provider (ex: Asaas para Stripe)
Q2 2026100%
KR-04
Eliminar dependência de serviços externos para desenvolvimento e testes
Percentual dos cenários de teste de pagamento que rodam sem conexão com internet (modo internal)
Q2 2026100%
KR-05
Atingir confiabilidade de produção medida por disponibilidade e entrega de eventos
Disponibilidade da API (uptime) e taxa de entrega de webhooks na primeira tentativa
Q3 202670%
Princípios de Produto
PP-01
Contrato acima de implementação — O valor do ECP Pay está na estabilidade do contrato de API. Mudanças internas de provider NUNCA devem vazar para os consumidores.
PP-02
Desenvolvimento sem dependências externas — O modo internal é uma feature de primeira classe que garante que qualquer dev roda o ecossistema completo com um único comando.
PP-03
Observabilidade como cidadão de primeira classe — Cada operação deve ser auditável, cada falha investigável e cada webhook rastreável.
PP-04
Segurança por design, não por checklist — Dados sensíveis nunca são armazenados. Tokens substituem dados reais. A segurança está na arquitetura.
PP-05
Operacional antes de bonito — O painel admin prioriza densidade de informação, filtros poderosos e ações rápidas sobre estética. Inspiração: Stripe Dashboard.
PP-06
Idempotência é inegociável — Em sistemas financeiros, processar uma operação duas vezes é pior do que não processar. Toda mutação deve ser idempotente por design.
Opportunity Solution Tree (OST)
15 oportunidades mapeadas a 5 Key Results, organizadas por tipo (pain, need, desire). Cada oportunidade identificada a partir de evidências do product briefing e tech spec.
| ID | Oportunidade | Tipo | KRs |
|---|---|---|---|
| OPP-01 | Cada app reimplementa toda a lógica de integração com Asaas, gerando semanas de trabalho repetitivo | pain | KR-01 |
| OPP-02 | Desenvolvedores precisam entender a API proprietária de cada gateway em vez de consumir um contrato único | pain | KR-01 |
| OPP-03 | Novos devs precisam de caminho rápido para rodar o ecossistema e testar pagamentos sem configurações complexas | need | KR-01 |
| OPP-04 | Operadores não têm visão consolidada das transações — precisam acessar dashboards separados por gateway | pain | KR-02 |
| OPP-05 | Owner precisa entender quanto cada app transaciona e a distribuição entre métodos de pagamento | need | KR-02 |
| OPP-06 | Investigar falhas exige acessar logs em múltiplos sistemas, sem correlação entre pedido e status no gateway | pain | KR-02 |
| OPP-07 | Se o Asaas mudar taxas ou API, todos os apps precisam ser atualizados simultaneamente | pain | KR-03 |
| OPP-08 | Ecossistema quer liberdade para negociar com múltiplos gateways sem retrabalho nos apps | desire | KR-03 |
| OPP-09 | Apps consumidores precisam de estabilidade contratual — o contrato não pode quebrar por decisões de infra | need | KR-03 |
| OPP-10 | Testes automatizados dependem de sandbox do Asaas que é lento, instável e requer credenciais por dev | pain | KR-04 |
| OPP-11 | Demos e apresentações ficam reféns de conectividade e disponibilidade de sandboxes | pain | KR-04 |
| OPP-12 | Staging precisa ser determinístico e controlável para validação antes de produção | need | KR-04 |
| OPP-13 | Apps precisam de garantia de que callbacks serão entregues mesmo em cenários de falha temporária | need | KR-05 |
| OPP-14 | Sem idempotência, retries podem causar cobranças duplicadas ou processamento inconsistente | pain | KR-05 |
| OPP-15 | Operadores precisam de replay de webhooks, reprocessamento e estorno acessíveis sem engenharia | need | KR-05 |
Questões Abertas
OQ-01
Qual o volume transacional esperado no primeiro trimestre? Isso impacta decisões de infraestrutura e o target de disponibilidade.
OQ-02
Existe previsão de quando o adapter de Stripe será necessário, ou Asaas é suficiente para o roadmap de 2026?
OQ-03
O split de pagamento será usado apenas no ecp-food ou há demanda em outros apps?
OQ-04
Como será medido o baseline de KR-01? Usar o tempo de integração do ecp-food com Asaas como referência?
Suposições
AS-01
Os três apps iniciais migrarão para consumir ECP Pay
Risco: Se algum app optar por manter integração direta, KR-02 (100% centralização) não será atingido.
AS-02
Modo internal terá paridade funcional completa com Asaas no contrato de API
Risco: Se houver divergência de contrato entre modos, apps terão comportamento diferente em dev vs. produção.
AS-03
Volume transacional compatível com SQLite no primeiro ano
Risco: Se o volume crescer além do esperado, SQLite pode se tornar gargalo antes do previsto.
AS-04
Asaas será o único gateway de produção na v1
Risco: Baixo — a interface de provider garante extensibilidade mesmo se Stripe for adiado.