How to Evaluate a Software Development Proposal (2026)
Costly software disappointments often trace back to the approval, not the development: a confident price, a polished deck, and a scope nobody read closely. A proposal is the one document where a vendor's assumptions, exclusions, and promises sit in plain sight, and signing it commits your budget, schedule, data, and intellectual property. This guide shows how to read a proposal like an auditor, compare offers on equal terms, and score them with a repeatable method before you commit.
TL;DR
A proposal is a set of promises and assumptions, not just a price. Judge scope clarity, exclusions, testing, ownership, and support before you look at the total.
Screen every proposal in ten minutes with pass, investigate, or reject checks, then spend deep diligence only on the ones that survive.
Normalize each offer to the same scope and compare three-year total cost of ownership, because the lowest quote often leaves out work you will pay for later.
Score with a weighted 1–5 scorecard, but apply no-go gates first: unclear ownership, missing security testing, or no exit path can disqualify a high scorer.
Move from review to signature through written clarifications, milestone-based approvals, and legal review, and consider a paid discovery phase when uncertainty is high.
Quick Answer: How do you evaluate a software development proposal?
To evaluate a software development proposal, screen it for clear outcomes, scope, exclusions, security, testing, ownership, and support. Then normalize each offer to the same scope, compare three-year total cost, score vendors with a weighted scorecard, apply disqualifying risk gates, and confirm every critical term in the contract before work begins.
Table of Contents
What a Software Development Proposal Is and Who Should Review It
A software development proposal is a vendor's written offer to deliver a defined piece of software, covering what will be built, how, by whom, when, for how much, and on what terms. It is a sales document and a planning document at once, which is why it deserves a review that goes beyond the price.
Several documents get confused. An estimate is a rough prediction of effort and can change. A quote states a price for stated work. A proposal wraps the quote in an approach, team, schedule, and assumptions. An RFP response is a proposal written against your formal request for proposals. A statement of work (SOW) is the contractual description of deliverables, milestones, and acceptance, and a contract binds both sides. Words such as “estimated,” “indicative,” or “subject to discovery” usually mark a nonbinding number, while an SOW signed under a master agreement is binding. Check which one you are holding.
A credible proposal normally contains:
Business context and measurable objectives
Scope, deliverables, assumptions, and exclusions
Technical approach and how it fits the wider software development lifecycle
Named team roles and responsibilities
Plan, milestones, and your own responsibilities
Testing and acceptance approach
Security and data-handling approach
Pricing model, payment schedule, and recurring costs
Ownership, support, and handover terms
No single reader can judge all of it. The business owner tests whether the proposal solves the stated problem, a technical reviewer tests feasibility and security, finance tests cost and payment terms, and a lawyer reviews the contract language. Tools such as proposal generation software and quote management software make every document look equally polished, so polish tells you little; content does. If you are still choosing vendors rather than reviewing a document, start with our guide on how to choose a custom software development company. This article picks up once proposals are on your desk.
The Ten-Minute Screening Checklist
Before deep diligence, run a fast screen. The goal is not to approve a proposal but to find fatal gaps early. Mark each check Pass, Investigate, or Reject. A Reject on a critical item usually means asking the vendor for a revision rather than continuing the review.
Check | Pass | Investigate | Reject |
|---|---|---|---|
Outcomes | Measurable business goals stated | Goals are generic | No link to your problem |
Scope | Features, roles, integrations listed | Vague items such as “etc.” | Scope is a slogan |
Exclusions | Explicit “not included” list | Only a few exclusions | None stated despite a low price |
Assumptions | Written and testable | Dependencies implied, not stated | Hidden client duties |
Budget | Breakdown by milestone or role | Single lump sum | Price moves without a scope change |
Timeline | Phases with dependencies | Dates without reasoning | Far shorter than peer offers |
Team | Named roles and time allocation | Roles without names | “Team to be assigned” for core roles |
Security | Controls tied to your data risk | Generic statements | Silent on security |
Testing | Test types and acceptance defined | “Testing included” only | No testing mentioned |
Ownership | Code and data rights stated | “To be agreed” | Vendor keeps all rights without explanation |
Change control | Written process and rates | Rates but no process | Open-ended changes |
Support | Warranty and support scoped | Support mentioned only | No post-launch terms |
An attractive price or a confident presentation is not evidence of quality. A low number often means the vendor read your brief narrowly or left work out. Use our web app development cost and web app development timeline guides as sanity checks on ranges, then investigate any proposal that sits far outside them.
Clarify Your Project Before You Commit An Articsledge project assessment helps discuss business goals, key workflows, integrations, and realistic next steps without assuming custom development is always appropriate. |
Check Business Objectives and Requirements First
A proposal should prove the vendor understands your business problem, not only your feature list. Look for the current workflow described accurately, the intended users named, the outcome measured, and your constraints acknowledged. If the vendor's version of your project could belong to any client, treat that as a warning.
Strong proposals state who uses the system, what those people do today, what success looks like in numbers, and what a minimum viable product (MVP) would contain if the budget shrinks. Check whether the vendor challenges features that do not serve the goal; a vendor that agrees to everything is not reducing your risk. Also confirm that more than one department's needs are reflected, since requirements from a single voice tend to return later as change requests.
A trustworthy vendor also discusses alternatives. If an existing product or a few integrations would solve the problem, the proposal should say so. Compare your options with our guides on build vs buy software and custom software vs SaaS. For a narrow need, an internal tool may be enough, and for client-facing sharing it helps to know when a portal beats a shared drive.
Illustrative example. A weak objective reads: “Build a fast, secure client portal.” A measurable version reads: “Clients can upload, review, and approve documents without email; 95% of document list pages load within two seconds for up to 200 concurrent users; each client can see only its own data; and every approval is recorded with a user and timestamp.” The second version can be tested, priced, and accepted. The first can only be argued about.
Build a Scope Crosswalk: What You Asked For vs. What Is Offered
A scope crosswalk is the most useful single document you can create during review. List every requirement from your brief, then record what the proposal actually offers, where it says so, and what is missing. It turns vague confidence into traceability: every requirement maps to a deliverable and, later, to an acceptance test. The rows below are an illustration for a client portal.
Requested | Offered | Evidence in proposal | Gap or action |
|---|---|---|---|
Client login with roles | Client, manager, admin roles | SOW section 3.2 | Confirm password reset and multi-factor scope |
Document upload and approval | Upload, approve, reject | Workflow diagram | Define file types and size limits |
CRM sync | “CRM integration” | One line, system not named | Name the CRM, fields, direction, frequency |
Historical data migration | Not mentioned | None | Ask for inclusion or a priced option |
Audit log | Basic activity log | Feature list | Confirm retention and who can view it |
Security testing | “Testing included” | General statement | Request test types and a sample report |
Read the crosswalk for two kinds of gaps. Functional requirements describe what the system does; nonfunctional requirements describe how well it does it, covering speed, availability, security, accessibility, and maintainability. Proposals tend to cover the first and skip the second, so look for the second explicitly in any web application proposal.
Integration lines deserve the most scrutiny. “Integrate with our CRM” can mean a one-time export or a continuous two-way sync through an application programming interface (API), and the cost difference is large. Our guides to CRM integration software and iPaaS platforms show when a ready-made connector could replace custom code.
Illustrative vague scope: “Includes CRM integration.” Illustrative defined scope: “One-way sync of client name, email, and account owner from the named CRM to the portal every 15 minutes through the CRM's public API; excludes custom CRM fields and write-back.”
Finally, check client responsibilities (who supplies content, test data, and access), third-party dependencies, data migration, and the change-request process. Migration is a frequent hidden cost because source records usually need cleanup first; see our explanation of data quality. Every exclusion and assumption should be written down, with an owner and a date where it affects the schedule.
Assess Architecture and Technical Feasibility
You do not need to read code to judge a technical approach. You need to ask whether the choices fit the problem and whether a second expert would agree. Request a short architecture summary covering the main components, hosting approach, data storage, integrations, and the reason behind each choice. Then look at these areas.
Fit and simplicity. A portal for a few hundred users rarely needs a sprawling design. Containers such as Docker, orchestration such as Kubernetes, or a full cloud-native architecture can be right at scale, but each adds cost and upkeep. Ask what problem each one solves for you.
Data. Ask which database is used, why, how it is backed up, and whether you can export it. For structured business records, a relational database is a common and well-understood choice.
Hosting and lock-in. Ask who owns the cloud account and how hard a move would be. Managed offerings such as platform as a service speed delivery but can tie you to one provider.
Third-party dependencies. List the frameworks, libraries, and paid services the system relies on, and who maintains them.
Operations. Look for logging, monitoring, and alerting so problems are noticed before users report them.
Technical debt. This means shortcuts that make future change slower and costlier. Ask how the vendor limits it through code review, automated tests, and documentation.
Consider paying an independent technical reviewer for a few hours to read the architecture summary and integration plan. Give them the questions in this guide and ask for written risks, not a verdict. The ISO/IEC 25010:2023 product quality model gives you shared vocabulary: it defines nine quality characteristics, including performance efficiency, security, maintainability, and compatibility, that help turn “good architecture” into requirements you can check. See the ISO/IEC 25010:2023 standard for the full model.
Software Built Around the Work You Actually Do Explore custom client portals, internal business applications, dashboards, and integration-led workflows when off-the-shelf systems do not fit. |
Security, Privacy, Accessibility, and Compliance Checks
Security in a proposal has two parts that readers often blur: the controls the vendor will build into your software, and the vendor's own practices and credentials. Ask for both, and treat claims as unproven until evidence appears. Scale the demands to risk. A portal holding client contracts needs more than a brochure site, and less than a payment processor.
Secure development practices. The NIST Secure Software Development Framework (SP 800-218, version 1.1, February 2022) describes a common set of secure development practices and notes that buyers can use it to communicate with suppliers. Ask which practices the vendor follows, such as code review, dependency checks, secrets handling, and vulnerability fixes. NIST describes recommended practices, not a certification a vendor must hold.
Application security verification. The OWASP Application Security Verification Standard (current stable version 5.0.0) provides requirements for testing web application security controls. Ask whether the vendor will verify against an agreed ASVS level and share the results. The level is a negotiation based on your risk, not a default.
Access control. Look for authentication, role-based authorization, least privilege, protected admin accounts, and session handling. Our primer on cybersecurity and guide to cloud security explain the vocabulary.
Data handling. Ask how data is classified, encrypted in transit and at rest, retained, and deleted, and who at the vendor can see production data.
Auditability. Ask what is logged, for how long, and who can read it. Audit trail software shows what mature logging aims to achieve.
Backups and recovery. Ask how often backups run, whether restores are tested, and how fast service returns after a failure. Options such as backup as a service may be relevant.
Accessibility. WCAG 2.2, a W3C Recommendation dated 12 December 2024, defines testable success criteria at levels A, AA, and AAA. Many buyers specify level AA, but whether accessibility is legally required depends on your jurisdiction, sector, and audience. The proposal should name a target.
Compliance. Privacy and sector rules apply according to the data you hold and where your users live, and they differ by jurisdiction. Do not assume a certification is mandatory, and do not accept a compliance claim without naming the specific control and evidence. Our guide to cloud compliance is a useful starting point.
Separate what is promised from what is proven. A vendor that says it follows secure practices should be able to show a sample test report, describe its vulnerability-handling process, or point to a reference.
Test Team and Delivery Credibility
Proposals sell the best people, while projects are delivered by whoever is available. Ask who will actually work on your project and for how many hours each week. Then test these areas.
Named roles. Project lead, developers, designer, and QA, with allocation percentages.
Subcontracting. Disclosure of who is outside the vendor's own team and how they are managed.
Evidence. A comparable delivered project, a reference you can call, or a live product you can inspect, rather than logos.
Communication. Regular demos, a shared task board, and one accountable contact. Iterative approaches such as agile methodology work well when you commit to timely feedback.
Governance. Who decides, who approves changes on each side, and how disagreements escalate. Tools for project management and for vendor management show how this can be tracked.
Continuity and capacity. What happens if a key person leaves, whether documentation is kept current, and whether your project competes with others for the same people.
Verify claims without demanding irrelevant credentials. Relevant delivered work matters more than certificates. Ask for one reference with a comparable scope, and ask that reference what went wrong and how the vendor handled it.
Timeline, Milestones, and Dependencies
A credible timeline shows phases, dependencies, and your own responsibilities, not just an end date. A schedule much shorter than competing offers usually signals skipped testing, missing scope, or optimism. Look for discovery, design, development, testing, integration, user acceptance testing (UAT), and launch, plus the time you need to give feedback. Slow approvals are one of the most common causes of delay, so they belong in the plan. Our web app development timeline guide explains typical drivers.
Also ask how the plan handles change. A fixed-scope plan suits clear requirements. An iterative plan, discussed in our overview of agile program management, suits evolving ones but needs review points and a budget ceiling. Whatever the method, there should be schedule contingency and a stated assumption about how many days you take to review each deliverable.
The table below is an illustrative milestone plan for a 20-week client portal. Durations vary with scope. Payment shares add to 100%.
Milestone | Deliverable and dependency | Approval gate | Payment |
|---|---|---|---|
M1: Scope sign-off (weeks 1–3) | Requirements and wireframes; you supply workflow samples | Signed scope and acceptance list | 10% |
M2: Design approved (weeks 4–6) | Clickable prototype; you give feedback within 3 business days | Written design approval | 15% |
M3: Core build (weeks 7–12) | Roles, upload, approvals on a test environment | Demo against acceptance criteria | 25% |
M4: Integration and migration (weeks 13–16) | CRM sync and data import; you provide CRM access | Reconciliation report accepted | 20% |
M5: UAT and launch (weeks 17–19) | Test cycles, fixes, deployment; your testers are available | UAT sign-off, no open critical defects | 20% |
M6: Handover (week 20) | Documentation, access transfer, training | Handover checklist accepted | 10% |
Pricing, Commercial Models, and Three-Year Total Cost of Ownership
The headline price tells you little. Compare proposals on equivalent scope and on total cost of ownership (TCO) over three years, which adds the costs that arrive after the first invoice. Start by identifying the commercial model, since each shifts risk differently. Our guide to fixed-price vs time-and-materials contracts goes deeper.
Fixed price. Suits clear scope. It protects your budget only as far as the scope is defined, so watch exclusions and change orders.
Time and materials. You pay for hours worked. It is flexible, but ask for the rate card, an estimate range, and a cap or review points.
Milestone-based. Payments follow accepted deliverables rather than elapsed time. It can combine with either model above.
Dedicated team. A monthly fee for a team. It suits long-running product work and requires you to manage priorities.
Then list every cost line the proposal may omit: discovery fees, change requests, hosting and cloud infrastructure, licences and third-party tools, integration charges, security testing, data migration, maintenance, upgrades, and contingency. For cross-border contracts add taxes and currency exposure. Our guides to custom software development cost and client portal development cost show typical cost drivers.
Three-year TCO = build price + excluded work you will need + contingency + (monthly hosting × 36) + (monthly maintenance × months after warranty).
Hypothetical calculation (not a market average or an Articsledge quotation). Take Vendor A from the worked case later in this guide. Its headline fixed price is $48,000. It excludes CRM integration ($9,000), data migration ($3,000), and security testing ($4,000), so the excluded work you will need is $16,000 and the one-time subtotal is $64,000. A 10% contingency adds $6,400. Hosting at $250 per month for 36 months adds $9,000. Maintenance at $1,500 per month for the 35 months after a one-month warranty adds $52,500. Three-year TCO: $64,000 + $6,400 + $9,000 + $52,500 = $131,900, about 2.7 times the headline price.
Equivalent scope is the point. A cheaper proposal that excludes work you need is not cheaper; it is incomplete. Normalize every offer to the same list of requirements before you compare totals.
Make the Scope Clear Before the Spend Discuss requirements, dependencies, and a practical first release before finalizing project assumptions and investment. |
Quality Assurance and Objective Acceptance Criteria
Testing and acceptance decide whether “done” means anything. Look for a quality plan that names the test types, who runs them, and what counts as passing. Typical layers include functional testing of each feature, integration testing of connected systems, security testing matched to risk, performance testing where load matters, usability and accessibility checks, and UAT by your own staff using agreed scripts.
Ask how defects are classified (for example critical, major, and minor), who fixes them, how fast, and how retesting works. Ask for a written definition of done. Automated deployment and testing practices, covered in our guide to DevOps, reduce regressions, and realistic test data is often needed from your side. Keep two ideas apart: acceptance is your formal confirmation that a deliverable meets agreed criteria, while a warranty is the vendor's promise to fix defects found afterwards. Tie payments to acceptance, and make sure a rejected deliverable has a defined correction path.
The criteria below are illustrative for a client portal. Set your own thresholds with a technical reviewer.
Area | Measurable criterion | How it is verified |
|---|---|---|
Access control | A client user cannot open another client's folder by editing the URL, in 20 of 20 test attempts | Scripted test witnessed in UAT |
Performance | Document lists load in under 2 seconds for 95% of requests with 200 concurrent test users | Load test report |
Upload | A 25 MB PDF reaches the approver queue within 60 seconds in at least 95 of 100 uploads | Test log |
Audit | Every approval, rejection, and comment is stored with user and timestamp | Audit log review |
Accessibility | No critical keyboard or contrast failures on the five key screens against WCAG 2.2 AA | Accessibility test report |
Defects | No open critical defects and no more than five open minor defects at sign-off | Defect tracker export |
Contract, Intellectual Property, and Risk Allocation
Proposals and marketing pages describe intent. The contract allocates rights and risk. Confirm each item below in writing rather than assuming it. This is a procurement checklist, not legal advice: rules on copyright assignment, liability limits, and data protection vary by jurisdiction, so have a qualified lawyer review the final agreement.
Source code and repository rights. Is ownership assigned or licensed, and when does it transfer (for example on final payment)? Do you receive repository access? Our explainer on source code covers what you are actually receiving.
Pre-existing vendor IP and third-party components. Ask for a list of reusable libraries, paid components, and open-source licences, with the terms that apply to your use.
Data ownership. Confirm that you own your data and can have it returned in a usable format.
Hosting and admin credentials. Confirm who holds cloud, domain, and production admin accounts from day one.
Confidentiality. Check scope, duration, and handling of your sensitive information.
Payment terms. Prefer milestone payments tied to acceptance over large upfront sums.
Change control. Look for a written process for requesting, pricing, and approving changes.
Warranties and liability. Check what is warranted, for how long, and any cap on liability.
Termination and disputes. Check termination rights, refunds for unaccepted work, governing law, and dispute resolution.
Exit. Confirm assistance with handover if the relationship ends. Contract management tools such as contract lifecycle software can help you track renewals and obligations after signing.
Terms that differ from your preference are not automatically unreasonable. A vendor may keep ownership of reusable libraries while licensing them to you, for example. What matters is that the arrangement is explicit, scoped, and accepted knowingly.
Maintenance, Support, and Handover
Proposals often blur four different things. Warranty fixes defects in delivered work for a stated period. Maintenance keeps the system healthy through security updates, dependency upgrades, monitoring, and backups. Support answers users and incidents within agreed response times. Enhancements are new features, priced as separate work. Ask the vendor to state what is covered, for how long, and at what price.
Service levels. Response and resolution targets by severity. SLA tracking software illustrates how these targets are measured.
Incident handling. Escalation contacts, out-of-hours expectations, and post-incident reports.
Operations. Who monitors the system and how, which our overview of CloudOps and cloud telemetry explains, plus who applies security updates and how quickly.
Documentation and training. Architecture notes, run books, admin guides, and training for your staff.
Access handover. Credentials, repositories, and environments transferred and verified at the end.
Portability. What moving to another vendor or provider would require; see the trade-offs of multi-cloud setups.
Request a year-three maintenance figure alongside the year-one figure. Support costs are easy to understate in a proposal and hard to renegotiate once you depend on the system.
The Weighted Proposal Scorecard
A weighted scorecard forces consistent comparison and exposes disagreement among reviewers. Rate each criterion from 1 to 5 using evidence from the proposal, not impressions, and note your confidence in each rating.
Rating | Meaning | Evidence standard |
|---|---|---|
1 | Missing or contradictory | Nothing relevant in the proposal |
2 | Weak | Vague claims without supporting detail |
3 | Acceptable | Reasonable but partly evidenced; open questions remain |
4 | Strong | Specific, consistent with scope, evidence supplied |
5 | Excellent | Specific and verified by a reference, sample, or test report; reduces your risk |
Use these default weights, which sum to 100%.
Criterion | Weight | What you are rating |
|---|---|---|
Business understanding and scope | 20% | Fit to your problem, scope clarity, exclusions |
Technical approach and feasibility | 15% | Architecture fit, integrations, maintainability |
Team capability and governance | 15% | Named roles, evidence, communication, continuity |
Security, testing, and quality | 15% | Controls, test plan, acceptance criteria |
Pricing and total cost | 15% | Normalized three-year TCO, not headline price |
Timeline and delivery feasibility | 10% | Realistic phases, dependencies, contingency |
Contract, ownership, support, and handover | 10% | IP, access, warranty, support, exit |
Total | 100% |
Weighted score out of 100 = sum of (criterion weight × criterion rating ÷ 5). A criterion weighted 20% and rated 4 contributes 20 × 4 ÷ 5 = 16 points. As a suggested reading, 80 to 100 indicates a strong candidate, 65 to 79 a viable one with conditions, and below 65 a proposal that needs substantial revision. These bands are guidance, not an industry standard.
Adjust weights to your context before you score, and keep the total at 100. A business handling sensitive records might raise security to 20 or 25 and lower price. A company facing a fixed launch date might raise schedule. Decide weights first so you do not tune them to favor a preferred vendor.
No-go gates. A mathematically high score must never override an unacceptable critical risk. Treat each of the following as disqualifying until it is fixed in writing:
Ownership or licence terms for code and data are unresolved.
No security testing is planned for a system holding sensitive data.
There is no data return or exit path.
Core scope is unclear or contradicts your brief.
You would not receive admin access to hosting and production systems.
The vendor refuses to answer written clarification questions.
The schedule is far shorter than comparable offers with no credible explanation.
Worked Case: Comparing Three Proposals
Hypothetical scenario. Every company, offer, score, and figure in this section is invented to illustrate the method. These are not real Articsledge projects, clients, or quotations, and the prices are not market averages.
The brief. A 40-person professional-services firm wants a client portal for about 300 client organizations. It needs three roles (client, account manager, admin), document upload and approval, email notifications, an activity log, a one-way CRM sync, migration of 2,000 historical document records, security testing, and UAT support. Assumptions: US dollars, a 36-month horizon, no taxes or currency effects, and contingency rates of 10% for Vendor A (fixed price, unclear exclusions), 5% for Vendor B (fixed price, well-defined scope), and 15% for Vendor C (uncapped time and materials). These rates are the buyer's judgment.
Item | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
Pricing model | Fixed, $48,000 | Fixed, $62,000 | Time and materials, $95 per hour; estimate $52,000–$68,000 |
Timeline | 14 weeks | 20 weeks, six milestones | 16 weeks (estimate) |
Excluded or extra | CRM sync ($9,000), migration ($3,000), security testing ($4,000) | Brief fully covered, including ASVS-aligned security testing | Independent security test ($4,000) |
Ownership and access | “To be agreed” | Assigned on final payment; component licence list provided | Client owns code; hosted in vendor account with no admin access offered |
Recurring | Hosting $250/month; maintenance $1,500/month | Hosting $300/month; maintenance $1,500/month | Hosting $450/month; maintenance $1,800/month |
Warranty | 1 month | 2 months | 1 month |
Vendor C's build cost uses the $60,000 midpoint of its range. The three-year totals follow the formula from the pricing section.
Cost line | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
Headline build price | $48,000 | $62,000 | $60,000 |
Excluded work needed | $16,000 | $0 | $4,000 |
One-time subtotal | $64,000 | $62,000 | $64,000 |
Contingency | $6,400 (10%) | $3,100 (5%) | $9,600 (15%) |
Hosting, 36 months | $9,000 | $10,800 | $16,200 |
Maintenance after warranty | $52,500 (35 × $1,500) | $51,000 (34 × $1,500) | $63,000 (35 × $1,800) |
Three-year TCO | $131,900 | $126,900 | $152,800 |
Vendor A has the lowest headline price, $14,000 below Vendor B, yet it costs $5,000 more over three years once its exclusions and recurring costs are counted. Now apply the scorecard. Each cell shows rating, then points (weight × rating ÷ 5).
Criterion (weight) | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
Business understanding and scope (20%) | 2 → 8 | 4 → 16 | 3 → 12 |
Technical approach (15%) | 3 → 9 | 4 → 12 | 4 → 12 |
Team and governance (15%) | 3 → 9 | 3 → 9 | 4 → 12 |
Security, testing, quality (15%) | 2 → 6 | 4 → 12 | 3 → 9 |
Pricing and total cost (15%) | 4 → 12 | 5 → 15 | 2 → 6 |
Timeline (10%) | 3 → 6 | 4 → 8 | 4 → 8 |
Contract, support, handover (10%) | 1 → 2 | 4 → 8 | 3 → 6 |
Weighted score (100%) | 52 | 80 | 65 |
Gates and decision. Vendor A fails two gates: ownership is unresolved and no security testing is planned. It is ineligible even though its price is attractive, and it would remain ineligible had it scored higher. Vendor C passes only if the contract gives you admin access to the hosting account and states a liability cap, and an uncapped hourly estimate needs a budget ceiling. Vendor B passes every gate.
Recommendation. Choose Vendor B, conditionally: it has the highest score (80), the lowest three-year TCO ($126,900), and the least open uncertainty. Before signing, confirm written acceptance criteria for each milestone, have counsel review the IP assignment and component licence list, and fix the CRM sync specification. The trade-off is time: 20 weeks against 14 and 16. If a launch date were critical, raising the timeline weight and rerunning the scores could change the order, which is exactly why weights should be decided before scoring.
Have a Web Application Project to Evaluate? Share your users, workflows, integrations, approximate budget, and objectives to explore a suitable development approach. |
Red Flags and How to Respond
A red flag is a prompt for evidence, not proof of misconduct. Many are resolved by asking a direct question. Treat a vendor's response to the question as part of your evaluation.
Warning sign | Why it matters | Evidence to request | Next action |
|---|---|---|---|
Vague scope (“standard features,” “etc.”) | Hidden work surfaces as change orders | Feature-level list with acceptance tests | Ask for a revised SOW |
Unsupported promises (“guaranteed,” “best”) | Claims without proof | Reference, sample, or cited metric | Discount until evidenced |
Unclear ownership | You may lack rights to what you paid for | Draft IP clause and licence list | Resolve before signing |
No testing or acceptance terms | “Done” becomes an opinion | Test plan and acceptance criteria | Add them as milestone conditions |
Price far below peers | Narrow scope or unrealistic assumptions | Line-item estimate and exclusions | Normalize to equal scope |
Large upfront payment | Reduces your leverage | Payment schedule tied to acceptance | Negotiate milestone billing |
No change-control process | Open-ended price growth | Change process and rate card | Add to the contract |
Unnamed or “TBD” team | Delivery and continuity risk | Named roles and allocation | Ask for named leads |
Undisclosed dependencies | Delays and surprise costs | Dependency list with owners | Assign owners and dates |
No maintenance or support terms | Unplanned post-launch cost | Support scope and service levels | Request a separate quote |
Questions to Ask Vendors Before You Sign
Use these in a live review meeting and ask for written follow-up. For a broader vendor-selection list, see our guide to questions to ask a software development agency.
Business understanding. Which of our requirements did you challenge or suggest deferring, and why? In what situation would you advise us to buy instead of build?
Scope. Which three items are most likely to grow, and what triggers a change order? What do you need from us, and by when, to hold the schedule?
Architecture. What would it take to move this application to another host or vendor in year two? Which third-party services could we not easily replace?
Security. Which ASVS level or equivalent will you verify against, and can we see a sample report? Who on your team can access production data, and how is that access logged?
Testing. What will our UAT testers be asked to do, and how many fix-and-retest cycles are included? How do you classify defects, and what is the fix deadline for each class?
Team. Who writes and who reviews the code? Will any work be subcontracted? What happens if the lead developer leaves mid-project?
Delivery. Which milestones depend on our decisions, and what is the effect if we are a week late?
Cost. Which assumptions would raise this price by more than 10%? What are the monthly hosting, licence, and maintenance costs at launch and in year three?
Ownership. When do code and repository rights transfer, and which pre-existing IP stays with you? Will we hold the hosting and domain accounts from day one?
Support and exit. What does the warranty cover compared with maintenance? What handover do you provide if we leave?
Negotiation and Approval Workflow
Review ends in a decision, and the steps below keep it defensible. Do not start development until the critical terms are agreed.
Normalize. Put every proposal on the same scope template and complete the crosswalk.
Clarify in writing. Send one list of questions to all vendors and compare the answers.
Log risks. Record open issues, owners, and dates.
Verify evidence. Call references, inspect samples, and request test reports.
Get review. Ask a technical reviewer for architecture risks and a lawyer for the contract.
Consider paid discovery. When uncertainty is high, a separately priced discovery phase can define scope before you fund the build.
Negotiate terms, not only price. Focus on scope clarity, milestone approvals, payment schedule, access, and exit terms.
Decide. Compare scores and gates against go or no-go criteria and record the result in a decision memo.
Kick off. Agree communication routines, access, the definition of done, and the first milestone.
Sample clarification request.
Thank you for your proposal. Before we compare it with others, please confirm in writing: (1) which CRM integration behavior is included, with fields, direction, and frequency; (2) whether migration of about 2,000 records is included; (3) which security tests will be run and whether we will receive the report; (4) when code and repository rights transfer; (5) who will hold the hosting accounts; and (6) which assumptions would change the price. Please also list anything you consider out of scope.
A one-page decision memo should summarize the requirements, the normalized comparison, the scorecard with confidence levels, gate results, residual risks with owners, negotiated changes, the recommendation, and the approvals.
Where Articsledge May Fit
Custom software is not always the answer, and a good evaluation may end with “buy it” or “integrate it.” Where your requirements are specific and off-the-shelf tools fit poorly, Articsledge offers custom web application development for client portals, internal business applications, custom dashboards, API integrations, and workflow applications such as client onboarding.
Its published process starts with a project assessment that also asks whether building, integrating, or improving existing tools makes more sense. It then moves through requirements and scope, which for complex work may be a separately paid discovery phase, followed by design, development, testing, deployment, and handover. Ownership, repository access, hosting, maintenance, price, and timelines are agreed per project, so ask for them in writing, as you would from any vendor. Articsledge works remotely with international clients.
Apply this article's checklist, scorecard, and gates to any Articsledge proposal exactly as you would to another vendor's. To start a conversation, share your business problem, intended users, required features, existing systems and integrations, approximate budget, and preferred timeline through the project assessment page or the contact page. For background, read our guides to custom web application development and custom business software.
Explore Articsledge Custom Web Application Development: articsledge.com/custom-web-application-development
Frequently Asked Questions
What is the best way to evaluate a software development proposal?
Screen it first with a ten-minute checklist, then build a scope crosswalk against your brief, normalize costs to equal scope, and score each proposal on a weighted scorecard. Apply no-go gates for ownership, security, and exit risks, and confirm critical terms in writing before signing.
What should a software development proposal include?
At minimum: objectives, scope with exclusions and assumptions, technical approach, named team, milestones, testing and acceptance, security approach, pricing and payment schedule, recurring costs, and ownership, support, and handover terms.
How do you compare two software development quotes?
Map both to the same requirements list, add the cost of anything one quote excludes, and compare three-year total cost rather than headline price. Then compare risk: acceptance criteria, ownership, security testing, and support. A quote that looks cheaper may simply cover less.
What are the most important evaluation criteria?
In the default scorecard, business understanding and scope carry 20%. Technical approach, team, security and quality, and total cost carry 15% each, while timeline and contract terms carry 10% each. Adjust the weights to your risk before you score.
Is the cheapest proposal ever the right choice?
It can be, if it covers the same scope, passes your no-go gates, and has a comparable total cost. The danger is that a low price reflects narrow scope or missing testing and support. Compare normalized total cost and evidence of quality before deciding.
How can I assess a proposal without technical knowledge?
Focus on what you can verify: whether the scope matches your brief, whether acceptance criteria are measurable, and whether ownership and support are clear. Pay an independent technical reviewer for a short review of the architecture and integrations, and ask for written risks.
How do I spot an unrealistic estimate or timeline?
Compare it with peer proposals and ask for effort by phase and the assumptions behind it. Warning signs include no testing phase, no time for your feedback, and a schedule far shorter than others for the same scope.
What are the most common software proposal red flags?
Vague scope, unclear ownership, no testing or acceptance terms, a price far below peers, large upfront payments, no change-control process, an unnamed team, and no support terms. Treat each as a question to answer, not proof of bad faith.
Who owns the source code after development?
It depends on the contract. Ownership may be assigned to you, licensed to you, or split between your custom code and the vendor's reusable components. Confirm when rights transfer, which components stay with the vendor or a third party, and your repository access, and have a lawyer review the terms for your jurisdiction.
What should testing and acceptance criteria cover?
Cover functionality, integrations, security, performance where relevant, accessibility, and UAT, with measurable thresholds such as response times and defect limits. Define severity levels, who fixes defects, retest rules, and what counts as accepted.
How should I evaluate maintenance and support costs?
Ask for monthly costs at launch and in year three, the service levels they buy, and what is excluded. Add hosting and security updates, then include everything in the three-year TCO. Separate warranty, maintenance, support, and new features so you compare like with like.
What should a statement of work contain?
Deliverables, scope, exclusions, assumptions, milestones, acceptance criteria, client responsibilities, payment schedule, change-control process, and roles. It should be specific enough that a third party could tell whether a deliverable was met.
When is a paid discovery phase worthwhile?
When requirements are uncertain, integrations are complex, or the budget is large relative to your confidence in the scope. Discovery can produce a clearer scope, assumptions, and milestones before you commit to the full build. Agree its deliverables and price in writing first.
What should I do after reviewing the proposals?
Send written clarification requests, update the scores, run technical and legal review, negotiate scope and terms, and record a go or no-go decision in a short memo. Do not start development until critical terms are signed. If no proposal qualifies, revise the brief and ask again.
Key Takeaways
A proposal is a bundle of promises and assumptions. Read the exclusions, assumptions, and acceptance terms as closely as the price.
Screen first. Send back or reject proposals with fatal gaps before you invest in deep diligence.
A scope crosswalk from your brief to the offered deliverables turns every unmapped requirement into a visible future change order.
Compare three-year total cost on equivalent scope. The lowest headline quote can be the most expensive option.
Ask for evidence rather than assurances: references, sample test reports, and component licence lists.
Security, accessibility, and compliance demands depend on risk and jurisdiction, so scale them to your situation instead of assuming one standard.
Decide scorecard weights before scoring, and never let a high score override a failed gate on ownership, security testing, or exit.
Apply the same standards to every vendor, including Articsledge, and do not start development until critical terms are signed.
Actionable Next Steps
Collect every proposal and your original brief in one place.
Run the ten-minute screen and mark each check Pass, Investigate, or Reject.
Build the scope crosswalk and list each gap, assumption, and exclusion.
Send one written clarification request to every vendor.
Normalize costs to equal scope and calculate three-year total cost of ownership.
Agree the weights, score each proposal, and check the no-go gates.
Commission a short technical review and a legal review of the draft contract.
Negotiate scope, milestones, payment terms, access, and exit terms, then record a go or no-go decision in a memo.
Kick off with agreed acceptance criteria and a clearly defined first milestone.
If you have a defined web application requirement and want to compare approaches, you can request a project assessment from Articsledge and judge the response with the same scorecard.
Glossary
Acceptance criteria: Specific, testable conditions a deliverable must meet to be accepted.
API (application programming interface): A defined way for software systems to exchange data and commands.
Change request: A formal request to add, remove, or alter agreed scope, usually with a revised price and schedule.
Discovery phase: A short, often separately priced stage that clarifies requirements, risks, and scope before the main build.
Fixed-price contract: An agreement to deliver defined scope for a set price.
Intellectual property (IP): Legal rights in creations such as source code, designs, and documentation.
MVP (minimum viable product): The smallest release that delivers real value and tests the main assumptions.
Nonfunctional requirements: Qualities such as speed, security, availability, accessibility, and maintainability.
RFP (request for proposals): A formal document inviting vendors to propose solutions to stated needs.
Statement of work (SOW): The contract document describing scope, deliverables, milestones, and acceptance.
SLA (service level agreement): An agreement that sets response and resolution targets for support.
Source code: The human-readable instructions from which software is built.
Technical debt: Accumulated shortcuts that make later changes slower and more expensive.
Time and materials: A pricing model where you pay for the hours and resources actually used.
Total cost of ownership (TCO): All costs of acquiring and running software over a defined period.
UAT (user acceptance testing): Testing by your own users to confirm the software supports real work.
Vendor lock-in: Dependence on one supplier or platform that makes switching costly.
Sources & References
Souppaya, M., Scarfone, K., and Dodson, D. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (NIST Special Publication 800-218). National Institute of Standards and Technology, February 2022. https://csrc.nist.gov/pubs/sp/800/218/final
OWASP Foundation. OWASP Application Security Verification Standard (ASVS), latest stable version 5.0.0. Date not specified. https://owasp.org/projects/asvs
ISO/IEC. ISO/IEC 25010:2023, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model, Edition 2. International Organization for Standardization, November 2023. https://www.iso.org/standard/78176.html
W3C. Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation. World Wide Web Consortium, 12 December 2024. https://www.w3.org/TR/WCAG22/
Articsledge. Custom Web Application Development Services. articsledge.com. Date not specified. https://www.articsledge.com/custom-web-application-development
