DEV Community: Felipe Ribeiro

[BUILD IN PUBLIC #1] — Estou construindo um SaaS para ajudar pequenos e médios empreendedores com seus feedbacks

Felipe Ribeiro — Tue, 20 May 2025 16:41:00 +0000

Introdução

Opa! Me chamo Felipe, tenho 23 anos e neste ano de 2025 eu decidi me juntar ao movimento de Indie Hacking. Não foi uma decisão 'do nada', já vinha tendo matérias focadas em empreendedorismo há 2 anos na faculdade (faço Engenharia de Computação desde 2021), mas somente após conhecer uma onda de pessoas trabalhando em seus próprios projetos, construindo seus sonhos e ganhando dinheiro com isso, decidi que entraria de vez para esse caminho!

O Projeto

O projeto se chamará Feedlyze e estou construindo ele há pouco mais de uma semana. O projeto em si consiste em que este pequeno/médio empreendedor que possua um negócio digital extraia através da ferramenta base desse negócio (Shopify, Mercado Pago, IFood, Hotmart, canal no YT, Instagram...) o arquivo referente aos feedbacks do seu cliente — isso é uma opção comumente fornecida por essas plataformas (geralmente em CSV ou JSON) — podendo ser feedbacks simples de comentários como também feedbacks mais específicos como NPS (Net Promoter Score) e CSAT (Customer Satisfaction Score).

Em posse desse arquivo, o usuário subiria ele para o Feedlyze que, com a IA, geraria um relatório detalhado com gráficos e sugestões de melhorias para seu negócio utilizando como base esses feedbacks recebidos, a fim de proporcionar insights para que este empreendedor possa crescer ainda mais seu negócio, entregando com melhor qualidade o seu serviço.

Atualmente, a página do projeto está assim:

Buscando o diferencial

Se o foco são pequenos e médios empreendedores, os quais geralmente terão um caixa apertado, para eles não compensa pagar R$100, R$200, R$500 por mês em análises complexas de relatórios como muitos serviços oferecem (SurveyMonkey, Typeform, UserVoice, UserTesting...).

A precificação iniciaria em torno de R$5,00 - R$15/20 — NÃO RECORRENTE
Praticidade: Sem necessidade de cadastro

Stack

Frontend → Flutter Web
Backend → Supabase
SMTP → Mailtrap
AI → Deepseek API

Finalizando

Para ser sincero, esse é meu primeiro SaaS. Creio que nesse caminho já cometi erros de principiante e ainda cometerei mais. Mas o aprendizado aqui é constante e estou disposto a aprender com meus erros.

Aceito sugestões e críticas construtivas, pois é ouvindo de outros devs, empreendedores e usuários comuns que vou poder melhorar em diversos pontos dessa minha jornada.

Me acompanhe

Vou estar documentando todo o processo dessa minha nova jornada no empreendedorismo lá no X/Twitter e talvez eu crie um canal no Youtube pra poder trazer ainda mais conteúdos de build in public e criação de micro-saas.

🚀 Do zero ao primeiro SaaS: 3 erros que me ensinaram mais do que qualquer acerto

Felipe Ribeiro — Mon, 05 May 2025 19:35:11 +0000

Em janeiro, decidi tirar minha ideia de SaaS do papel. O objetivo? Aprender na prática como levar um produto do conceito à loja. Confesso que foi uma onda de desafios (e ainda está sendo!).

Como era meu primeiro projeto, cometi vários equívocos. Eu queria compartilhar alguns abaixo ⤵️ — e como eles estão me ajudando a evoluir:

🔥 Planejamento impulsivo

Fui direto da ideia para a solução, sem mapear etapas ou prazos. Resultado? Retrabalho e ansiedade. Hoje, priorizo ferramentas de gerenciamento e cronogramas flexíveis para manter o foco sem engessar a criatividade.

🔍 Validação superficial

Criei o SaaS para resolver meu problema, mas não validei se era uma dor real do mercado. Consequência? Perdi tempo competindo com soluções já consolidadas. Aprendi que entrevistas com potenciais usuários são tão importantes quanto o código.

💸 Precificação "no feeling"

Foquei em funcionalidades incríveis, mas não pensei em como monetizá-las de forma atraente. Lição? Agora estudo modelos de precificação antes de sair desenvolvendo novas features, usando cases de sucesso como referência.

✨ O saldo positivo?

Esses tropeços me deram algo valioso: clareza. Hoje entendo melhor que errar faz parte do processo — desde que cada erro vire um degrau para iterar.

E você? Já passou por situações assim em seus projetos?

O que são Data Warehouses e o sistema OLAP

Felipe Ribeiro — Sun, 01 Sep 2024 01:41:54 +0000

Data Warehouse (DW / ~Armazém de dados) é um sistema de armazenamento de dados projetado para suportar a análise de grande quantidades de dados. Ele funciona em conjunto a um sistema OLAP (Processamento Analítico Online), que é uma tecnologia usada para organizar grandes bancos de dados e analisá-los sob múltiplas perspectivas. Nele podemos centralizar dados de diversas fontes em um só repositório, sejam dados provenientes de uma planilha excel, um PDF, uma API Rest, um JSON, um banco de dados, basicamente do tipo de fonte que você quiser. Ele processa essas informações usando várias ferramentas para que os dados estejam prontos para finalidades analíticas.

A ideia de um DW é poder integrar dados que, inicialmente, estão distribuídos em sistemas isolados e centralizar essas informações para que se tenha uma visão unificada e consistente desses dados, facilitando a análise e geração de relatórios detalhados. É muito utilizado por empresas que buscam alavancar vendas de produtos, descobrir concorrências/tendências de mercado, identificar pontos de melhoria dentro do próprio negócio e por aí vai.

E como funciona um OLAP?

Basicamente, podemos dividir em uma arquitetura com 3 camadas: 1. coleta dos dados; 2. extração, transformação e carregamentos dos dados; 3. Apresentação dos dados. Ou seja, primeiro os dados são coletados de diversas fontes, depois passam pelo processo ETL (Extraction, Transforming & Loading), onde esses dados são calculados, tratados e armazenados em um "cubo OLAP", por fim estes dados são disponibilizados para serem feitas consultas e geração de gráficos, relatórios e o que mais for necessário para facilitar sua análise.

Fonte

O que seria esse "cubo OLAP"?

Digamos que eu quero analisar as vendas de um produto em determinadas regiões do Brasil e em um determinado período (exemplo: durante cada quadrimestre). Logo, teremos uma análise em múltiplas dimensões: produto, local e tempo, podendo executar queries por essas dimensões para encontrar e filtrar dados.

Fonte

Em teoria, um cubo OLAP pode conter um número infinito de camadas, e cubos menores podem existir dentro dessas camadas — por exemplo, cada camada de loja pode conter cubos organizando vendas por vendedor ou produto.

Operações OLAP

A partir do cubo OLAP, podemos realizar operações para analisar os dados:

Sumarização: resume os dados para atributos específicos. Por exemplo, em uma visualização de vendas de produtos de acordo com sua localização — Nova York, Califórnia, Londres e Tóquio — pode ser resumida para uma exibição dos dados de vendas com base nos países EUA, Reino Unido e Japão.

Detalhamento: é o oposto da operação de sumarização. Por exemplo, passar da visualização de dados de vendas por ano para uma visualização de vendas por mês.

Decomposição: cria uma exibição bidimensional do cubo OLAP. Ao decompor o cubo, podemos criar uma tabela que contém as vendas de produtos em determinadas cidades num mês específico.

Fragmentação: cria um "subcubo" menor a partir de um cubo OLAP.

Pivotagem: envolve a rotação do cubo OLAP ao longo de uma de suas dimensões para obter uma perspectiva diferente sobre o modelo de dados multidimensional. Por exemplo, um cubo OLAP tridimensional tem as seguintes dimensões nos respectivos eixos:

Eixo X: produto
Eixo Y: localização
Eixo Z: tempo

Com a pivotagem, o cubo OLAP pode ter a seguinte configuração:

Eixo X: localização
Eixo Y: tempo
Eixo Z: produto

Fontes

https://aws.amazon.com/pt/what-is/olap/
https://www.ibm.com/br-pt/topics/olap
https://www.sprinkledata.com/blogs/olap
https://computerisation.co.uk/blog/what-is-a-data-warehouse

How to create your own element filter in Dart Language

Felipe Ribeiro — Sun, 24 Mar 2024 00:36:49 +0000

Couple of weeks ago I was submitted for a task that demmands a way to standardize an element filter (from DIFFERENT kinds of elements). Therefore, instead of install a new dependency, I decided to create a simple algorithm that receives a generic element list and determines from which field this element should be filtered by.

Without further delay, let's analyse what I did:

List<T> filterElementsByField<T>(
  List<T> elements,
  String Function(T) fieldToCompare,
  String query,
) {
  final texts = elements
      .where(
        (e) => fieldToCompare.call(e).isNotEmpty,
      )
      .toList();


  // If nothing was typed or if is just empty, it'll return the full list content.
  if (query.isEmpty) return elements;

  return texts.where(
    (element) {

      // This is the text that is contained in the field which was parsed to the function
      final fieldText = fieldToCompare
          .call(element)
          .toLowerCase();

      final queryText = query.toLowerCase();

      if (query.contains(' ')) {
        return fieldText.contains(queryText);
      }

      // It'll try to retrieve all the content that matches with the text it contains at the parsed field. It doesn't matter if the word has blank spaces between of them.
      return fieldText.split(' ').any(
            (x) => x.startsWith(queryText),
          );
    },
  ).toList();
}

So, let's try to apply this on a little sample code. Initially, I'll create a sample class (Pokemon) and a sample list.

class Pokemon {
   final int number;
   final String name;

   const Pokemon(
    {required this.number, required this.name,}
   );
}

List<Pokemon> pokemonList = [
    Pokemon(
     number: 1,
     name: "Pikachu",
    ),
    Pokemon(
     number: 2,
     name: "Galarian Moltres",
    ),
    Pokemon(
     number: 3,
     name: "Moltres",
    ),
    Pokemon(
     number: 4,
     name: "Charizard",
    ),
    Pokemon(
     number: 5,
     name: "Charizard X",
    ),
    Pokemon(
     number: 6,
     name: "Charizard Y",
    ),
];

For the filtered list, we'll pass our initial list, then the class field we want to be filtered and, finally, the query we want to match with the elements from the list by attending the function algorithm.

List<Pokemon> filteredList = filterElementsByField(
   pokemonList,
   (pkmn) => pkmn.name,
   "mo"
);

To print all the results, we'll do it as follows:

print(filteredList.map((e) => e.name).toList());

This filtered list will retrieve for us the following result:

['Moltres', 'Galarian Moltres']

// They match with query "mo"

Let's try a new one sample:

List<Pokemon> filteredList = filterElementsByField(
   pokemonList,
   (pkmn) => pkmn.name,
   "ch"
);

So, this new filtered list will retrieve for us the following result:

['Charizard', 'Charizard X', 'Charizard Y']

It'd be different if we just tried to do this:

List<Pokemon> filteredList = filterElementsByField(
   pokemonList,
   (pkmn) => pkmn.name,
   "x"
);

The result:

['Charizard X']

Seeing all the results, it's clear that it doesn't matter if the query matches with the first, second or another word from the same object field (as we saw like "mo" matching with "Moltres" from "Galarian Moltres" and "Moltres") and doesn't matter the word case (if it's lower, upper, alterning, capitalized...).

