ADR-101: Product Vision & Identity
Status: Accepted
Contexto
A MIDDAG opera 3 linhas de negócio (local_middag, consultoria Moodle, Campus EAD) com um stack fragmentado: WooCommerce para pedidos, HubSpot para pipeline, Stripe para cobrança, Jira para suporte, planilhas para entitlements. Nenhum lugar único onde admin ou cliente veja "Organização X tem 3 licenças, 2 ambientes, 1 projeto ativo e uma fatura vencendo sexta." Esse problema não é exclusivo da MIDDAG — qualquer empresa B2B no WordPress enfrenta o mesmo stack remendado de 6+ plugins e 3+ serviços externos.
Decisão
Construir o middag-account — um plugin WordPress para gestão de ciclo de vida B2B que unifica organizações, entitlements, faturamento, contratos e entrega de serviços em uma única superfície.
O Que É
Um plugin WordPress, DDD Light, Symfony DI, zero dependências WP na camada de domínio, que roda dentro do wp-admin (UI React via Inertia.js) e expõe REST API v1 com auth JWT RS256 para portais headless.
O Que NÃO É
| NÃO é | É |
|---|---|
| Um CRM | Integra com CRM (HubSpot), não substitui |
| Um helpdesk | Integra com helpdesk (Jira/Chatwoot), não substitui |
| Um sistema contábil | Registra faturas de fontes externas, sem plano de contas |
| Um painel de hosting | Rastreia environments, não provisiona servidores |
| Um substituto do WooCommerce | WC é motor de commerce por baixo; plugin adiciona camada B2B |
| Um produto à venda (hoje) | Ferramenta interna que pode se tornar produto |
| Específico para Moodle | Gestão B2B genérica — MIDDAG vende Moodle, o plugin gerencia o negócio |
Público-Alvo (3 segmentos)
- Primário — Empresas de software/SaaS no WordPress: 50–5.000 clientes (organizações), vendem licenças/assinaturas/ambientes, precisam de portal self-service
- Secundário — Empresas de serviço B2B no WordPress: Ciclo proposta→faturamento, gestão de contratos/SLA, service requests, equipes multi-usuário
- Terciário — Qualquer operação B2B WooCommerce: Superaram o design B2C-first do WC, precisam de gestão no nível de organização
5 Diferenciais
| Diferencial | Detalhe |
|---|---|
| Entitlement-centric | Todo produto/serviço/ambiente rastreado via código único (inspirado no SEN da Atlassian). Nenhum outro plugin WC faz isso. |
| Organization-first | Multi-tenant desde o início. Clientes são organizações com colaboradores, não usuários WP individuais. |
| WordPress-native | Roda dentro do wp-admin. Sem servidor separado, sem dependência SaaS. Dados no banco WordPress. |
| Headless-ready | REST API v1 com JWT RS256. Portal NextJS consome API — ou qualquer outro frontend. |
| Dual-entity billing | Suporta múltiplas entidades legais (ex: BR + US) com contas Stripe separadas e sistemas fiscais. |
Inspiração Atlassian SEN
O SEN (Support Entitlement Number) da Atlassian é um identificador único que vincula licença a acesso a suporte. middag-account adota o conceito e o expande:
- SEN = tipo único → middag-account: 6 classes tipadas: PLG, ENV, SVC, ORD, AFL, EDU
- SEN = formato opaco → middag-account: formato legível
{CLASS}-{YEAR}{MONTH}{SEQ:4d} - SEN = passivo (consulta) → middag-account: ciclo de vida com 4 estados e transições automatizadas
- SEN = sem provisioning → middag-account: auto-provisionamento de entidades downstream
- SEN = empresa única → middag-account: campo
companypara dual-entity
O entitlement é a foreign key universal: License, Environment, Service, ServiceRequest — todos os caminhos levam de volta a um entitlement.
Estratégia Internal-First / Product-Later
- v5.0: Uso próprio da MIDDAG (dogfooding). Todos os domínios funcionais, API v1 completa, admin UI, portal NextJS.
- v5.0.x: Ecossistema — notificações, integrações adicionais, automações.
- v6.0+ (aspiracional): Modelo open-core — core gratuito no wp.org, funcionalidades premium gated por licença. Multi-site, white-label, marketplace de extensões.
Métricas de Sucesso
Dogfooding (MIDDAG):
- Consulta de cliente < 5s (qualquer entitlement, fatura ou licença)
- Ciclo quote-to-payment automatizado (zero passos manuais após aceite)
- Zero erros de billing dual-entity (conta Stripe correta, sistema fiscal correto)
- Cobertura de testes > 90% na camada de domínio
Adotantes (futuro):
- Tempo até primeira organização < 30 min após instalação
- Tempo de resposta da API < 200ms (p95)
- 100% dos endpoints REST API v1 documentados
Consequências
Positivas:
- Visão unificada do cliente em um lugar — elimina alternância entre 3+ sistemas
- Pipeline automatizado quote→order→payment→entitlement
- Arquitetura preparada para distribuição externa sem rewrite
- Dados sob controle do operador (self-hosted), não em SaaS de terceiros
Negativas:
- Complexidade de manter 16 domínios em um único plugin
- Dependência de WooCommerce como motor de commerce
- Custo de manutenção de integrações externas (Stripe, HubSpot, Jira, ISSNet (NFSe Brasília/DF))
- Mercado-alvo nichado — nem todo negócio B2B está no WordPress