How a Ukrainian studio works with foreign clients

A company in Germany, the Netherlands or the United States looking for a development team sooner or later comes across proposals from Eastern Europe. The rate is noticeably lower than at home, the portfolios look decent, and the first question that arises is what the catch is.

There is no catch in the rate itself. What matters is whether the process is arranged in a way that lets a team a few time zones away actually deliver. Below is how that works in practice, told from the contractor’s side, without the usual sales gloss.

Why companies look for a contractor abroad

The reason is almost never only the rate. A lower price alone would not justify the inconvenience of distance.

• Availability. In many European cities a small studio is booked out for months ahead.
• Team size. A task that needs three people for six weeks is awkward to hire for locally.
• Narrow expertise. Something rare is needed once, not permanently.
• Support after launch. Local rates make a maintenance agreement look expensive.
• A second opinion. An external team looks at an existing project with fresh eyes.

The rate matters too, mostly for what it makes possible: the same budget buys either fewer local hours or a complete project abroad.

What the process looks like from first email to release

The estimate and why it is preliminary

The first reply to an inquiry is never a final number, and any contractor who gives one is guessing.

A preliminary estimate is a range. It is built from what is already clear from your description: the number of page types, whether there are integrations, whether the design exists, whether content is ready. The range is deliberately wide, and its lower and upper edges differ by a factor of two or more.

That range narrows after the second conversation, once the questions have been answered. What removes the uncertainty most is described in our article on what to prepare before talking to a studio, and the factors that move the final number are covered in our article on what determines the cost of website development.

Stages, demonstrations and feedback

Work is split into stages, and each ends with something you can look at rather than a status report.

The usual sequence is structure, then design, then build, then content, then testing, then release. On a small project some of these merge, on a large one each splits into several parts. Work that does not fit a template, such as an integration with the client’s own system or a tool built for one company, follows the same stages but with a longer research step at the front, and that is the shape custom web development usually takes.

Between stages there are demonstrations. For each one you get a working test copy at a link you can open on your own phone. Written descriptions of an interface are interpreted differently by the two sides, and a link removes the disagreement in a minute.

Feedback is collected in one place, in writing, with numbered items. Comments scattered across three chat threads and a phone call are the main cause of “we agreed on something else” arguments at handover.

Language is worth settling at this point too. English is the working language of the correspondence, the documents and the interface labels, and that is rarely a question. What does need agreeing is the language of the site itself when it differs from English, because someone has to check the wording, and that someone is usually on the client’s side. A build waiting three weeks for a native speaker to review the German text is a common and entirely avoidable delay. What exactly adds to the cost once there is more than one language is covered separately in our article on what adds to the cost of a multilingual website.

What happens between stages

The plan of work does not show it, but approvals take up a large part of the calendar.

Between the delivery of one stage and the start of the next there is a review, and how long it lasts depends on the client alone. A contractor can produce the design in two weeks, but if the comments on it take three weeks to come back, the stage takes five weeks instead of two.

That is why a plan usually carries two figures, the time the work takes and the time set aside for approvals. The second is often the larger one, and it is better seen in advance than discovered at the end.

Give every stage a fixed day on which you send your feedback, and keep that day the way you expect a contractor to keep a deadline. It is the one lever for speeding the project up that sits entirely on your side.

Time zones and the rhythm of communication

Kyiv is one hour ahead of Central Europe, two ahead of London and roughly seven ahead of New York. Working hours are Monday to Friday, nine to six Kyiv time.

For a European client that means almost a full overlap and there is nothing to arrange. For an American one the overlap is short, because the East Coast morning coincides with the end of our working day. The work therefore follows a fixed rhythm:

• One synchronous call a week. Enough for a project running to plan.
• Written status updates. Sent so they land at the start of your day.
• Questions batched, not drip-fed. So an answer is not needed within the hour.
• A written record of decisions. So a verbal agreement does not evaporate.
• A clear response window. When a reply is expected and when it is not.
• An agreed channel for urgent matters. Separate from the everyday one.

The overlap being partial is even an advantage on a long build. Work happens while you sleep and the result is waiting in the morning. It stops being an advantage only when something needs a decision every two hours, which is why the process aims to avoid that.

Paperwork and payments

This is where most of the anxiety sits, and in practice it is the most routine part.

Electronic signatures are the norm. Paper originals are exchanged only when the client’s own accounting requires it.

Payment by stages protects both sides. You do not pay for work that has not been done, and the contractor does not take on months of work with no cover. A one-hundred-percent advance is as much a warning sign as a demand for full payment only after release.

Who owns the code and the access

