# Análise competitiva, produto e go-to-market — NoLapis

**Tipo de documento:** consultoria estratégica + técnica, baseada no inventário (`Doc_Inventario_Repositorio.md`), no índice de docs (`Doc_INDICE.md`) e no código já levantado.  
**Última atualização:** 2026-06-08  
**Concorrentes citados:** Omie, Bling, Conta Azul, Tiny, GestãoClick, MarketUP, Nibo e “PME Brasil” de forma qualitativa.

---

## Legenda de evidência

| Tag | Significado |
|-----|-------------|
| **[Código]** | Evidência direta no repositório / inventário. |
| **[Estrutura]** | Inferência razoável a partir da arquitetura e módulos existentes, sem afirmar detalhe de implementação não visto. |
| **[Mercado]** | Comparação com ERPs brasileiros com base no **posicionamento público típico** desses produtos (PME, fiscal, financeiro, e-commerce). **Não** é auditoria feature-by-feature de versão atual de cada concorrente. |
| **[Recomendado]** | Sugestão de consultoria (produto, GTM, arquitetura). |
| **Não foi possível confirmar pelo código analisado** | Usado quando granularidade exige leitura adicional do repositório ou dados externos. |

**Aviso sobre colunas “Omie / Bling / …” nas tabelas:** classificações (**Ausente / Básico / Intermediário / Avançado / Diferencial / Não confirmado**) refletem **[Mercado]** — referência típica de categoria, não checklist licenciado de cada fornecedor. Para decisões contratuais ou comparativos legais, exige-se benchmark próprio.

---

# Análise por módulo

---

## Módulo: Multi-tenant, planos, cadastro SaaS e pagamentos

### 1. O que existe hoje no NoLapis **[Código]**

- Tenant (`tenant`), usuários com `idtenant`, `TenantScope`, middleware `admin.tenant`.
- Planos, funcionalidades, vínculo plano–funcionalidade; CRUD admin.
- Cadastro público (`cadastro/*`), PIX / Pagar.me (`CadastroController`, `PagarMeService`, `WebhookController`); **login SSO** Google / Microsoft no cadastro e no `/sign-in` (`SocialAuthController`, `SsoAuthService`, Laravel Socialite).
- Política de autenticação por **tenant** (`auth_padrao`, `sso_provedores`, `permitir_senha_local`) e por **usuário** (`auth_tipo`, `auth_provedor`, `sso_obrigatorio`) — ver **`Doc_Modulo_Tenant.md`** § 11 e **`Doc_Modulo_Pessoa_Usuario.md`** § 6.5.
- Dependências `laravel/cashier`, `laravel/passport` no Composer — uso profundo em domínio **não foi possível confirmar pelo código analisado** (vide inventário).

### 2. Maturidade atual

| Critério | Valor | Motivo |
|----------|-------|--------|
| Maturidade técnica | **7/10** | Multi-tenant e webhook presentes; dependências “fantasma” e API mínima reduzem nota. |
| Maturidade funcional | **6/10** | Onboarding e cobrança recorrente do **produto NoLapis** vs **contrato de cliente** podem confundir naming; limitação por plano na UI não mapeada no inventário. |
| Maturidade comercial | **5/10** | Falta evidência de trial self-service, métricas de uso, documentação de planos no app — **parcialmente inferido** por ausência no inventário. |
| Risco técnico | **Médio** | Passport/Cashier sem uso claro aumenta superfície e dívida. |
| Risco comercial | **Médio** | Cobrança e expectativa de “ERP completo” se planos não forem claros. |
| Prontidão para venda | **Média** | Viável para pilotos com contrato explícito de escopo. |

### 3. Funcionalidades identificadas

#### Funcionalidades completas **[Código]**

- Isolamento por tenant em models escopados; cadastro com pagamento e webhook.

#### Funcionalidades parciais **[Código] + [Estrutura]**

- “Assinatura” do software vs “assinatura/contrato” do cliente do tenant (dois mundos) — risco de mensagem confusa (**inferido**).

#### Funcionalidades frágeis **[Código]**

- Dependências instaladas sem uso evidente (Passport, Cashier).

#### Funcionalidades ausentes **[Mercado] + inventário**

- Portal do contador multi-tenant típico de Conta Azul/Omie; API pública ampla; marketplace de integrações — **não evidenciados** no inventário.

### 4. Fluxo de negócio percebido **[Código]**

Início: visitante escolhe plano → cadastro → PIX / webhook atualiza estado → usuário acessa tenant. Impacto: cria `tenant`, `pessoa`, vínculos. Efeitos fiscais/operacionais diretos **limitados** nesta fase.

### 5. Comparação com concorrentes **[Mercado]**

| Funcionalidade | NoLapis | Omie | Bling | Conta Azul | Tiny | GestãoClick / outros | Observação crítica |
|-----------------|---------|------|-------|-------------|------|----------------------|---------------------|
| Multi-tenant nativo | Intermediário | Avançado | Avançado | Avançado | Avançado | Intermediário | NoLapis é produto SaaS próprio — ponto alinhado a “ERP de software house”. |
| Self-service + trial | Básico | Avançado | Avançado | Avançado | Intermediário | Intermediário | Trial comercial presente; cadastro com **senha ou SSO** **[Código]**. |
| Login SSO (Google/Microsoft) | Intermediário | Avançado | Intermediário | Avançado | Básico | Básico | Implementado **[Código]**; política híbrida por tenant/usuário; sem SAML/AD corporativo por tenant ainda. |
| Billing recorrente produto | Intermediário | Avançado | Avançado | Avançado | Intermediário | Básico | Pagar.me ok; maturidade de billing interna **parcial**. |
| API OAuth / partners | Não confirmado | Avançado | Intermediário | Avançado | Intermediário | Básico | Passport sem rotas evidenciadas. |

### 6. Pontos fortes **[Código]**

- Multi-tenant real (scope), não só “empresa única”.
- Pagamento na entrada (Pagar.me) — reduz atrito operacional de monetização.
- **Login SSO** (Google / Microsoft) no cadastro e no acesso, com modo híbrido (senha + SSO) configurável por usuário e padrão por tenant — alinhado a PMEs com Google Workspace / Microsoft 365.

### 7. Pontos fracos **[Código] + [Mercado]**

