DEV Community: Leandro Horas Pereira

From a Login Screen to a Real ERP Flow: Building Navigation and the First Inventory Module

Leandro Horas Pereira — Wed, 01 Apr 2026 08:16:00 +0000

A few days ago, this project was still basically a login screen.

Now it has a responsive application shell, authenticated navigation, a module-based home screen, and its first real inventory flow connected to Supabase in production.

This article covers Sessions 5 and 6 of my project, ERP Modular, an open source ERP I am building as both a portfolio project and a deliberate way to learn professional software development in practice.

App demo video: [Watch the current app running here] https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z3cbtb0342nezld3g1bu.gif

https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cqjy3djighzy3vgzbk8r.gif

Why these two sessions mattered so much

Up to Session 4, I had already done the architectural planning, set the rules for the project, and implemented authentication. The system could log in and log out, but it still did not feel like an ERP yet.

Sessions 5 and 6 changed that.

Session 5 gave the project a real application structure:

authenticated routing
responsive navigation
a reusable app shell
a module-based home screen
a standard error/result pattern

Session 6 delivered the first actual business module end to end:

domain
repository
notifier
presentation
real data from Supabase
validated Row Level Security

That combination was important because it was the first time the architecture stopped being an intention and started behaving like a system.

Session 5: from isolated login to real ERP navigation

Session 5 focused on the navigation infrastructure of the app. Instead of continuing to add isolated screens, I built the foundation that defines how a user moves through the ERP.

The key pieces implemented were:

GoRouter with ShellRoute
a centralized router file in lib/core/router.dart
RouterNotifier to react to authentication changes
a responsive AppShell
a HomeScreen with module cards
placeholders for routes like dashboard and settings
the Resultado<T> pattern to standardize failures across layers

This was a big shift.

Before that, the project had a login screen and authentication flow. After Session 5, it had:

automatic redirects based on authentication
persistent navigation for authenticated screens
different navigation behavior for desktop and mobile
a home screen that already looked like the entry point of a modular ERP

According to my session notes, the project moved from “an isolated login screen” to “an application with real navigation — sidebar on desktop, mobile navigation, automatic authentication-based redirect, and a working home screen with module cards.” fileciteturn12file4

The responsive AppShell

One of the most important decisions from the previous architecture session was that the ERP should not let each screen invent its own layout. Instead, authenticated screens should live inside a shared shell. That decision became concrete in Session 5. The AppShell adapts navigation based on screen size, using a different structure for mobile, tablet, and desktop. fileciteturn12file4turn12file5

That matters more than it seems.

A login screen is just an entry point. A system starts to feel real when the user can move around it consistently.

Standardizing errors early

The other important addition in Session 5 was Resultado<T>, a sealed class used to standardize how repositories return either success or failure. From this point on, repositories are expected to return Resultado<T> instead of throwing unchecked exceptions directly. The context document explicitly defines this as one of the non-negotiable architectural rules of the project. fileciteturn12file0

That gave me a cleaner contract between layers:

repository returns Resultado<T>
notifier translates the result into state
widget renders the state

It is a small pattern, but it removes a lot of ambiguity when the project starts growing.

A session with an unexpected security check

Session 5 also had something I did not expect: a security detour.

Because of a reported RAT issue tied to the JavaScript ecosystem, I paused and verified my machine and other projects for traces of the malicious package. The result was clean, but the process itself was valuable. It reinforced a habit I want to keep: when a security concern appears, verify first and keep going with evidence instead of panic. fileciteturn12file6turn12file13

Session 6: the first real module, end to end

If Session 5 made the project feel like an application, Session 6 made it feel like an ERP.

This was the first real implementation session of the inventory module. In one session, I built the product feature through all layers:

domain
infrastructure
state management
presentation

The concrete result was a working stock listing screen connected to Supabase in production, with:

a rich Produto domain model
a repository contract in the domain
a Supabase repository implementation
a notifier with sealed states
search by name and internal code
soft delete with confirmation
visual low-stock indicators
a validated multi-tenant RLS behavior

