How the work actually runs.
From the first call to the handover, in the order it happens. What gets written down, what lands every week, what I need from you, and what happens when a date stops looking achievable.
The five stages
The first conversation
Twenty minutes, no deck, and a straight answer at the end.
Planning and scope
The scope is the contract, and the part worth reading twice is what it excludes.
Wireframes and design
Structure first, in gray, before anybody argues about a color.
Building it
There is no project manager. There is a weekly rhythm you can audit yourself.
Timelines, deliverables and budget
You hear about a slip the week it becomes likely, not the week it lands.
The first conversation
Twenty minutes, no deck, and a straight answer at the end.
You describe what is broken or what you want built. I ask the handful of questions that decide whether this is a two week job or a two quarter one, and then I tell you what I think. Sometimes what I think is that you do not need me yet, or that the thing you are describing is a page builder and a weekend of your own time. You get that answer on the call, not in a proposal three weeks later.
Every band I work in is published, so you can rule me out in thirty seconds without talking to anybody at all.
If it is a fit, I go away and write the scope. There is no second call.
What you get
- A straight answer about whether this is a fit, on the call, not a week later.
- The engagement shape I think it is, and the published band that goes with it.
- Somewhere better to look if I am not the right person for it.
What I need from you
- The outcome you want, roughly. If you already had a specification you would not need this call.
- Whatever exists today, including the parts you are not proud of. A half-built prototype tells me more than a description of one.
- The number you have in mind, or the range you are testing. I would rather size the work to your budget than send you something you were never going to buy.
- Whoever makes the decision, on the call if you can manage it.
Planning and scope
The scope is the contract, and the part worth reading twice is what it excludes.
After the call I write it up, usually within the week: what gets built, what explicitly does not get built in this phase, what I need from you and when, the dates each piece lands on, and the fixed number that covers all of it.
The exclusions carry more weight than the inclusions. A scope that lists only what is included is how a project ends up in an argument about whether something was implied. Seeing what is out of this phase is how you see what you are buying.
Fixed fee is the default. If I misjudge the work, absorbing that is my problem: I made the estimate. Work that genuinely cannot be scoped up front gets quoted hourly against a cap you set, and that is rare.
The statement of work carries the continuity plan too, in writing: who to call, what they get access to, and what it costs to bring them up to speed. You can read the clause before you sign it.
What you get
- A written scope with the inclusions, the exclusions and the assumptions in one document.
- A fixed fee, or a capped hourly rate when the work genuinely cannot be scoped up front.
- Dates for each phase, and a note of which ones depend on something arriving from you.
- A continuity plan written into the statement of work.
What I need from you
- One person who can decide without convening a committee. Everything else about a project can be worked around. This one cannot.
- Access early: the repository, the analytics, the vendor accounts, whatever exists. A large part of any estimate is finding out what is already there.
- The constraints you have not mentioned yet. A compliance requirement or a contract with an existing vendor changes the architecture, and it is far cheaper to hear about it now.
Wireframes and design
Structure first, in gray, before anybody argues about a color.
The first thing you see is not a visual design. It is the structure: which screens exist, what sits on each one, what a person can do there and in what order. Wireframes are deliberately plain, because a decision about what matters most on a screen is easier to make honestly when nobody is reacting to a shade of blue.
Real copy arrives at this stage, not after it. Words change layout. A button labeled with an actual verb is a different size from a placeholder, and the empty state nobody wrote is the first screen a new user meets.
Then the visual layer, and then a browser, quickly. A design that stays inside a design tool is a design nobody has tested at 360 pixels wide, with a customer name that is too long, on a connection that is not yours.
Contrast, focus states and keyboard behavior get decided here, not audited at the end. Retrofitting accessibility is a rebuild wearing a smaller name. This site fails its own build if a contrast floor drops.
What you get
- Wireframes for every screen that ships, and a written note of what was left out on purpose.
- A visual design once the structure is settled, not before.
- Something you can open in a browser early, not a picture of something.
What I need from you
- Reactions rather than approvals. A blunt "I would never click that" is worth more to me than a signature.
- Your real content, or an honest admission that it does not exist yet. Designing around copy that never arrives is how a launch date slips for reasons that have nothing to do with engineering.
- One consolidated set of feedback per review, from one voice. Five people forwarding contradictory notes is slower than any technical problem on the list.
Building it
There is no project manager. There is a weekly rhythm you can audit yourself.
Part of why this costs less than an agency is that nobody here is paid to carry messages between you and the person writing the code. What replaces that layer is a fixed weekly rhythm you can check without asking me for it.
A written update every week, whether or not there is good news in it: what shipped, what is next, what is blocked, and anything that moved. The bad weeks get the same format as the good ones.
Something you can click, every week, from the first week. A build you can use yourself is a status report that cannot be optimistic.
Code lands in your repository, under your accounts, from the first commit. You are never in a position where the only copy of your product lives with a contractor, and you never need my permission to look at your own work in progress.
What you get
- A written update every week, including the weeks that went badly.
- A deploy you can click, every week, starting with the first one.
- Commits in your repository under your own accounts, from day one.
- A test suite aimed at the paths that cost money when they break, not at a coverage number.
What I need from you
- A quick answer when I am blocked on a decision. Everything else can wait for the weekly update, but a blocked week is a week you paid for.
- Somebody who actually opens the weekly build. A product nobody has used until launch week is a product full of surprises.
- A decision at each fork. I will tell you which way I would go and what the other way costs, and you can overrule me knowing both.
Timelines, deliverables and budget
You hear about a slip the week it becomes likely, not the week it lands.
Most projects have a week where something takes twice as long as it should. That week is not the problem. Hearing about it late is.
The moment a date stops looking achievable it goes into the weekly update, with the reason and the options. There are usually three: move the date, cut something out of this phase, or add hands. I will tell you which one I would pick and what it costs.
Scope growth is a written change order you approve before the work starts, carrying its own number and its own effect on the date. Hourly work runs against a cap you set, which I do not cross without asking first. A fixed fee does not quietly grow an extra invoice because I estimated it badly.
Adding hands is a real option. I bring in senior engineers I have worked with directly, at no markup, and I stay accountable for what ships.
What you get
- Dates in writing, and an update in the week any of them changes.
- Change orders before the work, never as a line on an invoice after it.
- A handover another engineer could use: documented architecture, a runbook, and credentials in your name.
- A clean exit or a care plan, whichever you want.
What I need from you
- A decision when I bring you the tradeoff. Move the date, cut the scope, or add people: leaving it open picks the worst of the three by default.
- Your real deadline and what sits behind it. A board meeting, a season, a contract and nothing in particular are four different constraints, and they get planned four different ways.
- Somewhere for the work to live afterwards, whether that is your team or a care plan with me.
Who does the work
Me, and when a build needs it, more than me.
Most engagements are me from the first email to the handover, with no account layer in between. When a build wants more capacity, or a specialism somebody else is better at, I bring in senior engineers I have worked with directly, at no markup. That is a decision made in the open at scoping time rather than a subcontract you find out about later.
The question underneath this is what happens if I am unavailable. The about page answers it directly, including the three continuity terms written into every statement of work and what it looks like when I work inside a team you already have.
The same rhythm, seven kinds of work
The stages above hold whichever of these you buy. What changes is the shape of the middle. An AI sprint is two weeks with an evaluation set at the end of it. A native mobile build has a store review standing between finished and shipped. A marketing site starts with copy rather than with a data model, because a beautiful page that says nothing does not convert. A motion piece or a rendering set runs the same reviews with boards and markups standing in for the weekly build.
Fractional CTO
A part-time head of engineering: technical decisions, hiring, and code review, without the full-time salary.
AI integration
AI that answers questions from your own data and takes real work off your team, built into your product.
Web applications
The first version real users can pay for, built so the second version does not start over.
Mobile applications
Native iOS and Android, built correctly for each platform and each store.
Marketing sites
A fast, accessible site that ranks, and that you can edit yourself.
Branding and motion
Logo animation, brand films, and motion graphics your site and your socials can actually use.
AI renderings
Photoreal renderings of planned work, so a renovation, a property, or a vehicle can be seen before money is committed to it.
Testing all of this cheaply
Buy the smallest thing first.
Everything above is a description of how I work, and a description is not proof. The audit is the low risk way to find out whether it is true. It is $5K–$12K, it stands on its own, and the fee comes off the first build engagement that follows. You get a full round of this process before anything large is at stake.
If you would rather see evidence than method, the work page is honest about what is published there today, and every band is on the pricing page with what moves each number up or down.
The first step is twenty minutes.
No deck, no discovery fee, and a straight answer at the end about whether this is worth doing at all. If it is not, I would rather say so now than at proposal stage.