- Atrás de líderes em API, marketplace, maturidade de billing self-service.
- SSO **social/OAuth** apenas (não SAML/Entra por tenant dedicado); alterar tenant **não migra** usuários existentes — exige ajuste individual ou script de suporte.

### 8. O que precisa ajustar antes de vender **[Recomendado]**

| Ajuste | Motivo | Risco se não fizer | Prioridade |
|--------|--------|-------------------|------------|
| Remover ou integrar Passport/Cashier | Dívida e confusão de segurança | Médio | Alto |
| Documentar escopo por plano (o que liga/desliga) | Expectativa do cliente | Alto | Crítico |
| Definir trial e limites técnicos | GTM | Alto | Alto |

### 9. O que pode virar diferencial comercial **[Código] + [Recomendado]**

- **Confirmado:** provisionamento com pagamento na origem (menos “venda e implantação infinita” se bem empacotado).
- **Confirmado [Código]:** cadastro e login com Google/Microsoft; lead que entra via SSO nasce com tenant em modo SSO.
- **Viável [Estrutura]:** planos amarrados a `funcionalidades` já modeladas — falta UX/comercialização.

### 10. Recomendações técnicas **[Recomendado]**

Auditar `composer.json` vs uso real; documentar modelo de tenant; testes de isolamento multi-tenant; logs estruturados em webhook.

### 11. Recomendações de produto **[Recomendado]**

Página “o que está incluído”; comparativo de planos; wizard pós-cadastro; evitar jargão “assinatura” duplo sentido.

### 12. Prioridade estratégica

**Essencial para MVP comercial** — sem tenant/billing mínimo não há SaaS.

---

## Módulo: Cadastros (pessoas, empresas, usuários, perfis comerciais)

### 1. O que existe hoje **[Código]**

- `Pessoa` unificada com `tipo` (cliente/fornecedor/funcionário etc.); CRUDs separados (clientes, fornecedores, funcionários, representantes); empresas; usuários; Spatie roles; **autenticação por usuário** (`senha` / `sso` / `hibrido`, provedor Google ou Microsoft).

### 2. Maturidade atual

| Critério | Valor | Motivo |
|----------|-------|--------|
| Técnica | **7/10** | CRUD completo; validações centralizadas fracas (poucos Form Requests). |
| Funcional | **7/10** | Cadastro rico; possível inconsistência de `tipo` (minúsculas/maiúsculas) no model. |
| Comercial | **7/10** | Atende expectativa PME para cadastro mestre. |
| Risco técnico | **Médio** | Validação espalhada. |
| Risco comercial | **Baixo** | |
| Prontidão venda | **Alta** | |

### 3. Funcionalidades identificadas

- **Completas:** listas, busca, vínculos a NF/contrato/evento (por FKs).
- **Parciais:** padronização de enum `tipo` em toda UI/API.
- **Frágeis:** duplicidade CPF/CNPJ depende de regras em controller — **não auditado linha a linha**.
- **Ausentes [Mercado]:** portal do cliente fornecendo autoatendimento — **não confirmado** no inventário.

### 4. Fluxo percebido **[Código]**

Cadastro mestre → consumo em NF, parcelas, eventos, contratos.

### 5. Comparação **[Mercado]**

| Funcionalidade | NoLapis | Omie | Bling | Conta Azul | Tiny | Outros | Observação |
|-----------------|---------|------|-------|-------------|------|--------|------------|
| Cadastro pessoa/empresa | Intermediário | Avançado | Avançado | Avançado | Intermediário | Intermediário | Omie/CA forte em contador; NoLapis **adequado PME** se estável. |
| CRM profundo | Básico | Intermediário | Intermediário | Básico | Intermediário | Básico | NoLapis não é CRM puro — **esperado**. |

### 6. Fortes

Modelo unificado `pessoa` + perfis — flexível para nichos operacionais. **Login SSO** por usuário com fallback híbrido — adequado a clientes corporativos sem forçar todos ao IdP.

### 7. Fracos

Menos “contábil” que Omie/Nibo no cadastro de plano de contas integrado ao contador — isso é outro módulo. **Tenant vs usuário:** política SSO no tenant não atualiza usuários já cadastrados — risco operacional de suporte se não comunicado.

### 8. Ajustes antes de vender

| Ajuste | Motivo | Risco | Pri. |
|--------|--------|-------|------|
| Normalizar `tipo` e documentar | Bugs de filtro | Médio | Alto |
| Testes de CPF/CNPJ duplicado | Conflito de dados | Médio | Médio |

### 9. Diferenciais **[Código] limitado**

Diferencial comercial modesto; **não** é onde bater Omie — é tabela.

### 10. Recomendações técnicas

Form Requests por entidade; constraints DB onde possível.

### 11. Recomendações de produto

Nomenclatura clara “Cliente / Fornecedor / Colaborador”.

### 12. Prioridade estratégica

**Essencial MVP.**

---

## Módulo: Compras, pedidos e vendas (NF unificada)

### 1. O que existe hoje **[Código]**

- Uma tabela `nf` para compra (`tipo` D), pedido (C+P), venda (C+V); itens; duplicação; integração com parcelas, estoque, campanhas; import NF-e; rotas NFS-e em venda.

### 2. Maturidade atual

| Critério | Valor | Motivo |
|----------|-------|--------|
| Técnica | **6/10** | Controllers muito grandes; regras no model `Nf`. |
| Funcional | **8/10** | Pipeline de venda rico (incl. logística mercadoria). |
| Comercial | **7/10** | Forte para operação B2B; exige treino (um documento = várias faces). |
| Risco técnico | **Alto** | Acoplamento e tamanho de `VendaController`/`NfController`. |
| Risco comercial | **Médio** | Se fiscal prometido além do que importa/emite. |
| Prontidão venda | **Média–Alta** | Com escopo fiscal explícito. |

### 3. Funcionalidades

- **Completas:** compra/pedido/venda, status operacionais, duplicar, vínculo contrato/veículo conforme docs.
- **Parciais:** emissão NF-e SEFAZ end-to-end — **não foi possível confirmar pelo código analisado** em profundidade (importação confirmada no inventário).
- **Frágeis:** mesmo campo `status` mistura operação + cancelamento; legado acentuação.
- **Ausentes [Mercado]:** e-commerce nativo tipo Bling/Tiny (loja, carrinho) — **não** é foco evidenciado.

