The questions worth asking.

Send the quote form or an email with the messy version — what you are trying to build, who it is for, and what is broken or missing today. A paragraph is enough. I read every one myself and reply, including an honest no if I am not the right fit.

I come back with questions or, if it is already clear enough, a scope and a price range. If it looks like a fit we talk it through properly, then you get the whole thing in writing before anything is built.

Usually right away. I run several projects at once and I am not sitting on a six-week queue, so if the scope is clear we can be moving within days rather than months. If that ever changes I will tell you at the quote rather than after you have paid.

Yes. The work is remote by default and I work with clients across the United States and beyond. Time zones matter more than borders — if we can overlap for a few hours most days, distance is not a problem.

No, and it is often better if you do not arrive with a solution already picked. Describe the problem and what a good outcome looks like. Choosing the technology is my job, not yours.

There is no price list, because there are no standard projects. A website with a portal behind it and a website that is five pages of clear copy are not the same job, and pretending otherwise would only produce a number I would have to walk back later. What you can rely on is the process: describe what you need, and you get a real figure in writing based on your actual requirements, usually within a day or two of asking.

By the project, always. You are buying a finished thing rather than my time, which means the number does not move because something took me longer than expected, and neither of us is watching a clock instead of the work.

Because an honest range beats a precise number that quietly assumes everything goes perfectly. Once scope is genuinely nailed down the range tightens, and for well-defined work it can become a fixed figure.

Scope-dependent, and stated in the proposal rather than guessed at here. What I will not do is quote a timeline I do not believe, then spend the project apologizing for it.

Often, yes — a website on a tight deadline is usually achievable. Compressing a schedule costs more, and how much more depends on the size of the build, so I will tell you what is realistic before you commit to a date rather than agreeing and hoping.

It often does, and that is fine. Changes get priced and agreed as they come up rather than absorbed silently or sprung on you at the end. You always know where the number stands.

Work is staged, with payment tied to stages rather than one lump at either end. Where I keep something running and hosted for you, it is normally a build fee plus a monthly instead of one large number. The specifics go in the agreement so both of us know what triggers what.

For a simple brochure site, sometimes you should — and I will tell you if that is your situation. The problem shows up the moment you need something the builder does not do: a portal, a booking flow, a members area, a piece of logic specific to how your business works. At that point the tool decides what is possible instead of you. Everything I build is custom code, so that ceiling does not exist.

Most people who reach me have already paid someone — a template build that never landed, a friend who codes on the side, an offshore team that held the accounts and went quiet. The pattern is usually the same: no clear scope, no visibility while it was being built, and no way to take the work elsewhere. So you get scope in writing before anything starts, you watch it come together rather than waiting for a reveal, and the code and accounts end up in your name.

Not necessarily — they may be doing a smaller job than the one you described, or using a tool that will hit a wall later. Ask them what happens when you need something the platform does not support, and who owns the accounts at the end. If the answers are good and the price is lower, take it. I would rather you did than end up rebuilding.

If it allows real custom code, yes — GoHighLevel is a common example, and I am happy to build properly inside a system you are already committed to. What I will not do is assemble something out of drag-and-drop blocks, because that puts you back inside the ceiling you were trying to escape.

No. I design and build, and that is where I am genuinely good. I would rather tell you that than take money for something outside what I do well — plenty of people do marketing properly, and I am not one of them yet.

You talk to the person doing the work. Nothing is relayed through an account manager, nothing gets handed to a junior after the pitch, and the person who scoped it is the person who writes the code. The trade-off is capacity: I take on a limited number of projects at once, so timing matters.

Decisions, mostly, and reasonably quick ones. Access to whatever systems it has to connect to, someone who can answer questions about how the work actually runs, and honest feedback when I show you something. The project moves at the speed of the slowest answer.

Continuously. You see it as it comes together rather than at a reveal, so feedback lands while changing course is still cheap. That is the entire point of working this way.

I do not count rounds. Feedback within the agreed scope is just part of building it. A change that expands the scope is a change to the scope, and gets treated as one — openly, not as a gotcha.

Whatever genuinely fits the job, chosen for how well it will hold up in two years rather than for novelty. I will tell you what I have picked and why, in plain terms, and I will not build something on a stack only I can maintain.

Usually. Plenty of the work is improving or connecting systems that already exist rather than replacing them. If starting again really is the better option I will say so, and explain why, rather than quietly billing for a rebuild you did not need.

You do. Code, accounts and domains end up in your name. You get a walkthrough of how to run it and the access to do so. No hostage situations, and no rented access to your own product.

Tell me. Problems that trace back to the build are mine to fix. For ongoing changes and support beyond that, we agree an arrangement that matches how much you actually need rather than a retainer for its own sake.

Yes, and most projects have a second phase once real people have used the first one. Equally, if you would rather take it in-house or hand it to someone else, it is built and documented so that is genuinely possible.

No — those scenes are illustrative concept work, not client screenshots or measured client results. The real work is real: a paid website and video education platform, a church website built and donated, a SaaS product of my own, client work built through an agency that I cannot discuss in detail, and a church management system currently in build. Ask and I will walk you through what I can show.

Automating systems and processes. Taking a workflow that people are currently holding together by hand, working out where the hours and the mistakes are going, and building something that removes both. Websites and web apps are the front door; that is the work underneath.

I will tell you early, and where I can, point you somewhere better. Taking work I cannot do well costs us both more than an honest no does.