THE PROCESS, IN FULL
How we work
I run every engagement the same way. I call it The Founder’s Build: Apply → Prototype → One Call → Build → Live. You’ve seen agencies with a “proprietary process.” This isn’t that. It’s just the order that works, and I don’t skip steps.
Five steps from “I’ve been trying to get this built for a year” to “that runs now.” One call, not a sequence of them. A working prototype before you spend anything.
This page is the long version — including the parts that are on you, what I’ll ask for, and what happens when you think of something new halfway through. Better to know all of it before you apply than to find out in week three.
THE FIVE STEPS
No pitch. No proposal PDF. You see it running first.
Tell me what you want built
The application takes about six minutes. Plain English, in your own words — no tech-speak, no spec document, no diagram. If you can describe the problem out loud, you can fill it out.
I read every one myself. It doesn't drop into a CRM and wait for a salesperson. You hear back within one business day either way: if it's a fit, I tell you what I'd build first. If it isn't, you get a straight answer on why, and a better direction when I can point you to one.
- YOU BRING
- The problem, in your own words
- YOU GET
- A personal reply within 1 business day
I build it before we talk
This is the part that makes this different, so I'll be blunt about it: if your application is a fit, I build a working prototype of your system before our call and before you have paid me anything. Not a mockup. Not a wireframe. Not a slide deck with your logo on it. Something you can open and click.
You are not buying a promise that I understood you. You are looking at proof that I did. On a larger build it's a working proof of the riskiest piece — the integration everyone said was impossible, the part that decides whether the whole thing is viable.
If the prototype is wrong, that's useful too, and it cost you nothing to find out.
- YOU BRING
- Nothing. No deposit, no commitment
- YOU GET
- A real, clickable version of your idea
You click around your own system
About an hour, once. You drive the prototype while I watch, and you tell me where it's right and where it's off. That conversation is worth more than any discovery questionnaire, because you're reacting to something real instead of imagining it.
Then we scope. We write down what the finished thing does — a clear definition of done, in language you'd use to check the work yourself. Not a feature list that grows in the dark. A finish line we both agreed on.
We also decide together whether I'm the right person to build it. Sometimes the answer is no. One call is the whole sales process either way.
ON THE SAME CALL
We put numbers on it first
Before I build, we measure what the problem costs. Hours per week your team burns on it. What one error costs when it slips through. What breaks first if your volume doubles.
That baseline goes in the scope. Then we re-measure at day 30 and day 90 after launch. Same numbers, same method. If the build worked, the numbers say so. If something's off, we see it early enough to fix it.
- YOU BRING
- The decision-maker and honest reactions
- YOU GET
- Scope, price, a baseline, and a written definition of done
Weeks, not months
AI-leveraged development, run by someone who has been building these systems for 25 years. The speed is real and the quality holds — I ship solid, not fast-and-broken.
How long depends on the lane. A Sprint Build is 2–4 weeks. A Platform Buildout runs 8–12 weeks inside a 90-day block — the extra room is deliberate, because that's where team onboarding and the problems that only surface in real use actually happen. I'd rather scope 90 days and mean it than promise six weeks and renegotiate at week five.
A progress note lands in your inbox every week: what got built, what's next, and anything I need from you. You are never left wondering where it stands, and you never have to chase me for a status update.
Everything is in your name from day one. Your accounts, your domain, your payment processor, your data. Not held inside my agency and rented back to you.
- YOU BRING
- Access, assets, and feedback on time
- YOU GET
- A weekly progress note and working software
It runs in your business
Deployed into your real operation, doing the actual job with real customers and real data. Live means used, not delivered.
I train your team on it — the people who touch it daily, not just you — and I hand over the keys. Then I stay on and tune it against reality, because the first two weeks in the wild always teach you something the build never could.
Your first 30 days after launch are included, and I'm watching usage, not just uptime. That part gets its own section below, because it's the part everyone skips.
- YOU BRING
- Your team, for a short training session
- YOU GET
- A system you own, running in your business
That’s the whole shape of it. The rest of this page is the part most people don’t ask about until they’re already in it — whether your team will actually use it, and what a build asks of you.
WILL YOUR TEAM ACTUALLY USE IT?
The part everyone skips: adoption
Here’s the failure mode nobody puts on their website. The build ships. It works. Six weeks later your ops person is back in the old spreadsheet and the system you paid for is a login nobody uses.
That’s not a code problem. That’s an adoption problem, and most builders pretend it isn’t their job. I treat it as the job.
THE FLOOR INTERVIEW
Before I build anything, I talk to the people who will actually use the system — not just you. You know what the business needs. They know where the current process actually breaks, which fields nobody fills in, and which "required step" everyone skips. A system designed founder-only gets used founder-only.
A SWITCH DATE, IN WRITING
Before launch, we pick the day the old way stops, put it in writing, and tell the whole team. Not "we'll transition gradually." Gradually means never. Everyone knows the date, everyone knows what changes, nobody gets surprised.
THE OLD TOOLS GET CANCELLED
On the switch date, the tools the new system replaces get cancelled. If the old spreadsheet is still open in a tab, the new system is optional — and optional systems lose. Cancelling is also where the ROI shows up: subscriptions you stop paying for.
THE 30-DAY ADOPTION WATCH
Your first 30 days after launch are included — the clock starts when the system goes live, not when the build starts, so a four-week build and a three-month build get the same thing. And I'm not just watching uptime, I'm watching usage. Who's logging in. What's getting entered. Where people stall. If a shadow spreadsheet shows up, that's not the team failing the system — that's the system telling me where it's wrong, and I fix it while the fix is cheap. At the end of that month we talk about what ongoing support should look like. It's optional, not a subscription you have to sign to keep your own system running.
By day 30, the question isn’t “does it work?” It’s “does your team reach for it without thinking?” That’s the definition of done.
YOUR SIDE OF IT
What I need from you
I do the building. There are exactly three things I can’t do for you, and a build moves at the speed of these three.
DECISION-MAKER ACCESS
The person who can say yes is in the room
On the call, and reachable during the build. Not a committee that meets on Thursdays, not a proxy who has to take it back to someone else. Most builds that slow down don't slow down on code — they slow down waiting for a decision only one person can make.
ASSETS AND ACCESS
Logins, brand files, and data exports
Whatever the build has to touch: CRM and email logins, your logo and brand files, a data export from the thing you're replacing, API keys for anything the system has to talk to. I'll send one list, not a drip of requests. Getting it back in the first week is the single biggest thing you control about the timeline.
FEEDBACK TURNAROUND
Two business days on anything I send you
When I send something to look at, I need a yes, a no, or a specific change within two business days. Not a polished response — a fast one. Silence is the only thing that can quietly turn a six-week build into a twelve-week build, and it's the one delay I can't build around.
WHILE IT’S BEING BUILT
The communication rhythm
You should never have to wonder what’s happening or chase me for an update. Here’s what a normal week looks like from your side.
MON — THU
I build. You run your business. No standing status meeting eating an hour of your week to tell you something an email covers.
FRIDAY
The weekly progress note: what got built, what's next, anything I need from you, and whether we're still on the timeline we set.
BY TUESDAY
You come back on anything the note asked you about. Two business days, same standard as everything else.
ANY TIME
Email me directly and you'll hear back within one business day. If something needs a conversation, we get on a call that week — I just don't schedule calls for things an email already answers.
You’re working with me directly the entire time. No account manager relaying messages, no ticket queue, no junior developer you never met making decisions about your system.
WHY BUILDS ACTUALLY SHIP
Phase 2 stays Phase 2
Once you see your system working, you will think of ten more things it should do. That’s not a problem — it’s the sign it’s real to you. It’s also the exact moment most projects quietly stop shipping.
So every idea that shows up mid-build goes on the Phase 2 list. I write it down, you can see it, and nothing gets lost. What it doesn’t do is get quietly folded into the current build. Phase 2 items get scoped and priced separately, once Phase 1 is live and earning its keep.
This isn’t me guarding the scope document. It’s the reason you get a working system in weeks instead of a never-finished project in eighteen months. The definition of done we wrote on our call is what makes “done” a date instead of a feeling.
The same discipline points backward, too: I’m reluctant to mess with anything that’s already working. If part of your operation is efficient today, it stays. I build around what works, not through it.
THE ONE EXCEPTION
If something we scoped turns out to be wrong — not missing, wrong — I fix it inside the build. Discovering that a step doesn’t match how your business actually works isn’t scope creep. That’s the build doing its job.
Ship it. Use it. Then build the next thing on top of something that’s already working.
YOUR STACK, SORTED
Every tool in your stack gets a verdict
Part of every build: we go through everything you’re paying for, and every tool gets sorted into one of three piles.
Absorb
The system I build does this now. Cancel the tool.
Keep
It earns its seat. We integrate it properly instead of duct-taping around it.
Kill
Nobody's really using it and nothing replaces it. Cancel it, feel nothing.
A well-designed implementation deletes more than it creates. The subscriptions we cancel are ROI you can point at before the system earns you a dollar.
AND AFTER IT’S LIVE
Live isn’t the finish line. It’s the start of the watch.
ERRORS CAUGHT
Every error reported the moment it happens. I usually know before you do.
UPTIME WATCHED
Automated checks around the clock, from the outside.
BACKUPS TESTED
Continuous backups plus offsite copies — and restores actually get tested.
IN YOUR NAME
Accounts, domain, data, code. Yours from day one.
Step one takes six minutes.
Tell me what you’ve been trying to get built. If it’s a fit, the next thing you see is a working prototype of it — before we talk, and before you’ve paid a dollar.
Start the application →