Working with a Polish software studio: what the guides leave out
Every guide to nearshoring in Poland is written to make nearshoring in Poland sound easy. This one is written by a Polish studio and covers the parts those guides skip — including the ones that argue against hiring us.
The three things that actually matter
Most articles on this subject open with salary comparisons. That number is the least useful thing in the decision, because it says nothing about whether the work will be any good or whether you will still own it in three years.
Three things decide whether this arrangement works: how many hours a day you overlap, who owns the code and the data, and whether anyone besides the original author can run the system. Everything else is negotiable.
Time zones: the honest arithmetic
Poland is one hour ahead of the UK. In practice that means a Polish team is at its desk from roughly 08:00 to 16:00 London time — a seven-hour overlap with a standard British working day, and a full one with the morning.
This is the genuine advantage over further-shore arrangements, and it is worth being precise about why. It is not that more hours overlap. It is that the overlap covers the start of your day, so a question asked at nine has an answer by ten rather than tomorrow.
The cost is real too: after 16:00 London time you are on your own unless something is agreed in writing. If your business has its worst hours on Sunday evening, that needs to be in the service agreement, not in someone's good intentions.
The legal part is duller than people expect
Poland is in the EU, so a UK company buying software services from a Polish company deals with the same paperwork as buying from any EU supplier: reverse-charge VAT, an invoice in euro or pound, and GDPR applying to personal data by default rather than as an extra.
The part worth reading carefully is not tax. It is copyright transfer. Under Polish law, economic rights to software have to be transferred explicitly, in writing, and the contract has to name the fields of use. A contract that says the client «receives the software» without that clause may leave the rights with the contractor — not out of malice, but because the wording was copied from a template.
One question to ask any Polish contractor: «Which clause transfers the economic rights, and which fields of use does it name?» An answer that points at a specific paragraph is a good sign. An answer of «it is all in the contract» is not.
What we would ask, if we were you
- Who will actually write this? Not the account manager. The names, or at least the number of people and their role. In a small studio this is a short answer; in a large one it is often evasive.
- What happens when the person who built it leaves? A studio that cannot answer this has a bus problem and has not thought about it.
- Can we see something you built that is live right now? Not a case study PDF. A working address we can open.
- What did you last tell a client not to build? Anyone who has never talked a client out of a project has been selling, not advising.
- Where will the data physically sit, and can we export it ourselves?
Numbers from our own work, so this is not just opinion
We are a small studio, so our evidence is specific rather than broad. Three examples with figures that can be checked against the systems themselves.
A live shop was moved to a different architecture: 43 943 orders, 9 335 customers and 738 URL redirects carried across with no discrepancy between the old and new state. For an e-commerce operation, complaint handling went from about four hours per case to fifteen minutes, with a working version in 27 days. A booking system replaced a commission-taking intermediary and now runs in eight languages, with the page loading in 0.36 seconds against 1.16 before.
What those numbers do not tell you is how many projects we turned down, or the two that took longer than we said they would. Any studio quoting only its best figures is quoting a selection.
When a Polish studio is the wrong answer
This section exists because the guides do not have it.
- When you need people on site. Some work genuinely requires being in the room — a warehouse floor, a factory line, a regulated environment with physical access controls. Video calls do not cover this.
- When the requirement is not written down anywhere. Distance amplifies ambiguity. If the specification lives in one person's head and that person is busy, the first month will be spent guessing.
- When you need forty people by next quarter. A small studio cannot do that, and one that says it can is subcontracting to people you have not met.
- When the deciding factor is the day rate. If price is the only axis, someone will always be cheaper, and you will end up managing the difference yourself.
How this usually starts
Not with a specification. It starts with a description of a process that is slowing the business down — written in ordinary language, by the person it slows down. From that we can usually say within a few days whether building anything is justified, roughly what it would involve and how long it would take.
Sometimes the answer is that an existing tool does ninety per cent of it and the remaining ten can be handled in a week. We would rather say that early than three months in.