The quotations for the same requirement differ enormously. Does that mean somebody is inventing figures?

Not necessarily. In most cases the two sides simply understood a different scope. The phrase "membership system" can mean registration, login, and basic profile data to one vendor, and tiers, points, notifications, and back-office reporting to another. One assumes you supply the design; another includes design. One counts only development; another counts testing, deployment, and training. To judge whether a gap is reasonable, copy each quotation's included items and excluded items into a single comparison table and go line by line. You will usually find the source of the difference halfway through, rather than finding that somebody is expensive. When a line cannot be reconstructed at all, ask the vendor directly what the work for that item covers — willingness to explain is itself important information.

The vendor will not break the quotation down, but their price is the lowest. Should we accept it?

First work out whether the refusal reflects inability or unwillingness. Ask about one specific item — which screens a module covers, what gets delivered once it is done. If that cannot be answered, the low figure probably reflects an unfinished understanding of the work, and the number will move later. If it can be answered and they simply do not want to publish line-by-line pricing, make a smaller ask instead: let the price stay a single figure, but require the inclusions, the exclusions, and the deliverable for each part as an annex to the contract. The price may stay undivided; the scope may not. If both are refused, carry the invisible risk through the payment terms — split the milestones more finely and hold the final installment until after acceptance. If even that is rejected, what you are comparing is not two prices but two different things.

How much detail does a quotation need before we can sign?

Enough to answer four questions: what will be done, what will not be done, what circumstances add to the cost, and what counts as finished. What will be done maps to the feature and deliverables list. What will not be done maps to the exclusions. What adds to the cost maps to the assumptions and the change mechanism. What counts as finished determines the basis for both acceptance and payment. If any one of the four is vague, that is where the argument will happen. It is also worth confirming how long the quotation stands, what the schedule depends on from your side, and who owns the deliverables and when they transfer. None of this is being difficult — it brings an existing gap in understanding forward, which serves both parties.

How to Read and Compare Software Quotes

Three software quotations arrive. The item names differ, the level of detail differs, one runs to a couple of pages and another to ten, and in the end all you can do is compare the totals. That is a genuinely common position to be in, and it is where most later disputes begin.

The difficulty is that software is not equipment. Buy a machine to a given specification and every vendor is selling the same object. Say “order system” and different vendors may be picturing scopes that differ several times over. The real function of a quotation is not to price the work; it is to define the scope. If you cannot read the scope, the number means nothing.

What follows covers what a readable quotation looks like, which sections deserve the closest attention, and how to bring different vendors onto one basis for comparison.

Three ways a quotation gets written, and how much you can read

In practice you will meet three formats, and they differ enormously in how much they let you understand.

The single-line total. One phrase — “website development, lump sum” — and a figure. This supports no subsequent discussion whatsoever; when a disagreement arises, neither side has anything to point at.

The feature list. Items enumerated, each priced. Markedly more readable, but usually missing assumptions and exclusions, so arguments still break out at the boundaries.

Phases plus deliverables. Broken down by project stage, each stating the work involved, what gets delivered, who accepts it, and what conditions mark it complete. This is the format that protects both parties best.

You do not have to insist on the third format, but if what arrives is the first, ask for a breakdown outright. Whether a vendor is willing to produce one is itself a signal: a clear breakdown usually means they have genuinely worked through how to do the job, and an inability to produce one may mean they have not.

Line by line: what a readable quotation contains

Spread the quotation out and check whether these fields exist. The more that are missing, the higher the risk.

Item name and description. A name alone is not enough. “Membership module” needs to state whether it covers registration, login, password recovery, and profile editing, or also tiers and points.
Deliverable. What this item produces when it is done: a screen, a working feature, a document, or a deployment.
Basis of calculation. Lump sum, by page, by module, or by effort — the risk structure of each is completely different.
Definition of done. Is a feature complete when the code is written, or when it has passed testing and been deployed to production?
Schedule and its preconditions. How long it is expected to take, and what that estimate rests on — when material is supplied, how quickly replies come back.
Who is responsible. Which work the vendor does and which you provide. This column is frequently omitted, and it is a major source of disputes.

A common mistake: checking only whether features are listed, without checking the deliverable and the definition of done. Most disagreements are not “you did not do it” but “what you did is not what I pictured,” and that gap usually hides in the deliverable column.

Assumptions: the section most often skipped, and the most consequential

The assumptions usually sit toward the back, in small type, under a heading like “this quotation is based on the following assumptions.” Plenty of people skip straight past. Yet when a project goes wrong, this section does more damage than the feature list does.

A typical set looks like this: the client supplies the design files; the client prepares the hosting environment; the client writes the copy; the client applies and pays for third-party services; the client responds and confirms within a stated number of working days; the existing system provides usable integration documentation.

What these assumptions mean is that if any one of them fails to hold, the scope and the schedule move. Picture a situation where the quotation assumes complete design files are supplied, but what you actually have is a few reference images. The design work either returns to you or becomes an additional item, and either outcome affects the original figure and timeline.

The right way to read them is to ask yourself, one by one: can I genuinely do this? For anything you cannot, say so now and let the vendor fold it into the quotation. That is far cheaper than dealing with it after work begins, and it does not damage the working relationship.

The more detailed the assumptions, the more experienced the vendor usually is. A quotation with no assumptions at all is the one to be careful with, because those preconditions do not disappear by going unwritten — they simply surface later.

Exclusions: what is not written in is not included

Exclusions and assumptions are two sides of the same coin. Assumptions say “here is what I expect you to provide.” Exclusions say “here is what I will not be doing.”

Commonly excluded items include copywriting and data entry, image and video production, annual fees for third-party services, additional language versions, cleaning and converting existing data, post-launch maintenance, training, and the upper limit of browser or device compatibility.