### 4. Fluxo percebido **[Código]**

Criação NF → itens → (parcelas conforme status) → efeitos financeiros em `nfparcela`; fiscal em `nfes`/`nfses`; estoque via services; campanha em conclusão de venda.

**Problema de modelagem [Estrutura]:** um agregado com múltiplos papéis exige disciplina de time e testes.

### 5. Comparação **[Mercado]**

| Funcionalidade | NoLapis | Omie | Bling | Conta Azul | Tiny | GestãoClick | Observação |
|-----------------|---------|------|-------|-------------|------|---------------|------------|
| Pedido/venda interno | Avançado | Avançado | Avançado | Intermediário | Avançado | Intermediário | NoLapis forte em **fluxo operacional** (separado/envio). |
| NF-e emissão completa | Não confirmado | Avançado | Avançado | Avançado | Avançado | Intermediário | Comparar só após auditoria fiscal. |
| Importação XML | Intermediário | Avançado | Avançado | Intermediário | Intermediário | Básico | Presente. |
| E-commerce | Ausente | Intermediário | Avançado | Básico | Avançado | Básico | |

### 6. Fortes

Pipeline de venda “mercadoria” alinhado a distribuidor/indústria leve; um núcleo único reduz telas duplicadas **se** bem explicado ao cliente.

### 7. Fracos

Complexidade percebida vs Bling “vendas simples”; risco fiscal se prometer paridade Omie.

### 8. Ajustes

| Ajuste | Motivo | Risco | Pri. |
|--------|--------|-------|------|
| Quebrar controllers / application services | Manutenção | Alto | Crítico |
| Separar status operacional vs financeiro vs fiscal (ver seção global) | Bugs e relatórios | Alto | Crítico |
| Checklist fiscal “o que emitimos” | Venda irresponsável | Muito alto | Crítico |

### 9. Diferenciais **[Código]**

- Pipeline logístico na mesma NF de venda — **Diferencial** potencial vs “só financeiro” se nicho for distribuição/insumos.
- NFS-e: importação XML em venda + Caixa de Entrada Fiscal (ADN) — **Intermediário** para serviço (**parcialmente confirmado**).

### 10. Recomendações técnicas

Extrair casos de uso; testes de integração por `tipo`/`saida`; documentar máquina de estados.

### 11. Recomendações de produto

Duas “visões” de produto: mercadoria vs serviço já começam no model — comunicar na UI.

### 12. Prioridade estratégica

**Essencial MVP** para ERP operacional-financeiro.

---

## Módulo: Financeiro (parcelas, bancos, transferências, cartão, conciliação)

### 1. O que existe **[Código]**

- `nfparcela` com tipo crédito/débito, fluxo (`HasFluxo`), extrato/movimentação; agências; **transferência entre contas** (`TransferenciaController`); **cartão corporativo** e faturas (`cartao:faturas-gerar` diário); **conciliação** com histórico e auditoria de reabertura; telas **`/dashboard/dfc`** e **`/dashboard/dre`** (`Nf::paraDemonstrativoGerencial`: pedido `P`, pagamento fatura cartão `T`, transferência entre contas `transferkey`); financeiro legado em `/dashboard/financeiro` (mesmo filtro `paraDemonstrativoGerencial`).

### 2. Maturidade atual

| Critério | Valor | Motivo |
|----------|-------|--------|
| Técnica | **7/10** | Services dedicados; ainda acoplado a NF. |
| Funcional | **8/10** | Parcelas + conciliação — próximo de necessidade PME real. |
| Comercial | **7/10** | DRE/DFC **gerenciais** no produto; ainda não “contabilidade oficial” — posicionar tesouraria + demonstrativos internos. |
| Risco técnico | **Médio** | |
| Risco comercial | **Médio** | Cliente pode esperar contabilidade completa (Nibo). |
| Prontidão venda | **Alta** | Com mensagem correta (tesouraria + a pagar/receber). |

### 3. Funcionalidades

- **Completas [Código]:** parcelas, fluxo, conciliação, cartão, transferência entre contas, DFC operacional (FCO/FCI/FCF), DRE gerencial com drill-down, comando `cartao:faturas-gerar`.
- **Parciais:** exportação PDF/Excel dos demonstrativos; plano de contas / SPED / escrituração como Nibo/Omie contábil.
- **Frágeis:** `QUEUE_CONNECTION=sync` no `.env.example` — risco em volume (**Código]**).
- **Ausentes [Mercado]:** conciliação bancária OFX massiva multi-banco como líderes — **não foi possível confirmar pelo código analisado**.

### 4. Fluxo **[Código]**

NF gera/atualiza parcelas → agência → conciliação / transferências / cartão.

### 5. Comparação **[Mercado]**

| Funcionalidade | NoLapis | Omie | Bling | Conta Azul | Tiny | Nibo / outros | Observação |
|-----------------|---------|------|-------|-------------|------|---------------|------------|
| A pagar / a receber | Intermediário | Avançado | Avançado | Avançado | Intermediário | Avançado (Nibo) | NoLapis via parcelas — modelo válido. |
| Conciliação | Intermediário | Avançado | Intermediário | Avançado | Básico | Avançado | NoLapis tem fluxo próprio — **possível diferencial** se robusto em produção. |
| Contabilidade formal | Básico | Avançado | Intermediário | Avançado | Básico | Diferencial (Nibo) | Não competir de igual com Nibo sem roadmap contábil. |

### 6. Fortes

Conciliação + cartão corporativo + parcelas amarradas à NF — **tesouraria integrada à operação**.

### 7. Fracos

Contabilidade/diplan para escritório — **inferido [Mercado]** como gap vs Omie/Nibo.

### 8. Ajustes

| Ajuste | Motivo | Risco | Pri. |
|--------|--------|-------|------|
| Filas reais em produção | Jobs de fatura/campanha | Alto | Crítico |
| SLAs e limites de conciliação | Performance | Médio | Alto |

### 9. Diferenciais **[Código]**

Conciliação com auditoria de reabertura; cartão fatura gerada por comando — **viável diferencial** para PME com cartão corporativo intenso.

### 10. Recomendações técnicas

Índices em `nfparcela` (datas, status, idagencia); idempotência em webhooks/jobs.

### 11. Produto

