Descrição:
# Quem somos nós
Receitech é a primeira solução completa para quem produz e vende comida por conta própria.
Enquanto restaurantes já contam com sistemas completos de gestão, milhões de pequenos vendedores de comida seguem sem uma solução feita para a realidade da sua operação.
O Receitech resolve esse problema reunindo, em uma única ferramenta simples, as principais rotinas financeiras e operacionais desses negócios: precificação, pedidos, vendas, estoque e acompanhamento de lucro.
Nosso objetivo é dar a esses empreendedores a infraestrutura que eles ainda não têm para tomar decisões melhores, vender com mais segurança e transformar esforço em lucro real.
# Estágio atual
O Receitech já está disponível em sua primeira versão (web, app store e play store) e atualmente está passando por ajustes e expansão de funcionalidades.
Hoje o app já permite:
- cadastrar ingredientes, receitas e produtos e gerir os custos de tudo
- calcular preços de venda para assegurar lucratividade
- simular lucro mensal com base na quantidade de produtos vendidos
- registrar e acompanhar vendas e lucros do negócio
- visualizar quanto realmente sobra de lucro ao longo do mês
# Escopo do trabalho
O escopo abaixo refere-se a um período de trabalho inicial de 1 mês.
As atividades do desenvolvedor englobam:
- **Evolução do app:** Implementação de melhorias listadas no backlog, priorizadas semanalmente de acordo com o roadmap do app através de reuniões
Não haverá controle de jornada ou cobrança de horário de trabalho. Contaremos com reuniões combinadas entre ambas as partes para garantir alinhamento e priorização conjunta, a partir disso, o contratado possui total liberdade para decidir como trabalhar para realizar os entregáveis até as datas acordadas.
A *codebase* poderá ser disponibilizada ao contratado mediante assinatura de termo de confidencialidade (NDA).
# Expectativa de colaboração
O desenvolvimento do produto está sendo conduzido por três pessoas e organizado através de um backlog de tarefas.
As melhorias descritas acima representam a direção geral do produto, mas o trabalho será organizado em **tarefas menores priorizadas semanalmente**.
A expectativa não é implementar tudo de uma vez, mas sim **evoluir o produto gradualmente**, em blocos semanais, trabalhando nas tarefas mais importantes a cada momento.
Estamos buscando alguém que possa colaborar conosco de forma contínua, implementando funcionalidades, melhorias e correções conforme priorização do backlog.
# Tecnologias
Segue abaixo breve documentação técnica do app para entendimento de filosofia de desenvolvimento e stack utilizada até o momento.
# Remuneração
R$ 1.500,00 pelo período de um mês de trabalho.
Possibilidade de colaboração de longo prazo e participação societária conforme evolução do projeto e entregas realizadas.
# 📋 Receitech — Visão Geral para Desenvolvedores
> \*\*App Flutter\*\* para gestão de receitas e produtos alimentícios, com foco em \*\*cálculo de custo, precificação e lucratividade\*\*.
> O app até o momento foi desenvolvido por duas pessoas, em um desenvolvimento orientado por AI, com critério de arquitetura e revisão de código gerado a fim de garantir consistência ao longo da codebase.
\---
## 🛠️ Stack Técnica
|Camada|Tecnologia|
|-|-|
|**Framework**|Flutter (Dart SDK `^3.5.4`)|
|**Backend/DB**|[Supabase](https://supabase.com) (PostgreSQL + Auth + Storage)|
|**Estado**|`provider` (ChangeNotifier + MultiProvider)|
|**Persistência**|`shared\_preferences` (estado local leve)|
|**Deploy Web**|Firebase Hosting (preview channels + produção)|
|**Linter**|`flutter\_lints` (regras padrão do Flutter)|
\---
## 🏗️ Arquitetura: Feature-First + Repository-Provider
O código é organizado **por funcionalidade** (não por tipo de arquivo). Cada feature segue uma estrutura em camadas:
```
lib/
├── main.dart # Bootstrap: Supabase init + MultiProvider
├── app/
│ ├── app\_widget.dart # MaterialApp (tema + AuthWrapper)
│ ├── core/
│ │ ├── theme/ # AppColors, AppTheme, AppIcons
│ │ ├── widgets/ # Widgets reutilizáveis globais
│ │ └── utils/ # Mixins e helpers
│ └── navigation/ # NavigationProvider (tab persistente)
│
└── features/ # Cada feature tem data/ + presentation/
├── auth/ # Autenticação (Supabase Auth)
├── home/ # Bottom nav com PageView
├── onboarding/ # Telas introdutórias
├── profile/ # Perfil do usuário
├── ingredient/ # CRUD de ingredientes
├── packaging/ # CRUD de embalagens
├── recipe/ # CRUD de receitas
├── products/ # CRUD + fluxo de criação de produtos
├── supplies/ # Tela de insumos
└── common/ # Repositórios compartilhados
```
### Camadas Internas de Cada Feature
|Camada|Responsabilidade|
|-|-|
|`data/models/`|Modelos Dart com `fromMap()` / `toMap()` para Supabase|
|`data/\*\_repository`|Acesso direto ao Supabase (queries, storage)|
|`presentation/providers/`|`ChangeNotifier` — estado e lógica de UI|
|`presentation/pages/`|Telas/rotas|
|`presentation/widgets/`|Widgets específicos da feature|
\---
## ⚙️ Gerenciamento de Estado
* `ChangeNotifier` + `Provider` — é o **único** gerenciador de estado do projeto (sem BLoC, Riverpod, GetX)
* Todos os providers são registrados no `main.dart` via `MultiProvider`
* Uso de `context.read()` para ações e `context.watch()` para reatividade
* Padrão: cada feature tem um `Repository` (dados) e um `Provider` (estado) que consome o repository
\---
## 🗄️ Backend (Supabase)
* **Filosofia: backend como camada lean de dados** — lógica de negócio fica no app (Dart)
* Evita-se Edge Functions, RPCs complexas ou triggers desnecessários
* Alterações no schema são sempre validadas antes de aplicar
* Autenticação via Supabase Auth (email + senha)
* Upload de imagens via Supabase Storage
* Variáveis de ambiente (URL, chaves) injetadas em **compile-time** via `--dart-define-from-file=.env`
\---
## 🔀 Git e Workflow de Desenvolvimento
* **Branch principal:** `main`
* **Feature branches:** cada funcionalidade ou correção é feita em uma branch descritiva.
* **Merge via Pull Request** no GitHub
* **CI:** GitHub Actions configurado para build iOS on-demand (`workflow\_dispatch`)
* **Deploy web:** via Firebase Hosting com Makefile — `make deploy-test` (preview) e `make deploy-prod` (produção)
\---
## 📚 Documentação Complementar
O repositório mantém documentação detalhada em `docs/` sobre regras de negócio, schema do banco, arquitetura de custos e fluxos específicos. Este documento é apenas uma visão geral técnica — os detalhes de cada domínio estão em docs dedicados para explicação de especificidades e a maior parte da codebase segue padrões de mercado de desenvolvimento.