[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-comparing-software-proposals":3,"blog-post-adjacent-comparing-software-proposals":68},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":13,"datePublished":14,"dateModified":14,"category":15,"author":19,"tags":26,"answerFirst":31,"keyTakeaways":32,"body":38,"faqs":39,"sources":58,"relatedServices":59,"seo":63},"fvb8hoimb5ae5ndf0shpzndq","Comparing Software Proposals Beyond Price: What Each One Actually Includes","comparing-software-proposals","The cheapest proposal may simply include less. How to compare software proposals on the same rows: assumptions, exclusions, acceptance, ownership, support and changes.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_13_export_blog_16x9_fdc86a7fd8.jpg",2400,1350,null,"Dark cover reading \"Are they quoting the same work?\" beside three lit columns, A, B and C, opened to show different contents, on comparing software proposals.","2026-09-29",{"name":16,"slug":17,"description":18,"seo":12},"Engineering","engineering","Software architecture, code quality and the engineering practice behind the systems we build.",{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":12,"photo":12,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29],{"name":28,"slug":28},"decision-frameworks",{"name":30,"slug":30},"risk-management","To compare software proposals fairly, put them side by side on the same rows before looking at price: what each assumes, what it excludes or never mentions, how the work will be accepted, who owns the code and accounts, what support follows launch, and how changes are agreed. Proposals that differ sharply in price usually differ in these rows, because they are quoting different work.",[33,34,35,36,37],"The cheapest proposal may simply include less. Before comparing prices, check that the proposals are quoting the same work.","Read every assumption as scope with a condition attached. If the condition fails, the cost and the timeline move.","\"Not mentioned\" is a third answer, different from included or excluded, and the one most likely to become a disagreement later.","Compare how the work will be accepted, who owns the code and accounts, and what support follows launch. These are part of what you are buying.","Send every supplier the same questions in writing, starting with \"what is not included?\", and compare the answers on the same rows.","Three software proposals arrive for the same project. One is a two-page summary, one is a long document with a timeline, one is a spreadsheet. The totals are far apart, and the natural move is to compare the totals: pick the cheapest, or distrust it and pick the middle.\n\nBoth choices skip the question that matters. The cheapest proposal may simply include less. Before price means anything, you need to know whether the three are quoting the same work, and usually they are not.\n\nThis is the step after writing a clear brief. A good [software project brief](\u002Fblog\u002Fhow-to-write-a-software-project-brief) makes proposals easier to compare. It does not make them identical, and even well briefed suppliers make different assumptions about the parts nobody wrote down.\n\n## Why software proposals are hard to compare\n\nSoftware proposals are hard to compare because each supplier describes the project in its own structure, at its own level of detail, with its own idea of what is standard. One lists every screen; another lists outcomes. One includes testing as a line; another assumes it is inside every estimate.\n\nThe fix is not to ask for more detail from everyone. It is to take control of the format: build one comparison and make each proposal answer the same rows.\n\n## Put the proposals side by side on the same rows\n\nStart a simple grid. The columns are the suppliers. The rows are the things that change what you actually get:\n\n- The scope items from your brief, one per row\n- Assumptions each proposal depends on\n- Exclusions, stated and implied\n- How the finished work will be accepted\n- Ownership of code, accounts and data\n- Support after launch\n- How changes are estimated and agreed\n\nFill each cell from the proposal's own words. Where a proposal is silent, write \"not mentioned\" rather than guessing. The gaps are the point.\n\n## Read the assumptions as scope\n\nEvery proposal rests on assumptions, often in a short paragraph near the end. \"Content will be provided by the client.\" \"Integration uses the existing interface as documented.\" \"Designs are based on one round of revisions.\" \"Data will be supplied in a clean format.\"\n\nRead each one as scope with a condition attached. If the content arrives late, the interface is not as documented, or the data is not clean, the work and the timeline change. A proposal with many optimistic assumptions can look cheaper precisely because it has quietly moved risk back onto you.\n\n## Find the exclusions, stated and unstated\n\nSome proposals list what they exclude, which is helpful and a good sign. Others simply leave things out. Common gaps worth checking every time:\n\n- Moving existing data into the new system\n- Testing across the devices and browsers your users actually have\n- Hosting, environments and deployment\n- App store submission, where there is an app\n- Training, documentation and handover\n- Accessibility, security review and performance testing\n\nFor each, the answer is included, excluded, or not mentioned. \"Not mentioned\" is the most expensive of the three, because nobody agreed it and both sides will remember it differently later.\n\n## Check how the work will be accepted\n\nA proposal should say how you will decide the work is finished. Who tests it, against what, for how long, and what happens to defects found after sign-off.\n\nTwo proposals with the same feature list can differ enormously here. One includes a testing period against written acceptance criteria and a fix period after launch. Another treats delivery of the code as the end. The second is not necessarily wrong, but it is a different product at a different risk.\n\n## Confirm who owns the code, accounts and data\n\nOwnership belongs in the proposal, before anything is signed. Check that the code will live in repositories your organisation owns, that hosting, domains and third-party services are set up in your accounts, and that licences and any reused components are named, with the terms under which you can keep using them.\n\nIf a proposal is silent on ownership, ask. The answer is usually fine, and getting it in writing now costs one email. Finding out at the end of a relationship costs far more.\n\n## Compare what happens after launch\n\nLaunch is when real users find the problems testing missed. Compare what each proposal offers afterwards: a period in which defects are fixed, whether ongoing support is available, how quickly issues are responded to, and who you contact.\n\nDescribe each in the grid in plain words. A proposal that ends at launch and one that includes a stabilisation period are not quoting the same project, even if every feature matches.\n\n## Ask how changes are estimated and agreed\n\nEvery software project changes as it goes. What matters is how. Does the proposal describe how a change is requested, estimated, approved and scheduled? Who can approve it on your side? Is there a written record?\n\nA clear change process protects both sides. Its absence usually means changes get agreed informally in meetings and argued about at invoice time.\n\n## An illustrative inclusion comparison\n\nThe comparison below is illustrative, not taken from real proposals, and deliberately leaves out prices. It shows how the rows expose differences the totals hide.\n\n| Row | Proposal A | Proposal B | Proposal C |\n|---|---|---|---|\n| Data migration | Included | Excluded | Not mentioned |\n| Device and browser testing | Included, listed | Included | Not mentioned |\n| Acceptance period | Two weeks, written criteria | Not mentioned | One week |\n| Code in your repositories | Yes | Yes | Supplier's until final payment |\n| Fix period after launch | Included | Not mentioned | Included |\n| Change process | Written, estimated per change | Informal | Written |\n| Assumptions listed | 4 | 11 | 2 |\n\nProposal B may well be the lowest total. It also excludes migration, is silent on acceptance and post-launch fixes, handles changes informally, and rests on eleven assumptions. It is quoting a smaller, riskier project than A, not the same project for less.\n\n## Questions to send every supplier before choosing\n\nTurn the gaps into questions and send the same list to every supplier in writing, so the answers land on the same rows:\n\n- What is not included in this proposal?\n- Which assumptions, if wrong, would change the estimate the most?\n- How will we accept the work, and what happens to defects after launch?\n- Where will the code, accounts and data live, and in whose name?\n- How is a change requested, estimated and approved?\n\nThe first question is the most useful one. The answers will tell you more about each supplier than the totals did.\n\nIf you have proposals on the table that do not seem to describe the same project, that is worth untangling before choosing. Clarify the project scope with us: comparing proposals on the same rows is often where our [software development](\u002Fservices\u002Fsoftware-development) conversations start, even when the work ends up elsewhere.",[40,43,46,49,52,55],{"question":41,"answer":42},"How do you compare software development proposals?","Put the proposals side by side on the same rows before comparing price: the scope items from your brief, each proposal's assumptions, what it excludes or does not mention, how work will be accepted, who owns the code and accounts, support after launch, and how changes are agreed. Proposals with very different totals usually differ in these rows.",{"question":44,"answer":45},"Why are software proposals for the same project so different?","Because each supplier interprets the gaps in the brief differently and structures its proposal its own way. They make different assumptions, include or leave out different work such as data migration, testing or post-launch fixes, and describe it at different levels of detail. The totals differ because they are often quoting different projects.",{"question":47,"answer":48},"What should a software proposal include?","Beyond the feature list, it should state its assumptions, what is excluded, how the finished work will be tested and accepted, who owns the code, accounts and data, what support follows launch, and how changes are requested, estimated and approved. Anything it does not mention is worth asking about in writing before choosing.",{"question":50,"answer":51},"Is the cheapest software proposal a risk?","Not necessarily, but the cheapest proposal may simply include less. Check whether it excludes or never mentions things the others include, such as data migration, testing, an acceptance period or fixes after launch, and whether it rests on more assumptions. If it covers the same work on the same rows, the lower price may be genuine.",{"question":53,"answer":54},"What does \"not mentioned\" mean in a software proposal?","It means the proposal neither includes nor excludes the item, so nobody has agreed who will do it. That makes it riskier than a stated exclusion, because each side is likely to remember it differently later. Ask every supplier the same question about each unmentioned item and record the answers in writing.",{"question":56,"answer":57},"What questions should you ask software suppliers before choosing?","Ask each supplier, in writing: what is not included, which assumptions would change the estimate most if wrong, how the work will be accepted and defects handled after launch, where the code, accounts and data will live and in whose name, and how changes are requested, estimated and approved.",[],[60,61,62],"software-development","it-consulting","web-development",{"metaTitle":64,"metaDescription":65,"ogImage":66,"canonicalPath":12,"noindex":67},"Comparing Software Proposals Beyond Price","How to compare software development proposals beyond price: assumptions, exclusions, acceptance, ownership, support and change control, side by side.",{"url":9,"width":10,"height":11,"alt":12},false,{"prev":69,"next":12},{"id":70,"title":71,"slug":72,"excerpt":73,"cover":74,"coverAlt":76,"datePublished":77,"dateModified":77,"category":78,"author":79,"tags":80},"av7p5uv5zbl1ymz87gxx54pf","Planning an MVP Pilot: Write the Learning Plan Before the Launch Date","planning-an-mvp-pilot","A pilot is the first time a product meets people who did not help design it. Decide what it should teach, who is in it, and what counts as a result before the first invite goes out.",{"url":75,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_07_export_blog_16x9_565a485252.jpg","Planning an MVP Pilot: Users, Feedback, Success Criteria","2026-09-22",{"name":16,"slug":17},{"name":20,"slug":21},[81,82],{"name":28,"slug":28},{"name":83,"slug":83},"process-design"]