I built a simple Bluesky publishing automation using Supabase, Cron, Edge Functions, Vault, and PostgreSQL. Here's what a tiny side project taught me about reliability, security, AI-assisted development, and production-ready automation.
One lesson I've learned from production launches is that code complete and launch ready are not the same thing. A working app build is only one part of a successful release, and some of the biggest launch delays happen after development is finished.
After years of building native iOS apps, I chose Flutter for my own product. Here's why the decision was driven by product constraints, AI-assisted development, and long-term trade-offs rather than framework preference.
After building production apps with Firebase and now building a new product on Supabase, I've realized the conversation isn't about which platform is better. It's about understanding the trade-offs, the type of product you're building, and how much backend complexity you actually need.
Most AI coding failures aren't caused by poor prompts. They're caused by unclear requirements, missing constraints, and weak specifications. Here's what I've learned from using AI-assisted development in real projects.
Spec-Driven Development isn't new, but AI has exposed something many teams already knew: good implementations usually start with clear requirements. Here's why specifications, constraints, and acceptance criteria matter more than ever.
Every WWDC brings new frameworks and capabilities. What I'm hoping for this year is a little different: better tools for the parts of software development that consume the most time in real projects.
I recently got pulled into a project that was technically “finished.” The app worked, the flows worked, and the subscriptions worked. But the founder still didn’t feel safe releasing it, and honestly… I understood why almost immediately. The app had been built pretty quickly by a couple of junior
A few years ago, writing code itself was one of the main bottlenecks in software development. Implementation took time. Boilerplate took time. Research took time. Even translating ideas into working code was expensive. Today, that’s changed. Generating code is easier than ever. You can scaffold features in minutes, generate
One thing I’ve learned working on production systems over the years is that good engineering is rarely about following principles perfectly. Because real-world development constantly puts principles in conflict with each other. YAGNI. KISS. DRY. SOLID. They all make sense individually. Until deadlines, legacy systems, unstable requirements, production
I used to think this was a binary choice. Either you ship fast or you do it right. In reality, it’s almost never that clean. Most real-world projects don’t give you the luxury of perfect decisions. You’re dealing with: * Deadlines that won’t move * Backend dependencies
I’ve lost count of how many times I’ve joined a project and thought: “Okay… this is going to take a minute.” No docs. Weird naming. Logic scattered everywhere. And bugs that don’t make sense at first glance. And honestly… I’ve been on the other side of