I have been building things on the web for a few years now. The pattern I keep running into is that the interesting problems are never the ones on the surface. They are always one layer underneath. A page that loads slowly because of how the data is structured. A feature that feels broken because of a decision made months earlier. A system that works fine until it gets real traffic. That is where the actual engineering happens.

I started the way most people do. Picking up tools, following tutorials, shipping things that looked finished but did not hold up under real conditions. At some point I stopped trying to learn more things and started trying to understand fewer things better. That shift changed everything about how I build.

Right now the main thing I am working on is Shuyml. It is a trend intelligence platform that takes what is emerging across the web and turns it into deployed apps. The core idea is that the gap between a trend and a working product is mostly just execution speed. Shuyml is built to close that gap. It is still in progress but it is the most technically honest thing I have worked on.

At IMvision I lead development of a visual creation platform. Most of the interesting work there has been around WebGL rendering and making collaborative edits feel instant before the server responds. Before that I contributed to Tailark as an open source contributor, building accessible components and reworking their theming engine.

Day to day I work mostly in Next.js and TypeScript. Having strong opinions about how data moves through a system, how pages behave under real conditions, and how architecture decisions made early show up as problems later. I use Drizzle ORM,TanStack Query, Neon, Vercel AI SDK, and Upstash regularly enough that I can tell you exactly where each one gets annoying.

AI is part of my workflow. Mostly for moving faster through the parts that are not the interesting problem. I still write the architecture, make the calls, and own the output. It just means I spend less time on the boilerplate and more time on the thing that actually matters.

I avoid over-engineering. I would rather ship something that works and fix it with real feedback than wait until it is theoretically perfect. Most of the best calls I have made came from using something in production, not from planning it in advance.

Outside the work I write about what I am building and running into on 𝕏. Not advice for the sake of sounding senior, just the things I actually wish I had read when I was stuck on something. If any of it lands for you, that is the point.

If you want to talk about something you are building, reach me on 𝕏 or by email.