How to Review a Software Development Proposal Before You Spend $100,000

How to Review a Software Development Proposal Before Cost Becomes Commitment

Knowing how to review a software development proposal before you commit $100,000 or more can prevent an expensive business problem from being locked into a contract. A proposal can look polished, include impressive technology names and still leave critical questions unanswered about what will actually be delivered.

The answer is not simply to find the cheapest quote. You need to understand the scope, assumptions, delivery approach, ownership, security, ongoing costs and what happens when things do not go to plan.

I have reviewed software projects from both sides of the table, as a developer, technology leader, CTO and independent adviser. One lesson keeps coming back. The quality of the decision you make before development starts often has more impact than what happens once the developers begin writing code.

Takeaways

A Good Proposal Should Help You Make a Business Decision

A software proposal is not just a sales document.

It should give you enough information to decide whether the proposed project is commercially sensible, technically credible and achievable within the budget and timeframe being discussed.

That means answering basic questions such as:

• What business problem are we solving?
• What exactly are we buying?
• What is not included?
• How much will it cost?
• What could cause that price to change?
• How long will delivery take?
• Who is responsible for what?
• How will we know that each stage is finished?
• Who owns the software and data?
• What happens after launch?
• What happens if the supplier relationship fails?

If a $100,000 proposal cannot answer these questions clearly, more detail about programming languages or cloud platforms will not fix the problem.

Technology should support the people and the business. That is why I put people before technology when reviewing proposals. I want to understand how the proposed system helps customers, staff and the business before getting excited about the architecture.

Start With the Business Problem, Not the Proposed Technology

Before examining features, architecture or development methodology, go back to the reason the project exists.

Ask:

What business outcome are we paying for?

Perhaps you want to:

• replace a spreadsheet-heavy process
• reduce manual administration
• create a customer portal
• replace ageing software
• launch a new digital product
• integrate disconnected business systems
• improve reporting
• automate repetitive work
• support business growth

The proposal should connect the software being built with those outcomes.

If the proposal jumps immediately into React, APIs, cloud hosting, artificial intelligence or mobile apps without explaining the business problem, I would want to know why.

Technology choices matter. They just come later.

This is also where Technology Strategy becomes relevant. A technically good project can still be the wrong investment if it does not support the wider business direction.

Check Whether the Scope Is Actually Clear

The word scope gets used constantly in software projects, but it is often misunderstood.

Scope describes what the project is expected to deliver.

A proposal saying:

Customer portal with account management, reporting and administration functionality.

might sound reasonable.

It is nowhere near detailed enough to support a six-figure decision.

What does account management mean?

Can customers create accounts themselves? Can administrators create them? Is multifactor authentication required? Can users belong to multiple organisations? Who can reset passwords? What happens when an employee leaves a customer organisation?

Each answer creates work.

The proposal does not need hundreds of pages of specifications before anything starts. In fact, excessive detail can create a different problem by pretending everything is already known.

But there needs to be enough definition to understand the size and boundaries of the project.

Look for:

• major features
• user groups and roles
• key workflows
• integrations
• reporting requirements
• data migration
• administration requirements
• security requirements
• devices or browsers supported
• accessibility requirements
• regulatory requirements
• exclusions

Pay particular attention to exclusions.

Sometimes the most important sentence in a proposal is not what the supplier promises to do. It is what they specifically say they will not do.

Look for Assumptions Hidden Behind the Price

Every software estimate contains assumptions.

The problem comes when those assumptions exist only inside the supplier’s head.

Imagine a proposal assumes:

• your existing data is clean
• an external system has a suitable API
• your employees will provide requirements quickly
• you will supply all written content
• no historical information needs migrating
• only one level of approval is required

If one of those assumptions turns out to be wrong, the scope, price or schedule may change.

A strong proposal makes material assumptions visible.

You should be able to identify what the supplier expects from your business and what they have assumed when estimating the work.

Ask the supplier:

“What assumptions did you make when calculating this price?“

The answer can be remarkably revealing.

Compare Deliverables, Not Just Prices

Suppose you receive three proposals:

Supplier	Quoted Price	Initial Impression
Supplier A	$78,000	Cheapest
Supplier B	$104,000	Middle
Supplier C	$138,000	Most expensive