The diary describes it as the first time a complete module was built “from domain to presentation in a single session,” with the stock module working through a full flow and RLS isolation validated in the database. fileciteturn12file1turn12file3

The `Produto` domain model

The Produto class became the richest domain entity in the project so far.

It includes identification, fiscal fields, stock quantities, pricing, location, image URL, reprocessing support, and multiple barcodes. It also includes derived properties like:

estoqueBaixo
ativo

That was an important design moment because I wanted the domain object itself to answer business questions.

For example, the UI should not decide whether stock is low. The product should know that.

This is one of the parts that made the architecture feel practical rather than theoretical.

The repository and the result pattern in practice

The IProdutoRepository contract was defined in the domain, and SupabaseProdutoRepository became the only class in the feature that actually knows Supabase.

That repository returns Resultado<T> for every operation, applies soft delete, and performs the data access logic while keeping the rest of the feature independent from the backend implementation. The session notes also mention that PostgreSQL error codes were classified in the repository, which is exactly the kind of boundary I wanted to establish between infrastructure and the rest of the app. fileciteturn12file1

Again, the rule stayed the same:

widget does not know Supabase
notifier does not know backend details
repository knows infrastructure
domain carries business meaning

A visual result that actually means something

By the end of Session 6, the stock screen was already showing three test products with meaningful feedback:

a washer below minimum stock with a red indicator
two other products above minimum stock with green indicators
a visible product counter
a working sidebar
refresh button
overflow menu
a floating action button for future product creation

That is exactly the kind of progress I wanted from this project: not just “data on the screen,” but data rendered with domain meaning. fileciteturn12file1

The accidental RLS test

One of the best moments of Session 6 was not planned.

A test ended up confirming that Row Level Security was working correctly in production. The isolation by empresa_id was not just documented or assumed; it was observed behaving correctly. The context notes summarize it directly: RLS was validated in production, and data inserted with the wrong empresa_id stayed invisible to the user. fileciteturn12file0turn12file13

That was a very meaningful milestone for me.

Because at that point, the project was no longer just “my architecture idea.” It had already validated one of its most important real-world constraints.

What these sessions taught me

Sessions 5 and 6 reinforced something I am starting to understand more clearly:

architecture only starts to prove itself when real features begin to use it.

It is easy to feel good about clean folders and diagrams. It is harder, and much more valuable, to see those decisions survive:

authentication redirects
responsive navigation
state transitions
repository boundaries
result handling
database isolation

These two sessions were the first time I felt that happening consistently in the project.

What comes next

The next step is Session 7: parsing NF-e XML files and starting the fiscal side of the inventory workflow. The current context already defines the next targets:

XmlService
fiscal domain classes like DocumentoFiscal, NotaFiscal, and ItemNota
repository and notifier for invoice import
a file selection screen
notas_fiscais and nota_itens tables in Supabase. fileciteturn12file13turn12file17

This is important because inventory without invoice import would still be incomplete for the actual use case I have in mind.

Conclusion

Session 5 gave the ERP a real application structure.

Session 6 gave it its first real business module.

Together, they marked the moment when the project stopped feeling like a prototype and started feeling like the beginning of a real system.

That does not mean it is complete. It is not.

But it now has:

authentication
responsive navigation
a modular home screen
a working inventory listing
search
soft delete
standardized error handling
validated multi-tenant isolation

For me, that is a meaningful threshold.

If you are also building a portfolio project and trying to learn architecture through something real instead of toy examples, this has been one of the most rewarding parts of the journey so far.

I will keep documenting the next steps.

I spent 3 hours writing no code — and it may have saved weeks on my ERP project

Leandro Horas Pereira — Tue, 31 Mar 2026 09:07:00 +0000

Why this session mattered

Session 4 of my ERP Modular project had no code at all.

No UI.
No new repository.
No new feature branch with a working screen.

And it may still have been one of the most important sessions so far.

Instead of implementing the next feature immediately, I spent about three hours reviewing the project structure, identifying architectural gaps, and formalizing decisions that would affect every module from this point on.

That changed the nature of the project.

It stopped being just a technically planned app and started becoming a structured product architecture.

The context

ERP Modular is an open source portfolio project I am building with:

