On this page
Why the hourly meter turns against you
An hourly rate puts a price on your time. That arrangement is fair while time is the hard part of the job. The moment a tool does in ten minutes what used to take you three hours, the meter starts working against you: same result for the client, smaller invoice for you. You get better and you earn less. That is a strange thing to build a career on.
There is a second problem underneath it. The tasks AI already handles well sit in a crowded, low-priced band, roughly $4–7 per hour. Data entry and encoding, copy-pasting between systems, formatting and sorting, basic rewriting, simple research and summarising. A client can now attempt all of that themselves at midnight. Charging by the hour for that kind of work puts your rate in a direct comparison you cannot win. What you can earn looks at that gap from the earnings side.
Hourly billing also shapes the conversation. When you sell hours, clients manage hours: timers, screenshots, polite questions about why something took as long as it did. When you sell a finished thing, the client looks at the finished thing.
Hourly pricing charges for the typing. Deliverable pricing charges for the outcome. AI made the typing faster and left the outcome exactly where it was.
The thing you are actually selling
Change the unit. Instead of selling an hour, sell something the client can point at and recognise when it arrives. A client portal where each customer sees only their own files. An enquiry inbox that sorts messages into three queues and drafts a first reply for approval. A weekly report that builds itself from the data the team already keeps.
A deliverable has an edge to it. An hour does not. That edge is what lets you quote a number, defend it, and know when you are finished.
It also puts the price on the right thing. The valuable part of this work is rarely the building. It is seeing what is broken inside a business, deciding who is allowed to see what, and checking the AI's output before a client ever sees it. That judgement is invisible on a timesheet, and it is the part that holds its price. From prompts to systems covers how that work is actually delivered.
A method for building a price
Guessing usually means picking a number that feels survivable and hoping nobody flinches. A method replaces the feeling with something you can explain. Work through it in this order.
- Write the outcome in the client's own words. Not "build a Softr portal" but "stop sending client files over Messenger". If you cannot write that sentence, you are not ready to quote.
- List every stage, not just the building. Discovery calls, getting access to their accounts, cleaning the data they send you, building, testing, fixing what testing finds, handover, and the short support window afterwards. The building is often the smallest part.
- Estimate the hours honestly, then keep them private. Include the unglamorous stages. Include the week you will spend waiting for a spreadsheet. This estimate is your sanity check, not your quote, and the client never sees it.
- Set a floor. Decide the least you would accept for this project and still be glad you took it. Below that, the honest answer is no. A floor protects you far better than a rate card does.
- Price against the outcome, not the clock. Ask what the problem costs the business now: the hours their staff spend re-keying data, the enquiries that go cold, the files sitting in a chat thread. That comparison, not your speed, is what makes a number reasonable.
- Offer two or three shapes, not one. A smaller version, the version you recommend, and a larger one with the extras attached. Choice moves the conversation from "yes or no" to "which one", and it tells you what the client actually values.
If you have never quoted a build before
Price your first two or three projects deliberately low if you want, but price them as deliverables. The habit matters more than the amount. Track your real hours privately against the estimate. After a few projects you will know exactly where you underestimate, and that knowledge is what removes the guessing.
Scope so revisions do not eat the profit
Fixed-price work tends to lose money in the same place: not in the build, but in the fortnight afterwards, when small requests arrive one at a time and each of them individually feels too small to argue about. Scope is how you stop that.
- Write the done sentence. One sentence both of you agree on: "This is finished when the five staff logins work, each client sees only their own records, and the team has had the handover session." Agreement on "done" before you start is worth more than any clause.
- Cap revisions and define what one is. Pick a number, two is a sensible default, and say what a round actually means: one consolidated list of changes, sent once, within an agreed window. Left undefined, a round becomes an open channel of messages.
- Name the inputs you need and when. Logins, data, brand files, the answers to your questions. Then state the consequence plainly: late inputs move the delivery date, not the price.
- Insist on one decision-maker. Feedback from four people who disagree with each other is not feedback, it is unpaid mediation.
- Handle changes as changes. Every addition gets a short written note with a price and a new date, agreed before you touch it.
What to put in writing
None of this needs a lawyer. A clear email or a one-page document is enough, sent before any work starts, and confirmed by a reply.
Include: the outcome in plain words; the specific deliverables, listed; what you need from the client and by when; the timeline; the number of revision rounds and what counts as one; the price and the payment points, usually a deposit and a balance on handover; what happens if the project is paused or cancelled; who owns the accounts and the data at the end; and how long you will support the build after handover.
Exclude, explicitly: anything you suspect they might assume. Ongoing maintenance. New features that were discussed but not agreed. Content writing, if you are building the system rather than filling it. Paid tool subscriptions, if the build needs one. Training beyond the handover session. Migration of old data you have not seen.
The exclusions list feels awkward to write and is the kindest thing in the document. It prevents the conversation where a client is disappointed and you are unpaid, both of you sincerely believing you had agreed something different.
Access and data belong in the scope too. Deciding who is allowed to see what is real work with real consequences, and it is worth naming rather than absorbing. Client data and what you are responsible for goes through that in detail.
How to say the number without apologising
The expensive mistake is rarely the number itself. It is the noise around the number: the softening, the nervous justification, the discount offered before anyone objected.
Three rules. State the price as a fact. Do not narrate how you arrived at it. Then stop talking.
"The build is [amount]. That covers the portal, the client logins, and the handover session. Two rounds of changes are included. Anything outside that list I will quote separately before I start it. Shall I send the written scope?"
Say it, then let the silence sit. The pause after a price feels much longer to the person who said it than to the person hearing it, and it is easy to fill that gap by discounting yourself.
Some phrases to retire: "I was thinking maybe around", "I know it is a lot", "but I can go lower if that helps", "is that okay?". None of them make a yes more likely. They tell the client the number is negotiable before the client has decided whether it is.
If the conversation happened on a call, put the same number in writing the same day. Prices discussed out loud drift; prices in an email do not.
When the client pushes back
Pushback is normal and usually not personal. The useful instinct is to protect the price and move the scope.
"That is more than I expected"
"I understand. The price is tied to what is in the scope, so I can bring it down by taking something out. If we leave the automated reports for a later phase, it becomes [amount]. Would you like me to write up that version?"
"Can you just charge hourly?"
"I price the deliverable rather than the hours. It means you know the cost before I start, and the number does not move if the work takes me longer than I planned."
"Someone else quoted much less"
"That may well be the right choice for this project. My quote includes testing, the access rules, and a handover session, so it may not be the same piece of work. I am happy to quote a smaller version if you would like to compare like with like."
The extra request halfway through
"Happy to add that. It sits outside what we agreed, so it is [amount] and moves delivery to [date]. Want me to send it as a change note?"
Say yes to the work and no to doing it for free. Those are separate answers, and clients hear them as one calm sentence rather than a refusal.
No pricing method makes a client say yes. JobTayo does not guarantee income, rate increases, employment or clients, and this guide is not a prediction of what you will charge or be paid. What a method gives you is a number you can explain, a scope you can defend, and a conversation you are not dreading.
Where to go next
- What you can earn — VA work versus AI-certified work, the companion guide to this one
- From prompts to systems — how AI work is really delivered, if you want to see what a deliverable looks like in practice
- The skills that outlast the tools, on the judgement that is hard to price by the hour
- The JobTayo Academy curriculum, if you want to see what is taught and in what order