Supplier A initially looks attractive.

But perhaps Supplier A excludes data migration, automated testing, training and post-launch support.

Supplier B includes all four.

Supplier C includes those services plus a larger discovery phase and twelve months of support.

You are not comparing three prices for the same thing.

You are comparing three different projects.

Before comparing the numbers, normalise the proposals. Create a list of expected deliverables and mark whether each supplier includes, excludes or has not mentioned them.

Only then does the pricing comparison begin to mean something.

This kind of comparison is part of what I look at during a Technology Investment Readiness Review. The purpose is not to tell a business which supplier has the prettiest proposal. It is to understand whether the proposed investment makes sense before significant money is committed.

Understand How the Estimate Was Created

A software estimate is not a promise that somebody has discovered exactly how long the future will take.

Software development contains uncertainty.

The important question is how that uncertainty has been handled.

Find out whether the quote is:

• fixed price
• time and materials
• capped time and materials
• milestone based
• monthly development capacity
• an indicative estimate pending discovery

None of these approaches is automatically good or bad.

They allocate risk differently.

A fixed-price quote can provide budget certainty, but only if the scope is sufficiently understood. Otherwise, disputes can develop over whether something is included.

Time and materials provides flexibility, but the client carries more cost risk.

A discovery stage followed by a revised estimate can be sensible where requirements are still uncertain.

What worries me is false certainty.

If somebody claims they know exactly what a complex six-month software project will cost despite having spent two hours understanding the business, I would ask some fairly direct questions.

Review the Milestones and Payment Schedule

Never look at the final delivery date alone.

Look at how value is delivered along the way.

A project might have milestones such as:

1. Discovery completed
2. User experience and architecture agreed
3. First working release
4. Core workflows completed
5. Integrations completed
6. User acceptance testing
7. Production release
8. Support transition

The exact structure depends on the project.

What matters is that you can see progress.

I prefer working software and observable outcomes over lengthy status reports saying everything is “90% complete“.

That thinking reflects the principles behind the Agile Manifesto, which places working software and collaboration ahead of heavy processes and documentation.

If you are paying large instalments, each payment should correspond to something meaningful.

Be cautious if most of the money is due before you have seen working software.

Make Acceptance Criteria Part of the Proposal

One question I like to ask is:

How will both parties know that this has been successfully delivered?

That leads to acceptance criteria.

Acceptance criteria describe the conditions that must be met before a feature, milestone or project is considered complete.

For example, “build customer reporting” is vague.

A stronger definition might specify that authorised customers can:

• view reports for their own organisation
• filter results by an agreed date range
• export information in an agreed format
• see data refreshed within a defined period
• access reports only according to their user permissions

Acceptance criteria reduce arguments about what “finished” means.

They also help developers because expectations are clearer.

Understand the Change Control Process

Change is normal.

Poorly controlled change is expensive.

During development you will discover things that nobody understood at the start. Customers provide feedback. Business priorities change. Integration constraints appear.

The proposal should explain what happens next.

A sensible change process normally answers:

1. How is a change requested?
2. Who assesses its impact?
3. How are additional cost and time calculated?
4. Who approves it?
5. How is the project plan updated?

Without this process, seemingly harmless requests can quietly increase the project.

“Could we just add one more field?” has probably been responsible for more software project conversations than anyone cares to count.

The field is rarely the problem.

It is everything that field touches.

For complex or troubled projects, independent Project Delivery oversight can also help keep scope, decisions, risks and responsibilities visible.

Look Beyond the Build Price

A $100,000 application does not necessarily cost $100,000.

Ask about the total cost of ownership.

That can include:

• cloud hosting
• licences
• third-party APIs
• SMS or email services
• payment transaction fees
• monitoring
• backups
• security services
• domains and certificates
• ongoing development
• technical support
• application maintenance
• operating system or framework upgrades
• external integrations
• app store costs

Some costs increase as usage grows.

That is not necessarily a problem, but you need to know.

I would rather tell a client before approval that an application could cost $3,000 a month to operate than have them discover it six months after launch.

Review Ownership and Intellectual Property

This part can become uncomfortable if it is left until the relationship goes wrong.