Flutter
Supabase
Riverpod v3
GoRouter

The current focus is still Module 1: Warehouse and Inventory.

The first three sessions had already covered:

project planning
setup and infrastructure
full authentication with layered architecture

By Session 4, the codebase already had a foundation. But the architectural review showed that some important questions had not yet been fully decided:

What should happen right after login?
How should permissions work beyond a simple role field?
Should stock be controlled only per product, or per product and lot?
How should invoice duplication be handled?
What conventions should remain stable across future modules?
How should the system represent errors consistently?

Those are exactly the kinds of decisions that often get postponed until the code starts hurting.

I wanted to make them before that happened.

What was defined in Session 4

1. A real ERP entry point instead of jumping straight into Inventory

One of the first decisions was to stop thinking of the app as “login -> inventory”.

That would not fit a modular ERP.

So the post-login entry point became a general ERP home screen, with module cards shown according to:

what the company has activated
what the user has permission to access

That seems small, but it changes the entire navigation structure.

Instead of a feature-first entry point, the app now has a product-level entry point.

2. Permissions in three layers

A single role field would not be enough.

So the permission model was defined in three layers:

Role — the user's broad profile (admin, supervisor, operator, sales)
Module — which modules the company has active
Action — what the user can do inside each module (view, import, approve, edit, etc.)

This matters because real systems rarely map cleanly to a single role.

For example, two users can both be operators while still having different permissions inside Inventory.

The verification strategy was also defined in three places:

GoRouter for route-level redirection
widgets for UI visibility and usability
RLS in Supabase for actual data protection

That last part is important: hiding a button is not security.

3. Product and stock modeling became much more realistic

The product model was expanded well beyond the original basic structure.

It now includes concepts such as:

multiple barcodes
NCM and CEST fields
physical location
image URL
cost and sale price
reprocessing support
lot control
expiry date

The biggest modeling decision was this:

stock will be tracked by product and by lot from the beginning.

That has a major impact on the domain and database design, but it avoids a very common problem: starting with a simplified stock model and later discovering that the business flow actually needs traceability.

In this project, traceability matters.

That means the system needs to know:

total stock for a product
current stock for a specific lot
lot origin in reprocessing scenarios
which lot was used in each movement

That is much better to decide now than to retrofit later.

4. Invoice duplication is no longer a vague edge case

Another important decision was around duplicate NF-e imports.

For readers outside Brazil: NF-e (“Nota Fiscal eletrônica”) is the standardized electronic invoice format widely used in the country, and these invoices are often processed through XML files.

The system now has a defined duplication strategy:

detect duplicates by the invoice access key
show the existing record and its current status
allow navigation to the original note
allow reimport only with a required reason and supervisor approval
register the exception separately

A unique constraint on chave_acesso in the database was also defined to prevent duplication even if the Flutter logic fails.

That is one of my favorite types of decision: protect the flow both in the app and in the database.

5. Conference is now treated as a real state machine

This was one of the biggest improvements in the session.

The conference flow is no longer just “open” or “closed”.

It now has an explicit state machine:

criada
em_andamento
pausada
divergente
aguardando_aprovacao
concluida
cancelada
reaberta

More important than the list of states were the rules around the transitions.

For example:

any operator can pause and resume a conference
a divergent conference requires supervisor approval with a reason
reopening a completed conference also requires supervisor approval and a reason

This is exactly the kind of business rule that becomes fragile when modeled with booleans.

A state machine makes it explicit.

6. Naming conventions and error handling were standardized

Two technical patterns became formal rules during this session.

Naming

The project now has a definitive naming convention for:

database tables
Dart classes
interfaces
repository implementations
files and folders

For example:

database tables use plural snake_case
Dart classes use singular PascalCase
interfaces use the I prefix
Supabase implementations use the Supabase prefix

This sounds boring until the project starts growing.

At that point, inconsistent names become friction everywhere.

Error handling with `Resultado<T>`

This was another major decision.

Repositories will no longer throw raw exceptions to the rest of the app.

Instead, they return a sealed result type:

Sucesso<T>
Falha<T>

And failures are classified by a TipoFalha enum, with cases such as:

