How to choose a software house: 7 questions and evasive answers

How to choose a software house is settled by the way a company answers questions about the situations where something goes wrong — not by its portfolio and not by its review count. Below are seven such questions for the first meeting, each with a description of what an evasive answer sounds like. GESEL.IO is a software house itself, and these questions apply to us exactly as they apply to anyone else. Ask them of us too.

How to choose a software house when the “portfolio, reviews, communication” list settles nothing

The criteria repeated in buyer’s guides do not separate one studio from another, because every studio answers them the same way. A software house is a company that designs, builds, and maintains software to order — and practically all of them will show a portfolio, say they work in two-week sprints, and list the same team: project manager, analyst, UX/UI designer, developers, and a tester (QA). True answers, useless for comparison.

What separates studios is a question where an honest answer costs them something: it limits their freedom, lowers your cost of leaving, or hands you control over something they kept on their side. The seven below are built that way. Send them in writing, in identical wording, to every company you approach — only the answers laid side by side show anything. They do not replace a description of the project, so collect the scope, the roles, and the systems to integrate with separately, as set out in the guide on writing a software project brief.

Question 1: who owns the repository during the project and after it

The repository should belong to your organisation from day one, and the studio should receive permissions inside it — not the other way round. That means an organisation account on GitHub, GitLab, or Bitbucket registered to your company and your domain, the owner role on your side, and named accounts for the studio’s team that can be revoked with one click.

Apply the same test to the rest of the infrastructure: domain and DNS, hosting or the cloud account, the Google Play Console and Apple Developer accounts, the app signing keys, third-party service accounts, and payment gateways. You should be the account owner and the one the invoice is issued to.

A plain “of course the code is yours” is evasive too, as long as it skips whose account the repository sits on today and who holds the owner role. Owning the repository is not the same as owning the rights to the code: under Polish law, which governs the deal when you contract a Polish studio, an agreement transferring economic copyright must be in written form or it is void (art. 53 of the Polish Act on Copyright and Related Rights). The rest is unpacked in the guide on who owns the code. This material is information, not legal advice.

Question 2: will the people from the pitch deck actually work on the project

A specific answer is a named team list annexed to the contract, with each person’s role and declared time commitment, plus a clause saying that replacing a key person requires advance notice and a substitute of comparable experience. Without it you are buying a name from the deck and getting whoever happens to be free on the start date.

Three moves verify this: ask to speak with the person meant to run the project rather than a salesperson; ask how many projects that person runs in parallel and what share of their time falls to yours; ask them to lead the kick-off and prepare the first estimate. Someone who will genuinely be on the project asks about your process, not your budget.

Evasive answers sound like this: “we have a team of several dozen people and we will assign the best available ones”, “we guarantee appropriate experience”, “we will settle the team once we know the start date”.

Question 3: can I call one of your portfolio clients

A verifiable portfolio is one where the studio points at a project of comparable scale to yours, states its role in it, and arranges a call with the person who accepted that project on the client side. Screenshots and logos prove nothing.

Ask that reference four things:

• whether deadlines moved, and at what point they were told,
• who ran the project and whether that person changed along the way,
• what went wrong and how the studio fixed it,
• who maintains the system after launch, and on what terms.

Ask directly what share of the rollout the company delivered — subcontracting one part of somebody else’s project is sometimes presented as an own delivery, and that is a different level of responsibility. The evasive answer is “our NDA does not allow it” produced for every single case, or “our clients do not want to be contacted”: a confidentiality agreement can genuinely block one rollout, but a company running for years usually has someone willing to take a call. If you are also looking for a partner to handle search visibility, that is a separate intent with its own questions, collected in the guide on how to vet an SEO agency.

Question 4: what does handover look like if the engagement ends early

A specific answer is an exit plan written into the contract: a notice period, a closed list of what is handed over, and paid support for the incoming team for a defined time after the end. The documentation covers the source code, the specifications, and the user and developer documentation — plus a full set of access credentials, production data in an importable format, instructions for standing the environment up from scratch, and a list of dependencies with their licences.

The follow-up question: in the last two years, have you taken a project over from another company, and what was the biggest problem then. The answer shows whether the studio treats handover as a technical task with a list of steps, or as a subject it would rather not discuss.

Question 5: what exactly does the warranty cover, and who maintains the system after launch

A warranty with no definition of a bug is a declaration, not a commitment. Ask for four things in writing: what counts as a bug and what counts as a scope change; the response time and the fix time for each ticket category; the hours and the channel through which tickets are accepted; and what voids the warranty, for example code changes made by another party.

Ask separately about maintenance after the warranty period: hosting, monitoring, updates to dependencies and to mobile store requirements, and security patches. That is the line item that most often disappears from the first offer and returns as a cost a year later — what the delivery figure is really made of is broken down in the guide on mobile app development cost.

Evasive versions sound like “12-month warranty” with no definition of a bug, “we are always available for our clients”, and “we will firm up the support terms after launch”.

Question 6: will you agree to a code audit by a third party

A specific answer is consent written into the contract before kick-off, with the timing of the audit agreed and the payer identified — usually the client. Settle what the auditor gets: the repository with its full change history, the documentation, access to a test environment, and the list of dependencies.

The sensible moment for that review is the first working release: the architecture exists and there is still budget left for fixes. An audit after final acceptance is material for a dispute, not a repair tool. Where that moment falls in the schedule is shown in the guide on how to build a mobile app.

Evasive answers: “we have internal code reviews, an audit is not needed”, “it is a matter of trust”, “we will agree, but only after the project ends”, “an external auditor would learn our know-how”.

Question 7: what is your change-request procedure

A specific answer names the form of the request, the pricing deadline in business days, the decision-maker on each side, and the effect of the change on the schedule. Flexibility without a procedure means you learn what a change cost after the fact, on the invoice or in a moved deadline. The procedure looks different under a lump sum than under hourly billing, which is compared in the guide on fixed price vs time and materials.

Evasive versions sound like “we are flexible, we always work things out”, “small changes are included in the price” with no limit stated, and “that is a standard amendment” with no deadline for pricing it.

Send all seven questions in one message, in identical wording, to every company on your shortlist. The block below is ready to copy.

Compare the form of the answers as much as their content: who replied point by point and proposed contract wording, and who sent back a generic deck and an invitation to meet. If you are still putting your project description together, start that conversation with us — we will work through the goal, the scope, and the constraints first.