Why Romania keeps appearing on shortlists
Four practical reasons, none of them about being cheap.
- Romania is in the EU. Contracts are governed by EU law, invoicing follows intra-EU rules, and there is no separate data-transfer regime to negotiate — your DPO will not ask you to complete a questionnaire about international transfers.
- GDPR is the local default. Romanian studios have operated under GDPR since the regulation came into force, so data processing agreements, retention rules and subprocessor lists are part of routine discussions rather than an education project.
- A strong technical education base. Romania has long-established technical universities and a large, mature outsourcing and product sector, which means there are enough senior engineers who are used to working with international clients.
- Time zone overlap that actually works. Romania is on Eastern European Time, so a Romanian working day overlaps almost completely with Western Europe and covers the morning on the US East Coast. That is enough for a daily stand-up with teams in either region, without asking anyone to work nights.
English is standard in the industry, and for European clients the cultural distance is small — but treat both as things to verify in a conversation with the actual engineers, not as claims to accept from a landing page.
Pick the engagement model before you pick the studio
Most bad engagements start with the wrong commercial or contractual model, not the wrong people. Four models cover almost everything.
- Discovery — a short, paid, fixed-price phase that ends with a technical plan, a scope, an architecture sketch and an estimate. Use it whenever the requirements are still being discussed. It is also the cheapest way to test a studio: you find out how they think before you commit a significant budget.
- Fixed-price MVP — appropriate only when the scope is genuinely well defined and the acceptance criteria are written down. Fixed price does not remove risk; it prices it. Expect a studio to add a margin for uncertainty and change requests to be slow and formal.
- Time and materials — the honest default for evolving products. Manage it with a sprint budget cap, a clear priority owner on your side, and a working demo every iteration. Without those three, T&M is where budgets quietly disappear.
- Embedded team — one or more engineers integrated into your process, your board and your reviews. Best when you have in-house technical leadership and need capacity, not direction.
A studio that pushes one model for every problem is telling you something about their operations rather than about your project.
Vet the engineering, not the deck
Case studies are marketing materials. What you want is evidence of how the work is actually done, and there are a few reliable ways to get it.
- Ask for a code sample and review it — a real repository under NDA, or a representative extract. You are not looking for beautiful code. You are looking for real tests, commit messages that explain intent, reversible migrations, secrets that are not stored in the repository, and a README that lets a new engineer set up the project and start work.
- Ask how a change reaches production. The answer should be specific: branch, review, CI, environments, migrations, rollback. Vagueness here predicts most of the problems you will have later.
- Ask what they did when something went wrong. Every real team has an outage or a bad estimate story. A team that has none has either not shipped much or is not being straight with you.
- Give them a small paid trial task on your real codebase or a realistic problem. Two days of paid work tell you more than four calls, and the cost is low compared with making the wrong choice.
- Ask what they would refuse to build. A partner with no opinions is merely an implementer, and you can hire one more cheaply.
Find out who actually does the work
This is the single most common gap between the sales and delivery processes. Get the details in writing before signing.
- Names and seniority of the people who will be on your project, and how much of their week you get.
- Whether any of the work is subcontracted, to whom, and under what agreement. Subcontracting is not automatically bad, but discovering it in month three is.
- Whether the person who impressed you in the pitch will be writing code, reviewing it, or neither.
- What happens when someone leaves or is reassigned: notice period, handover, and who takes over the knowledge and project context.
Then insist on talking to the engineers, not only to a delivery manager. A twenty-minute conversation with the person who will do the work is the most revealing one in the whole process.
Communication cadence
Nearshore removes the time-zone excuse, so what remains is discipline. Agree the cadence explicitly and treat drift from it as an early warning.
- A working demo on a regular schedule — weekly or fortnightly, in a real environment, not a screen recording.
- A written weekly note: what shipped, what is blocked, what changed in the plan, what is needed from you. Two paragraphs are enough; the absence of the note is not acceptable.
- Your own access to the repository, the issue tracker, the CI and the staging environment, from week one. If you cannot see the work in progress, you are being kept at a distance rather than treated as a partner.
- A named decision owner on each side, and a defined response-time expectation. Most delays in nearshore projects are caused by waiting for the client to answer, not by slow engineering.
Contract, IP and data protection
Commercial documents protect a good engagement and make a bad one expensive.
- IP assignment must be explicit and in writing. Under Romanian and EU copyright rules, paying an invoice does not by itself transfer copyright — the contract has to assign it, and it should cover code, designs and documentation.
- Ownership must vest on payment for work delivered, not at the end of the whole project. If an engagement ends early, you should still own what you paid for.
- Third-party and open-source components should be listed, with their licences, so no copyleft-licensed code enters your product by accident. Ask how that list is maintained.
- A data processing agreement under GDPR, naming subprocessors, retention periods and the security measures in place. If your product processes personal data, this is not optional, and a serious studio will already have a template.
- Confidentiality that covers the engineers individually, not only the company.
- An exit clause: what you receive on termination — repositories, infrastructure access, credentials, documentation — and within how many days.
This is an engineering perspective on what to look for, not legal advice. Have the contract reviewed by a lawyer qualified in the relevant jurisdiction before signing.
Security basics worth asking about
You do not need a certification programme to ask sensible questions. The answers tell you a lot about operational maturity.
- How are your production credentials handled? The correct answer involves a secrets manager and scoped access, not a shared document.
- Who has access to production data, and is there any reason for a development environment to contain real customer records?
- Are laptops encrypted, is multi-factor authentication enforced for repository and cloud accounts, and is access removed the day someone leaves?
- How do dependency updates and security patches get applied after the project ships, and whose job is that?
Red flags
- An estimate produced without questions. A serious estimate follows a discussion about scope, constraints and unknowns; anything else is a number chosen to win the deal.
- An unwillingness to start small. A studio confident in its work will accept a discovery phase or a paid trial.
- The team you meet is not the team you get, and the studio refuses to put names in the contract.
- No access to the repository or the environment while work is ongoing.
- Every question is answered with "yes, we can do that". A partner who never pushes back is not evaluating your problem.
- A portfolio with no technical detail and no verifiable reference you can contact, in a market where NDAs are the normal reason details remain private — the honest phrasing is "private engagement, details under NDA", not silence.
- Pressure to sign quickly, or a discount that expires. Software engagements are long; pressure in the sales process is a poor indicator of delivery speed.
What a well-run first two weeks look like
By the end of week two, in a well-run engagement, you should have all of the following. If you do not, raise the issue immediately rather than waiting for the first missed milestone.
- A running environment with something real deployed to it — even if it is a skeleton, the deployment process is demonstrated early, not at the end.
- A written scope and plan for the first milestone, with the assumptions and the open questions stated explicitly.
- Repository, tracker, CI and environment access for your side, plus a named contact on theirs.
- The architecture decisions that are expensive to reverse, written down with their rationale: data model, tenancy, authentication, hosting.
- A demo of whatever exists, and a written note listing what changed in the plan once the work began. Something always changes.
Vetting checklist
- Engagement model chosen deliberately, and matched to how settled the scope really is.
- Code sample reviewed by someone technical on your side.
- A specific, concrete answer to "how does a change reach production?".
- Named engineers, their allocation, and any subcontracting disclosed in writing.
- A direct conversation with the people who will do the work.
- Agreed demo schedule, written weekly note, and your own access from week one.
- IP assignment on payment, in writing, covering code, designs and documentation.
- A GDPR data processing agreement with subprocessors and retention periods specified.
- An exit clause listing exactly what you get back and when.
- A small paid trial before a large commitment.
Use this list to assess any studio, in any country. A partner worth hiring will find the questions reasonable — and will usually have most of the answers ready before you ask.