Why choosing the vendor is 80% of a project's success
Failed IT projects rarely fail because of technology. Most often it is a badly chosen partner: no understanding of the business, chaotic communication and a scope that grows unchecked until the budget runs out halfway through.
The market is wide — from one-person freelancers to companies with several hundred staff. Prices can differ several times over for a seemingly identical scope, and the difference almost never comes from greed, but from the fact that everyone is pricing something different.
This guide is a list of things worth checking before you sign a contract.
Four types of vendors and when each makes sense
Freelancer
Cheapest and fastest for a small, well-defined task. The risk: one person is a single point of failure — illness, another project or a job change stops everything. Rarely covers design, backend and maintenance at once.
Small software house
A team of 5–30 people. Handles the project end-to-end, and you usually talk to the people who actually work on it. The limitation: less resilience when several large projects run at once.
Large company
Resources, processes and resilience to staff turnover. Costs more, and your project can be one of many — with lower priority if it is not the biggest in the portfolio.
Intermediary
A company that takes the order and hands it to a subcontractor. It can make sense, but you need to know about it — ask directly who writes the code and where that team sits.
What to look for in a portfolio
Real deployments, not mock-ups
Ask for links to working products and results in numbers, not just Behance screenshots. For comparison, see how we present our projects — with scope, technologies and results.
Projects similar to yours
A company that has built five booking systems will build the sixth faster, cheaper and will avoid pitfalls others do not know about yet.
A stack that can be maintained
Popular technologies (React, Node.js, React Native) mean you will easily find developers in the future — you are not locked in to a single vendor.
References with a contact
A good software house will not hesitate to give you a client you can call and ask what the cooperation was really like.
7 questions for the first meeting
The answers to these questions will tell you more about the company than any sales presentation:
Who will actually work on my project? — The team from the sales pitch and the team on the project are a frequent mismatch. Ask to meet the people who will actually write the code.
What does the process from idea to launch look like? — Look for specifics: workshop, mock-ups, iterations, testing, deployment. No clear process is a preview of chaos.
How often will I see progress? — A good answer: a working demo every 1–2 weeks. A bad one: "we'll show you everything at the end".
What happens when the scope changes? — The scope ALWAYS changes. An honest company will describe the change-pricing process rather than promise that "nothing will happen".
Who owns the code? — The code, repository and access should be yours — written explicitly into the contract, not "to be agreed later".
What does maintenance after launch look like? — A product without care dies. Ask about response times, maintenance rates and who picks up the phone when something breaks.
Why this technology? — A good company justifies the stack with your project and your budget — not with whoever happens to be available.
How to read a quote
A quote with a single number cannot be compared with any other. A reliable offer breaks the cost down into stages and explicitly lists the assumptions it rests on.
Fixed price makes sense for a smaller, well-defined scope. It is clear what is being built, so it can be priced fairly.
Time and materials is right for longer projects. A fixed price for a system that takes several months means either a thick risk buffer built into the amount, or negotiating an annex at the first scope change. The condition is regular insight into progress — a working demo every one or two weeks.
Beware of an offer clearly cheaper than the rest. It usually means a narrower scope hidden in the assumptions, no testing, or billing everything not explicitly listed as extra work. You will pay the difference later, with no room to negotiate.
Six things that must be in the contract
Not as a formality — each of these points resolves a dispute that genuinely happens:
Transfer of rights to the code — Economic rights should pass to you explicitly, together with payment for each stage. Not "to be agreed after the project ends".
Access on your side — The repository, hosting, domain and app store accounts should be created with your details. Recovering them later from a former vendor can take months.
A described scope — A concrete list of what is being built. Without it, every conversation about what was supposed to be done is word against word.
A scope-change process — The scope always changes. The contract should describe how a change is priced and approved — not promise there will be no changes.
Warranty — What it covers, how long it lasts and how a warranty bug differs from a new feature. This is the most common area of dispute after launch.
Rules for ending the cooperation — Notice period and what you get on exit: code, documentation, access and knowledge transfer. You check this clause when things are already going badly.
Three technical questions worth asking even if you are not technical
"What technologies will you build this in, and why those?" You are looking for a justification based on your project, not on what the company likes. Popular technologies — React, Node.js, React Native — mean you will find other developers in the future. A niche choice can tie you to a single vendor for years.
"What happens to the project if we stop working together?" A good answer describes the handover: repository, documentation, access, a meeting with the new team. An evasive answer is a warning sign in itself.
"Who will maintain this after launch and on what terms?" A product without care dies — system updates, libraries, security patches. Ask about response times, rates and who actually picks up a ticket at two in the morning.
Warning signs
No matter how well a company performs in the meeting — stay alert with these signals:
A quote without asking questions
Nobody can reliably price an app after a single e-mail. A quick "quote out of thin air" means you will learn the real cost during the project.
"Everything is possible, no problem"
No questions about priorities and trade-offs means the scope and budget will drift. A good partner also says "no" and proposes cheaper alternatives.
No contract describing the scope
Working "on trust" ends in a dispute about what was supposed to be done. Scope, schedule and change rules must be in writing.
Contact only through a salesperson
If you cannot talk to anyone technical before signing the contract, it will not get easier after signing.
Comparing software house offers?
Send us your brief — we will show you how we would approach the project, with what team and at what cost. No obligation, within 24 hours.
Local or remote?
Good news: it is not an either/or choice. Working with a company near Poznań gives you the option of meeting in person at key stages — the discovery workshop, important sign-offs or planning the next phases — while day-to-day work runs online anyway, in short iterations with regular demos.
Our office is in Dąbrówka, a few minutes from the western edge of Poznań, so a meeting over coffee is our standard, not an exception. We work remotely with clients from all over Poland and abroad, and you can see our deployments in our projects.
Frequently asked questions
How much do software house services cost in Poland?+
Software house or freelancer?+
Do I have to be based in Poznań to work with Just Site?+
Do I need to understand technology to choose well?+
How long should a quote take?+
Is it worth choosing a vendor nearby?+
Have a project in mind?
We’ll help you design and deliver it — from strategy to a finished solution.
