Building a website for a Belgian client from Croatia was not slowed down by the distance. It was slowed down by how decisions were made. On FESCA's site I had no single person on the client side to decide with, and project information lived in email, meetings and a Trello board at the same time. Both are now fixed in how I run every project.
The situation: one website for members in 18 countries
FESCA, the Federation of European Scleroderma Associations, brings together 23 associations from 18 European countries and is based in Belgium. It supports patients, educates the public and represents patients' rights before institutions. The site is in English because its audience is the whole of Europe, not one national market.
The proposal went out on 30 October 2024, and the site dates from 2025. The proposal, the mutual NDA and the contract were all in English. A mutual NDA is a confidentiality agreement that binds both parties the same way: each side protects what the other shares during the project.
The content had to serve very different readers. Someone diagnosed yesterday needs support in their own country, a researcher needs clinical trials and the European Patient Survey, and members and journalists look for something else again. You can see how I arranged that in the FESCA case study.
What a Belgian client expects to go wrong with a developer in Croatia
From Brussels, a developer in Zagreb looks like three risks: language, law and reachability. None of the three turned out to be where the time went.
Language was covered by the documents. Everything the client signed was in English, the language the federation itself works in. Reachability is a matter of the clock: Croatia and Belgium are both on Central European Time, so my working hours, Monday to Friday from 09:00 to 20:00 CET, are the client's working hours. London is one hour behind, which still leaves the whole UK working day inside that window.
Law took one clause. The contract named the courts of the country where the defendant has its registered office, so each side is sued at home. It was accepted without discussion. The formulation follows the general rule of the EU regulation on jurisdiction, under which a person domiciled in a Member State is sued in that State's courts (Regulation (EU) No 1215/2012, Article 4, accessed 24 September 2026). This is how I work, not legal advice for your contract.
What actually cost the time: decisions without one decision-maker
The mistake was that I did not have one dedicated person at FESCA to make decisions with. Several people were involved, and that is where most of the project's time went.
That is not a criticism of the federation. An organisation made of 23 member associations naturally has many stakeholders, and each of them has a fair claim on how the site presents patients, members and research. The problem was mine: I did not ask, at the start, who has the last word.
Without that answer, a decision is not finished when one person agrees. It is finished when everyone who might have an opinion has had the chance to give one. The waiting and the reconciling happen between the building, and they add up.
The second mistake: information in three places
I did not yet have my own client portal, so information was split between email, meetings and a Trello board. We sometimes lost track of what had been agreed where. When something was settled, the next question was which of the three channels it had been written down in.
None of the three tools is bad on its own. The trouble is that three channels have no single answer to the question ‘what is the current state?’. On a project with several stakeholders, that question comes up all the time.
What I do differently now
One named decision-maker is now the first organisational question at kickoff. The discovery checklist I use asks who approves, expects one person, and asks who has the last word if there are several. The proposal lists ‘one person authorised to approve’ under what I need from the client, and the contract asks the client to designate one person for feedback and approvals. Other people can still give input. The decision is one person's.
Information now lives in one place: the client portal. The client sees the phases and progress, and news posts with comments underneath. Materials are a checklist, each item with its own upload slot and a short instruction. Questions that do not belong under any news post go into their own threads, with a title, that are closed once the topic is settled.
Phase approval is where the portal answers the FESCA problem most directly. When a phase is ready, the client either approves it or sends it back with comments. Each decision is saved as a record that cannot be changed later, so ‘who approved what, and when’ has one answer. A phone approval still works, but the default is a click with a date attached.
The two fixes belong together. A portal with five people approving is still five people, and one decision-maker working across three channels still loses track. One person decides, and one place records the decision.
Two things that went the other way
Not everything moved from my process to the client. The English hosting and maintenance agreement signed with FESCA became the original, and my Croatian maintenance contract is derived from it. The FESCA NDA also contained an exception my Croatian NDA was missing: information the disclosing party has already made generally available, without restriction, is not confidential. The Croatian version now has it too.
If you are weighing a custom site for an organisation that speaks to several countries at once, the websites service page sets out the scope and the investment. What happens after launch is on the support page.
About the author
Jurica Stublić
Web designer and developer · 4 years · 50+ projects
I build custom web and mobile apps, web shops and websites, and I stay on the project after launch. Alongside client work I develop my own product: ai.webica.hr.
