How I think about the work

I didn't start Wonderful Software LLC because I love business or wanted to "scale an agency." I started it because after two decades in startups and product companies, I realized I do my best work when I'm building things with a small number of people I actually want to help.

Most of my career has been spent in that messy space between "we have an idea" and "we have something people are using." It requires a weird combination of impatience and precision. You need to move fast enough to maintain momentum, but careful enough that you don't build a house of cards.

How I See the Work

Software development isn't a manufacturing process. It's more like carpentry—there are principles and techniques that matter, but every project has its own grain. You can't just apply the same pattern to everything and expect good results.

I'm skeptical of methodologies that promise certainty. Agile, Waterfall, Shape Up—they're all just frameworks. Useful sometimes, cargo cult other times. What actually matters is whether you're building the right thing, whether it works, and whether someone can maintain it six months from now.

I've built products that raised millions. I've also built products that launched to crickets. The difference was never the code quality or the tech stack. It was whether we were solving a real problem for people who actually cared.

Things I've Learned the Hard Way

Fast and sloppy doesn't save time. It just moves the pain to later, usually when you can least afford it. But slow and perfectionist doesn't work either—you run out of money before you learn anything. The trick is knowing which corners you can cut and which ones will collapse the whole structure.

Technology trends are mostly noise. Every few years, someone declares that [new framework/architecture/paradigm] has "changed everything." It hasn't. The fundamentals—data modeling, user experience, performance, security—those haven't changed. The tools are just different.

Communication matters more than code. I've seen brilliant codebases fail because nobody could agree on what they were building. I've also seen mediocre code succeed because everyone was aligned on the goal and willing to iterate.

You can't test your way to quality. Tests are great. I write them. But quality comes from thinking clearly about what you're building and why. Tests just help you not break things later.

What Actually Matters

A successful project isn't one where everything went according to plan. It's one where we shipped something real, learned from it, and used that knowledge to make it better.

It's a project where the person I'm working with isn't locked into my specific way of doing things. Where the code is clear enough that someone else could take over if needed. Where we made tradeoffs consciously instead of accidentally.

It's building something that actually gets used. Not something that wins design awards or gets upvoted on Hacker News, but something that solves a problem for real people.

That's what I'm here for.