Software when it makes sense.Results, always.

I help companies identify operational bottlenecks and, when technology is the right intervention, design, build and put bespoke internal solutions into production.

Talk to Jean Diego

Software engineering with direct access to the person who understands the problem and builds the solution.

Where software can unlock an operation

Manual processes, spreadsheets that no longer scale, disconnected systems and routines that consume the team's time.

Spreadsheets that no longer scale

When they require constant checks, multiple versions, duplicated work or knowledge held by one person, an internal solution can make the process simpler, safer and scalable.

Manual work between systems

Copying data, checking information and consolidating results often reveals a gap between tools. Connecting them may be better than replacing them.

Repetitive routines

A process should not be automated simply because it can be. It must first be understood, stable enough and worth the investment.

A problem already identified

When the diagnosis already exists, I can work directly on technical design, development, deployment and stabilization.

Not every problem needs a new system.

Before building anything, we need to understand what is actually happening.

Sometimes the answer is an internal tool.

Sometimes it is an integration between systems already in place.

Sometimes a mature routine can be automated.

And sometimes building software is simply not justified.

My work starts with the problem, not the technology.

First, we understand the problem.

A pain point only becomes a project after it becomes evidence.

Where does work wait? What is manual? Where do errors or rework happen? How many people are involved? How often? What limits the operation?

  1. Problem
  2. Evidence
  3. Priority
  4. Intervention
  5. Result

A decision path

I have a process that is creating too much work.

Answer a few questions. The result may be to build software, but it may also be to leave things alone for now.

A recommendation may lead to

  • keeping the process as it is
  • improving the process before automating it
  • using an existing tool better
  • integrating systems
  • building an internal solution
  • automating a routine
  • applying AI when there is a clear use case and the conditions to use it responsibly

When building is justified

From problem to production.

When development is the right decision, I stay personally responsible from end to end.

  1. Understanding

    Problem, context, impact and success criteria.

  2. Definition

    Scope, proposed solution, priorities, responsibilities and project boundaries.

  3. Development

    Build with ongoing review and validation.

  4. Deployment

    The solution stops being a project and begins operating in the real business.

  5. Stabilization

    Corrections and support under the conditions agreed for the project.

  6. Acceptance

    The contracted outcome is delivered and validated. Future evolution becomes new work.

Every project needs a beginning, a middle and an end.

The solution belongs to your company.

I do not believe in creating artificial dependency to justify recurring contracts.

The code, data and assets required to continue the solution should remain under the company's control or be transferable to it.

I can continue supporting maintenance and evolution when needed, but the operation should not depend permanently on my presence.

My work ends well when the solution keeps working without me.

Direct access

Senior engineering without the structure of a software house.

Jean Diego, Software Engineer

Based in Itajaí, Santa Catarina (Brazil), working with companies across the country.

Throughout my career, I have helped build and evolve systems for companies including Dasa, Plaenge, Avenue and Omni Financeira.

Today I also take on independent projects directly with companies whose operational problems can justify software engineering investment.

You speak directly with me through discovery, technical decisions, development and deployment.

No unnecessary layers between the problem and the person who actually builds the solution.

You may not need software.

But if a process consumes too much time, creates rework, depends on manual controls or no longer keeps up with the operation, it may be worth understanding it better.

Talk to Jean Diego