Clarify who owns:

• source code
• custom designs
• documentation
• database structures
• infrastructure configuration
• automated deployment scripts
• domains
• cloud accounts
• third-party accounts
• intellectual property developed specifically for the project

Also identify which components rely on third-party or open-source licences.

Your organisation should know where the source code is stored and what happens to it if the supplier disappears.

You should also understand whether another competent development team could reasonably take over the system.

Being permanently dependent on one supplier or developer can turn a successful software launch into a long-term business risk.

Check Access to Accounts From the Beginning

I regularly see organisations discover that important technology assets are controlled entirely by their supplier.

That might include:

• source code repositories
• AWS, Azure or Google Cloud accounts
• domain registrations
• analytics
• app store accounts
• databases
• email delivery services
• monitoring platforms

Your supplier may administer these systems.

That is different from owning them.

For important systems, the business should generally have appropriate administrative access or a documented mechanism for obtaining it.

This matters especially if the relationship ends unexpectedly.

Security Cannot Be a Line Added Near the End

Security should be considered before development begins.

Australia’s current Guidelines for Software Development cover areas including documented security requirements, secure development practices, threat modelling, logging and software supply-chain controls.

The Australian Government’s procurement and outsourcing guidance also emphasises supplier security, transparency and clearly documented responsibilities between customers and suppliers.

You do not need to turn every commercial software proposal into a government security assessment.

You do need answers appropriate to your risk.

Ask about:

• authentication
• user permissions
• encryption
• logging
• backup and recovery
• software vulnerabilities
• dependency management
• data location
• privacy
• security testing
• incident response
• who has access to production information

A healthcare organisation holding sensitive patient information will have different requirements from a small public marketing website.

Context matters.

Ask What Testing Is Included

“Testing included” is not enough.

Ask what type.

Testing might cover:

• developer testing
• automated tests
• integration testing
• browser testing
• mobile device testing
• performance testing
• security testing
• user acceptance testing
• regression testing

Also ask who performs the testing.

If the same developer who wrote the feature clicks through it once and declares it finished, that is a very different level of assurance from a defined quality process.

Testing should match the commercial and operational risk of the application.

Know What Happens After Launch

Launching software is the beginning of its operational life.

It is not the point where technology magically stops requiring attention.

Your proposal should explain the transition into support.

Ask:

• Is there a warranty period?
• How are defects handled?
• What qualifies as a defect rather than a change?
• Who responds if the application stops working?
• What are the support hours?
• Are response times defined?
• Who monitors the system?
• Who applies security updates?
• What happens when third-party services change?
• What does ongoing support cost?

I have seen businesses spend heavily building an application and only start asking who will support it during the week before launch.

That is rather late.

Check Whether the Supplier Can Actually Deliver

A polished sales presentation is not evidence of delivery capability.

Look behind it.

Ask who will actually work on the project.

Find out:

• Who is the technical lead?
• Who manages delivery?
• Are developers employees or subcontractors?
• Where is the team located?
• How much capacity is allocated?
• What happens if a key developer leaves?
• Has the team delivered comparable systems?
• Can the supplier provide relevant references?
• Who makes architecture decisions?
• Who communicates with your organisation?

This is especially important if the supplier depends heavily on one technical person.

A good salesperson and a good development team are not automatically the same thing.

Use a Simple Proposal Evaluation Scorecard

You do not need a 47-tab spreadsheet.

A simple scorecard can make the decision much clearer.

Area	Suggested Weight	Questions to Consider
Business fit	15%	Does this solve the right problem?
Scope clarity	15%	Is it clear what is included and excluded?
Delivery approach	15%	Are milestones and responsibilities credible?
Technical approach	10%	Is the proposed approach appropriate and maintainable?
Supplier capability	15%	Can this team realistically deliver it?
Security and risk	10%	Are security, privacy and resilience addressed?
Commercial model	10%	Are price, assumptions and change costs clear?
Support and ownership	10%	What happens after launch or if the supplier relationship ends?

Do not treat the resulting number as scientific truth.

Its value is in forcing the leadership team to discuss the decision from multiple angles rather than saying:

“Supplier B seemed impressive, and their demo looked good.“