Evitar prometer “substitui contador” — posicionar **tesouraria + DFC/DRE gerenciais** (caixa quitado e resultado por hierarquia), não contabilidade legal.

### 12. Prioridade

**Essencial MVP** para proposta “financeiro + operação”.

---

## Módulo: Contratos e recorrência

### 1. O que existe **[Código]**

- Contratos com itens/veículos, recorrência, `ContratoService`, comando `assinatura:gerar-cobrancas` agendado; geração de NFs vinculadas.

### 2. Maturidade

| Critério | Valor | Motivo |
|----------|-------|--------|
| Técnica | **7/10** | Scheduler agressivo (cada minuto) pode ser risco operacional. |
| Funcional | **8/10** | Recorrência real. |
| Comercial | **8/10** | Diferencia PMEs com mensalidade. |
| Risco técnico | **Médio** | |
| Risco comercial | **Médio** | “Assinatura” vs assinatura SaaS. |
| Prontidão | **Alta** | Nicho recorrente. |

### 3. Funcionalidades

- **Completas:** contrato ativo/pendente/inativo; integração NF.
- **Parciais:** status `CONCLUÍDO` em view vs validação controller — consistência **[Código]** inventário.
- **Frágeis:** comando a cada minuto — custo e overlap.
- **Ausentes [Mercado]:** gestão de aditivos complexos, multa, indexador — **não confirmado**.

### 4. Fluxo **[Código]**

Contrato ativo → scheduler → serviço gera NF/parcelas → financeiro.

### 5. Comparação **[Mercado]**

| Funcionalidade | NoLapis | Omie | Bling | Conta Azul | Tiny | Outros | Observação |
|-----------------|---------|------|-------|-------------|------|--------|------------|
| Assinatura/recorrência | Intermediário | Avançado | Intermediário | Intermediário | Básico | Básico | NoLapis **bem posicionado** para serviços recorrentes. |

### 6–7. Fortes / Fracos

**Forte:** recorrência nativa ligada a NF. **Fraco:** menos flexível que suites maduras para edge cases.

### 8. Ajustes

| Ajuste | Motivo | Risco | Pri. |
|--------|--------|-------|------|
| Revisar periodicidade do scheduler | Infra/custo | Médio | Alto |
| Alinhar status contrato | UX e dados | Médio | Médio |

### 9. Diferenciais **[Código]**

Recorrência + NF + financeiro — **Diferencial** claro vs “só PDV” do MarketUP.

### 10–11. Recomendações

Backoff/jitter no schedule; UI de “próxima cobrança” e falhas.

### 12. Prioridade

**Diferencial / Essencial** conforme nicho (serviços recorrentes = essencial).

---

## Módulo: Estoque e lotes

### 1. O que existe **[Código]**

- `Lote`, `LoteTrans`, `LoteController`, `LoteEstoqueService`, `EstoqueService`; integração com venda.

### 2. Maturidade

| Técnica | Funcional | Comercial | RT | RC | Venda |
|---------|------------|-----------|----|----|-------|
| 6/10 | 6/10 | 5/10 | Médio | Médio | Média |

Motivo: estoque por **lote** é nicho (ex.: combustível, cimento — há componentes Livewire específicos no inventário de pastas); **não** é WMS completo genérico.

### 3. Funcionalidades

- **Completas:** movimentação por lote para domínios cobertos.
- **Ausentes [Mercado]:** multi-depósito, picking, endereçamento — **não confirmados**.

### 5. Comparação **[Mercado]**

| Funcionalidade | NoLapis | Bling | Omie | Tiny | Observação |
|-----------------|---------|-------|------|------|------------|
| Estoque genérico | Intermediário | Avançado | Avançado | Avançado | |
| Lote/indústria leve | Intermediário | Intermediário | Intermediário | Básico | NoLapis pode ser **Diferencial** em nicho vertical já sugerido pelo código (diesel/cimento etc. **[Estrutura]** por nomes de componentes no inventário). |

### 6–12. Resumo

**Forte:** lote para vertical específica. **Fraco:** paridade Bling e-commerce. **Prioridade:** **Fase 2** para ERP genérico; **Essencial** se nicho for esse vertical.

---

## Módulo: Fiscal (NF-e import, NFS-e, catálogos fiscais)

### 1. O que existe **[Código]**

- CFOP, finalidade fiscal, natureza operação, CTN; import NF-e + mapeamento produtos; `Nfe`/`NfeItem`; NFS-e (`Nfse`, `NfseXmlImportService`); Caixa de Entrada Fiscal (ADN/DistDFe); importar XML NFS-e em venda.

### 2. Maturidade

| Técnica | Funcional | Comercial | RT | RC | Venda |
|---------|------------|-----------|----|----|-------|
| 6/10 | 6/10 | 5/10 | **Alto** | **Alto** | **Baixa–Média** |

Motivo: fiscal **é** área de risco legal; emissão NF-e completa **não confirmada**; NFC-e **não confirmada**.

### 3. Funcionalidades

- **Completas:** importação e estruturação de NF-e; import XML NFS-e em venda; Caixa de Entrada Fiscal (consulta ADN/DistDFe).
- **Parciais:** maturidade de rejeição/cancelamento/carta de correção — **não mapeado**.
- **Frágeis:** vender “fiscal Omie” sem checklist.
- **Ausentes:** SPED contábil, apurações completas — **típico [Mercado]** fora escopo PME leve.

### 5. Tabela resumida **[Mercado]**

| | NoLapis | Omie/Bling/CA |
|--|---------|---------------|
| NF-e emissão | Não confirmado | Avançado |
| Importação XML | Intermediário | Avançado |
| NFS-e (import + Caixa de Entrada) | Intermediário | Avançado (vários players) |

### 8. Ajustes

| Ajuste | Motivo | Risco legal/comercial | Pri. |
|--------|--------|----------------------|------|
| Matriz “emitimos / não emitimos” | Compliance | Altíssimo | Crítico |
| Testes automatizados fiscais | Regressão | Alto | Crítico |

### 9. Diferenciais **[Código] limitado**

Import + mapeamento — útil; **não** único no mercado.

### 12. Prioridade

**Competitividade** se vender B2B com nota; **Fase 2** se posicionar como “pré-contábil”.

---

## Módulo: Agenda (pública + API)

### 1. O que existe **[Código]**

- CRUD agendas admin; rota pública `agendas/{pessoa}`; POST agendar; API `getHorariosOcupados`.