validation
domain
permission
not found
duplicate
invalid XML
network
server
unknown

The rule by layer became:

repository returns Resultado<T>
notifier translates that into state
widget displays state without knowing the failure type directly

That is one of the cleanest architectural decisions made so far.

7. A universal module guide was created

The final big outcome of the session was the creation of a Universal Module Guide.

The point of that document is simple:

I do not want to re-decide the same architectural rules every time a new module is created.

So instead of having architecture spread across memory, old chats, and assumptions, the project now has a reusable reference that defines:

mandatory folder structure
quality checklist
rules shared by all modules
module lifecycle
things that should never be done

That means future modules such as Sales, Technical Support, or Dashboards can start from a defined standard.

What I learned from a session with no code

This session reinforced something I am starting to value more and more:

architecture is not a delay before coding. It is one of the ways you avoid writing the wrong code faster.

It also reminded me that a good architecture review does not need to happen only inside one tool or from one perspective.

This session used both Claude and ChatGPT as structured reviewers for the same set of documents.

The result was surprisingly useful.

Not because either one “solved the architecture”, but because they pushed the review from different angles:

one helped consolidate decisions
the other helped identify missing points and inconsistencies

That process felt very close to a lightweight version of peer review.

What comes next

The next session returns to implementation.

The immediate goal is to replace home: LoginScreen in main.dart with:

GoRouter
ShellRoute
a responsive AppShell
a general HomeScreen with module cards
authentication-based redirection

But now that code will be written on top of a much clearer architectural base.

Final thought

A lot of beginner portfolio projects try to prove skill by showing how many features were shipped quickly.

I am trying something different.

I want this project to show that I am learning how to make technical decisions with intention.

Sometimes that means writing code.

Sometimes it means spending three hours writing no code at all — and still moving the project forward in a way that matters.

Building a Modular ERP from Scratch with Flutter, Supabase, and Riverpod — Part 1

Leandro Horas Pereira — Sun, 29 Mar 2026 10:36:59 +0000

English Version 🇺🇸

Why I started this project

I decided to build a modular ERP as a portfolio project with two goals in mind:

build something real, with actual business value
learn professional software development in practice instead of studying isolated concepts with no real context

The project is called ERP Modular, and it is aimed at small businesses.

Right now, the focus is only on Module 1: Warehouse and Inventory.

The goal is not to jump into multiple modules at once. The goal is to build a solid foundation first and expand later with more confidence.

What I am building

In this first module, I want to support a real operational flow:

import NF-e XML files, the XML documents used by Brazil's electronic invoice system
read barcodes
check invoice items against scanned products
manage inventory with movement history
generate conference PDFs
support multiple companies with Row Level Security

So this is not just a pretty UI project. It is a system designed around real business rules.

For readers outside Brazil: NF-e ("Nota Fiscal eletrônica") is the standardized electronic invoice format widely used in the country.

Chosen stack

The stack I chose was:

Flutter for the frontend
Supabase for the backend
Riverpod for state management
Go Router for navigation
mobile_scanner for barcode scanning
xml for NF-e parsing

I chose Flutter because I wanted a single codebase that could eventually run on web, desktop, and mobile.

I chose Supabase because I wanted a real PostgreSQL database, built-in authentication, storage, and row-level security without having to maintain my own backend from day one.

The most important rule of the project

Before writing the first line of code, I defined one rule:

I did not want to repeat the beginner mistake of coding without direction and accumulating technical debt from the very first commit.

Because of that, my first session was entirely dedicated to planning.

I wrote no code at all. And that was intentional.

Session 1: planning before implementation

In the first session, I defined:

the scope of the current module
the technical stack
the layered architecture
the feature-based folder structure
Git rules
the initial database model
the OOP concepts and design patterns I wanted to apply consciously

The architecture looked like this:

lib/
  features/
    estoque/
      presentation/
      application/
      domain/
      infrastructure/
    notas/
      presentation/
      application/
      domain/
      infrastructure/
    conferencia/
      presentation/
      application/
      domain/
      infrastructure/
  core/
    services/

The idea was simple:

