About
I'm Brian Nipper. I've been doing this a long time.
Twenty-plus years of software development and enterprise architecture, across companies of every size — large corporations with more process than product, and small teams where I was the entire technology department. I've been an employee, and I've been the business owner signing the checks. Brash Technology is what happens when you point all of that at the businesses I think need it most.
Why "Brash"
Simple Solutions are Brash
There's a reflex in this industry to make things sound more complicated than they are — it's an easy way to seem impressive. I've come to believe the opposite is true: it takes more confidence, not less, to look at a hard problem and choose the simple answer. That's what "brash" means here. Not loud for its own sake — willing to say the straightforward thing when everyone around you is dressing the problem up.
Why small businesses
I prefer working where the impact is obvious
I've built systems for organizations big enough that a single decision could take months to make and years to matter. There's a place for that kind of rigor. But I get more satisfaction from working with a business of one to ten people, where a good technical decision shows up in the business within weeks, not fiscal quarters — and where I can actually talk to the person the decision affects, instead of a committee representing them.
How I think about this work
Most people don't want the details. They want to trust the person who has them.
I don't expect a business owner to care about the difference between a CNAME and an A record, and I don't think they should have to. What I do think matters is that when I explain something, I explain it well enough that you could follow along if you wanted to — because that's how you tell the difference between someone who understands a thing and someone who's hoping you won't ask a follow-up question. The free resources on this site exist because teaching is the most honest way I know to demonstrate that.
Outside of work
Still a geek about it
I like this stuff. I read the changelogs for fun, I have opinions about text editors, and I'll happily go down a rabbit hole about why something broke long after I've fixed it. That's not a separate side of me from the professional one — it's exactly why the professional side works. You want the person managing your technology to actually be curious about it.