Almost every shop in this business ends the pricing conversation the same way: book a call for a quote. I understand the reasoning — estimates are genuinely hard, and nobody wants a number on a public page that a prospect will hold them to two years later.
The effect on the buyer is rough, though. You write one paragraph describing what you need, send it to four places, and get back four numbers that do not look like they describe the same project. One is low five figures. One is six. And you have no way to tell whether the cheap one is a bargain or a rebuild waiting to happen.
So here is the opposite: my actual rate, how I size a first build, what makes a project expensive, and which parts of the work have genuinely gotten cheaper. Everything below is a range. Ranges help you decide whether to have the conversation at all; they are useless as a contract. Anybody who can quote your project accurately from one paragraph is guessing — me included.
Why the same paragraph gets four different numbers
Three things drive most of the spread, and only one of them is about who is better at the work.
The description is not a spec
“A portal where my team can track orders” is somewhere between forty hours and four hundred, depending on answers you have not given yet. Do different roles see different things? Is there an audit trail when someone changes a price? Does it import from the system you already run, or does someone retype? Who gets emailed when an import fails?
The cheap bid priced the sentence. The expensive bid priced the questions, and padded for the ones it did not think to ask. Neither vendor is lying to you. They are answering different questions.
You are paying for the org chart
An agency quote covers an account manager, a project manager, a designer, two developers, a QA person, and the sales commission on your deal. One of those roles writes your code. Coordinating six people genuinely costs money — but the blended hourly rate you were quoted is not the rate of the person building your thing.
Offshore rates are real. Offshore coordination is not free
The hourly numbers are exactly what they look like, and plenty of offshore teams do good work. What does not appear in the quote is the cost on your side: a specification detailed enough to survive a twelve-hour timezone gap, a review cycle where every clarification costs a day, and someone in your building technical enough to judge whether what came back is right. That works when requirements are settled. It goes badly when you are still figuring out what you want, which describes most first projects.
How the money actually works
So that the numbers below mean something: I bill new work at $95–$125 an hour, depending on the kind of work and how much of it there is. Clients I already work with are on the rate we agreed when we started, which in some cases is lower — I do not reprice people retroactively.
For market context: agency blended rates commonly land between $150 and $300 an hour, and offshore teams frequently quote $25–$60. Those are observations about the market, not quotes from me.
But the rate is the least interesting part, and a total project price is usually the wrong thing to be shopping for. Here is the shape I actually work in, because it is the shape that keeps a small business from over-committing: a first build, then whatever you need after that.
Part one: the first build
The goal of a first build is not to deliver everything on the list. It is to get the thing that hurts most out of the spreadsheet and into something real, and to do it small enough that you find out quickly whether it was worth doing.
In practice a first build is tens of hours, not hundreds. A focused piece — a marketing site, a single form that writes to a real database instead of an inbox, a scheduled job that assembles the file somebody currently rebuilds by hand — is often in the range of ten to forty hours. A real internal application, with logins and roles, a couple of screens where the work happens, and one outside system in the picture, is more likely to be somewhere in the tens to low hundreds of hours.
At my rate you can do that arithmetic yourself, and I would rather you did. The point is that a first build is usually a four-figure decision, sometimes low five figures for something substantial — not the kind of number that needs a board meeting.
What that includes: a working application deployed onto real infrastructure, the screens where the work actually happens, and enough documentation that your team can run it without me. What it usually excludes on the first pass: a custom design system, a mobile app, and migrating five years of history out of the old thing. Those are all real work, and they are all things you can decide to do later, once the core is earning its keep.
Part two: only what you need after that
This is the part that matters more than the build number, and it is the part nobody quotes.
After the first build, most of my client relationships settle into a rhythm of ongoing hours that varies with what is actually happening in the business. Some months that is a couple of hours — a format changed on the other end of an integration, a report needs a new column, someone needs a login. Some months it is more, because you decided to add the next thing. Some months it is nothing at all.
You are not on a subscription for capacity you are not using. You are not buying a fixed scope up front and then negotiating every change against it. You fund a first build, you see whether it works, and after that you buy hours when you have a reason to. Longer relationships often move to a retainer, but that is a convenience for both of us once the pattern is predictable — not a way to bill you for a quiet month.
The practical effect is that the decision in front of you is never “can I afford a custom system.” It is “is this specific piece worth this specific number of hours,” asked over and over, with the option to stop at any point and keep everything built so far.
What actually got cheaper
Here is the part that sounds like a contradiction: my hourly rate went up, and the quotes I write got smaller. Both are true, and the second one is the reason the first one is fine.
One slice of this work got dramatically faster over the last couple of years, and an honest pricing conversation should say so rather than pretend it did not happen. The slice is scaffolding: authentication, sessions, role-based access, password reset, CRUD screens, admin tables, form validation, PDF export, database migrations, the first draft of a user interface, and the tests around all of it. That is the boring stuff that has to work, and it used to be a real fraction of the estimate on any internal application. I use AI coding tools on client work every day, and they compress that slice hard. The code still has to be reviewed and it still has to be right — I read all of it — but the hours are not what they were.
You are billed for hours, not for a rate. If the rate goes up ten percent and the hours come down by a third, your invoice went down. I would rather charge a rate that reflects the work and hand back the savings in scope than hold a lower number and quietly take longer.
First builds shrank the most, because a first build is mostly scaffolding wrapped around one good idea. The consequence worth naming: a category of project that never penciled out now can. The ones where the value was always obvious and the build cost was just as obviously higher than that value. If you shelved something a few years ago because the math did not work, the math is worth redoing.
Where AI tooling did not help at all
This is the part the tooling vendors skip, and the part that decides your budget.
Integration with legacy systems. A model will write an API client in a minute. It cannot tell you what the vendor means by the field called status_2, why three of the status codes are undocumented, or which of the two people who know still works there. That answer takes a week of asking humans questions. It always did, and it still does.
Data cleansing. One project involved reconciling two large datasets that described the same properties using entirely different identifiers — fuzzy matched, scored, merged into one canonical record set. Writing a matcher is a solved problem. Deciding what counts as a match is a business judgment call, not a technical one, and no tool will make that call for you. Same with customer records listed under three slightly different names: the code is trivial, the rules are not.
Domain judgment. Nobody has written down how your business actually works. There is a column somebody added in 2019 that quietly encodes an exception for one customer, and a rule everybody follows that nobody has said out loud. AI builds what you describe. It has no idea what you forgot to describe.
AI made the typing cheaper. It did not make the deciding cheaper — and the deciding was always the expensive part. It was just hidden inside the typing.
What actually makes a project expensive
- Unclear requirements. By a wide margin the biggest driver. Every unanswered question becomes an assumption, and a meaningful share of assumptions turn out wrong. Wrong assumptions get discovered at the demo and rebuilt at full price.
- The number of integrations. Cost does not scale linearly. Each system brings its own authentication, rate limits, failure modes, and an owner whose calendar you need. The expensive part is never the happy path — it is retry logic, error handling, and alerting, so a broken sync does not fail silently for six weeks.
- Data migration from messy sources. “And move the old data over” is where budgets die. Vendor exports, PDF reports, three spreadsheets that disagree, the same entity spelled four ways. Cleaning it is often a bigger job than the application it is being cleaned for.
- Compliance and sensitive data. Health records, card data, or an enterprise security questionnaire all add real scope: audit trails, encryption at rest, access reviews, retention policies. Budget for it deliberately, and ask whoever you hire if they have done it before.
What to ask before you sign
- What is in this number, and what is explicitly not? Data migration, training, and post-launch support are the three that quietly go missing. Get the exclusions in writing.
- Who writes the code, and can I talk to them? If the person on the sales call disappears after signing, you will explain your business twice.
- What happens when the estimate is wrong? Every estimate is wrong. The question is whether you hear about it in week three or month five.
- What do I see in week two? If the answer is a document rather than something running, be careful.
- Where does the code live, and who owns it? Repository access from day one, ownership in writing. No exceptions.
- What does it cost to keep running? Hosting, third-party fees, licenses, ongoing support. A cheap build with an expensive tail is not cheap.
- What happens if you disappear? Boring, widely-known technology means the next person can pick it up. Clever technology nobody else uses is a liability dressed as an advantage.
- Can I see something you built that is still running? Not a screenshot. Something in production years later, with a client who will take the call.
Where to start
If you are collecting quotes, the most useful thing you can do is narrow the ambiguity yourself. Write down the workflow as it happens today, step by step, including the parts that embarrass you. Name every system the data comes from and goes to. Say what has to be true a year from now for this to have been worth it. That one document pulls the spread between your quotes in dramatically, and it shows you who actually read it.
That is roughly how I start too: thirty minutes on a call to understand the problem and work out whether I am the right fit, then within a week a written summary of what I would build, in what order, with an hours estimate you can budget against. If it turns out you do not need custom software at all, I would rather tell you that early.
You can see what I build and run, or hit the Get in touch button below and just describe the problem if you would rather skip straight to that. I usually reply within a day.