About
Engineer mindset.
Technology driven.
Business focused.
I came to software from engineering, which means I tend to ask what a system has to withstand before I ask what it should be built with.
I build technology for businesses — websites, applications, automation and AI-driven tools. What I actually do most of the time is quieter than that: I work out where a process is losing time or accuracy, and then decide whether software is the right answer.
My background is civil engineering. I completed 140+ university credits before technology pulled me in a different direction, and that training still shapes everything I build. Engineering teaches you to establish the constraints first, design for the real load rather than the ideal one, and accept that a structure is only as good as its weakest assumption. Those habits transfer to software almost directly.
From there I built the technical foundation deliberately rather than accidentally — Harvard's CS50 for computer science fundamentals, freeCodeCamp for shipping practice, CompTIA A+ and Google IT Support for the hardware, networking and operations layer, then AI and agent architecture as that became the most interesting place to build.
The result is a combination I find genuinely useful: enough engineering to think in systems, enough software to build them, and enough operational and IT context to know what an organisation will actually let you deploy.
Background
From structures to systems.
Not a straight line, and the detour is the point — the engineering years are why I approach software the way I do.
Foundation
Civil Engineering studies
Dominican Republic
140+ university credits in an engineering discipline. It taught a way of thinking before it taught any subject: understand the forces, respect the constraints, and never design past what you have verified.
Transition
From structures to systems
The same analysis I had been applying to physical structures turned out to describe business workflows just as well — bottlenecks, load, failure points. Software was simply the faster material to build in.
Fundamentals
Computer science and IT
Harvard's CS50 for the fundamentals, freeCodeCamp for shipping practice, and CompTIA A+ with Google IT Support for the hardware, networking and operations layer underneath it all.
Building
Software for real workflows
Started building for actual problems rather than exercises: Clean Taggy for a manufacturing quality team, Transcriptor for confidential recordings. Both were designed around constraints a tutorial never mentions.
Now
AI, agents and automation
Working where applied AI meets real operational data — agent skills, structured extraction from technical documents, and locally-run models for work that cannot leave the building. Running it on infrastructure I built and administer myself.
Principles
What I hold to.
Four positions I have arrived at by building things that worked, and a few that did not.
01
Constraints are the brief
No installs, no server, corporate policy, a user who will not read instructions — these are not obstacles to the design. They are the design.
02
The workflow comes before the stack
Choosing a framework before understanding the process is how you end up with software nobody uses.
03
Simple survives
A tool that is one file, or one command, keeps working long after the clever architecture has rotted.
04
Honest results only
A qualitative outcome you can defend is worth more than a percentage you invented.
Capabilities
What I work with.
Want the short version?
Engineering thinking, software execution, and a bias toward the simplest thing that removes the problem. If that is useful to you, let's talk.