available for roles and freelance work

I build web systems that
leave your local environment:
API, interface, database and deploy.

I'm Jonas Filho, a FullStack developer. My work lives in projects that run in production, with a database, authentication and automated publishing, instead of course exercises. I chose Node, React and PostgreSQL because that is what shows up when a feature has to work outside my computer.

See the projectsGet in touch

Projects

Three systems that solved a real problem

I describe each one by the problem it solves and by the decision I had to make. The technology list sits at the end of the card because it is a consequence, not an argument.

01

Central de Operações

internal system · live

The problem

I needed a single place to see what was happening across my projects and my server: what had been published, what had failed, what was in progress. All of it scattered across terminal, logs and agent memory.

What was built

A portal on nginx with TLS that receives automated publications, indexes every activity, keeps a history of what was done and records reports. Publishing became one command with validation, commit and a check that the version that went up is the one on disk.

Technical decisions
  • Authentication across the whole public area, verified on the server
  • Publishing in a worktree: the edit is already live when the deploy finishes
  • A public demo kept separate from the real instance and generated by a one-way script
  • nginx
  • TLS
  • Bash
  • Git
  • AI agent
Public demo
02

DevBurguer

fullstack e-commerce · live

The problem

A course project I took past the assignment: a complete store, with user signup, catalogue, cart and payment, not only the visual part the exercise asks for.

What was built

Two separate bases. The interface in React with Material UI, form validation, category carousel and Stripe checkout. The API in Node and Express, with two database layers (MongoDB through Mongoose and Postgres through Sequelize), JWT authentication, image upload to Cloudinary and error handling.

Technical decisions
  • API separated from the interface, with a contract defined between the two
  • JWT token with authentication and admin-role middlewares
  • Image upload solved after three attempts. The record of what went wrong is in the commit history
  • React
  • Node.js
  • Express
  • MongoDB
  • PostgreSQL
  • JWT
  • Stripe
RunningAPIInterface
03

Inventory Genius

inventory control · typescript

The problem

Material control in a small business usually means a spreadsheet: no traceability of what comes in and out, no change history and no warning when stock drifts.

What was built

A TypeScript system with PostgreSQL to register products, their materials and the link between the two. The interface uses shadcn/ui on React, with product and material forms and control over how much of each material is tied to each product.

Technical decisions
  • Relational modelling of product, material and the link between them
  • TypeScript instead of JavaScript precisely because the domain has many fields
  • Form components kept apart from business rules
  • TypeScript
  • PostgreSQL
  • React
  • shadcn/ui
See the code

It started as a project generated with Lovable and I rebuilt the data layer. It is where I have used TypeScript the most so far.

More code on my GitHubThe course exercises I started with, and what I am building now.

AI and automation

Where the model is part of the process, not a demo

Two systems where AI does real work: an agent that runs scheduled routines on the server and a pipeline that generates, checks and publishes content. In both, usage figures are measured, not estimated.

01

Automation agent

agent with tools · 25 routines live

Much of what I did by hand always had the same shape: read a source, decide by some criterion, execute and record what happened. A plain script could not handle it, because the decision changes case by case and the source does not always offer an API.

An agent that runs on its own VPS, with file, terminal, browser and external API tools, memory across sessions and procedures loaded according to the task. Today there are 25 scheduled routines, covering publication at four times of day, monitoring an external source, a weekly report and backups. Every run goes through the internal portal, which has recorded 217 publications.

  • Procedure in a file instead of one giant prompt: each task loads only the instruction that matters, which cuts error and cost per run
  • A tool with write power asks for permission: publishing, spending and deleting still require explicit approval
  • A scheduled routine validates before publishing and checks that the version live is the one on disk
  • Python
  • Node.js
  • LLM APIs
  • Tool calling
  • nginx
  • systemd
  • PostgreSQL
  • Bash
Portal demo
02

Content pipeline

image, voice and video · measured cost

A social post a day would not fit if every step were manual: write, draw, review, narrate and assemble the video. The bottleneck was production time, not a lack of ideas.

A pipeline that turns a topic into a published piece. The script comes from the model, the image comes from a diffusion API, the piece goes through automated verification, narration is synthesised into voice and the vertical video is assembled from the command line. When text has to sit in an exact position, the artwork is generated in HTML and captured by a headless browser, because image models get typography wrong.

  • Verification before publishing: the script measures margin, crop and stroke thickness per pixel, because eyeballing it and asking a vision model both fail at this kind of check
  • Cost per piece measured, not estimated: about US$ 0.03 per generated image, tracked on every batch
  • Each tool doing what it does best: model for image, HTML and CSS for text in a fixed position
  • Python
  • Image API
  • LLM
  • TTS
  • ffmpeg
  • Headless Chromium
  • cron
See it on Instagram

Technical writing

What broke while I was building, written in detail

I publish on dev.to, in English, the problem that showed up and how I found the cause. It is the same kind of check I do before publishing anything: measure, do not assume.

All articles on dev.toI write about what I am building and about what breaks along the way.

How I work

Three decisions that repeat in every project

  1. 01

    I understand the problem before choosing the tool

    Every project starts by knowing what has to happen, not by deciding whether I use React or CSS. The stack choice follows from the constraint: data volume, who will maintain it, what is already running.

  2. 02

    I build the part that breaks first

    Authentication, database, upload and deploy are where software fails. I do those two days of work before polishing screens, because finding a permission problem after the interface is done costs ten times more.

  3. 03

    Deploy is part of the work, not the finish line

    If it is not live, it is not done. I version it, publish it and check that the version on the server is the one on my disk. That is how Central de Operações stopped being a local project.

Jonas Filho

About

Learning in public, in a way I can keep up

I started with the course exercises and they are still on GitHub: the history of how someone evolves says more than a front-end list. What moved me forward was wanting to see things working outside my laptop, and that is why Central de Operações exists.

Where
Minas Gerais, Brazil
Education
Faculdade Pitágoras Anhanguera Unopar
Degree
Computer Science
Studying
DevClub
Certifications
Credly
Stack
Node · React · TypeScript

Contact

If your role or project needs someone who delivers what is live, let's talk.

I prefer WhatsApp, but any channel works. If you have a technical problem in mind, write what it is in one sentence. To me that is worth more than a resume.