I highly appreciate if you read this far. If this helped you with anything, so I'm happy.

Using Github Actions to publish your Flutter APP to Firebase App Distribution

Felipe Ribeiro — Thu, 05 Jan 2023 04:04:15 +0000

Hey, everyone! 👋🏻

I want to start talking about my decision for this year, which is to start to write more tech articles to help people, increase my knowledges (cuz I need to study either ^^) and also improve my english writting skills. So, this will be the beggining of this journey and I hope you all could enjoy it :)

Summary

1. Why am I writting this article?
2. Firebase App Distribution
3. The manually way
4. The GitHub workflows way (main topic)
5. Final workflow yaml file result
6. Testing it!

1. Why am I writting this article?

Few months ago I started to develop a Flutter app side-project, which is not available yet, but I intend to publish it on app stores when I feel that it is ready for MVP release.
On this project, I'm using Firebase database to store the app data, authentication, files storaging and some other features. BUT we have one that is the main topic of this article: Firebase App Distribution.

2. Firebase App Distribution

Firebase has it own functionality whose job is literally distribute your app to an user (or a group of users).
When we're talking about Flutter apps, we're also talking about downloading this apps at our mobile devices (in case mobile apps, I'm not going to talk about Flutter Web at this article). Maybe you or your team wanna test it or show it for the team manager or team leader, whatever.
This is the "nice" but rough way to do it. Uploading your app file to Firebase App Distribution.

3. The manually way

First of all, of course, you'll need to generate a build of your Flutter app.

flutter build apk

flutter build aab

When you get into your Firebase project console, you have in the left side a shortcuts list, and you will probably see an option named 'App Distribution'. Click on it.

You'll see a big dashed blue box asking you to upload your app APK or AAB file.

After that, it will appear a card with a text field to put the tester e-mail or the name of a tester group (which you can create by clicking at third top navigation bar).

Then, you'll just need to press 'Next' and 'Send to testers'.

Well done! Now, your app is on the devices of all the testers you sent it.
But... Doing this EVERY time sounds like a waste of time. Isn't? Maybe. Maybe not.

But we can do it better. Follow me to the next topic!

4. The GitHub Actions way

Now, in the main topic of this article, I'll show you how automate this process of uploading your app to Firebase App Distribution and send it to testers.
In the end of this topic, you'll know how to do this process just by pushing or opening a pull request on a specific Git branch of your project.

In your project, create a path named .github/workflows, just like that:

Inside of it, create a .yaml file with the name of your workflow. I named mine as 'firebase_workflow.yaml'.

Let's beggin by giving a name to the workflow.

name: Firebase APP Workflow

Then, we will need to determine when this workflow will be triggered. Pushing to a branch? Creating a pull request to a branch?

Exemple of how it should looks like the yaml file until here:

name: Firebase APP workflow

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

We need to put jobs on our workflow file. Above we have an exemple of setting that is very important for the whole workflow operation.

I created a key named firebase_distribution and gave it the name "Firebase App Distribution". Then, I setted the virtual machine which would it runs on. You can read more about this here.

jobs:
  firebase_distribution:
    name: Firebase App Distribution
    runs-on: ubuntu-latest ## virtual machine
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: "12.x"

Then, we have two important initial steps to define. The first one is an official GitHub Action used to check-out a repository so a workflow can access it. The second one it's pretty more complex but, briefly, downloads and set up a requested version of Java.

Continuing the steps:

Give a name to this step, now we gonna make our workflow decode the most important file which makes Firebase work on our project: the google-services.json.

      - name: Decode google-services.json
        env: 
            GOOGLE_SERVICES_JSON: ${{ secrets.GOOGLE_SERVICES_JSON }}
        run: echo "$GOOGLE_SERVICES_JSON" > android/app/google-services.json

Inside env key we put another key called GOOGLE_SERVICES_JSON. But, for now, I'll need to explain what is this "secrets.GOOGLE_SERVICES_JSON" here.

For this, open your Github project repository and get into settings page.

On the left side options, look for the security session and click on "Secrets" > "Actions".

We need to create 3 secret keys. Each one for:

Firebase App ID
Firebase Token
Google Services Json

Name them by your preference.

The Firebase App ID can be found by following this short click steps on your Firebase project console:

We just need to copy and paste it on our secret key.

Firebase token can be obtained by running a few commands on your machine.

At first, we'll need to install npm and run the following command:

npm install -g firebase-tools

Then, run this second command:

firebase login:ci

After that, the token will be shown by your CLI.

For the last key, we just need to open the google-services.json on our project in path "android/app/google-services.json", copy the whole content inside and paste it on the respective secret key in your Github project repository.

Now, we can get back into our workflow and understand what will happen from now:

      - name: Decode google-services.json
        env: 
            GOOGLE_SERVICES_JSON: ${{ secrets.GOOGLE_SERVICES_JSON }}
        run: echo "$GOOGLE_SERVICES_JSON" > android/app/google-services.json

Basically, using secrets.KEY_NAME allows us to access our project secret keys.

We're accessing the secret key named GOOGLE_SERVICES_JSON and running a command on it.

Now, we can continue writting our workflow:

      - uses: subosito/flutter-action@v1
        with:
          channel: "stable"

subosito/flutter-actions@v1 is just a Flutter enviroment running on our workflow. So, now we have 'access' to Flutter enviroment, we can choose a Flutter channel to use. Read about this action here.

From now, we will run Flutter commands inside our workflow:

      - run: flutter pub get
      - run: flutter build apk
      - uses: actions/upload-artifact@v1
        with:
          name: release-apk
          path: build/app/outputs/apk/release/app-release.apk

Notice that already known commands like flutter pub get and flutter build apk now it shows up on our workflow. But, to upload the generated app file (artifact), we'll need to use the action upload-artifact@v1 and parse the build path which it will be storing the app file.

To finally finish this (I swear), we complete our workflow with a Firebase action that will have the responsability to upload the app to Firebase App Distribution. Read about wzieba/Firebase-Distribution-Github-Action. This action uploads your artifacts with .apk, .aab and .ipa (this last one for iOS) extensions to Firebase App Distribution.

      - name: upload artifact to Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
            appId: ${{secrets.FIREBASE_APP_ID}}
            token: ${{secrets.FIREBASE_TOKEN}}
            groups: testers
            file: build/app/outputs/flutter-apk/app.apk

We'll need to parse the remeaning secret keys, the tester group name (which you created at your Firebase project console) and the file path. In Flutter, by default, it is stored at build/app/outputs/apk/release/app-release.apk.

That's it! Our workflow process file is done!

5. Final workflow yaml file result

This is how your workflow file should looks like:

name: Firebase APP workflow

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

jobs:
  firebase_app:
    name: Run Firebase Workflow
    runs-on: ubuntu-latest ## virtual machine
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: "12.x"

      - name: Decode google-services.json
        env: 
            GOOGLE_SERVICES_JSON: ${{ secrets.GOOGLE_SERVICES_JSON }}
        run: echo "$GOOGLE_SERVICES_JSON" > android/app/google-services.json

      - uses: subosito/flutter-action@v1
        with:
          channel: "stable"
      - run: flutter pub get
      - run: flutter build apk
      - uses: actions/upload-artifact@v1
        with:
          name: release-apk
          path: build/app/outputs/apk/release/app-release.apk
      - name: Upload to Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
            appId: ${{secrets.FIREBASE_APP_ID}}
            token: ${{secrets.FIREBASE_TOKEN}}
            groups: testers
            file: build/app/outputs/flutter-apk/app.apk

6. Testing it!

Now, we just need to push our project to github's project branch which we had chosen or merge pull request (it depends on what did you choose to do) to trigger the workflow.

After that, you can see the process working by clicking at "Actions" tab in your project repository.

This is how it should your workflow alert looks like:

That's it!

Thanks A LOT for reading until here! I hope this article may help you create github actions workflows to upload your app to Firebase APP Distribution.

Consumindo arquivos JSON no Dart

Felipe Ribeiro — Tue, 27 Jul 2021 15:10:11 +0000

Neste artigo pretendo mostrar como consumir arquivos JSON no Dart. Não é bem como consumir uma API, algo que dependa de requisições web. Se trata de fato em consumir arquivos JSON da máquina local e atribuindo-os a objetos Dart.

Estruturando o arquivo JSON

Vamos criar um arquivo JSON em nosso projeto e, em seguida, estruturá-lo da seguinte forma:

 [
 {
 "id": 1,
 "nome": "Bulbassaur",
 "regiao": "Kanto",
 "tipos": [
  "Grass",
  "Poison"
]
},
{
 "id": 2,
 "nome": "Ivyssaur",
 "regiao": "Kanto",
 "tipos": [
  "Grass",
  "Poison"
]
},
{
 "id": 4,
 "nome": "Charmander",
 "regiao": "Kanto",
 "tipos": [
  "Fire"
]
}
]

Antes de mais nada, vamos pegar esse arquivo JSON que escrevemos e chamá-lo de poke_db.json, por exemplo.

Definindo a classe

class Pokemon {
 int id;
 String? nome;
 String? regiao;
 List<String>? tipos;

 Pokemon({this.id, required this.nome, this.regiao, this.tipos});
}

Criando o método de deserialização do JSON

Antes de partirmos para a criação do método, vamos entender o que é deserializar um objeto JSON?
O que acontece é que o que está presente em nosso "poke_db.json" são dados prontos e fresquinhos para serem consumidos, e nós precisamos de alguma forma utilizar esses dados. Para isso, nós pegamos esses dados "fresquinhos" e reconstruímos eles na forma de um model, um modelo. No caso, atribuímos esses dados aos atributos de uma classe.

No mesmo arquivo da classe criada, criaremos o método fromJson().
O que acontece nesse método?

O fromJson serve para atribuir valores vindos de um objeto JSON para sua classe. Um objeto JSON é reconhecido como um Map devido ao seu comportamento e estruturação de chave-valor. Então pegamos os atributos da classe e fazemos com que recebam os valores do JSON referentes às chaves do Map correspondentes a estes.
Basicamente, esta função é uma espécie de MAPEAMENTO da classe para um objeto JSON.

Pokemon.fromJson(Map<String, dynamic> json) {
    id = json['id'];
    nome = json['nome'];
    regiao = json['regiao'];
    tipos = json['tipos'].cast<String>[]();
  }

Por qual motivo a tipagem do Map utilizado como parâmetro é <String, dynamic>?
Bom, já sabemos que o tipo informado no lado esquerdo é a tipagem das chaves. Já no direito, é a tipagem dos valores.
No caso, utilizamos o dynamic para os valores justamente pelo motivo de que podemos ter números (int, double), textos (String), listas (List), Maps...

Exemplo de um JSON genérico

{
   "chave": "valor"
}

Vamos consumir o objeto JSON

Vamos criar um arquivo chamado poke_repository.dart.

Neste arquivo iremos criar algumas funções que ficarão responsáveis pelo processo de consumo do nosso objeto JSON.

Primeiramente iremos realizar alguns imports

import 'dart:async';
import 'package:flutter/services.dart' show rootBundle;
import 'dart:convert';
import 'package:pokemon_json/poke_model.dart'; // import da classe

Criaremos uma função para carregar a String contendo todo o arquivo poke_db.json.

É muito importante lembrar de colocarmos o caminho do arquivo JSON nos assets do nosso pubspec.yaml!

assets:
    - lib/poke_db.json

Future<String> _carregarPokemonJSON() async {
  return await rootBundle.loadString('lib/poke_db.json');
  // Aqui passamos o [caminho] do arquivo JSON
}

Tendo a String do nosso arquivo JSON carregada, vamos criar uma função que irá nos retornar a lista contendo os objetos Dart de Pokémon.

// Como temos uma lista em nosso objeto JSON, podemos então dizer para nossa função que pode aguardar uma List<Pokemon>
Future<List<Pokemon>> carregarPokemon() async {
  // Atribuímos a String de todo o JSON para a variável pokeJsonString
  String pokeJsonString = await _carregarPokemonJSON();

  // Agora utilizamos o método json.decode() para "decodificarmos" essa String
  final respostaJson = json.decode(pokeJsonString);

  // criando lista genérica para armazenar os Pokémon do objeto JSON
  final lista = <Pokemon>[];

  // Atribuindo cada objeto da lista JSON para a classe Dart Pokémon utilizando o método Pokemon.fromJson()
  for (var pokemon in respostaJson) {
    final poke = Pokemon.fromJson(pokemon);
    lista.add(poke);
}

  // e finalmente teremos a lista com nossos Pokémon
  return lista;
}

Pronto, com esta última função sendo chamada em alguma parte de seu código você já pode ter acesso aos dados do poke_db.json.

Exemplo:

Future<void> main() async {

 final listaPokemon = await carregarPokemon();

 print(listaPokemon[0].nome); // Bulbassaur


 for (Pokemon pkmn in listaPokemon) {
   print(pkmn.nome);
   /*
   Bulbassaur
   Ivyssaur
   Charmander
  */
}
}

Artigo que possa vir a te ajudar em caso de dúvidas mais específicas em relação ao Dart
Dart4Noobs