### 2. Maturidade

| Técnica | Funcional | Comercial | RT | RC | Venda |
|---------|------------|-----------|----|----|-------|
| 7/10 | 6/10 | 6/10 | Baixo | Baixo | Média–Alta |

### 5. Comparação **[Mercado]**

| | NoLapis | CA / outros |
|--|---------|-------------|
| Agenda simples | Intermediário | Intermediário |
| Agenda + operação + NF | Intermediário | Básico | **Possível diferencial** se integração ao evento/venda for vendida como pacote **[Estrutura]**. |

### 8–12

Garantir UX mobile da agenda pública; rate limit API. **Prioridade:** **Diferencial** para nicho serviços + agendamento.

---

## Módulo: Eventos, Kanban, time tracking, colaboração

### 1. O que existe **[Código]**

- Eventos, tipos, Kanban (status, etiquetas, checklists, comentários, membros, responsáveis), reorder, `TimeTrackingController`, `EventoKanbanActivityLogger` / `evento_atividade`.

### 2. Maturidade

| Técnica | Funcional | Comercial | RT | RC | Venda |
|---------|------------|-----------|----|----|-------|
| 7/10 | **8/10** | 6/10 | Médio | Baixo | **Alta** para nicho OS |

### 5. Comparação **[Mercado]**

| | NoLapis | Omie | Bling | Tiny | Observação |
|--|---------|------|-------|------|------------|
| OS/Kanban profundo | **Avançado** (para ERP) | Básico | Básico | Básico | ERPs horizontais **fracos** aqui — **Diferencial [Mercado]**. |

### 6. Fortes

Profundidade típica de **ferramenta de projeto/OS**, não de ERP médio.

### 7. Fracos

Pode confundir cliente que quer “só nota fiscal”.

### 8. Ajustes

| Ajuste | Motivo | Risco | Pri. |
|--------|--------|-------|------|
| Onboarding “modo OS” vs “modo nota” | Adoção | Médio | Alto |

### 9. Diferenciais **[Código]**

**Diferencial real** combinado com NF/evento.

### 12. Prioridade

**Diferencial** / **Fase 3** para ERP genérico; **Essencial** para nicho field service / instalação.

---

## Módulo: Campanhas e gamificação

### 1. O que existe **[Código]**

- Models campanha, job pós-venda, comando encerrar campanhas, dashboard ranking.

### 2. Maturidade

| Técnica | Funcional | Comercial | RT | RC | Venda |
|---------|------------|-----------|----|----|-------|
| 6/10 | 6/10 | 5/10 | Médio | Médio | Média |

### 5. Comparação **[Mercado]**

| | NoLapis | Bling/Tiny |
|--|---------|------------|
| CRM campanhas | Intermediário | Avançado em e-comm |

### 9. Diferencial

Possível **Diferencial** B2B trade (não e-comm). **Viável [Estrutura]** com mais UX.

### 12. **Fase 2–3** para MVP fiscal-first; **Diferencial** para trade.

---

## Módulo: Tags e retiradas

### 1. **[Código]** — tags, tipos, retiradas, dashboards, `TagRetiraService`.

### 2. Maturidade: técnica 6, funcional 6, comercial 5; risco médio/baixo.

### 5. **[Mercado]** — logística leve: Bling tem expedição; NoLapis parece **especializado** (retirada).

### 9. Diferencial **viável** em nicho com controle de retirada física.

### 12. **Fase 2** ou **Diferencial** vertical.

---

## Módulo: Veículos e custos

### 1. **[Código]** — frota, dashboards custo, vínculo NF/contrato/evento.

### 2. Maturidade 6–7; **nicho** transporte/frota.

### 5. **[Mercado]** — Omie tem módulos setoriais pagos; NoLapis **Intermediário** em frota light.

### 12. **Diferencial** para transporte; **Fase 2** genérico.

---

## Módulo: Fluxo configurável (status, transições, cores)

### 1. **[Código]** — `FluxoService`, tabelas fluxo/status, UI `fluxo/edit`, paleta.

### 2. Maturidade técnica **8**, funcional **8**; risco **médio** (complexidade para usuário final).

### 5. **[Mercado]** — Omie tem fluxos; NoLapis parece **mais exposto** na configuração — **Intermediário a Avançado**.

### 9. **Diferencial** para empresas com processo próprio sem IT.

### 12. **Competitividade** + **Diferencial**; cuidado com suporte.

---

## Módulo: PDV

### 1. **[Código]** — tela `/PDV`, Livewire PDV, `PdvNfService`, tabelas caixa; **POST `/PDV/store` stub** (`dd`).

### 2. Maturidade técnica **4**, funcional **4**, comercial **3**; risco técnico/comercial **Alto**.

### 3. **Frágil / incompleto** para venda como PDV concorrente de MarketUP/Bling PDV.

### 5. **[Mercado]** — NoLapis **Básico/Ausente** vs MarketUP/Bling PDV.

### 8. **Crítico:** fechar persistência ou retirar do site.

### 12. **Não prioritário** para GTM “PDV loja” até corrigir; **Fase 2+**.

---

## Módulo: Dashboards e “relatórios” visuais

### 1. **[Código]** — Painéis: visão geral, **DFC**, **DRE**, extrato, financeiro legado (KPIs), cartões; demais dashboards Livewire (produto, evento, tags, veículos, campanha). Documentação: **`Doc_Modulo_Dashboards.md`**.

### 2. Maturidade **7–8** / **7** / **6** (técnica/funcional/comercial) para analytics interno; DFC/DRE elevam paridade com “relatório gerencial” de suites PME.

### 5. **[Mercado]** — Conta Azul forte UX relatório; NoLapis **Intermediário–Avançado** em DRE/DFC **gerencial** [Código]; exportações e contábil formal **não confirmadas** [Código].

### 12. **Competitividade**; export PDF/Excel **Fase 2**.

---

## Módulo: Permissões e segurança

### 1. **[Código]** — Spatie, middleware `role`, CRUD permissions; policies vazias; poucos Form Requests; **login SSO** Google / Microsoft (`auth.social.*`); bloqueio de senha para contas `sso_obrigatorio`; pré-cadastro obrigatório (sem auto-provisionamento pelo IdP).