presentation displays
application orchestrates state
domain defines rules and contracts
infrastructure implements external access

I also established a few golden rules from the beginning:

no widget talks directly to the database
no provider knows where the data comes from
complex objects should be created through factory constructors
commits must follow Conventional Commits

That first session mattered because it forced me to think like someone building a real system, not just assembling screens.

Session 2: setup and infrastructure

In the second session, planning became real structure.

That was when I:

created the public GitHub repository
configured the project in Supabase
generated the Flutter project correctly
organized the layered folder structure
added supabase_flutter, flutter_riverpod, and go_router
initialized Supabase in the app
ran the application on Linux desktop

One detail that changed my mindset was the fact that the first important commit was not a feature.

It was .gitignore.

I protected credentials before almost anything else, including the local Supabase configuration file.

That may sound small, but it is not.

It was a technical decision to avoid leaking something sensitive into the repository history right at the beginning.

Another important part of this session was getting more intentional exposure to terminal commands and Git.

I had used Git before, but this was the moment when I started to better understand:

staging
the difference between local and remote
commit organization
the value of small commits
commit history visualization in VS Code Source Control

Seeing Supabase initialized and the app running for the first time was a simple milestone, but a very meaningful one.

Session 3: full authentication and the first real engineering moment

The third session was the most intense one so far.

In about two hours, I implemented the complete authentication feature while respecting the project's layers:

domain
infrastructure
application
presentation

The final result was a real login flow with:

email and password authentication
form validation
loading and error states
display of the authenticated user's name and role
working logout

But the most important part was not that the login worked.

It was how it was built.

1. The `Usuario` domain class

This was the first real domain entity in the project.

I consciously applied:

final fields
a constructor with required named parameters
factory Usuario.fromMap()
toMap()
equality and hashCode overrides

This was the moment when some OOP concepts finally started to make sense in practice.

For example:

immutability: an authenticated user should not suddenly become a different user during execution
encapsulation: the object controls its own state and its own creation

2. `IAuthRepository`

Instead of letting the UI or the state layer talk directly to the backend, I defined an abstract contract with the main authentication methods.

In other words, anything that depends on this repository knows what it does, but not how it does it.

3. `SupabaseAuthRepository`

This class isolated the concrete Supabase implementation.

That taught me an important distinction:

Supabase Auth handles credentials
business-related user data lives in the usuarios table

So the flow was not just “log in.”

It was:

authenticate with Supabase Auth
fetch the user's name, role, and company data
transform that raw data into a valid domain object

That was one of those moments when architecture stopped being a diagram and became code with clear responsibilities.

4. `AuthState` and `AuthNotifier`

For state management, I modeled the authentication scenarios explicitly:

initial
loading
authenticated
unauthenticated
error

That helped me understand why explicit state modeling avoids invalid combinations and makes UI logic simpler.

5. `LoginScreen`

The screen became responsible for observing state and displaying what made sense for each scenario.

No database logic.

No infrastructure logic.

No improper coupling.

That was exactly the kind of separation I wanted to practice in this project.

The mistake that taught me the most so far

Not everything worked on the first try.

In Session 3, I started implementing the authentication state using a Riverpod v2 pattern, but the project was already using Riverpod v3.

The result was a lot of errors at once in the editor.

It was frustrating for a few minutes, but it turned into one of the best lessons so far.

Because the problem was not simply “the code is broken.”

The problem was more professional than that:

I was using an outdated pattern for a different version of the library.

Fixing it required rewriting the implementation using Notifier and NotifierProvider, and that made the concept much clearer than if everything had worked immediately.

Another small but useful mistake also happened: I committed an empty interface file because I forgot to save it before running git add.

I fixed it with a fix commit and enabled autosave to prevent it from happening again.

What this project is actually teaching me

So far, the biggest gain is not only technical.

It is mindset.

I am starting to understand more clearly:

why architecture is not bureaucracy
why separating responsibilities reduces confusion
why small commits improve the way I think
why patterns make sense when they emerge as solutions to real problems
why documenting blockers is just as valuable as documenting wins

I am also seeing something important in practice:

good code does not appear ready-made.

It improves as the foundation, criteria, and understanding improve.