Red Flags in a Software Development Proposal

Some warning signs deserve a closer look.

The proposal is mostly about technology

Technology matters, but the proposal should demonstrate understanding of your business problem.

The scope uses vague language

Words such as “dashboard“, “automation“, “AI integration” and “customer management” can conceal a remarkable amount of work.

Almost everything is described as included

Real projects have boundaries.

A supplier that identifies no exclusions may not have explored those boundaries properly.

The estimate contains no assumptions

There are always assumptions.

If you cannot see them, you cannot assess them.

There is one large final delivery

You should normally have opportunities to review working software during development.

Change control is missing

This can become the source of expensive disagreement later.

The supplier owns or controls everything

Your ability to change supplier should not depend on somebody else’s goodwill.

Support is an afterthought

Software needs operating, monitoring and maintaining after launch.

There is no clear customer responsibility

Your organisation has work to do as well. Decisions, feedback, subject matter expertise, testing and access to people all affect delivery.

When an Independent Review Makes Sense

If the proposed investment is small and low risk, you may be comfortable reviewing it internally.

As the cost and business impact increase, independent review becomes easier to justify.

Consider getting another opinion when:

• the investment is substantial
• the software is critical to business operations
• management does not have senior technical expertise internally
• you are comparing competing suppliers
• the proposal contains technical language nobody internally can challenge
• requirements are still unclear
• there is disagreement about the proposed approach
• the project will handle sensitive information
• replacing the system later would be difficult
• the organisation will become dependent on the supplier

Independent review is not about trying to catch a development company doing something wrong.

A good supplier should welcome sensible questions.

The purpose is to identify assumptions, gaps and risks while they are still cheap to fix.

For larger or strategically important technology investments, a Technology Due Diligence review can examine the commercial and technical risks in more depth.

If the organisation needs ongoing senior technology guidance rather than a one-off review, Fractional CTO support can provide that leadership without requiring a full-time CTO.

Questions to Ask Before Signing

Before approving the proposal, I would want clear answers to these questions:

1. What business outcome are we buying?
2. What exactly is included?
3. What is specifically excluded?
4. What assumptions underpin the price?
5. What could cause the price to increase?
6. How will scope changes be handled?
7. What will we see during development?
8. How will each milestone be accepted?
9. Who is actually doing the work?
10. What happens if a key developer leaves?
11. Who owns the source code and intellectual property?
12. Which accounts will our business control?
13. What security requirements have been considered?
14. What testing is included?
15. What happens after launch?
16. What ongoing costs should we expect?
17. How could another supplier take over?
18. What happens if the project stops halfway through?

If those questions produce vague answers, do not be frightened to slow the decision down.

A week spent getting clarity before signing can be far less painful than six months arguing about what everybody thought the contract meant.

Frequently Asked Questions

What should a software development proposal include?

A strong proposal should explain the business objective, scope, exclusions, assumptions, deliverables, milestones, responsibilities, pricing model, change process, testing, security, ownership and post-launch support. The level of detail should reflect the size and risk of the investment.

How do I know whether a software development quote is reasonable?

Do not assess the total price in isolation. Check what is included, how the estimate was produced, which assumptions were made and whether comparable suppliers are quoting for the same scope.

How do I compare two software development proposals?

Create a common list of requirements and assess each proposal against it. Compare business fit, scope, supplier capability, delivery approach, technical risk, security, commercial terms, ownership and ongoing support before comparing the final price.

Should I get a software development proposal independently reviewed?

For a substantial or business-critical investment, an independent review can be worthwhile, especially when your organisation does not have senior technical expertise internally. The goal is to identify unclear scope, assumptions, commercial risks and technical concerns before signing.

How detailed should a proposal be before development starts?

It needs enough detail for both parties to understand the project’s boundaries, major requirements, responsibilities, commercial model and risks. It does not need to pretend every detail of a complex software project is already known. Where uncertainty remains, the proposal should explain how that uncertainty will be resolved.

Final Thoughts

A good software proposal should make you more confident about the investment, not leave you hoping the supplier understands what you meant. Ask difficult questions while changes are still inexpensive, and remember that knowing how to review a software development proposal is as much about protecting the business and its people as it is about checking the technology.