How I Work

Most founders I work with have already been burned once. A dev team that built the wrong thing, or the right thing badly, or nothing at all for three months while the invoices kept coming. By the time they find me they don't want another vendor. They want someone they can trust and who actually understands what they need.

This page is that methodology, written down. It's not a pitch. It's how I actually think about every engagement, in the order I think about it.

Last updated July 2026. This is a living document. I update it when my thinking changes.

I find the real problem before I build anything.

You'll come to me with a solution already in mind. That's normal. You've been staring at this problem longer than I have. But the solution you're picturing and the problem you're actually trying to solve aren't always the same thing.

So before anything gets built, I ask questions. A lot of them. Not to slow you down. To make sure we're aiming at the right target before we spend a dollar on hitting it. Nobody wants to find out six weeks in that we built the right thing the wrong way, or the wrong thing perfectly.

Custom software isn't always the answer.

I build custom products for a living. I also know most business problems don't need one. Part of my job is telling you that, even when it means less work for me.

Every engagement starts the same way: what's actually going to solve this? Sometimes it's a custom build. Sometimes it's a tool that already exists and you just need someone to help you pick and install the right one. Sometimes it's Zenpost, because I already built it and there's no reason to build it twice. I'll always tell you which one you actually need, not which one pays me more.

That's also why I say I don't just build, I advise. I've run an agency myself. I know what the founder needs. And I've managed dev teams of 12+, so I know what's actually possible to build, how long it really takes, and what it really costs. I sit in the middle and translate both directions. Developers like working with me for the same reason founders do. I represent everyone's real interests, not just whoever's in the room.

I build with AI. Not "AI-assisted."

When I'm the one building, AI writes the code. I'm not talking about autocomplete. I'm talking about the actual implementation, directed by me, top to bottom. I built Zenpost this way. A traditional agency would've quoted 18 months and half a million dollars. I did it solo in 8 months.

But here's the part people miss: my expertise is the product, not the prompt. Speed is what happens when someone who already knows what to build uses AI to build it faster. It's a side effect. It was never the pitch.

A few things I hold the line on so "built fast" doesn't turn into "built sloppy":

• I review every meaningful piece of output before it ships. AI writes fast and confidently even when it's wrong. I'm the check on that.

• I architect before I generate. AI is great at filling in a well-defined structure and bad at deciding what that structure should be. That decision stays mine.

• I test in the real conditions the product will actually run in, not just the happy path AI defaults to.

• I know where AI-assisted development breaks down, and those are exactly the spots I slow down and do by hand.

Scope gets defined before a single line of code.

The number one reason builds go sideways isn't bad developers. It's a scope that was never actually a scope. Just some vague bullet points everyone nodded at, that turn out to mean three different things to three different people the moment the product actually exists.

So we define it. Specifically. What's being built, what it does, what it doesn't do, and what "done" looks like. That document is what protects your budget, your deadline, and the relationship. No surprises, because there's nothing left to be surprised by.

You always know exactly where the build stands.

Whether I'm the one building or I'm overseeing a dev team, the whole project lives in a shared workspace you have access to. Daily updates on what got built and what's ready to review. A weekly report on where things stand, what came up, what's planned next.

You should never have to ask "how's it going." You should already know.

I protect the build's vision, budget, and deadline like they're mine.

The first version is the minimum viable product. Not because we're cutting corners, but because scope that keeps growing never ships. When new ideas come up mid-build, and they always do, they go on the list for next round. Not into this one. My job is keeping us pointed at the actual problem we set out to solve, not every good idea that shows up along the way.

That goes both directions. Sometimes it's a client getting excited and wanting to add on. Sometimes it's a developer who wanders off to solve a problem nobody asked about. Either way, I'm the one keeping the build on target, on budget, and on schedule.

Deadlines work the same way. I put a date on the calendar and we build toward it. If it needs to move, I move it carefully and I tell you why. What I don't do is let it float further out every few weeks until the launch quietly stops happening. Your problem is costing you money every day it isn't solved. The faster we ship, the faster that stops.

I don't just build it. I install it, train your team, and stick around.

A product nobody knows how to use isn't a finished engagement. It's an unfinished one that got handed to you early.

Every build I ship is built for three things: usability, so the interface makes sense without a manual; flexibility, so it can grow without a rebuild every time something changes; and security, so the right people see the right things and nobody else does.

Then I install it, write real training documentation, and walk your team through it. You don't get a login and a "good luck." You get a product your team actually knows how to run.

What I won't do.

• Build the solution you walked in with if it's solving the wrong problem.

• Sell you a custom build when an existing tool would do the job.

• Let scope drift because a call felt too awkward to have.

• Let a deadline quietly slide three months without telling you why.

• Hand off a finished build and disappear.