Quintin Orsmond
Building software for over 25 years, and still not bored of it.
Hi, I’m Quintin. I’m mostly self-taught, and most of what I know I learnt by building things and living with the consequences.
I’ve built maps for farmers, desktop apps that kept working when the network didn’t, web and mobile apps, the APIs behind them, and an online framing shop I wrote from scratch. Along the way I’ve seen plenty of frameworks and this-changes-everything moments come and go.
What strikes me is how little the hard part has moved: working out what people actually need, and keeping the result understandable for whoever has to change it next. Quite often that’s me, a few months later, wondering what I was thinking.
Coding agents have made the typing fast and the hard part easy to skip. It’s never been quicker to build the wrong thing, so that’s where most of my attention goes now.
What I’m working on now
It mostly happens in the open at Bits to Live By, my engineering publication and lab. This site is about me; Bits to Live By is where the work gets done properly, with the reasoning, the evidence, and the experiments that didn’t work.
-
Essay · 23 October 2026
Another X-Driven Development?
TDD, BDD, DDD, Spec-Driven, and now Artifacts-Driven. Why we keep inventing these, what coding agents changed, and the question I think we keep skipping: did we agree on the right thing in the first place?
-
Method · AI-assisted engineering
FeatureKit
Skills for the coding agent you already use, so it plans before it codes and proves the work before calling it done. It’s also a long-running experiment in how much process an agent actually needs, and it only changes when the evidence says it should.
-
Method · CSS and design systems
Baseline, Tokens, Layouts, Behaviors
A way of structuring CSS in four layers, so a product keeps up with its design system and a design change lands in one place. Bits to Live By is built with it, which keeps me honest.
Where the years went
I could give you a wall of logos (this site used to), but it wouldn’t tell you much. These are the problems that kept me busy instead.
Maps for people who work the land
Years of GIS for agriculture at Farm-IT: a desktop system silo managers ran their daily operations on, and a web app for agronomists weighing input budgets against what was actually spent. This was before spatial data was easy, so a fair bit of it was persuading MapGuide and SQL Server to talk.
Software that doesn’t wait for the network
That silo system kept its own copy of the data and synced with the server, so it kept working when the connection didn’t. I was building web apps that worked offline by 2012, a few years before anyone called them progressive web apps, and mobile apps after that, from Cordova through to Flutter.
Proving it works
I was pointing people at behaviour-driven development in 2011, and I’ve leaned on tests and automated delivery ever since. Done means proven, not claimed. It’s the same idea at the heart of FeatureKit, just with an agent doing more of the typing.
Interfaces that outlive their frameworks
From wrestling IE9 to AngularJS, Angular, React, Vue and Web Components. Frameworks come and go; the fundamentals underneath them are the bits you get to keep. Lately that means design systems, and products that drift out of step with them, which is what Baseline, Tokens, Layouts, Behaviors is for.
A shop for a craft I love
I’ve been picture framing for years. A little price estimator, written to make my own framing easier, grew into Framealot, an online shop where you design your own frame, built from scratch when none of the off-the-shelf platforms quite fit. When it’s your own product, every decision comes back to you.
Choosing the stack, and living with it
I learnt early that picking a stack shapes everything that comes after. I’ve made those calls, lived with the results, and led teams through them. Less is more, nearly every time: less for the user to think about, and less for the next developer to untangle.
Some of this I wrote about at the time. The old posts go back to 2009, kept as they were written, even where the advice has moved on.
So why am I still at it after all these years? Because I still love building things. The part I enjoy most has just moved: it’s less the typing now, and more working out what’s actually worth building. Looking back, that was always the fun part.
If any of this sounds familiar, or you’re working on something similar, I’d love to hear about it.