Why don't you publish prices?

Because the price depends on scope, integrations, and existing data, and a range without seeing your case would be made up. What is fixed: the pilot has a closed price, in writing, before we start.

Do you bill hourly or per project?

The pilot is fixed-price. Production is quoted in writing with defined scope. Ongoing support, if you want it, is agreed separately.

What about the cloud bill?

It's a recurring cost you pay in your own AWS account. It's estimated before the project with the public AWS calculator and reviewed monthly with budget alerts.

How much does it cost to maintain custom software?

It depends on how much the process changes and how many integrations it has. What can be said: a system with automated tests, infrastructure as code, and monitoring costs less to maintain than one without them, because every change is cheaper and every failure is caught earlier.

How much does custom software cost?

Ink drawing of a level balance scale with a paper circle on one pan and three blocks on the other.

Short answer: custom software doesn't have a fixed price; it has a range that depends on what you're buying. A one-off automation, an internal application with users and a database, and a system that runs an entire process and integrates with your ERP are three different projects with three different cost logics. What separates them isn't vendor whim: it's concrete factors (scope, integrations, users, data, operations, and who builds it) that you can identify before asking for a quote.

This guide doesn't publish ranges, because a range without seeing your process would be made up. What it does is explain what moves the price, which costs almost nobody puts on the table, and how to compare proposals without being technical.

What kind of project are you buying?

Before getting quotes, place your project in one of these three categories. Each solves a different problem:

Type	What it is	Examples
One-off tool	Solves a specific task, with few users and almost no screens	An integration between two systems, a report that generates itself, a form that feeds the ERP
Internal application	A system with users, permissions, and its own database, for one department	Shop-floor data capture, request tracking, a dashboard with live data
System that runs a full process	Multiple roles, ERP or CRM integrations, your own business rules, and continuous operation	A customer portal with a quoting tool, an order system connected to inventory and invoicing

The first is quoted per task. The second and third are quoted as software projects, with scope, architecture, and maintenance.

Which six factors move the price?

Within each category, the price moves along six factors you can spot in any quote:

Scope: how many processes and screens. A system covering one process with three screens doesn't cost the same as one covering five processes with different roles. Written scope is the first line of any serious quote.
Integrations. A standalone form is a minor task; a quoting tool connected to the ERP, the CRM, and WhatsApp is a separate build per connection, and each one has to be tested.
Users, permissions, and security. Login, roles, an audit trail of who did what, personal data protection. More people and more sensitive data mean more invisible work.
Existing data. Migrating and cleaning what currently lives in spreadsheets or a previous system usually costs more than expected and almost never shows up in the first quote.
Operations: cloud, monitoring, and maintenance. Who keeps it running, applies patches, responds when it fails, and pays the AWS bill every month. Included or not, it changes the total cost.
Who builds it: freelancer, agency, or consultancy. Each has a different cost structure, and none is automatically right: it depends on complexity and on how critical the system is to your operation.

Which costs does almost nobody quote?

Before comparing the final price, check what's left out:

The monthly cloud bill. The software runs somewhere; that recurring cost continues after the project is delivered and invoiced. It can be estimated beforehand with the public AWS Pricing Calculator (https://calculator.aws/).
Maintenance and security. Dependency updates, patches, and monitoring aren't optional if the system is going to stay in operation.
Training and adoption. A system the team doesn't use isn't worth what it cost. Someone has to train, document, and support the first few weeks.
The cost of rebuilding it. A weak technical foundation, with no tests, no documentation, and no room to grow, ends up forcing a full rebuild sooner than planned. That second project costs more than investing properly the first time.

How do you compare quotes without being technical?

Get the scope in writing before signing: which processes, which screens, which integrations, and what's out of scope. Verbal scope is the most common source of rework and overruns.
Confirm that the code, the cloud account, and the credentials stay under your company's name, not the vendor's. If the project ends or you switch vendors, you need to be able to move without depending on anyone.
Ask what's included and what isn't: cloud, maintenance, post-delivery support, training. If it isn't written down, it's usually not included.
Demand measurable success criteria, not just screens that look good: process time before and after, data-entry errors, hours freed up. A system that works but didn't move the metric didn't do its job.
Ask how it's tested. Automated tests, code review, repeatable deployment. Without those, future maintenance cost is a guess.

When is it worth investing more, and when isn't it?

If what you need is to be found and contacted, paying for custom software makes no sense: a well-built informational website covers it. If the problem is data discipline or an ERP module already solves it, same answer; we explain that in Custom software or keep stretching the ERP?.

The larger investment is justified when the system is a business tool: it runs a process that's done by hand today, joins data that's re-entered today, or serves customers who wait for a phone call today. In those cases the cost is compared against the cost of staying as you are, measured in hours and errors, not against zero.

So how much?

At ozeida we don't publish generic ranges because they wouldn't be real. What we do:

A free first call to understand the process, tell you which category it falls into, and whether it's worth doing.
A fixed-price pilot, set in writing after that call, with bounded scope, one metric, and a cutoff date.
If the pilot meets the metric, a written quote for production with the same team. If it doesn't, we say so and stop.

Code, infrastructure, and documentation belong to your company from day one. That's how we work in custom software. Our business hours overlap US Central and Eastern time, and we work in English.