Most developers optimize for other developers. I optimize for results.

I'm Otavio Petry

A software engineer who builds products that ship, not architecture that impresses.

The Shift

At some point, I had enough.

If the "correct" way of doing software meant months of architecture astronautics before shipping anything real, I didn't want to be correct anymore.

I watched teams spend weeks debating folder structures while competitors launched. I saw codebases so over-engineered that adding a button required a planning meeting. I worked with people who treated every feature like it deserved a conference talk.

So I decided to go a different way: understand the fundamentals deeply, ignore the weekly tool churn, stay close to the product, and build to validate, not to impress other developers.

That decision changed everything.

Philosophy: Healthy Engineering

I call my approach healthy engineering. It's not about cutting corners. It's about knowing which corners matter.

Context-aware decisions.

Every choice depends on the moment: the company stage, the product maturity, the market pressure, the team you have. What's right for a Series B startup is wrong for a bootstrapped MVP. I read the room before I write the code.

Quality without cathedral-building.

Good code is maintainable, testable, and clear. But "good enough to ship and iterate" beats "perfect in six months" every time.

Stay close to the Product Owner.

I don't want to see just the ticket. I want to see the roadmap. When you understand where the product is going, you make better decisions about what to build now.

Try to understand the user.

Code serves people. The best technical solution that users hate is the worst solution.

Zero tolerance for bad actors.

Politics, blame-shifting, dishonesty. These kill teams faster than any technical debt. I don't play those games and I don't work with people who do.

Embrace the paradigm shift.

AI isn't a fad to dismiss or a threat to fear. It's a new way of building that's worth mastering. I'm all in on learning what it changes and what it doesn't.

The Edge: I Build and I Frame

Here's something that doesn't fit the usual developer bio: I studied Social Communication (Advertising and Propaganda) at UFRGS before I wrote my first line of professional code.

Most people see that as a detour. I see it as an edge.

I learned how to frame ideas, structure narratives, and communicate with clarity before I learned how to structure databases. That background didn't disappear when I became an engineer. It's layered underneath everything I do.

This means I can build the product AND explain why it matters. I can write the feature AND write the launch copy. I can debug the system AND present the solution to stakeholders who've never seen a terminal.

I build and I frame. That combination is rare.

What I've Done

The proof is in the shipped work:

Solo-shipped a complete dating platform in 9 months.

From zero to live product: React Native mobile apps, NestJS backend, AWS infrastructure. No team. No excuses. Just execution.

Led front-end teams serving 100K+ monthly active users for 4 years.

Real scale, real users, real consequences when things break. I've been the person on-call when the dashboard goes red.

Full-stack across the modern stack.

React Native, Angular, NestJS, AWS. I pick the right tool for the job, not the one that looks best on my resume.

Current Focus

Right now, I'm building at the intersection of product and code.

I work with founders and teams who need someone who can own the technical delivery without losing sight of the business goal. Someone who asks "what are we actually trying to achieve?" before asking "which framework should we use?"

I'm also deep in the AI tooling space, not chasing hype, but learning what genuinely changes how we build software and what's just noise.

If you're building something that matters and you need an engineer who thinks like a product person, let's talk.

Let's Talk