
Junior Jets
Marine services management ecosystem: work order flow, digital approval via unique link, and automated WhatsApp notifications.
Full-stack developer. I build complete systems — from the database to deployment — and the automations that keep everything running on its own.
Three systems in production, each solving a different problem. One of them cut 65% of the time the client’s team spent opening and approving work orders.
A full landing page redesign for a programming school, built for a contest. Result still under review.
Institutional sites and conversion pages. The goal here was never a pretty portfolio — it was the client being found and getting contacted.

I spent nine years running construction and real-estate projects. I learned to align people who disagree, to deliver bad news early, and to defend a deadline without running over the person next to me — none of which changes when the project becomes code. What changed was the setting: now it's a repository. From my first lines of code to an ERP running in production took under two years.
Before writing the first line of Junior Jets, I went to watch the workshop run on paper and talked to the people filling out the work orders. Two decisions came out of that, which no requirement asked for: approval goes by unique link, because a boat owner won't create an account or remember a password; and the alert goes by WhatsApp, because in that market email doesn't get read. Then I cut scope to hit the deadline — the first release attacked only what was blocking the operation. Today a quote becomes a signed work order in under three seconds, at the same workshop that ran everything on paper.
I'm studying Software Engineering, and I want a team where I contribute to the product from the first sprint. I already work with branches, semantic commits, pull requests and CI on GitHub Actions. What I'm missing is the other side of that: code review from more experienced people, architecture discussion, someone pointing out what I can't see yet. Taking pressure without freezing is the part I already bring with me.
Not a wall of logos. This is the architecture I actually build, layer by layer, and the reason behind each choice.
Server Components by default. JavaScript only where there's real interaction — everything else arrives as ready HTML.
Typed contract end to end, with Zod validating at the edge and Next Route Handlers in front. The same schema runs on client and server, so they can’t drift apart.
Relational when integrity is at stake, document when the schema is still moving. The choice comes from the problem, not from habit.
This is where most developers stop and I keep going. Webhooks, queues and the WhatsApp API so the system keeps working after I leave.
Reproducible deploys and preview per branch. If it doesn't ship with one command, it isn't ready.
Tell me the problem you need solved. I reply within 24 hours with a technical path and a timeline estimate — not a generic quote.