### 2. Maturidade 6 / 6 / 5 → **7 / 6 / 6** (com SSO); risco técnico **médio–alto** (validação e autorização fina); SSO reduz risco de senha fraca para tenants que adotam IdP.

### 5. **[Mercado]** — **Intermediário** vs suites com RBAC granular por tela+campo; **SSO social** alinhado a Omie/Conta Azul básico, atrás de SAML enterprise.

### 6. Fortes

Spatie roles; SSO Google/Microsoft; política por tenant e por usuário editável pelo admin NoLapis.

### 7. Fracos

Policies ainda vazias; confusão tenant/usuário na migração para SSO; sem SAML/SCIM por tenant.

### 8. Policies por recurso; testes de autorização; **Crítico** para multi-tenant em escala.

### 12. **Essencial** antes de escalar clientes.

---

## Módulo: Obras

### 1. **[Código]** — `ObraController`, views, model; **rotas não listadas** no inventário.

### 2. Maturidade baixa; prontidão **baixa**.

### 8. **Crítico:** rotas ou remover do escopo comercial.

### 12. **Não prioritário** ou **correção imediata** se for prometido.

---

# Diagnóstico Geral do NoLapis

1. **Tipo de produto mais próximo [Estrutura] + [Mercado]:** **sistema de gestão para PMEs** com ênfase em **operacional + financeiro (tesouraria)** e **OS/agenda**, mais que “contabilidade full” (Nibo) ou “e-commerce hub” (Bling/Tiny). Também: **ERP operacional-financeiro** com verticalização possível (frota, lote, retirada).

2. **Cinco módulos mais fortes hoje [Código]:** (1) NF unificada compra/pedido/venda, (2) Financeiro/parcelas/conciliação/cartão, (3) Contratos/recorrência, (4) Eventos/Kanban/time tracking, (5) Fluxo configurável.

3. **Cinco mais fracos/incompletos:** (1) PDV (stub), (2) Fiscal emissão completa **não confirmada**, (3) Obras sem rota, (4) API/billing avançado **parcial**, (5) Testes/auditoria global.

4. **Indispensáveis para vender com segurança:** cadastros estáveis; NF compra/venda/pedido com escopo fiscal explícito; financeiro/parcelas; multi-tenant; permissões mínimas sólidas; contrato de escopo.

5. **Fase 2:** campanhas avançadas, exportações, PDV loja, obras, integrações marketplace, contabilidade profunda.

6. **Onde NoLapis pode ser melhor [Mercado] + [Código]:** **OS/Kanban + time tracking** integrados a operação e NF; **fluxo configurável** muito explícito; **conciliação/tesouraria** ligada à NF; **recorrência contratual** nativa; **logística interna** (tags/retirada/lote) para nichos — líderes horizontais costumam ser mais rasos ou pagos como add-on.

7. **Onde é claramente pior [Mercado]:** **e-commerce** (Bling/Tiny); **contabilidade/SPED** (Omie/Nibo); **PDV varejo** (MarketUP/Bling); **ecossistema de integrações** e **API pública**; **marca/confiança** e **suporte em escala** (incumbentes).

8. **Onde não precisa competir [Recomendado]:** loja virtual completa; contador como produto central; SPED como promessa inicial.

9. **Nicho para lançar primeiro [Recomendado] + [Código]:** **PME B2B de serviço ou operação com entrega/OS** (instalação, manutenção, distribuição leve, agência de campo) que precisa de **agenda + execução + financeiro + nota importada/emissão de serviço controlada** — **não** competir como “ERP contábil único” nem como “PDV loja” até fechar lacunas.

---

# Matriz de Maturidade

| Módulo | MT | MF | MC | RT | RC | Prioridade |
|--------|----|----|----|----|----|------------|
| Multi-tenant / planos / billing entrada | 7 | 6 | 5 | M | M | Essencial |
| Cadastros | 7 | 7 | 7 | M | B | Essencial |
| Compras/Pedidos/Vendas (NF) | 6 | 8 | 7 | A | M | Essencial |
| Financeiro / parcelas / conciliação | 7 | 8 | 7 | M | M | Essencial |
| Contratos / recorrência | 7 | 8 | 8 | M | M | Diferencial nicho |
| Estoque / lotes | 6 | 6 | 5 | M | M | Nicho / Fase 2 |
| Fiscal | 6 | 6 | 5 | A | A | Crítico se prometer |
| Agenda | 7 | 6 | 6 | B | B | Diferencial |
| Eventos / Kanban | 7 | 8 | 6 | M | B | Diferencial |
| Campanhas | 6 | 6 | 5 | M | M | Fase 2–3 |
| Tags / retirada | 6 | 6 | 5 | M | B | Fase 2 vertical |
| Veículos | 6 | 7 | 5 | M | B | Nicho frota |
| Fluxo configurável | 8 | 8 | 6 | M | M | Competitivo |
| PDV | 4 | 4 | 3 | A | A | Não vender como está |
| Dashboards | 7 | 6 | 6 | M | B | Competitivo |
| Permissões | 6 | 6 | 5 | M–A | M | Essencial escala |
| Obras | 4 | 3 | 2 | M | M | Corrigir ou ocultar |

*MT/MF/MC = 0–10; RT/RC = Baixo/Médio/Alto.*

---

# Matriz Competitiva

| Área | NoLapis | Concorrente líder típico | Gap atual | Oportunidade |
|------|---------|--------------------------|-----------|----------------|
| Clientes/fornecedores | Intermediário | Omie/Bling/CA Avançado | API/portal | Nicho interno |
| Produtos/serviços | Intermediário | Bling Avançado | E-comm | Hierarquia + `linhadre` + DFC FCO/FCI/FCF |
| DRE / DFC gerencial | Intermediário–Avançado [Código] | Avançado | Avançado | Telas dedicadas; não SPED |
| Vendas | Avançado (op.) | Bling Avançado (e-comm) | Canal online | B2B operação |
| Compras | Intermediário | Omie Avançado | workflow compras | Import XML |
| Financeiro | Intermediário | Nibo/Omie Avançado | contábil | Tesouraria integrada |
| Contas a pagar/receber | Intermediário | CA/Omie Avançado | banco/OFX massivo | Conciliação |
| Parcelas | Intermediário | Omie Avançado | — | Fluxo+NF |
| Estoque | Nicho lote | Bling Avançado | WMS | Vertical |
| Fiscal | Parcial | Omie/Bling Avançado | emissão completa | Serviço+import |
| Agenda | Intermediário | CA Intermediário | — | Pacote serviço |
| Recorrência | Intermediário | Omie Avançado | edge | Contratos |
| Dashboards | Intermediário | CA Avançado | export | Operacional |
| Permissões | Intermediário | Omie Avançado | policies | Refino |
| Login SSO | Intermediário [Código] | CA/Omie Avançado | SAML/AD por cliente | Google/Microsoft + híbrido |
| Integrações | Básico | Bling Avançado | marketplace | API faseada |
| Onboarding | Básico | CA Avançado | wizard | Piloto guiado |
| UX | Intermediário | CA Avançado | polish | Nicho tolerante |
| Relatórios | Básico–Interm. | Omie Avançado | PDF/Excel | Livewire+export |
| Automação | Intermediário | Omie Avançado | jobs/scale | Scheduler+filas |
| IA | Ausente | Emergente mercado | — | Fase 4 |

