What's odd over these last few weeks, I am concluding it's less really on coding and more like being the designer that delivers.
From mid-December to today, I touched more moving parts than I expected to exist in a single project: Vercel deployments, Supabase auth and RLS, Next.js and Node, Google OAuth redirect rules, Stripe flows and webhooks, Cloudflare DNS quirks, PostHog analytics, Python scripts, OpenRouter calls, Cursor IDE, ChatGPT/Codex as a co-pilot… and that’s just the headline list. The surprising part wasn’t the number of tools. It was what the tools revealed about the real game.
The game is design, agility, and accounting for change.
Coding is the visible part, the satisfying part, the part you can point at. But real progress came from setting up a system that can survive reality: environment variables that don’t leak localhost into production, OAuth settings that don’t break when you switch domains, DNS records that point where you think they point, security rules that don’t quietly turn your database into a public bulletin board.
It turns out “knowing how” matters less than building a workflow that keeps working when something inevitably changes.
And something always changes.
Another realization... there is everything for everyone nowadays.
There’s a service for every layer: auth, database, analytics, billing, deployment, monitoring, rate limiting, even “AI glue” to stitch it together. That’s empowering… and also disorienting. If you’re not careful, you can spend weeks assembling tools like you’re building a spaceship—without ever launching.
So I had to learn a new discipline: tools are only valuable if they reduce time-to-learning. If a tool makes me feel productive but doesn’t create feedback, it’s likely a trap.
Each tool is easy in isolation. The pain is in the seams.
Not “hard algorithm” pain—more like “the internet is a haunted mansion” pain:
The lesson: shipping isn’t about writing perfect code. It’s about building a system where failures are understandable, debuggable, and fixable.
Underneath the chaos is an emerging and reusable skeleton.
Now I have a baseline process flow I can build on top of:
This feels like a spiritual continuation of my old Pega experience—except instead of rules in a platform, I’m building “rules” as policies, schemas, flows, and guardrails across services. Same mental model, different universe.
It’s hard to describe, but this is a different way to be alive.
It’s interesting and weird at the same time.
Interesting because the iteration loop is fast. You can have an idea at 10am, a working version by lunch, and a real deployment by dinner. Weird because the bottleneck isn’t typing speed—it’s decision-making: what to build, what to ignore, what must be correct now, and what can be ugly but functional.
And it’s frustrating too. The moment you move a real domain, you feel the weight of it. It’s not a side project anymore. It’s an object in the world.
If I had to compress the last month into a few principles:
From here, the goal is simple: keep reducing the distance between “I think this is useful” and “a real person used it and got value.”
That’s the game now. Not coding. Not tools. Value, feedback, iteration—repeat.