I'm a software engineer and engineering leader who still likes the hands-on work. Professionally that has meant automotive software, from dealerships to independent repair shops, where the system has to work for the people answering phones, writing repair orders, managing jobs, and keeping a business moving. I've worked across APIs, integrations, platform architecture, delivery, and team leadership.
Outside that, I build the things I want to use. A better way to manage Cursor windows, a glanceable meter for AI-tool usage, small native apps, and tools that remove an everyday annoyance. Those projects are where curiosity turns into software.
Understand the real problem. Keep complexity on a short leash. Make something that earns its place.
After years leading teams and operations, I chose a principal role to get closer to the building again. It puts me where the architecture and the code are decided, which is where I can drive the most change and help the whole team succeed. At Shift that means software for independent repair shops, where advisors, technicians, and owners need systems that reflect how work actually happens. I connect product decisions to architecture and implementation, and make sure the engineering holds up in production.
Previously · Dealerships
Volie
Senior Software Engineer, then Director of Engineering
Volie took me to the dealership side of automotive, where new cars are sold and serviced. I built software and integrations for dealership communications and, later, led engineering. Dealerships run on different systems, volumes, and pressures than an independent shop, and seeing both sides shaped how I build. Reliable external integrations, clear ownership, good delivery, and systems that support the people doing the work.
Previously · Aftermarket repair
Bolt On Technology
Developer, then Senior Vice President of Technology Operations
This is where I learned the independent aftermarket. I started as a developer on shop-management software for repair shops, building web applications and keeping the incoming data pipeline healthy across clients. The role grew into operations, support, customer success, and leading the development team, and then into technology operations after the company merged with Bolt On Technology. The work was bringing the journey together from pre-sales to post-sales, and building the teams and processes behind it.
Product and architecture
Start from the workflow, then decide what the system is allowed to become.
APIs and integrations
External systems fail in specific ways. The design has to say what happens then.
Engineering leadership and delivery
Clear ownership and a path to production matter as much as the design.
02
How I approach the work
Start with the person
I start with the person doing the job. In a repair shop that might be an advisor trying to keep a promise to a customer while the parts, the technician, and the schedule disagree. In a developer tool it might be me, annoyed that the answer I need is split across three dashboards. If I cannot say who is stuck and what would actually help, I do not have a project yet.
Small and coherent
The first version should be coherent and small. AI Meter did not need a cloud account to show a menu bar. CursorStack did not need to become an editor. Daily On Plan did not need a social layer. Leaving room for what real use teaches you is a design choice. Building the platform for version ten, before version one has earned it, is how software gets heavy.
Details are the product
The details I will not treat as polish are the ones people feel when something goes wrong. Reliability, privacy, recovery, accessibility, performance, and how an update actually ships. AI Meter keeps tokens in the Keychain and off the Watch. CursorStack says what the Accessibility permission is for, and what it will never do. Those are product decisions.
AI, deliberately
I use AI the same way. It is good at compressing drudgery, widening a search, and helping me move through code. It does not get the judgment, the verification, or the responsibility. If I ship it, I own it.
Leadership
Leadership, when I am doing it, is the same instinct at a different scale. Make the ownership obvious, keep the delivery path honest, and do not separate the architecture from the people who have to run it on a busy day.
03
Seven principles
Solve the real problem.
A good implementation of the wrong idea is still the wrong idea. Understand the person doing the work and what would actually help.
Start small, and design to last.
Ship a coherent first version and leave room for what real usage teaches you. Do not prematurely build the platform for version ten.
Care about the details that matter.
Performance, reliability, privacy, recovery, accessibility, and deployment are part of the product, not polish added after the demo.
Own the whole thing.
Product understanding, architecture, implementation, operations, and the user experience are connected. Taking responsibility across those boundaries produces stronger software.
Prefer clarity over cleverness.
If the straightforward version works, that is the version. Cleverness has to earn its place the same way complexity does.
Use AI deliberately.
AI can compress drudgery, speed research, and support coding. Judgment, verification, security, and responsibility still belong to engineers.
Keep learning by making.
Small experiments and side projects sharpen the thinking that goes back into larger systems.
I still get excited about a good problem.
If you're building something thoughtful, working through a tricky engineering challenge, or trying one of my tools, I'd enjoy hearing about it.