---

# Análise dos status de negócio

**Diagnóstico [Código]:** o mesmo campo `nf.status` concentra **pipeline operacional** (separação, envio, entrega) e **estados terminais** (cancelado/inativo) e ainda **legado ortográfico** (`CONCLUIDO`/`CONCLUÍDO`). Isso **mistura** dimensões que em produtos maduros costumam ser separadas ou subordinadas a máquinas distintas.

**Parcelas:** migração moveu para `PENDENTE`/`PROGRAMADO`/`QUITADO`/`CANCELADO` — **melhor** que “CONCLUÍDO” financeiro, mas ainda **amarrado** a string + `idfluxostatus` — risco de divergência se UI não refletir fluxo.

**Proposta de modelagem [Recomendado]** (conceitual; implementação é esforço **G**):

### Venda (operacional / logística) — `nf` ou entidade derivada

- Rascunho → Pendente aprovação → Aprovada → Faturada (operação) → Em separação → Em envio → Entregue → Encerrada operacionalmente | Cancelada operacionalmente.

### Financeiro da venda — agregado em parcelas ou snapshot

- Sem parcelas → Parcelas geradas → Parcialmente liquidado → Liquidado → Inadimplente → Estornado/ajustado.

### Fiscal

- Não transmitida → Transmitida → Autorizada → Rejeitada → Cancelada/denegada — **espelhado** em `nfes`/`nfses`, não necessariamente em `nf.status` string única.

**Assinaturas:** separar **(A)** assinatura do software NoLapis e **(B)** contrato recorrente do cliente do tenant — nomes e dashboards distintos **[Recomendado]**.

---

# Riscos técnicos

| Risco | Onde aparece | Impacto | Probabilidade | Recomendação |
|-------|----------------|-----------|---------------|--------------|
| Controllers gigantes | `VendaController`, `NfController`, `ContratoController`, `Evento*` | Alto | Alta | Extrair use cases + testes |
| Dois modelos de “venda” | `nf` vs `vendas` | Alto | Média | Documentar; convergir ou renomear |
| Poucos testes | `tests/` | Alto | Alta | Pirâmide mínima por NF/parcela |
| Fila sync default | `.env.example` | Médio | Média | Produção com queue real |
| Policies vazias | `AuthServiceProvider` | Médio | Média | Policies + testes multi-tenant |
| Status polissêmico | `nf.status` | Alto | Média | Modelagem (seção acima) |
| Obras sem rota | `ObraController` | Baixo | Baixa | Rota ou remoção |
| PDV stub | `web.php` | Alto se vendido | Alta | Implementar ou ocultar |
| Dependências não usadas | Passport/Cashier | Médio | Média | Remover ou usar |

---

# Riscos comerciais

| Risco comercial | Impacto | Como mitigar |
|-----------------|---------|--------------|
| Prometer paridade Omie/Bling | Alto | Posicionamento nichado + checklist público de escopo |
| Vender PDV atual | Alto | Retirar marketing até MVP PDV |
| Fiscal sem maturidade declarada | Altíssimo | “Roadmap fiscal” + termos |
| Sem onboarding/trial claro | Médio | Piloto guiado + vídeos curtos |
| Suporte indefinido | Médio | Planos com SLA e canal único |
| Implantação não cobrada | Médio | Implantação paga em vertical complexo |

---

# Plano de Ação Go-to-Market (resumo em fases)

### Fase 1 — Crítico antes de vender amplo

| Pri | Fase | Módulo | Ação | Justificativa | Esforço | Impacto com. |
|-----|------|--------|------|---------------|---------|--------------|
| Crítico | 1 | Fiscal/Produto | Declarar escopo emissão vs import | Risco legal | M | muito alto |
| Crítico | 1 | PDV | Remover promessa ou implementar store | Risco venda | G | alto |
| Crítico | 1 | Plataforma | Filas reais + monitoramento jobs | Confiabilidade | M | alto |
| Crítico | 1 | Segurança | Testes multi-tenant + policies mínimas | Vazamento dados | M | muito alto |

### Fase 2 — MVP comercial vendável

| Alto | 2 | Geral | Pacote “Operação + financeiro + OS” | Nicho | M | alto |
| Alto | 2 | Onboarding | Wizard + dados demo | Adoção | M | alto |
| Médio | 2 | Relatórios | Export CSV/PDF top 5 | Paridade básica | M | médio |

### Fase 3 — Diferenciação

| Médio | 3 | Eventos/Fluxo | Case studies verticais | GTM | P | alto |
| Médio | 3 | Campanhas | Pacote trade B2B | Receita add-on | M | médio |

### Fase 4 — Escala

| Médio | 4 | API | Integrações selecionadas | Canal partner | G | muito alto |
| Médio | 4 | Observabilidade | APM, logs, auditoria financeira | Enterprise light | M | alto |

---

# Backlog priorizado (amostra executável)

