How to read a software development quote and what to watch out for

You have three software development quotes for the same online store in front of you, and three figures that do not match. Before you compare the numbers, check whether you are comparing the same project, because most often each company has priced a slightly different one.

This guide takes you through a quote in the order in which it is easiest to read: from the scope, through the billing model and payments, to the rights to the code, the costs outside the offer and what happens after launch. At the end there is a list of questions to ask before signing the contract. You can send it to every contractor, including us.

Before you look at the figure, check what was priced

The most common mistake when comparing offers is to line them up from the cheapest to the most expensive. A figure only makes sense once you know what it is for. An offer for an online store that includes integration with invoicing software, a product import from a wholesaler and testing on mobile devices is not a more expensive version of an offer without those elements. It is a quote for a different project.

The method of comparison is tedious but simple. Take all the offers and write every scope item from them into one shared list. Then, for each item, mark whether a given offer covers it, explicitly excludes it or does not mention it at all. The third category is the most important, because that is where future misunderstandings hide.

The table in this example does not point to a winner, only to questions. Offer A needs follow-up questions about invoicing and the English version, offer B about the design and the import, and offer C about deployment. Only once you have the answers do the figures become comparable, and it often turns out that the cheapest offer stops being the cheapest once the missing elements are added.

If you sent your enquiry to several companies, it also helps to check whether they all received the same description. A contractor who asked ten questions and got answers is pricing a fuller scope than one who priced the job on the basis of two sentences. Pass the answers you gave one company on to the others, so that the quotes are based on the same information.

Scope described as features, not buzzwords

A buzzword in a quote sounds specific but commits to nothing. "Admin panel", "payment integration", "responsiveness" and "SEO optimisation" can mean two days of work or several weeks. If the contract contains only the buzzword, both sides can honestly believe they are right when it turns out at acceptance that each of them understood it differently.

A scope item is well described when you can use it to check whether it has been done. Compare two ways of writing down the same thing:

The second column is longer, but only it protects both sides. The contractor knows exactly what it has to deliver, and you know what you are entitled to receive. If the offer contains only buzzwords, ask for them to be spelled out before you sign the contract. A contractor that priced the project properly already has this list in its notes, because without it the amount could not have been calculated.

The second part of a good scope is the list of exclusions. Website copy, photos, translations, data migration from the old system, team training, fees for third-party services: each of these can be inside the project or outside it. A quote that says nothing about exclusions leaves these decisions to the moment when they are hardest to discuss, which is the middle of the project.

Fixed price or billing by the hour

Quotes in IT are usually based on one of two models. In the fixed price model, the contractor takes on the risk that the project will take longer than it assumed, and you know the amount upfront. In the time and materials model, you pay for the hours actually worked at an agreed rate, and the risk of going over the estimate is on your side.

Neither model is cheaper by definition. With a fixed price, the contractor adds a risk buffer, because it is the one who pays for any underestimate. With hourly billing there is no such buffer, but there is no upper limit either. A fairly priced project should cost about the same in both models, and the difference lies in who carries the risk of a mistake.

With hourly billing, ask about two things. First, a maximum budget beyond which the contractor stops work and asks for your approval for further hours. Second, the form of reporting: how often you get a statement of hours and how detailed it is. A statement that says "40 hours: application development" lets you check nothing.

A hybrid model is also common: a fixed price for a well-described first stage and hourly billing for further development after launch. It is a sensible solution when the first version has a clear scope and the next features depend on how users receive the product.

Hour estimates: how to check whether the numbers are realistic

If a quote includes a breakdown into hours, that is its most valuable part, even with a fixed price. The point is not to judge for yourself whether a contact form will take four hours or six. The point is to see which kinds of work the contractor has planned for at all.

Check whether the breakdown includes items that are easy to forget, because you do not see them in the finished product:

• Testing. If testing has zero hours or is missing altogether, it either will not be done or is hidden in other items. In both cases, ask what it involves.
• Deployment. Configuring the server, domain, certificate and email and moving the project to production is real work.
• Communication and project management. Meetings, reports and answering questions take time whether or not they are in the quote.
• Fixes after acceptance. Time reserved for the corrections that come out in the first contact with users.
• Documentation. A description of how to run and develop the project, without which it is hard to hand it over to someone else.

A single item of a hundred hours, for example "frontend", is not an estimate, just an amount converted into hours. Ask for a breakdown into smaller parts, at least into the main screens or modules. If the contractor cannot provide one, it means it has not broken the project down, and the figure comes from a comparison with a similar job rather than from an analysis of yours.

The hourly rate and the number of hours only mean something together. A low rate with a lot of hours can give the same amount as a high rate with only a few. If two offers differ several times over in the number of hours for the same feature, ask both companies how they intend to build it. The difference often comes from a different technical solution, for example a ready-made component versus building from scratch, and that affects the cost of later changes.

