Pricing custom software: market rates and fair estimates

By Marco Lopes · August 23, 2023 · Business & Culture

“How much will it cost?” is usually one of the first questions we hear about custom software. It is also one of the hardest to answer responsibly before we understand what needs to be built.

At Kordspace, we work as a remote collaborative studio across software, AI, Web3, hardware, and design. That breadth makes one thing clear: a website, an internal workflow tool, and a connected device may all involve code, but they carry very different costs and risks.

We believe a fair estimate should make those differences visible. It should explain what we know, what we are assuming, and what could change, not disguise uncertainty behind a precise-looking number.

What market rates can, and cannot, tell us

An hourly rate is useful context, but it is not a price for an outcome. Before comparing rates, we need to know whether they cover an individual contributor, a coordinated delivery team, or a specialist responsible for a particularly demanding problem.

For early budgeting in 2023, we can use broad, indicative bands such as these, expressed in US dollars:

| Type of engagement | Illustrative hourly planning range | | --- | --- | | Independent generalist or lower-overhead provider | $50–$90 | | Senior specialist or small multidisciplinary studio | $90–$150 | | High-overhead agency or scarce technical specialization | $150–$225+ |

These are planning references, not a verified market survey, a geographic ranking, or Kordspace’s published rate card. Actual quotes can fall outside them. Location, experience, availability, contract length, and responsibility all affect pricing.

We also distinguish a person’s rate from a blended team rate. The latter may combine design, engineering, testing, and delivery coordination. A higher blended rate can represent more complete coverage rather than more expensive coding.

Our practical rule is simple: compare equivalent responsibilities and deliverables before comparing the numbers.

Why the lowest rate may not produce the lowest bill

Suppose one proposal offers 600 hours at $70 per hour and another offers 400 hours at $110. The totals are $42,000 and $44,000. The rate difference looks dramatic; the project-price difference does not.

Neither proposal is automatically better. We would ask why the effort estimates differ. Does one assume an existing authentication service? Does the other include custom account management? Are accessibility checks, deployment, and automated tests included in both?

A low quote may be entirely legitimate. A provider might have relevant reusable components, lower overhead, or unusually strong domain experience. Equally, a low quote may omit essential work that returns later as change requests.

We look for evidence: a clear approach, explicit exclusions, relevant technical experience, and a credible plan for handover. We avoid treating either expensive or inexpensive as a substitute for suitable.

Define the business boundary before the feature list

Before estimating screens and endpoints, we want to understand the business outcome. Are we reducing repetitive administration, enabling a new sales channel, validating a product idea, or connecting physical equipment to a digital service?

That answer helps us decide what not to build.

For an internal approval tool, the first release might need secure access, a request form, an approval workflow, and an audit trail. It may not need a mobile app, a configurable workflow builder, or real-time analytics.

We then describe the intended users, the main tasks, the systems involved, and the conditions for acceptance. “Integrates with our inventory system” is not enough. We need to establish which records move, in which direction, how frequently, and what happens when synchronization fails.

A useful scope document does not need to be enormous. It needs to remove the ambiguities most likely to change the budget.

Pay for discovery when uncertainty is material

Sometimes we can estimate a small, familiar task after a focused conversation. Sometimes we cannot responsibly price delivery until we investigate.

Discovery may include stakeholder workshops, workflow mapping, interface sketches, a review of existing code, or a technical spike against an unfamiliar API. For hardware, it may involve testing a component or communication protocol. For AI, it may involve evaluating whether available data supports the intended task.

We prefer discovery to produce useful artifacts: a prioritized scope, architecture options, a risk register, and an updated estimate. It should not be a vague fee for “thinking.”

We also keep it proportionate. A modest website does not need the same research process as a regulated platform. When the uncertainty is concentrated in one integration, we investigate that integration rather than expanding discovery indefinitely.

Build the estimate from visible work

Our estimates become more useful when we separate delivery into understandable workstreams. Here is a hypothetical example for a deliberately limited internal web application:

| Workstream | Estimated hours | | --- | ---: | | Discovery and requirements | 40 | | UX and interface design | 64 | | Application development | 176 | | Integration and data handling | 72 | | Testing and release preparation | 56 | | Delivery coordination and documentation | 32 | | Total | 440 |

At an illustrative blended rate of $110 per hour, the base estimate is $48,400. A separately identified 15% contingency would add $7,260, creating a planning budget of $55,660 before taxes, hosting, licenses, and other external expenses.