| Ordem | Módulo | Tarefa | Tipo | Pri | Esf | Resultado |
|------:|--------|--------|------|-----|-----|-----------|
| 1 | Fiscal | Matriz pública emitimos/não | Produto | Crítico | P | Reduz risco |
| 2 | PDV | Implementar persistência ou esconder rota | Bug/UX | Crítico | G/M | Alinha promessa |
| 3 | Plataforma | Queue não-sync + supervisão | Ajuste téc | Crítico | M | Confiabilidade |
| 4 | NF/Venda | Extrair serviço de transição de status | Ajuste técnico | Alto | G | Manutenção |
| 5 | Permissões | Policies por recurso + testes | Segurança | Alto | M | Escala |
| 6 | Contrato | Revisar intervalo scheduler | Performance | Alto | P | Infra |
| 7 | Obras | Rotas ou deprecar | Ajuste | Médio | P | Consistência |
| 8 | Relatórios | CSV movimentação/financeiro | Funcional | Médio | M | Paridade |
| 9 | Onboarding | Checklist pós-login | UX | Alto | M | Adoção |
| 10 | API | Documentar 5 endpoints internos/partner | Comercial | Baixo | M | Canal futuro |

---

# Posicionamento comercial sugerido

1. **Público-alvo inicial [Recomendado]:** PME B2B **com campo/OS** e **cobrança recorrente ou projeto**, que já usa nota (importada ou serviço) e sofre com **planilha + WhatsApp**.
2. **Proposta de valor:** “Operação, financeiro e execução no mesmo lugar — com fluxo do jeito da sua empresa.”
3. **Destacar no site [Código]:** NF compra/venda/pedido; parcelas e bancos; conciliação; **DFC e DRE**; cartão corporativo; transferência entre contas; contratos; eventos/Kanban; agenda; importação XML; **login com Google/Microsoft**.
4. **Não destacar ainda:** PDV loja; obras; promessa fiscal total; campanhas até ter case.
5. **Argumentos:** menos disperso que “ERP + Monday à mão”; mais operacional que “só contábil”.
6. **Riscos vender cedo:** fiscal, PDV, suporte, expectativa Omie.
7. **Vender sem prometer demais:** página de **transparência de escopo** + roadmap.
8. **Planos [Recomendado]:** Bronze / Prata / Ouro (estrutura pedida).
   - **Bronze:** cadastros, compras/vendas essenciais, financeiro básico, 1 empresa, sem campanhas avançadas.
   - **Prata:** + contratos, fluxo completo, dashboards, import XML, multi-usuário padrão.
   - **Ouro:** + eventos/Kanban avançado, conciliação/cartão, agendamento, suporte prioritário, mais tenants/empresas.
9. **Add-ons [Recomendado]:** campanhas trade; integração fiscal premium; frota avançada; horas de customização fluxo.
10. **Implantação paga:** vertical com lote/tags/retirada — **G** configuração.
11. **Consultoria opcional:** “modelagem de status” e tesouraria — monetiza complexidade **[Recomendado]**.
12. **Suporte:** ticket Bronze; horário estendido Prata; Slack/phone Ouro — **padrão mercado [Mercado]**.

---

# Diferenciais possíveis

| Diferencial | Confirmado no código? | Potencial comercial | O que falta |
|-------------|----------------------|---------------------|-------------|
| OS/Kanban + NF | Sim (módulos existentes) | Alto | Cases + UX onboarding |
| Fluxo configurável exposto | Sim | Médio–Alto | Suporte/curadoria templates |
| Conciliação + auditoria reabertura | Sim (rotas/serviço) | Médio | Marketing tesouraria |
| Login SSO Google/Microsoft | Sim (cadastro + sign-in) | Médio | Comunicar tenant vs usuário; SAML fase 4 |
| Recorrência contrato → NF | Sim | Alto | Estabilidade fiscal clara |
| Agenda pública + API | Sim | Médio | Mobile/resiliência |
| Import XML + mapa produto | Sim | Médio | Não é único — empaquetar |
| IA | Não | Baixo hoje | Não priorizar |

---

# Parecer Final

**Resposta:** **Parcialmente, apenas para clientes controlados/piloto.**

**Motivo [Código] + [Mercado]:** o núcleo **operacional + financeiro + OS** é substancial e **pode** diferenciar de ERPs horizontais em nicho específico; porém **PDV com rota stub**, **fiscal sem matriz pública de emissão**, **testes mínimos**, **controllers de alto risco** e **lacunas (obras, dependências)** impedem recomendar **venda em massa self-service** como Omie/Bling sem **risco técnico e comercial alto**.

---

## Encerramento

1. **Resumo executivo:** NoLapis é um **ERP SaaS operacional-financeiro** com **OS/Kanban forte** e **tesouraria ligada à NF**; não é substituto pronto de **e-commerce** nem de **contabilidade Nibo** sem roadmap explícito.

2. **Diagnóstico técnico:** arquitetura Laravel sólida para MVP, mas **dívida em controllers**, **fila/testes**, **status polissêmicos** e **lacunas pontuais** (PDV, obras).

3. **Diagnóstico funcional:** **rico** em operação B2B e recorrência; **parcial** em fiscal PDV e relatórios exportáveis.

4. **Diagnóstico competitivo:** **evitar duelo frontal** com Omie/Bling/CA em “ERP completo PME”; **ganhar** em nicho **campo + financeiro + nota**.

5. **Maiores riscos:** promessa fiscal/PDV; escala sem filas/testes; posicionamento genérico.

6. **Maiores oportunidades:** OS integrado; fluxo configurável; conciliação; contratos; verticais com lote/retirada/frota.

7. **Roadmap recomendado:** Fase 1 transparência+fila+PDV ou ocultar; Fase 2 MVP nichado+export; Fase 3 cases+diferenciais; Fase 4 API/partners.

8. **Próximos 10 passos práticos**

1. Publicar matriz “emitimos / importamos / não suportamos” (fiscal).  
2. Decidir PDV: implementar fluxo completo ou remover do marketing.  
3. Configurar fila assíncrona em staging/prod.  
4. Suite mínima de testes: tenant isolation + transição NF + parcela.  
5. Refatorar primeiro caso de uso de `VendaController` para service.  
6. Normalizar documentação de status (produto + técnico).  
7. Pacote comercial piloto com escopo escrito e preço implantação.  
8. Gravar 3 vídeos: venda mercadoria, serviço+NFS-e, conciliação.  
9. Corrigir ou registrar obras e scheduler contrato.  
10. Atualizar `Doc_Inventario_Repositorio.md` após cada marco.

---

*Documento de consultoria. Comparativos de concorrentes em tabelas são **[Mercado]** (referência típica), não substituem due diligence em produtos terceiros.*