About
Hi, I'm Michael Kimsal.
I've been building for the web since before Google existed. I'm not nostalgic about it — I just have perspective that only comes from time.
The longer version
I started writing web software in the mid-1990s, back when "web development" meant CGI scripts and arguing about whether tables were a reasonable layout tool. A lot has changed since then. The fundamentals haven't.
Over the years I've worked across industries — finance, healthcare, media, e-commerce, and SaaS — as an architect, engineering lead, and technical consultant. I've designed systems for teams of two and teams of two hundred. I've inherited architectures that made me want to cry and shipped software I'm genuinely proud of.
PHP has been the thread through most of it. I became a Zend Certified Engineer and later an instructor for Zend's training programs, which gave me a different relationship to the language — less about what I could do with it and more about how to explain it, how to teach it, and how to help others get good at it. That shift shaped how I consult.
I've also spent significant time with Java and the Grails framework, which gave me a useful perspective that's easy to miss when you only know one ecosystem. Good engineering principles cross languages — and so do the bad habits.
JavaScript has been part of the work the entire time too — from the early days of jQuery making the DOM bearable, through Backbone and Angular, into the Vue and React era. I've seen every wave of "this framework will replace everything" come and go. I know when to reach for a modern frontend framework and when vanilla JS or something lightweight like Alpine is the right call.
These days I focus on consulting, training, and the occasional prototyping engagement. I care about craft. I care about teams. I care about shipping software that actually works for the people who use it.
How I approach the work
Honest over comfortable
I'll tell you what I actually think, including when I think the problem is harder than you've admitted. That's what you're paying for.
Context before prescription
I don't arrive with a favorite solution looking for a problem. I try to understand your situation first — your team, your constraints, your history.
Practical over perfect
The best solution is one your team can implement, maintain, and understand. Elegant architecture that nobody can operate isn't elegant.
Teaching over dependency
I want your team to be able to do this without me. Engagements that create long-term dependence are a failure, not a success.
Want to work together?
I'm available for consulting, training, and prototyping engagements. Let's have a conversation.