Aizaz
I used to think software pricing was simple
When I first started helping Ali sell software, I had a very sophisticated pricing model.
Client tells us what they want.
Ali tells me how long it will take.
I try to sell it cheaper.
Ali gets annoyed.
That was basically the system.
I was completely new to selling software internationally, so in my head the equation seemed obvious:
If something takes less time to build, it should cost less.
Then I started seeing projects that completely broke that logic.
One MVP could be delivered for $800 in two weeks.
Another product could have a similar-looking dashboard and easily turn into a $5,000, $20,000 or much larger system.
Same engineers.
Same laptops.
Same AI tools.
So what exactly was I charging the client for?
That question has probably taught me more about software pricing than any rate calculator ever could.
Two products can look similar and be completely different underneath
One of our earlier projects was SalesAngel.
It was already an ambitious product: a multi-user, multi-tenant CRM and dialer for sales teams.
On the surface, that can still look pretty normal.
Contacts.
Dashboard.
Calls.
Users.
Reports.
But the moment you start asking what has to happen underneath those screens, things change quickly.
If multiple companies use the same product, who owns each record?
Can one company ever access another company’s data?
Who can make calls?
Who pays for those calls?
What happens when the calling provider fails?
Where do AI-generated transcripts or scores belong?
What happens when billing changes what a user is allowed to access?
None of those questions necessarily make the interface look more impressive.
They make the system more responsible.
That was one of the first things I misunderstood as someone sitting on the commercial side.
I would hear:
“Add this feature.”
And think:
Okay. Another feature.
Ali would hear the same sentence and start thinking about databases, permissions, external services, failures and whether the decision changes something we already built.
That is when I started understanding that complexity is not measured in screens.
Then we got a completely different kind of project
PropertyMatch was almost the opposite experience.
The client already ran a real-estate business.
He already had a workflow.
He already knew what problem he wanted to solve.
His team was using an Airtable-based process to manage buyers, agents and property opportunities, and he wanted a simpler SaaS product around that workflow.
There was much less guessing.
The first version needed things like:
- agent accounts
- buyer information
- property records and search
- matching buyers with opportunities
- communication inside the workflow
You could explain the important part of the product in a few steps:
Enter the information.
Find the match.
Contact the right person.
Use the product.
That clarity changed everything.
We delivered that MVP in 14 days
PropertyMatch was an $800 fixed-price project.
Would I ideally sell that same level of engineering for $800 today?
Probably not.
We were still building our profiles, the client had his own budget, and we agreed to it.
But the project taught me something much more valuable than the price itself.
A clearly scoped product can move really fast.
We used Next.js for the application, Supabase for the managed data platform, Vercel for deployment, Resend for email and Mapbox for maps.
We did not need to build our own email infrastructure.
We did not need to build mapping technology.
We did not need to invent a complicated deployment platform.
Those services already existed.
The engineering work could stay focused on the actual business problem.
And the MVP was hosted and delivered in 14 days.
That experience changed the way I think about the phrase:
“custom software.”
Custom does not mean rebuilding everything yourself.
Sometimes the smartest engineering decision is knowing what not to build.
So why can one MVP cost $800 and another cost $20,000?
At first I thought the answer would be development time.
It is part of it.
But now I think there are a few bigger factors.
The first is responsibility
A small internal tool used by five people carries a different level of responsibility from a SaaS platform serving hundreds of businesses.
More users usually means more permissions.
More data.
More failure cases.
More infrastructure.
More things that cannot casually break.
The code might not be twenty times harder to type.
The system can still carry twenty times more responsibility.
The second is architecture
A product with one user type and one workflow is very different from a system with organizations, administrators, employees, customers, billing, AI processing and external APIs.
The more parts that need to communicate correctly, the more decisions have to be made before and during implementation.
And bad decisions get expensive later.
The third is infrastructure
More users means more storage.
More data means more processing.
AI features introduce model usage.
Calling introduces telephony costs.
Payments introduce another provider.
ERP and CRM integrations introduce external systems that your product now depends on.
At some point the question stops being:
“Can we build this?”
and becomes:
“Can this keep working reliably when a real business depends on it?”
The fourth is uncertainty
This might be the one I underestimated the most.
Products are allowed to evolve.
That is normal.
But there is a big difference between:
“Let’s put this in version two.”
and:
“While you’re building version one, let’s change what version one actually is.”
If the destination keeps moving, estimates become harder because architectural decisions already made for the original product may have to change.
That costs time even when AI makes writing the replacement code much faster.
AI made this even more interesting
I have already written about whether AI is making software development cheaper, because I genuinely struggled with this.
If AI can generate huge amounts of code quickly, why should software still cost thousands of dollars?
I used to argue about this with Ali.
From my side, I wanted clients.
From his side, I was trying to sell senior engineering expertise for prices he considered ridiculous.
Over time I started understanding the difference.
AI is incredibly useful for implementation.
But a client is not really paying for somebody to press generate until an application appears.
Someone still has to decide:
What should we build?
Which service should we use?
How should the data be structured?
Who should have access?
What happens when something fails?
And is this thing actually ready for production?
The faster implementation becomes, the more obvious those decisions become.
This is why I no longer want to sell Aizaz as “cheap software”
Would we accept a small $500 project today?
Yes.
We are still growing.
Reviews matter.
Relationships matter.
And revenue definitely matters.
I am not going to pretend we are some enormous consulting company where the first conversation starts at $50,000.
But there is a difference between accepting a small project and building your entire positioning around being cheap.
A very small validation project might make sense around $500–$1,000.
For a properly scoped MVP with senior engineering involvement, I increasingly see $1,500+ as a healthier starting point.
Then $5,000, $20,000 and beyond can make complete sense depending on the system.
The price should follow the responsibility.
Not the number of buttons.
The question I learned to ask
I used to think one of the first questions should be:
“What features do you need?”
Now I care much more about:
“What does done look like?”
Can the client describe the moment where we can sit together and say:
Yes.
This version does what we agreed it would do.
PropertyMatch had that.
That is one of the reasons it could move quickly.
When that boundary is unclear, pricing gets much harder because nobody is completely sure what they are pricing.
That is why our approach is increasingly becoming:
Scope first. Price second.
Can every MVP be delivered in 14 days?
No.
We have delivered one in 14 days.
That does not mean every product someone calls an MVP belongs inside a two-week deadline.
A 14-day MVP makes sense when there is:
- a clear business problem
- a defined workflow
- known users and roles
- limited integrations
- access to the data and services required
- an agreed definition of completion
If we are still deciding what the product actually is, development is not really the bottleneck yet.
The deadline has to follow the scope.
Not the other way around.
I’m still learning how to price this stuff
I am not writing this after closing a hundred enterprise contracts.
I am writing it as a first-time co-founder who is still learning the commercial side of software.
I have underpriced work.
I have looked at projects and wondered why an engineer thought something was more complicated than it looked.
I have watched one client give us a clear workflow and make delivery surprisingly smooth.
And I have slowly learned that when you buy software engineering, you are not just buying code.
You are buying decisions.
Responsibility.
Architecture.
Experience.
And hopefully a team that knows when not to overcomplicate your product.
So when someone asks me now:
“How much would my MVP cost?”
I do not really want to start with a number.
I want to start with:
“Show me what you are trying to build, how your business works today, and what version one actually needs to prove.”
Once we know that, the price becomes a lot easier to explain.