For a while, I was convinced software developers were charging too much.
I had written code manually before AI coding tools became as capable as they are now. I knew what it was like to spend hours writing logic, testing it, realizing something didn't work, changing it, breaking something else and going through the whole process again.
Then tools like Cursor and Claude became genuinely useful.
Suddenly you could explain what you wanted and watch a surprising amount of code appear in front of you.
From the business side, my conclusion seemed obvious:
If writing software has become this much easier, shouldn't software development become much cheaper too?
That idea affected how I looked at pricing.
More than once, I pushed the engineers around me to quote lower because I wanted the client.
$10 an hour.
$15.
Maybe $20 if we could get away with it.
Looking back, I was mixing up two completely different things:
the cost of producing code and the cost of being responsible for software.
They are not the same.
Watching someone buy AI did not suddenly make the project move
One of the larger products we've been involved with has been under development for a long time.
There were moments where our engineer was saying some parts of the work should have been finished months earlier if the technical decisions and ownership had been clearer.
Eventually, the owner bought one of Claude's highest-tier plans and started trying to work through parts of the codebase himself.
And I completely understood why.
From the outside it seems logical.
If Claude can read the repository, explain functions, generate code and make changes, why should you keep waiting for an engineer?
The interesting part was that the project didn't suddenly start flying.
AI could help him write things.
It could explain parts of the repository.
It could suggest fixes.
But whenever the problem crossed several parts of the system, he still needed somebody who understood how the application actually fit together.
That was probably when the difference became obvious to me.
AI can read a lot of code. A production system is more than its code.
There is the database.
There are external APIs.
There are payment providers.
There are environment variables.
There are old architectural decisions.
There are background workers.
There is deployment infrastructure.
There are business rules that aren't written neatly in one file.
And then there are users doing things nobody expected them to do.
AI only knows the context you manage to give it.
The engineer responsible for the system gets blamed for everything outside that context too.
Then I tried a “simple” Razorpay integration myself
Payment integration sounds incredibly simple when somebody explains it at a high level.
A customer clicks Pay.
The payment provider confirms payment.
Your application marks the order as paid.
Done.
I spent around two hours trying to work through a Razorpay integration myself.
AI helped me throughout it.
And after those two hours, I still came away realizing there were parts of the process I did not properly understand.
Because once you get past the button and the happy path, suddenly you have questions.
What happens if a webhook arrives twice?
What if the payment succeeds but your application fails before updating the database?
How do you verify that the webhook actually came from the payment provider?
What happens if two actions happen at nearly the same time?
When should the system retry?
What happens to commissions if a transaction later has to be reversed?
Who owns the state of the transaction?
None of those problems disappear because AI can generate the controller for you.
We've spoken with founders building products where the requirements looked straightforward at first: bookings, payments, vendors, customers.
Then you look properly and there is a booking state machine, payment verification, automatic expiry, lead reassignment, wallet transactions, commissions, background jobs and concurrency.
AI can generate code for every one of those things.
That does not mean every generated implementation is safe to put in production.
I used to think the obvious strategy was to quote low
This created a pricing argument I kept having with Ali.
My thinking was commercial.
We're a growing company.
We want clients.
AI makes development faster.
So why not quote aggressively?
There was a marketplace founder we spoke with where I initially wanted us to offer something around $4,000 just to improve our chances of winning the job.
Ali thought the actual scope justified something closer to $6,000 or more.
Once the requirements were properly discussed, the full structured build was quoted significantly higher.
The client eventually explained that his available budget was under $5,000.
So the scope was reduced.
We didn't get the project.
At the time, part of me thought:
Someone else is probably going to build this for him for $2,000.
And they might.
There will almost always be somebody willing to quote less.
What I've started asking now is:
What exactly is the client buying for that lower price?
Maybe the cheaper developer can create every screen.
Maybe they can create the endpoints.
Maybe the demo looks exactly right.
But what happens when two vendors attempt to accept the same booking?
What happens when Razorpay sends the same event twice?
What happens when a wallet gets credited incorrectly?
What happens when the background process dies after completing half of an operation?
What happens six months later when somebody needs to understand why any of this exists?
That's when the price difference starts making more sense.
I also underpriced specialist engineers
I made the same mistake when selling specialist work.
Early on, I was desperate to get projects moving.
I once sold work involving a specialist engineer for around $10 an hour.
At the time I didn't fully appreciate how expensive specialization actually is.
I thought about the task.
I didn't think enough about the years of context sitting behind the person doing the task.
That matters particularly with systems like ERP platforms, integrations and existing production applications.
When something behaves normally, AI is often extremely helpful.
When something behaves abnormally, the value of somebody who has seen the same class of failure twenty times becomes much more obvious.
You're not paying a specialist because they type code faster.
You're paying because their path from:
“Something is wrong.”
to:
“I know where I'd look first.”
can be dramatically shorter.
That distinction took me longer than it should have to understand.
Where AI has genuinely saved us enormous amounts of time
None of this means I've become skeptical of AI.
I use it constantly.
Our team uses it constantly.
The amount of parallel work a small engineering team can now handle is completely different from what was possible a few years ago.
One person can have Cursor helping with one repository.
Someone else can be investigating another system.
At the same time we can use AI to brainstorm an architecture decision, research a provider, prototype an internal idea or understand an unfamiliar library.
That leverage is real.
For clearly defined work, AI can be ridiculously effective.
Boilerplate?
Excellent.
First implementation?
Excellent.
Explaining an unfamiliar API?
Very useful.
Refactoring something the engineer already understands?
Often excellent.
Generating tests?
Useful.
Documentation?
Useful.
Getting from an empty repository to the first working version of a product?
This is probably where the change feels most dramatic.
A capable small team can now get to a working MVP much faster than the traditional software industry would have considered normal.
That's one reason we've become interested in shorter, more focused engineering engagements like our AI Systems Sprint.
If a meaningful workflow really can be shipped in two weeks, I don't think a client should be charged for three months simply because that used to be the expected timeline.
Production debugging is where the illusion starts breaking
The place where my view changed most was existing production software.
We've worked around a healthcare system involving video consultations, transcription, AI processing, patient records and several external services.
From the outside, a problem can look incredibly simple:
“The AI feature stopped working.”
But that sentence can represent ten completely different failures.
Maybe an API rate limit was hit.
Maybe a background job failed.
Maybe a retry mechanism created unexpected behaviour.
Maybe an external service delivered something late.
Maybe the application couldn't match incoming data correctly.
Maybe credentials were used somewhere else.
Maybe a more expensive model was selected outside the application.
Maybe the database says the job completed when another system never received the result.
At one stage there were failures around long transcription workloads.
Fixing that properly wasn't just:
Ask Cursor to fix the OpenAI call.
The system needed better retries, recovery tools and a queue so large jobs could wait and process safely instead of disappearing when several operations competed for the same limits.
Later there was a separate investigation into unexpected AI spending.
Again, the obvious assumption was:
the recent code change must have caused the cost increase.
That is a reasonable assumption from a customer's perspective.
But debugging means proving or disproving assumptions.
You have to compare application activity with provider usage.
Check which models were called.
Inspect logs.
Look at retries.
Look at the database.
Look at external account activity.
Rotate keys if necessary.
Add limits.
And sometimes the answer is somewhere outside the code you were originally asked to fix.
AI can help you investigate all of that.
But it cannot magically know information that isn't inside the context you gave it.
This is what I think clients misunderstand about development
When a client sees a senior engineer use Cursor or Claude, it is easy to think:
“The AI wrote half of that. Why am I paying senior-engineer rates?”
I understand that thought because I had essentially the same one.
But I now think the better question is:
What am I actually paying this engineer to take responsibility for?
If all you need is a prototype that needs to look correct for a presentation next week, the answer may genuinely be: not very much.
AI has made that type of software incredibly accessible.
But if you're accepting payments, storing customer data, integrating several external systems or building something that another developer needs to maintain a year from now, the answer changes.
The code is only one part of the deliverable.
You're buying decisions.
You're buying somebody deciding which AI suggestion is wrong.
You're buying somebody understanding why a shortcut is safe in one place and dangerous in another.
You're buying somebody who knows when the architecture is becoming unnecessarily complicated.
And eventually you're buying somebody who will answer the message:
“Production is broken. Can you find out why?”
So has AI actually made software development cheaper?
I think the answer is clearly yes.
Pretending otherwise doesn't make sense.
An experienced engineer can produce more software today than the same engineer could produce several years ago.
A small team can tackle a scope that previously might have required many more people.
Clients should benefit from that.
Development timelines should become shorter.
Prototyping should become cheaper.
Focused MVPs should become easier to justify.
And software companies probably do need to rethink pricing models built entirely around the number of hours somebody spends typing.
But I've stopped believing software prices should collapse at the same rate as the cost of generating code.
Because the bottleneck is moving.
It used to be:
How quickly can we build this?
Increasingly it is:
Are we building the right thing?
Does it actually work when the happy path ends?
Can somebody understand it six months from now?
Who owns the problem when production behaves differently from the demo?
AI made code cheaper.
It made good engineers faster.
What it hasn't made cheap is judgement, ownership and experience.
And unfortunately, those are usually the things you realize you were paying for only after something goes wrong.