Next steps

The next focus of the project is to keep expanding the Warehouse and Inventory module according to the roadmap, moving toward product listing screens, product modeling, XML import, barcode-based checking, stock movements, and reports.

But the priority remains the same:

grow with consistency, not in a hurry.

Conclusion

This project is my way of studying software development more honestly.

Instead of only consuming theory, I am trying to build something real and use every step to better understand:

OOP
layered architecture
design patterns
Git
domain modeling
backend integration

It is still the beginning.

But it is the most solid beginning I have managed to build so far.

If you are also studying architecture, Flutter, or building a portfolio project with more intention than urgency, I will keep documenting this journey.

Versão em Português 🇧🇷

Por que comecei este projeto

Decidi construir um ERP modular como projeto de portfólio com dois objetivos em mente:

construir algo real, com valor de negócio de verdade
aprender desenvolvimento de software de forma prática, em vez de estudar conceitos isolados sem contexto real

O projeto se chama ERP Modular e é voltado para pequenos negócios.

Neste momento, o foco está somente no Módulo 1: Almoxarifado e Estoque.

A ideia não é sair construindo vários módulos de uma vez. A prioridade é criar uma base sólida primeiro e expandir depois com mais confiança.

O que estou construindo

Neste primeiro módulo, quero atender um fluxo operacional real:

importar arquivos XML de NF-e
ler códigos de barras
conferir itens da nota com os produtos escaneados
controlar o estoque com histórico de movimentações
gerar PDFs de conferência
suportar múltiplas empresas com Row Level Security

Ou seja, este não é apenas um projeto com uma interface bonita. É um sistema pensado em torno de regras de negócio reais.

Stack escolhida

A stack que defini foi:

Flutter no frontend
Supabase no backend
Riverpod para gerenciamento de estado
Go Router para navegação
mobile_scanner para leitura de códigos de barras
xml para parse de NF-e

Escolhi Flutter porque queria um único codebase com potencial para rodar em web, desktop e mobile.

Escolhi Supabase porque queria um banco PostgreSQL real, autenticação pronta, storage e segurança em nível de linha sem precisar manter um backend próprio desde o primeiro dia.

A regra mais importante do projeto

Antes de escrever a primeira linha de código, defini uma regra:

eu não queria repetir o erro de iniciante de sair codando sem direção e acumular dívida técnica desde o primeiro commit.

Por isso, minha primeira sessão foi inteiramente dedicada ao planejamento.

Eu não escrevi nenhuma linha de código. E isso foi intencional.

Sessão 1: planejamento antes da implementação

Na primeira sessão, defini:

o escopo do módulo atual
a stack técnica
a arquitetura em camadas
a estrutura de pastas por feature
as regras de Git
a modelagem inicial do banco
os conceitos de POO e os design patterns que eu queria aplicar conscientemente

A arquitetura ficou assim:

lib/
  features/
    estoque/
      presentation/
      application/
      domain/
      infrastructure/
    notas/
      presentation/
      application/
      domain/
      infrastructure/
    conferencia/
      presentation/
      application/
      domain/
      infrastructure/
  core/
    services/

A lógica era simples:

presentation exibe
application orquestra estado
domain define regras e contratos
infrastructure implementa o acesso externo

Também estabeleci algumas regras de ouro desde o começo:

nenhum widget fala diretamente com o banco de dados
nenhum provider sabe de onde os dados vêm
objetos complexos devem ser criados por factory constructors
os commits precisam seguir Conventional Commits

Essa primeira sessão foi importante porque me obrigou a pensar como alguém que está construindo um sistema real, e não apenas juntando telas.

Sessão 2: setup e infraestrutura

Na segunda sessão, o planejamento virou estrutura real.

Foi quando eu:

criei o repositório público no GitHub
configurei o projeto no Supabase
gerei o projeto Flutter corretamente
organizei a estrutura de pastas da arquitetura
adicionei supabase_flutter, flutter_riverpod e go_router
inicializei o Supabase no app
rodei a aplicação no Linux desktop

Um detalhe que mudou minha forma de pensar foi o fato de o primeiro commit importante não ter sido uma feature.