The short answer is that the contract spells out what passes to the client on full payment. Payment alone does not transfer rights; the contract clause does. The longer answer is the list itself.

• The source code. All of it, not just what was compiled.
• The design files. In an editable format, not only as images.
• Domain and hosting access. Registered to the client, not the contractor.
• Third-party service accounts. Analytics, mail, payment provider.
• Documentation. How it is deployed and how it is updated.

A separate point concerns third-party components. Almost any site uses ready-made libraries and extensions, and those remain under their own licenses. That is normal and does not restrict you, but if a paid extension was bought for the project, the license must be registered to you rather than to the contractor. Otherwise it stops receiving updates the day your work with the contractor ends.

The full list of what to check at handover is in our article on the website handover checklist.

Confidentiality and working under NDA

On larger projects an NDA is signed before the details are discussed.

As a result, the client’s name and the project’s specifics do not appear in the portfolio, in case studies, in conference talks or in conversations with other clients. The technical side is enforced too: access is granted only to the people working on the project, and it is revoked when the work ends.

An NDA also works in the other direction. Anything the client learns about the contractor’s internal processes stays inside the project. That part is rarely used, but it makes the document mutual.

What to show instead of case studies when the client cannot be named

This is the awkward part of working under NDA. The most substantial projects are exactly the ones that cannot be shown.

• A description without identifying details. The task, the approach, the outcome, no names.
• Technical decisions. What was built and why that way.
• Figures the client allows. Sometimes a metric may be quoted without the source.
• Open projects of similar complexity. Different industry, comparable scale.
• A reference by phone. Some clients agree to that even under NDA.

If a contractor shows nothing at all and explains it entirely by confidentiality, that is worth questioning. A complete absence of showable work usually means something other than an abundance of NDAs.

How to test a contractor before a large project

The safest approach is not to start with a large project.

A small paid task shows more than any interview. It does not have to be part of the future project; it can be a separate job with its own budget and deadline. What you learn from it costs far less than learning the same thing three months into a big build.

What such a task reveals is straightforward. Whether the deadline was met and whether you were warned in advance if it was not. Whether questions were asked before starting or assumptions were made. What the code looks like when handed over. How comments were handled, and whether the same remark had to be made twice.

Also ask who exactly will build your project. At Amidcode, every project is handled by our own designers and developers, and a dedicated project manager stays in touch with you from brief to launch.

The criteria for choosing a team, and the signals worth reacting to early, are gathered in our article on how to choose a web agency.

Risks worth asking about at the start

Asking directly is better than discovering later. A contractor who answers these calmly is a better sign than one who treats the questions as distrust.

• What happens if the deadline slips. Delays happen, so ask what is done when one occurs.
• Who continues the work if the developer leaves. Whether anyone else knows the project.
• Where the code is kept. In your Git repository if you have one, or in ours, with access for you on request.
• What happens after release. Whether errors are fixed and for how long.
• How the project ends. The procedure for handing everything over.

Clients ask about the war too. Teams work with backup power, backup connectivity and staff distributed across cities and countries. Interruptions happen, are usually measured in hours, and are covered by the same principle as any other risk. The project must not depend on one person or one location.

What you get when the work is finished

Release is not the end of the relationship, but it is the point at which nothing should be outstanding on either side.

You get a working site, the access to it, the source files, the documentation and an invoice with nothing outstanding. The contractor gets full payment and, if the project is not under NDA, permission to show it.

What happens next is a separate decision. Some clients move to a maintenance agreement, others take the project to their own team, others come back a year later with a new task. All three are normal outcomes, and none of them should require negotiating your way out of anything.

Cost and how it is billed

Work outside a fixed-scope project is billed hourly, $25/hr. A project with a defined scope is quoted as a fixed price by stages.

The hourly model suits work where the scope cannot be fixed in advance: research, integrations with somebody else’s system, improvements to an existing project. A fixed price suits a build with a clear result. Mixing them within one agreement is where most disputes begin, so they are usually separated from the outset.

Conclusions

The real difficulty in working with a contractor abroad is ambiguity. A team on the other side of the continent that works in stages, demonstrates results at a link and records changes in writing is more predictable than a local one that reports verbally.

Everything described above is a process rather than a promise, and a process can be checked before a large budget is committed.

If you are considering a contractor from Ukraine and want to understand how it would work in your case, write to us with a description of the task and your constraints on deadline and budget. We will reply with a preliminary range, a list of the questions that would narrow it, and a suggestion for a small first task if you would rather begin by testing the process than by signing for the whole project. Development of this kind is what we do as custom web development.