The payment schedule and what you pay for upfront

The payment schedule tells you how the risk is shared between the parties. Paying everything upfront puts all the risk on the client, and paying everything after acceptance puts it on the contractor. Most sensible contracts sit somewhere in between: a deposit to start, further instalments once stages are completed and the last part after acceptance.

Each instalment should be tied to something that can be checked. "The second instalment halfway through the project" does not say what halfway is. "The second instalment after approval of the prototype and access to a staging environment with a working basket" says it unambiguously. If the stages in the payment schedule have no description of what has to be ready, ask about it before you sign.

Signals in the schedule that call for follow-up questions:

• All or almost all of it payable upfront on a project lasting weeks or months.
• The last instalment due before acceptance, for example "on completion of the development work", before you have had a chance to check the result.
• No acceptance procedure, meaning no clause on how much time you have for testing and what happens when you report bugs.
• Payment dates without delivery dates on the other side of the contract.

Also check whether the amount in the quote is net or gross. Software services in Poland are, as a rule, subject to 23% VAT, so the difference matters when comparing offers. A contractor that uses the VAT exemption will give an amount without tax, and then net means the same as gross. If one offer is given net and another gross, comparing them without converting is a mistake.

Fixes, scope changes and the deadline

A quote should answer the question of what happens when, after seeing the results, you want to change something. There are three approaches: a set number of rounds of fixes, a time buffer for fixes, and the rule that every change is paid for separately. Each of them works, as long as it is described. The problem arises when the quote is silent.

The most depends on how a fix is defined. A fix brings something to the state that was agreed: a bug, a typo, an element that works differently from the scope description. A scope change is something new: an additional feature, a new view, a rework of an approved layout. If the quote talks about "fixes" without drawing this line, then at the first bigger request each side will interpret it in its own favour.

When it comes to scope changes, ask about the procedure. Good practice looks like this: you request a change, the contractor describes its impact on the deadline and the amount, and work starts only after you have approved it. If the quote or contract does not describe this, it may turn out that changes made on the fly during the project only show up on the final invoice.

Also check what the deadline is counted from. "Delivery in 6 weeks" can mean six weeks from signing the contract, from paying the deposit or from the client delivering all the materials. The last version is fair, because the contractor cannot build a website without copy, but you need to know about it to plan the preparation of the materials. If the contract provides for contractual penalties for delay on one side only, ask how delays caused by waiting for your decisions are settled.

Copyright to the code and access to the repository

This is the part of a quote that is easiest to skip, because it changes nothing on launch day. It does matter a year or two later, when you want to develop the system with another contractor, sell the company or bring in an investor who will ask whether the code really belongs to the company.

Under Polish law, a computer program is a work protected by copyright. Two things follow from the Polish Act on Copyright and Related Rights that you need to know when reading a contract. A contract transferring the economic copyrights has to be made in writing, otherwise it is void (Article 53). It also covers only the fields of exploitation, meaning the specific ways of using the work, that are expressly listed in it (Article 41(2)). A general sentence saying "the rights to the code pass to the client" without a list of fields of exploitation may not give you what you expect.

When reading the quote and the contract, pay attention to these elements:

• Transfer of rights or a licence. A transfer means the economic rights belong to you. A licence means you can use the code on specified terms, while the rights stay with the contractor.
• Fields of exploitation. The list should cover at least recording and reproducing the code, modifying it, and putting it on the market and making it available.
• When the rights pass. Often this is the moment the last instalment is paid. That is a fair solution, but you need to know about it.
• Elements you will not get the rights to. Open source libraries stay under their own licences, and paid components and themes under their makers' licences. A good contract explains this.
• The contractor's own framework or CMS. If the project is built on a closed tool belonging to the contractor, ask whether you can keep using it and developing it with someone else after the cooperation ends.

The rights are one thing, and practical access is another. Ask whether you have access to the repository during the project, whether you will get the code with its full change history, whether documentation will be produced that lets someone else run the project, and in whose name the domain, the server and the third-party service accounts will be registered. Copyright to code you do not physically have is of little help on the day the contractor stops answering.

This section is not a substitute for legal advice. For a large project or an unusual contract, have a lawyer read it before you sign, not when a dispute arises.

Costs that are not in the project price

The amount in the quote is the cost of building. The cost of owning the system is higher, because it includes recurring fees and services the contractor does not include, since you pay for them directly to the providers or they only come up after launch. A good quote lists them, even if it cannot give their exact amount.

The last row of the table is the item that most often comes as a surprise. Code that is not updated becomes vulnerable to known security holes over time, and libraries stop being supported. That does not mean every website needs paid care every month. It means that someone should be responsible for it, and it is good if the quote says whether that is the contractor or you.

