How to choose a software house? By what you can verify, not by what the company writes about itself. Every offer promises an experienced team, punctuality and flexibility, so those words settle nothing. What settles it are things you can check: an entry in a public register, live projects, a conversation with a previous client, answers to specific questions before signing and the content of the contract itself, especially the part about the rights to the code. None of the steps described below requires any knowledge of programming.
- Before you start looking, write down what is to be built, by when and what the biggest risk of the project is. That decides whether you need a software house, a freelancer or an agency.
- A shortlist is three to five companies. Check each one in the Polish business registers (KRS or CEIDG) and on the VAT white list before you book a call.
- Verify the portfolio yourself: open the projects, measure them and ask which part of each project the company actually did.
- With references, talk about what went wrong and how the contractor dealt with it. The question "are you satisfied?" tells you nothing.
- Transferring the economic rights to the code requires written form and a list of fields of exploitation. Without an explicit transfer, the law presumes a licence.
Before you start looking: three sentences about the project
Many failed choices begin with looking for a company before it is clear what it is needed for. Contractors then get compared on the look of their websites and on their rates. Before you open a search engine, write down three things. What is to be built and who will use it. By when, and why exactly by then. What is the hardest or riskiest part of this project.
The last point is the one most often skipped, and yet it decides what kind of contractor you are looking for. With a simple company website, the risk is mainly the deadline and whether the copy is ready. With a panel that pulls orders from an online store and passes them to invoicing software, the risk lies in the integrations. With a platform with payments and user accounts, the risk is security and who will develop it two years from now.
These three sentences narrow down the search. A company whose portfolio contains only brochure websites has no way of showing that it can handle an integration with an accounting system. That is not a judgement of quality, only of fit.
Software house, freelancer or agency: who fits which project
These three names describe different ways of working, not levels of quality. They differ in how many people work on the project, who is responsible for the whole and what happens when one person becomes unavailable.
| Criterion | Freelancer | Software house | Marketing agency |
|---|---|---|---|
| Who writes the code | One person | A team of developers employed by the company or working with it | Often a subcontractor, less often an in-house team |
| Strength | Direct contact, little organisational overhead | Several specialisations at once: frontend, backend, deployment, testing | Strategy, campaigns, content and graphics in one place |
| Main risk | Illness, holiday or the departure of one person stops the project | The conversations are led by someone other than the person writing the code | The code is an add-on to a marketing service |
| Good fit for | A small website, a single integration, fixes to existing code | A panel, a platform, an online store with integrations, an app developed over years | A campaign in which the website is one of many elements |
For a small, well-described task, a freelancer is often the best choice, and there is no reason to pay for a structure the project does not need. A software house has the edge when the project needs several specialisations at once or is meant to live for years. Most of the steps described below, including the registers, references and rights to the code, apply in exactly the same way to a freelancer.
The shortlist: three to five companies, not fifteen
With a dozen or more companies, you cannot properly answer each one's questions, talk to their references and compare their offers. You end up choosing by price, which is the one number that does not tell you what you will get. With three to five, you can give each of them an hour of conversation and a quarter of an hour of checks. The sources you build the list from vary in how reliable they are:
- A recommendation from someone who has finished a project. The most valuable, provided the person recommending was on the client side and the project is already live, not still in progress.
- Projects you know as a user. An online store or app that you use and that works well. The contractor is sometimes named in the footer, and if not, you can ask the owner.
- Public code. Companies that publish their own tools or fix open source libraries leave a trail you can inspect without their involvement.
- Rankings and company directories. Good for collecting names, poor for evaluating them. Check whether the order on the list depends on a paid placement.
Reject straight away any company that does not give its registration details on its website. The company name, NIP (the Polish tax identification number) and address are the minimum that lets you check who you are talking to.
Check the company in the registers before you book a call
A quarter of an hour in public registers answers questions that are not worth asking on a call. The sources below are free and need no login.
| Source | What it tells you | What to look at |
|---|---|---|
| KRS search, the National Court Register | Company details, registration date, management board, rules of representation | Who can sign the contract on the company's behalf and how long the company has existed |
| CEIDG company search, the register of sole traders | Details of a sole proprietorship and the date it started | Whether the business is active or suspended |
| Register of VAT taxpayers, known as the white list | VAT status and the bank accounts reported to the tax office | Whether the account number on the invoice is on the list |
| Financial Statements Repository | Financial statements of companies entered in KRS | Whether the company files its statements and the scale of its revenue |
The white list also has tax consequences. When the one-off value of a transaction with another business exceeds PLN 15,000, the payment has to go through a payment account (Article 19 of the Polish Entrepreneurs' Law). If you pay an active VAT taxpayer to an account that is not on the list on the day you order the transfer, you cannot count that payment as a tax-deductible cost (Article 15d of the Corporate Income Tax Act, Article 22p of the Personal Income Tax Act). The exception is a notification filed with your tax office within 7 days of ordering the transfer.
What counts is the value of the whole transaction, not of a single instalment, so a project paid in three parts of PLN 6,000 each is also covered by this rule. Checking the account number on the list before a transfer takes a minute.
The registration date is not a measure of quality. A young company may be a new entity set up by an experienced team. The register answers simpler questions: does the entity you are going to sign with exist, who represents it and does its scale fit your project.
Portfolio: what you can verify yourself
The portfolio is prepared by the company itself, so it needs checking, not just browsing. Start with whether the projects work. Open a few of them on your phone, go through the contact form or the basket and check whether the content is up to date. A project that stopped working a year after launch is a topic to raise on the call, even if it was the client who dropped the support.
Then measure. Enter the project's address in PageSpeed Insights and look at the score for mobile devices. One measurement is not a verdict, because the score varies between runs and also depends on what the client added after handover. Poor scores across all the projects, however, are a pattern.
The most important question for the portfolio is: what exactly did you do on this project. Large projects are often built by several companies. One prepares the graphic design, a second the frontend, a third the integrations. Each can honestly show the project in its portfolio, but only one is responsible for the part you care about. Ask for a description of their role and for a contact on the client side who can confirm it.
Some projects are covered by confidentiality, and that is normal for internal systems. You can then ask for a description of the problem without the client's name, or for a demo on sample data. A company whose entire portfolio is confidential, however, has a hard time proving anything.
Public code is evidence that cannot be prepared for a particular client. If a company's fixes make it into other people's open source libraries, they have passed review by those projects' maintainers, who have no reason to be lenient. You do not need to read code to benefit from this: the accepted changes, their dates and the maintainers' comments are understandable without knowing how to program. We contribute to Proxmox VE, PHPMailer and ILSpy, among others, and we have gathered our projects on our open source page.
References: what to ask a previous client
The question "are you satisfied?" gets the answer "yes", because no company will give you the contact details of an unhappy client. The value of references lies in the details, and you have to ask about them directly. Ask for the contact details of a client from a similar project that finished at least a few months ago, because a client who is still mid-project does not yet know what acceptance and post-launch support look like. Then ask questions that cannot be answered in one word:
- What in the project went differently from the plan, and how did the contractor respond to it?
- How far did the final cost and deadline differ from those in the offer, and why?
- Who did you talk to day to day, and did that person know the technical details?
- What did acceptance look like, and how many bugs came up in the first weeks after launch?
- Did you receive the code, access to the repository and documentation?
- Did the contractor ever say they would not do something, or that something was a bad idea?
- Would you give them another project, and if not, why not?
The first question tells you the most. Every project has problems, and a reference in which nothing went wrong usually means the person does not remember the details or does not want to talk about them. A good answer sounds roughly like this: "the integration with the wholesaler turned out to be harder, the contractor told us in the second week, proposed two options and together we chose the simpler one". It shows that the problem was raised early, together with possible solutions, and that the client made the decision.
The sixth question checks something you cannot see in a portfolio: whether the contractor is able to disagree. A company that does everything it is asked to, without a single "are you sure?", shifts onto you the responsibility for technical decisions you should not need to understand.
Questions to ask a software house before signing the contract
The first call is usually led by someone who is good at talking about the company. Your goal is to get past that story and see how the company actually works. Questions that have to be answered with specifics do this best.
| Question | Good answer | Signal to dig deeper |
|---|---|---|
| Who exactly will write the code on my project? | Specific people or roles and their share in the project | "We'll put the team together after signing", without details |
| Can I talk to that person before signing? | Yes, a technical conversation before the contract | All technical questions go through a salesperson |
| How will I see the progress of the work? | Access to a test version and the repository during the work, regular reports | A demo only at the end of a stage, no visibility in between |
| What will you do if halfway through the project something turns out to be much harder? | A description of the procedure: information, options, the client's decision | "That doesn't happen with us" |
| What does your offer not cover? | A specific list of exclusions | "We'll do everything you need" |
| What will I get when the project ends? | Code, transfer of rights, documentation, access to accounts | A vague promise of "full support" |
| What happens if in a year I want to change contractor? | A description of the handover, nothing on the contractor's side blocks the switch | The project runs only on the contractor's infrastructure or system |
Also notice whether the person you are talking to asks you questions. A contractor who has asked about the users, the data and the surrounding systems will quote more reliably than one who gives a figure straight away. A figure given before any question has been asked comes from a template, not from an analysis of your project.
Asking for advice is a good test: "does this even make sense in my situation?" A reliable contractor will sometimes reply that an off-the-shelf tool or a smaller scope will solve the problem.
Communication: you can check it before you sign anything
Before the contract is signed, a company has the strongest motivation to reply quickly and specifically. If replies already take a week or skirt around the questions, things will not get better during the project. You can check a few things in the first exchange of messages:
- Predictable replies. This is not about minutes. A company that writes "we'll reply by noon tomorrow" and keeps its word is better than one that sometimes replies at once and sometimes after a week.
- An answer to every question. Send five questions in one message and count how many of them got an answer. The skipped questions are often the ones with an inconvenient answer.
- Language. From the reply you understand what will happen, without a glossary of acronyms. Jargon does not prove competence. Being able to explain something technical to someone outside the industry does.
- A summary after the call. Whether a written list of what was agreed arrives after the meeting. During the project, summaries like this protect both sides from the "but we agreed something else" kind of dispute.
Also ask how often you will get information about progress without having to ask. A report every week or two, covering what was done, what comes next and what is blocking the work, is enough for most projects.
Who will really write the code, and what that means for the rights
A software house may work with developers on employment contracts, with people collaborating under civil-law contracts or with subcontractors. Each of these models is legal and common. It matters to you for two reasons: the continuity of the project and the chain of copyright.
Continuity is the question of what happens when the person leading your project leaves. Ask whether documentation is produced and whether code goes through review by a second developer. If so, knowledge of the project does not sit in one person's head.
The chain of rights is less obvious. The economic rights to a computer program created by an employee as part of their duties under an employment relationship belong to the employer, unless the contract provides otherwise (Article 74(3) of the Polish Act on Copyright and Related Rights). That provision, however, applies to employees. When the code is written by a developer working with the company under a B2B contract, that is as a self-employed contractor, or by a subcontractor, the rights arise with them, and the software house acquires them only under its contract with that person. A software house cannot transfer to you rights that it has not effectively acquired itself.
That is why the contract should include a statement by the contractor that it holds the rights to the code being handed over to the extent needed to transfer them, and an undertaking that the contractor will take on any third-party claims concerning that code. A company with orderly contracts with its developers will sign this without discussion.
Rights to the code: clauses without which a contract does not protect the client
Whether the code is yours is decided by the contract, not by a paid invoice. The Act on Copyright and Related Rights contains several provisions that work against the client if the contract does not take them into account.
The first concerns form. A contract transferring the economic rights must be made in writing, otherwise it is void (Article 53). Written form means a handwritten signature or a qualified electronic signature, which the Polish Civil Code treats as equivalent (Articles 78 and 78¹ of the Civil Code). Accepting an offer by email is not an effective contract transferring rights, even if the offer contained the sentence "the rights to the code pass to the client".
The second concerns the fields of exploitation, that is the specific ways of using the work that the transfer covers. A contract transfers rights only in the fields of exploitation expressly listed in it (Article 41(2)) and can only cover fields known at the time it is concluded (Article 41(4)). A general "we transfer all rights" without a list is not enough. For a computer program, the list should cover at least the rights in Article 74(4): permanent or temporary reproduction of the program in whole or in part, its translation, adaptation, rearrangement and any other alteration, and distribution, including lending and rental. In practice, making it available online, loading it into server memory and the right to commission changes from third parties are added as well.
The third concerns the presumption of a licence. If the contract does not expressly speak of a transfer of rights, the author is deemed to have granted a licence (Article 65). A licence without any other arrangements entitles you to use the work for five years in the territory of the country where the licensee has its seat, after which it expires (Article 66). A poorly drafted contract can therefore give you the right to use your own system for only five years.
The fourth concerns the moment the rights pass. If the contract is silent, the rights pass when the work is accepted (Article 64). Many contracts tie the transfer of rights to payment, which is fair to the contractor. Just make sure it is clear what happens to the code from stages that have already been paid for.
Apart from the rights, you need physical access to what you are buying:
The code handed over as a repository, not a ZIP archive, ideally kept from the start of the project on an account you have access to.
Accounts with the domain registrar and the server provider set up for your company, with access for the contractor, not the other way round.
Payment gateway, email delivery, maps, analytics: the contracts with these providers on your side.
A description of how to run the project, how to deploy it and where the data is, good enough for another team to take the project over without asking the authors.
A list of libraries and paid components with their licences. For these elements you will not get copyright, only the right to use them on their authors' terms.
What the documentation must contain for a handover to another team to be realistic is described in our article on monitoring and maintenance after launch.
This section describes the law in force in August 2026 and is not a substitute for legal advice. For a larger project or an unusual contract, have a lawyer read it before you sign, not when a dispute arises.
The contract: what else to check besides copyright
Several other clauses decide how any dispute ends:
- Scope as an annex. The contract should refer to a description of features against which you can check whether something has been done. "Building an online store" is not a scope.
- Acceptance procedure. How many days you have to check, in what form you report bugs and when acceptance is deemed to have taken place if you raise no objections.
- Changes along the way. Who prices them and whether work can start before you have accepted the cost.
- Contractual penalties. Delays also come from waiting for the client's materials and decisions, so the contract should say how the deadline is counted while the contractor is waiting for you. The contractor can demand a reduction of a penalty that is grossly excessive or that concerns an obligation already largely performed (Article 484 § 2 of the Civil Code).
- Statutory warranty and guarantee. Defects in a commissioned work are governed by the statutory warranty rules for sales (Article 638 of the Civil Code), and between businesses the statutory warranty can be extended, limited or excluded (Article 558 § 1 of the Civil Code). If the contract excludes it, check whether there is a guarantee instead: how long it lasts, what it covers and how quickly the contractor responds to a report.
- Personal data. If the contractor will have access to your customers' data, for example when importing a database or maintaining a server, you need a data processing agreement meeting the requirements of Article 28 of the GDPR.
- Ending the cooperation. How the work done is settled when either side ends the cooperation early, and within what time you receive the code, documentation and access.
The last point works like insurance: you do not plan to use it, but thanks to it a parting of ways costs time, not the whole project.
Red flags when choosing a contractor
None of the signals below proves that a contractor is dishonest, and some of them come from haste. Each of them, though, is a reason to ask a question and wait for the answer before you sign anything.
| Signal | Why it is a problem | What to do |
|---|---|---|
| No registration details on the website or in the offer | You do not know who you are signing the contract with | Ask for the NIP and check the company in KRS or CEIDG |
| A figure given before any questions about the project | The quote does not come from your scope | Ask what assumptions were made |
| Pressure for a quick decision, a discount valid until Friday | Pressure takes the place of arguments | Give yourself as much time as you need to compare |
| All or almost all paid upfront | All the risk is on your side | Propose payments tied to stages |
| No clause on transferring the rights to the code | The law will presume a licence, not a transfer | Ask for a transfer of rights with a list of fields of exploitation |
| Code kept only by the contractor, no visibility during the work | You will see the code at acceptance or not at all | Ask for access to the repository from the start |
| The project runs only on the contractor's closed system | Changing contractor means building from scratch | Ask about the right to keep using and developing it |
| Refusal to put you in touch with references | No satisfied clients or no real projects | Ask for at least one contact from a similar project |
| Contact only with a salesperson | Technical questions go through an intermediary | Ask to talk to the person who will write the code |
The reaction to a question says more than the signal itself. A company that answers a question about transferring the rights with "we'll send a contract template with a list of fields of exploitation" has solved the problem in one sentence. A company that changes the subject or offers a discount is showing you what the conversations during the project will look like.
A paid first stage instead of a bet on the whole project
On larger projects, a good way to test a contractor is to commission a small, self-contained stage first. It can be an analysis and a description of the scope, an interface prototype or the one integration that is the riskiest part of the system. A stage like this ends with something that stays yours, whatever you decide next.
The first stage answers questions that no conversation will: how the contractor asks follow-up questions, how it keeps to deadlines and how it reports. If the cooperation does not work out, you have a scope description or a prototype that you can take to another company. For this to work, write into the contract that the result of this stage passes to you on the same terms as the rest of the project.
How to choose a software house from your finalists
After the calls, references and offers, you are usually left with two or three companies. Comparing them by price is tempting, but the price says the least if the offers describe different scopes. It is better to rate each company in several categories and only then set the result against the price.
| Category | What you assess | Where the rating comes from |
|---|---|---|
| Fit of experience | Whether they have done a project with the same main risk | Portfolio, call |
| Verifiability | How many of their claims you have checked yourself | Registers, live projects, public code |
| References | Whether the client described a specific problem and how it was solved | Conversation with a previous client |
| Communication | Predictability and completeness of the replies | Exchange of messages before the offer |
| Scope of the offer | Features described in a checkable way, a list of exclusions | Offer |
| Contract | Transfer of rights, fields of exploitation, acceptance, ending the cooperation | Contract template |
| Project handover | Repository, documentation, accounts on your side | Offer, call |
Rate each category on a scale from 1 to 3, where 1 means "I don't know, or poor" and 3 means "I checked and it's good". The company with the highest total does not have to win, but if the cheapest offer has the lowest total, you know what you are saving on. In a tie, choose the company you know more about from independent sources.
Frequently asked questions
How many companies should I ask for a quote?
Three to five. With fewer you have nothing to compare, and with more you will not manage to check each company properly and will end up choosing by price.
Should I choose the cheapest offer?
First check whether all the offers cover the same scope. The cheapest offer often leaves out things the others priced in, for example testing, deployment or fixes after launch. If, once the scope has been levelled, it is still the cheapest and the company checked out well, there is no reason to reject it.
Should I sign an NDA before the first call?
Yes, if information that really must stay confidential will come up in the conversation, for example customer data or the details of agreements with partners. For a general description of the project an NDA is usually not needed, and negotiating it delays the first call.
What should I do if the contractor does not want to transfer the rights to the code?
Ask why. Sometimes it is about the company's own library, which it uses in many projects. A sensible solution then is a transfer of the rights to the code written for you plus a licence for the shared element, with the right to modify it and to commission changes from other companies. Pay attention to the term of the licence: a licence granted for an indefinite period can be terminated by the author with a year's notice, unless the contract rules this out (Article 68(1)). If the contractor agrees to none of these options, you are buying a service, not a system.
Check us against the same list
We do not ask you to take our word for it. We have been in business since 2020 and have written more than 5 million lines of code. Our fixes make it into open source projects, including Proxmox VE, PHPMailer and ILSpy, and every one of them can be viewed publicly. We deliver websites with a PageSpeed score of 95+, which you can measure yourself, and when the project ends you get the rights to the code and documentation that allows another team to take the project over.
We describe how the cooperation works step by step on our How we work page, and you can find more about the company on our about us page. If you already have a shortlist of contractors and want to add us to it, write to us via the contact form. We will answer the questions from this article as specifically as you expect any other contractor to.
