This matters more than any individual system on this site. It's the thing that's consistent across all of them. If you want to understand how I'll approach a problem I haven't seen yet, this is where to look.
Every system on this site started the same way. Not as a market gap on a spreadsheet, but as an idea I've either run into or genuinely struggled with myself: counting stock at close, juggling five supplier logins, hitting a paywall trying to edit one confidential document online, or watching how far the prosthetics industry still is from moving a hand naturally instead of switching between rigid, preset grips, something I'd have assumed AI would have already solved. I try to stay open to all of it, because you never know where a good opportunity is going to come from. Whether it sounds like an impossible, technically challenging problem, or something with more of a plan already, I like to see where an idea takes me.
That's also why the systems on this site span such different worlds: hospitality, parking, biomedical research, privacy, my own workload. The common thread was never the industry. It's whether something that should be easy is still, for no good reason, broken.
AI has accelerated how quickly I can build and test an idea. What used to take months of setup can now take days. I don't necessarily build and test fast by nature; the acceleration is the tooling, not the habit. What hasn't changed is this: if I believe a system fundamentally works but still has real issues, I'm not afraid to break it down and rebuild it from first principles if that's what gets it further, rather than patching around a problem to avoid admitting it needs more work. That's exactly what's happening with a couple of the systems on this site right now.
Before I write a line of code, I want to know exactly where time gets wasted and why it's still done that way. The problem is rarely the technology itself.
AI accelerates how quickly a first version becomes testable against real constraints, rather than a lab condition. That first version exists to test an assumption, not to be the finished thing.
AI-assisted code needs the same scrutiny as anyone else's. I test it like it's trying to fail, look for the security and edge-case gaps a demo hides, and rebuild whatever doesn't hold up instead of working around it.
I started my first business at sixteen. Mechatronics and robotics came first, then years of freelance and agency client work, and only after that, building AI-powered products. I haven't spent years on a single corporate engineering ladder, and I'm not chasing a large public open-source profile for its own sake. What I have instead is a wide, first-hand view of where software actually fails people, because I've either built it, sold it, or used it broken myself.
That's not the kind of credibility a clean, conventional CV gives you, but I think it's the more useful one for the kind of problems worth solving. There's more on that background, including the years of client work before Everant Studio, on the About page and in the web design years.
Success for me isn't a slick demo, or a number that looks good on a slide. It's whether an actual venue would trust a stock count over doing it themselves by hand, or whether a customer's payment genuinely goes through the way it's supposed to, every time, not just in testing. If a system doesn't hold up against real use, the metrics around it don't matter to me, and I'd rather say a project is still early than dress it up as further along than it is.
I'm looking to bring this way of working into a team actively building with AI, somewhere engineering, product thinking and real-world outcomes matter more than optics.