Foi o .gitignore.

Eu protegi as credenciais antes de quase qualquer outra coisa, incluindo o arquivo local de configuração do Supabase.

Isso pode parecer pequeno, mas não é.

Foi uma decisão técnica para evitar que algo sensível vazasse para o histórico do repositório logo no começo.

Outra parte importante dessa sessão foi ter um contato mais intencional com comandos de terminal e com Git.

Eu já tinha usado Git antes, mas esse foi o momento em que comecei a entender melhor:

staging
a diferença entre local e remoto
a organização dos commits
o valor de commits pequenos
a visualização do histórico de commits no Source Control do VS Code

Ver o Supabase inicializado e o app rodando pela primeira vez foi um marco simples, mas muito significativo.

Sessão 3: autenticação completa e o primeiro momento real de engenharia de software

A terceira sessão foi a mais intensa até agora.

Em cerca de duas horas, implementei a feature completa de autenticação respeitando as camadas do projeto:

domain
infrastructure
application
presentation

O resultado final foi um fluxo de login real com:

autenticação por e-mail e senha
validação de formulário
estados de carregamento e erro
exibição do nome e do papel do usuário autenticado
logout funcionando

Mas a parte mais importante não foi apenas o login funcionar.

Foi como ele foi construído.

1. A classe de domínio `Usuario`

Essa foi a primeira entidade de domínio real do projeto.

Nela, apliquei conscientemente:

campos final
construtor com parâmetros nomeados obrigatórios
factory Usuario.fromMap()
toMap()
sobrescrita de igualdade e hashCode

Esse foi o momento em que alguns conceitos de POO finalmente começaram a fazer sentido na prática.

Por exemplo:

imutabilidade: um usuário autenticado não deve simplesmente virar outro durante a execução
encapsulamento: o objeto controla o próprio estado e a própria criação

2. `IAuthRepository`

Em vez de deixar a UI ou a camada de estado falarem diretamente com o backend, defini um contrato abstrato com os principais métodos de autenticação.

Em outras palavras, qualquer parte que dependa desse repositório sabe o que ele faz, mas não como ele faz.

3. `SupabaseAuthRepository`

Essa classe isolou a implementação concreta com Supabase.

Isso me ensinou uma distinção importante:

o Supabase Auth cuida das credenciais
os dados de negócio do usuário ficam na tabela usuarios

Então o fluxo não era apenas “fazer login”.

Era:

autenticar com o Supabase Auth
buscar nome, papel e dados da empresa do usuário
transformar esses dados brutos em um objeto de domínio válido

Esse foi um daqueles momentos em que a arquitetura deixou de ser um diagrama e virou código com responsabilidades claras.

4. `AuthState` e `AuthNotifier`

No gerenciamento de estado, modelei explicitamente os cenários da autenticação:

inicial
carregando
autenticado
não autenticado
erro

Isso me ajudou a entender por que uma modelagem explícita de estados evita combinações inválidas e simplifica a lógica da UI.

5. `LoginScreen`

A tela passou a ser responsável por observar o estado e exibir o que fazia sentido em cada cenário.

Sem lógica de banco de dados.

Sem lógica de infraestrutura.

Sem acoplamento indevido.

Esse era exatamente o tipo de separação que eu queria praticar neste projeto.

O erro que mais me ensinou até agora

Nem tudo funcionou de primeira.

Na Sessão 3, comecei implementando o estado da autenticação com um padrão de Riverpod v2, mas o projeto já estava usando Riverpod v3.

O resultado foi uma grande quantidade de erros de uma vez no editor.

Foi frustrante por alguns minutos, mas acabou se tornando uma das melhores lições até aqui.

Porque o problema não era simplesmente “o código está quebrado”.

O problema era mais profissional do que isso:

eu estava usando um padrão desatualizado para uma versão diferente da biblioteca.

Corrigir isso exigiu reescrever a implementação usando Notifier e NotifierProvider, e isso deixou o conceito muito mais claro do que se tudo tivesse funcionado de primeira.

Outro erro pequeno, mas útil, também aconteceu: comitei um arquivo de interface vazio porque esqueci de salvá-lo antes de executar git add.