Worth stressing: not appearing in the exclusions does not mean it is included. The rule should run the other way — only what is explicitly written into the inclusions counts as included. If something matters to you and appears in neither list, it is a gray area, and it needs to be confirmed and written down before signing.

A common mistake: assuming “something this basic must be covered.” That kind of unspoken understanding barely exists in software projects, because everybody’s definition of basic is different. Better to ask a few more questions at the quotation stage than to argue afterward.

The items almost everyone forgets

The following are the items both sides most often overlook while quoting, and which invariably appear during execution.

Migrating and cleaning existing data. Whether data from the old system comes across, whether formats need tidying, who deals with the dirty records. This is usually separate work, and not small.

Applying for and configuring third-party services. Payments, SMS, maps, and e-invoice (統一發票) services require account applications, agreements, configuration, and testing, and the review time is not under the developer’s control. For the steps involved, see Payment Gateway Integration in Taiwan.

The scope of testing. Who tests, to what depth, how defects are graded, whether fixes are counted. Leave this vague and acceptance becomes a tug of war.

Training and operating documentation. Once the back office reaches your colleagues, is anybody going to teach them, and is there anything to consult?

Warranty and maintenance after launch. A warranty and a maintenance agreement are different things: a warranty generally covers fixing defects within the delivered scope, while maintenance is continuing care and adjustment. Note that neither term has a settled industry definition — vendors word them differently, so go by the text of the contract in front of you rather than by somebody else’s convention. For the detail, see What Website Maintenance Actually Covers.

Ownership of hosting and the domain. Who registers them, in whose name they sit, who handles renewal. Invisible day to day, decisive the moment you change vendors.

Payment milestones only mean something when tied to acceptance

Payment milestones should not simply carve up the calendar. They should correspond to results you can accept. The common and sensible approach ties them to a few clear milestones: requirements and design confirmed, core features operable, acceptance passed in the test environment, and the end of the acceptance window after go-live.

Check three things:

Every milestone has a matching deliverable. “The second installment is payable on completion of development” is not enough, because “completion of development” has no objective test.

There is an acceptance window and a response deadline. You need time to actually use the thing, and the vendor needs to know how long until feedback arrives. Otherwise the project hangs in mid-air.

The last installment sits after launch. Holding part of the final payment until the system has run steadily for a period is a reasonable arrangement for both sides. For how to design acceptance, see How Software Acceptance Works.

Look at how changes are handled at the same time. Mid-project adjustments are close to inevitable; what matters is agreeing in advance which are clarifications (not charged separately), which are equivalent substitutions, and which are additions to be estimated separately. The boundaries between those three, and who has the authority to approve, belong in writing. For choosing the contract model itself, Fixed Price or Agile offers a fuller comparison.

How to bring different vendors onto one basis

Comparing totals directly will almost certainly mislead you. The workable approach is to build your own comparison table, with vendors across the top and the following items down the side, and fill in every cell.

Feature scope. Merge every feature any vendor mentioned into one combined list, then mark what each of them covers. The gaps are not savings; they are work you will pay for later.
How design is handled. Included or not, how many concepts, how many rounds of revision.
Assumptions. Copy each vendor’s assumptions down and see who is shifting more of the cost onto you.
Exclusions. The same exercise.
Schedule and preconditions. A short schedule is not automatically better; look at what it is built on.
Deliverables. Source code, design files, and documentation — when they transfer, and to whom they belong.
Warranty and maintenance. Scope, duration, response times.
Payment milestones. What results they are tied to.

Once the table is full you will usually find that the one that looked cheap is the one with the most exclusions, and the one that looked expensive had counted testing, deployment, and training. Level both sides up to the same scope, and only then compare.

There is one more dimension people miss: whether the assumptions match your actual situation. A technically thorough quotation built on the premise of a dedicated client contact replying daily is not the right fit if you cannot supply that.

Three questions to ask about this quotation

Plenty of questions can follow a quotation, but only three of them can be answered by this document alone. There is no need to be shy about asking, and the quality of the answers is itself a useful reference.

What specifically does this item include, and what will I have when it is done? Ask for an answer stated as a deliverable, not as a feature name.
Which parts are you least certain about, and if the estimate is wrong, which way will it move? A vendor willing to name the uncertainty has usually thought the work through; one claiming total certainty has simply left the risk with you.
If a feature has to be adjusted midway, how is it counted and who approves it? Ask for a worked example using this quotation — it reveals the real practice faster than reading the clause does.

Everything else — how the team is composed, what they have built before, how the contract terms read, which red flags to walk away from — belongs to choosing a vendor rather than reading a quotation, and has its own set of questions in How to Choose a Software Development Company. Keeping the two separate stops one meeting from mixing scope and trust together.

One last test, and a simple one: a good quotation leaves you clearer about how involved the work is, not vaguer. If all you remember after reading is a single figure, the document has not yet done its job.

Copy the inclusions, the exclusions, and the deliverables from the quotations on your desk into a single table, and the real question usually surfaces on its own. If the table will not fill in, or you would rather pin the scope down before issuing the requirement at all, talk to NETVANA about your project — clarifying scope, assumptions, and deliverables is where we prefer to start. Software services are quoted on inquiry rather than sold as fixed packages; for what each service includes and delivers, see the software services overview.

Further reading: before issuing a requirement, organize the document by following the structure in How to Write Software Requirements. To understand the cost structure behind a quotation, see How Website Costs Are Calculated. If what you are comparing is an app project, see The Complete Guide to App Development Costs. If the schedule worries you, see Why Software Projects Run Late. And if you are still weighing outsourcing against hiring, see Outsourcing or Building an In-House Team.