These costs are easiest to set out split into the first year and the following years. The first year includes the one-off fees, for example licences and content preparation, while in later years only the recurring items remain. If two offers propose different technical solutions, for example one a paid, subscription-based store platform and the other custom code on an ordinary server, comparing just the build prices is misleading. Compare the cost over a horizon of several years, because a lower implementation price is sometimes clawed back through the subscription.

With mobile apps, there are also the store requirements. Apple and Google regularly update their publishing rules and system version requirements, so an app that is not being developed may, after a while, need an update just to stay in the store. Ask how the contractor takes this into account.

Testing, acceptance and what happens after launch

A quote should say how the project will be tested and what acceptance looks like. "Testing" as a single word in the scope says nothing. Ask what is checked: whether paths such as registration, payment and form submission are clicked through manually, at what screen widths and in which browsers the project is checked, whether performance is measured and whether anyone checks what the user sees when something goes wrong.

Acceptance is the moment from which the last payment, the transfer of rights and the warranty period usually run, so it should have a described procedure. How many days you have to check the project, how you report bugs, what happens if there are a lot of them, and when acceptance is deemed to have taken place if you raise no objections. Without these clauses, the moment of acceptance will be settled in practice, sometimes against your intention.

After acceptance, ask about three things. First, for how long the contractor fixes bugs that come up after launch free of charge, and how quickly it responds. Second, whether the project is monitored, that is whether someone will know the website has stopped working before a customer writes in about it. Third, what further care and development cost after the warranty period ends, and whether those terms are written down or still to be agreed.

A specific question makes a good test: "what happens if the contact form stops working two months after launch". The answer will show whether the contractor has a procedure for it or will only start thinking about it then.

Red flags in a software development quote

The signals below do not automatically mean a dishonest contractor. Some of them come from haste or from inexperience in writing offers. Each of them, however, is a reason to ask a question before you sign the contract, not after the fact.

Also pay attention to how the contractor reacts to the questions in this table. An answer with specifics, even if it is "we don't do that", is a good sign, because it shows the company knows its scope. A vague answer, or a change of subject to a discount, is a sign that conversations during the project will look the same, when what is at stake is the deadline rather than a signature on a contract.

The last row matters both ways. A low price does not have to mean poor quality. It may come from the contractor proposing a ready-made solution where the others priced building from scratch, or from it knowing similar projects well. The only way to tell the difference is to ask where the gap comes from and to check the answer against the scope table from the first section.

The reverse also happens: an offer that is clearly more expensive than the rest does not have to mean an inflated price. Sometimes it is the only one that includes data migration, testing or a period for fixes, while the others are simply silent about them. The scope table works in both directions and shows whether the higher amount buys something specific.

Questions to ask before signing the contract

You can copy the list below and send it to every contractor you are talking to. Written answers are also good material for comparing offers, because they show how a company communicates before the work has even started.

1. Which scope items are included in the price, and which are explicitly excluded from it?
2. Is the price fixed, or does it depend on the hours worked, and if it depends on hours, what is the maximum budget?
3. Is the amount given net or gross?
4. Which stages are the payments tied to, and what has to be ready before each of them?
5. Which event is the delivery deadline counted from, and what happens when materials from my side arrive later?
6. What is a fix and what is a scope change, and what is the procedure for pricing changes?
7. Do I have access to the repository and the test version during the project?
8. Do the economic copyrights to the code pass to me, in which fields of exploitation and at what moment?
9. Will I get documentation that lets another team take the project over?
10. In whose name will the domain, the server and the third-party service accounts be registered?
11. What recurring costs will I bear after launch, and who is responsible for updates?
12. For how long after launch do you fix bugs free of charge, and is the project monitored?
13. Can I talk directly to the person who will write the code?

Our answers to some of these questions are the same for every VulCode project. For a general outline of a project we give a price range, and a specific figure once the scope, deadline and requirements have been agreed. We usually split the payment into three equal parts, 33/33/33, the price includes a buffer for fixes equal to 15% of the project time, and you have access to the repository and staging during the work. At the end you get full rights to the code and documentation for the handover, and the project is monitored free of charge, usually for 90 days. We sign an NDA on request, send progress reports without being asked, and you talk to the person who writes the code.

We do not publish packages, only "from" prices for individual types of project, for example Company Website from PLN 1,199 or Online Stores & E-commerce from PLN 1,699. You can find the full list on the offer page, and the course of the cooperation, stage by stage, on our How we work page. If you already have quotes from other companies and want us to look at them against this list, write to us via the contact form. Quotes and advice are free, we reply within an hour, and if we think one of the offers you already have is a better fit for your project, we will tell you so plainly.