Corrigi com um commit de fix e ativei o autosave para evitar que isso aconteça de novo.

O que este projeto está realmente me ensinando

Até aqui, o maior ganho não é apenas técnico.

É mentalidade.

Estou começando a entender com mais clareza:

por que arquitetura não é burocracia
por que separar responsabilidades reduz confusão
por que commits pequenos melhoram a forma como eu penso
por que patterns fazem sentido quando surgem como solução para problemas reais
por que documentar travamentos é tão valioso quanto documentar acertos

Também estou vendo algo importante na prática:

código bom não aparece pronto.

Ele melhora à medida que a base, os critérios e o entendimento evoluem.

Próximos passos

O próximo foco do projeto é continuar expandindo o módulo de Almoxarifado e Estoque de acordo com o cronograma, avançando para telas de listagem de produtos, modelagem de produto, importação de XML, conferência por código de barras, movimentações de estoque e relatórios.

Mas a prioridade continua a mesma:

crescer com consistência, não com pressa.

Conclusão

Este projeto é a minha forma de estudar desenvolvimento de software de maneira mais honesta.

Em vez de apenas consumir teoria, estou tentando construir algo real e usar cada etapa para entender melhor:

POO
arquitetura em camadas
design patterns
Git
modelagem de domínio
integração com backend

Ainda é só o começo.

Mas é o começo mais sólido que já consegui construir até aqui.

Se você também está estudando arquitetura, Flutter ou construindo um projeto de portfólio com mais intenção do que urgência, eu vou continuar documentando essa jornada.

DEV Community: Leandro Horas Pereira

From a Login Screen to a Real ERP Flow: Building Navigation and the First Inventory Module

Why these two sessions mattered so much

Session 5: from isolated login to real ERP navigation

The responsive AppShell

Standardizing errors early

A session with an unexpected security check

Session 6: the first real module, end to end

The Produto domain model

The repository and the result pattern in practice

A visual result that actually means something

The accidental RLS test

What these sessions taught me

What comes next

Conclusion

I spent 3 hours writing no code — and it may have saved weeks on my ERP project

Why this session mattered

The context

What was defined in Session 4

1. A real ERP entry point instead of jumping straight into Inventory

2. Permissions in three layers

3. Product and stock modeling became much more realistic

4. Invoice duplication is no longer a vague edge case

5. Conference is now treated as a real state machine

6. Naming conventions and error handling were standardized

Naming

Error handling with Resultado<T>

7. A universal module guide was created

What I learned from a session with no code

What comes next

Final thought

Building a Modular ERP from Scratch with Flutter, Supabase, and Riverpod — Part 1

English Version 🇺🇸

Why I started this project

What I am building

Chosen stack

The most important rule of the project

Session 1: planning before implementation

Session 2: setup and infrastructure

Session 3: full authentication and the first real engineering moment

1. The Usuario domain class

2. IAuthRepository

3. SupabaseAuthRepository

4. AuthState and AuthNotifier

5. LoginScreen

The mistake that taught me the most so far

What this project is actually teaching me

Next steps

Conclusion

Versão em Português 🇧🇷

Por que comecei este projeto

O que estou construindo

Stack escolhida

A regra mais importante do projeto

Sessão 1: planejamento antes da implementação

Sessão 2: setup e infraestrutura

Sessão 3: autenticação completa e o primeiro momento real de engenharia de software

1. A classe de domínio Usuario

2. IAuthRepository

3. SupabaseAuthRepository

4. AuthState e AuthNotifier

5. LoginScreen

O erro que mais me ensinou até agora

O que este projeto está realmente me ensinando

Próximos passos

Conclusão

The `Produto` domain model

Error handling with `Resultado<T>`

1. The `Usuario` domain class

2. `IAuthRepository`

3. `SupabaseAuthRepository`

4. `AuthState` and `AuthNotifier`

5. `LoginScreen`

1. A classe de domínio `Usuario`

2. `IAuthRepository`

3. `SupabaseAuthRepository`

4. `AuthState` e `AuthNotifier`

5. `LoginScreen`