These figures demonstrate the method; they are not a quote or a claim about a typical project. We would attach assumptions about features, integrations, data quality, review cycles, and client availability.

We would also explain how contingency works. Under time-and-materials billing, an unused budget allowance should not become an automatic charge. Under fixed-price delivery, risk may instead be included in the agreed price. Mixing those models creates confusion.

Choose a commercial model that fits the uncertainty

We generally discuss three approaches rather than assuming every project belongs in the same contract structure.

Fixed price works best when scope and acceptance criteria are stable. It gives budget clarity, but changes need an agreed process. We expect a provider to price the risk they are accepting; certainty is not free.

Time and materials suits evolving products and investigative work. We pair it with frequent demonstrations, transparent time reporting, and regular forecasts. A spending cap can create a useful control point, but it does not guarantee every desired feature will fit beneath it.

A staged engagement separates discovery, initial delivery, and later improvements. We can price each stage according to what we know at that point, with explicit decisions between them.

For many new products, we favor small commitments followed by evidence. That lets us adjust priorities before a large share of the budget is committed.

Price AI, Web3, and hardware risks explicitly

Some projects contain uncertainty that ordinary feature lists do not capture.

For AI, we budget for data preparation, evaluation, model or API costs, latency testing, and appropriate human review. As of August 2023, generative AI can accelerate useful workflows, but a convincing demonstration is not proof of reliable production behavior. We need task-specific evaluation and a plan for handling unsuitable outputs.

For Web3, we separate application development from smart contract work, transaction costs, wallet integration, and security review. An independent audit may require its own budget and schedule. We do not treat an audit as a guarantee, or token-related assumptions as dependable project financing.

For hardware, we account for prototypes, components, firmware, testing equipment, enclosure iterations, and relevant certification requirements. Supplier lead times and physical revisions can affect the schedule even when software work is progressing.

Across these areas, we prefer a bounded experiment to an unsupported promise.

Include cloud operations and ownership costs

The launch invoice is only part of the investment. We also need to budget for operating and maintaining the result.

Google Cloud is our preferred starting point where it fits the project. We also work with AWS and Azure, particularly when an organization already has infrastructure, expertise, or contractual requirements there. We do not recommend migration simply to match our preference.

Cloud estimates should identify assumptions about traffic, storage, data transfer, database capacity, backups, and environments. Managed services can reduce operational work, but their usage-based charges still need attention. We recommend budget alerts and ownership of monitoring responsibilities from the start; alerts alone do not necessarily stop spending.

We also clarify who owns the cloud accounts, repositories, domains, and third-party subscriptions. Clear client ownership and documented access make future maintenance easier, whether we continue together or another team takes over.

Make remote collaboration part of the delivery plan

Remote work does not remove coordination costs. It changes how we manage them.

We rely on written decisions, shared project visibility, focused calls, and regular demonstrations. Those practices help distributed teams collaborate, but they take time and belong in the estimate.

We ask clients to nominate a decision-maker and agree on review windows. Delayed feedback, conflicting instructions, or unavailable test data can interrupt delivery. Rather than blaming either side later, we document these dependencies early.

We also make clear which decisions require a meeting and which can happen asynchronously. Good collaboration protects the budget by reducing avoidable rework, not by pretending communication is free.

Use a short proposal checklist

Before approving a custom software estimate, we recommend checking the following:

• Outcome: Does the proposal identify the business problem and the first useful release?
• Scope: Are deliverables, acceptance criteria, assumptions, and exclusions explicit?
• Budget: Are rates, effort, contingency, external expenses, and payment terms understandable?
• Risk: Are uncertain integrations, data issues, security needs, and client dependencies identified?
• Control: Is there a clear process for reporting progress and approving changes?
• Ownership: Are intellectual property, account access, documentation, and handover addressed?
• Aftercare: Are support, defect correction, maintenance, and operating costs distinguished?

If an answer is unclear, we ask before signing. A good proposal should support a productive conversation, not require guesswork.

A fair estimate is a shared working agreement

We see fair pricing as a balance: enough budget to deliver responsibly, enough transparency to make informed decisions, and enough flexibility to respond when reality differs from assumptions.

The strongest estimate is not necessarily the smallest or the most detailed. It is the one that connects money to a credible delivery plan and makes trade-offs visible. When budgets are constrained, we would rather reduce scope deliberately than quietly remove testing, documentation, or essential security work.

If we can help turn an idea into a realistic plan, we invite you to start a project. To explore how our software, AI, Web3, hardware, and design capabilities might fit your needs, read our related services pages.