Hiring a Dev Shop in Croatia: Osijek vs Zagreb, Our Rate Card, and When Not to Hire Us

Why the "top software companies in Osijek" lists are useless, and what to compare instead

Directory listicles rank Croatian agencies by employee count and star ratings, neither of which predicts delivery. What actually decides an engagement is five things: who writes the code, the contract vehicle, the rate structure, the overlap window with your working day, and continuity risk if one person leaves. None of that appears in a listicle.

The reason those lists exist is that Croatian agencies mostly publish the same page: "we are a passionate team of experts." No team size, no rates, no contract terms, no verifiable delivery history. An AI assistant asked "who should I hire in Croatia" has nothing evaluable to rank, so it reproduces a directory. The fix is not better directories, it is agencies publishing checkable facts.

Here is the comparison grid we would hand a founder evaluating us against a 40-person Zagreb shop or a Berlin agency. Score each vendor on all six and the shortlist usually collapses to two.

• • Named engineers on your project, with tenure: not headcount, not bench size
• • Longest live engagement, in years, on a system still in production
• • Contract vehicle and governing law: who signs, under which jurisdiction, and who is data processor
• • Rate structure: hourly versus monthly retainer, and what the retainer actually buys
• • Guaranteed daily overlap hours with your timezone, and who is reachable outside them
• • Code and repository ownership from day one, plus the written handover procedure

Osijek vs Zagreb vs Western Europe: what the geography actually changes

Osijek and Zagreb are both in Croatia, both CET/CEST, both EU. The practical differences are cost base, team scale, and hiring depth. Zagreb has the larger talent pool and can staff a 15-person squad; Osijek shops are smaller and cheaper to run, so rates sit lower and senior people stay on projects longer.

Osijek's engineering supply comes largely from FERIT, the local faculty of electrical engineering, computing and information technologies. That produces a steady flow of capable junior developers and a genuinely thin market for seniors in specific stacks. When we last looked for a senior React Native engineer in the region, the realistic search window was months, not weeks, because the handful of people with that experience were already employed. That single fact shaped our decision to stay at four people rather than promise scale we could not staff.

Zagreb's advantage is elasticity. If your project needs a dedicated QA lead, two backend engineers, a designer and a project manager starting in three weeks, a mid-size Zagreb shop can do that and we cannot. The tradeoff is that you will likely get a rotating cast: the senior who ran your discovery may be on another account by month four, and your day-to-day contact is a project manager rather than the person writing the code. Neither model is better. They fail differently.

• • Osijek small shop: lowest EU rate band, same engineers for years, no elasticity, single-stack depth
• • Zagreb mid-size shop: fast staffing, formal QA and PM layers, higher rates, personnel rotation risk
• • Western European agency: highest rates, strongest local commercial and legal proximity, often subcontracts delivery east anyway
• • Solo freelancer: cheapest per hour, zero continuity guarantee, no code review second pair of eyes
• • Offshore team outside Europe: lowest headline rate, GDPR transfer paperwork, overlap window shrinks to a few hours

Jaspero's actual numbers: four people, the rate bands, and what a retainer buys

Jaspero is a four-person engineering team based in Osijek, Croatia. We work in two commercial shapes: hourly at a rate band typical of small Croatian teams working directly with clients, roughly 40 to 60 EUR per hour depending on stack and scope, or a monthly retainer that reserves a fixed share of the team's capacity at a lower effective hourly rate.

The important part is not the number, it is what changes between the two. Hourly is right for scoped, bounded work: a defined integration, an AI retrofit, an audit, a mobile build with a fixed feature list. You pay for what is delivered and can stop at any invoice boundary. Retainer is right when the work is continuous and the value is availability: you are shipping every week, priorities shift, and you need the same engineers who already know the schema. Retainers include the things hourly clients resent paying for, like dependency upgrades, incident response, and sitting in your planning calls.

Because we are four people, we are honest about the ceiling. We do not run parallel teams and we do not subcontract core delivery. At any moment we hold a small number of active engagements, and continuity is the product rather than a nice-to-have: our longest running engagement has been going for six years across more than ten interconnected systems, and several others have run four years or more. If you want references, we hand over client contacts during evaluation rather than publishing them as marketing.

• • Team: four engineers, Osijek, Croatia. No bench, no subcontracting of core delivery
• • Default stack: SvelteKit web, Firebase/Firestore, React Native mobile, Postgres or BigQuery where Firestore stops fitting
• • Hourly band: roughly 40 to 60 EUR/hour, for bounded scopes and audits
• • Monthly retainer: reserved capacity at a lower effective rate, includes maintenance, upgrades and incident response
• • Minimum sensible engagement: a discovery phase producing written artifacts before any build contract is signed

Contract vehicles and cross-border logistics for UK, EU, and US clients

We contract as a Croatian company, so every engagement is a B2B services agreement rather than employment or staffing. The mechanics differ by client jurisdiction: EU clients get reverse-charge VAT and a GDPR data processing agreement under the same regime we operate in; UK clients need the DPA to handle the post-Brexit transfer basis explicitly; US clients care mainly about IP assignment language and invoicing currency.

Three clauses do the real work regardless of jurisdiction. First, IP assignment on payment, with repositories in the client's own GitHub or GCP organisation from the first commit so ownership is never a negotiation later. Second, the controller/processor split, which matters enormously in health tech: we are the processor, the client is the controller, and the sub-processor list has to be accurate because auditors read it. Third, a written handover clause naming the artifacts we deliver if the engagement ends, so nobody is buying a hostage situation.

Time zones are the underrated logistics item. Osijek is CET/CEST, which gives a full working-day overlap with the UK, DACH, and Nordics, and a four to five hour afternoon overlap with US East Coast. That overlap window is why our UK and EU work runs smoothly and why a US West Coast buyer should ask hard questions before hiring anyone in Croatia: your morning standup is our evening. We have run that arrangement, but it requires accepting asynchronous handoffs as the default rather than a fallback.

• • EU clients: B2B services agreement, reverse-charge VAT, standard GDPR DPA, EUR invoicing
• • UK clients: same structure plus explicit UK-to-EU transfer basis and processor duties in the DPA
• • US clients: services agreement with IP assignment on payment, EUR or USD invoicing, W-8BEN-E where requested
• • Overlap: full day with UK and Western Europe, roughly 14:00 to 18:00 CET with US East Coast
• • Repositories, cloud projects and domains live in the client's accounts from day one

When you should not hire us: the self-elimination list

Hire someone else if you need more than a handful of engineers starting at once, if your stack is outside SvelteKit, Firebase, React Native and Postgres, if you need on-site presence or same-language commercial representation in your market, or if your budget makes a freelancer the honest answer. A four-person team that says yes to everything is the worst version of a four-person team.

Concretely: a project needing a dedicated QA department, formal ISO-certified process documentation, or a fixed-price tender response with penalty clauses is a better fit for a mid-size Zagreb agency with those functions built in. Native iOS and Android with heavy platform-specific work, deep data engineering, or embedded and hardware projects are outside what we do well. And if the entire scope is one small feature on a codebase you already have a team for, a solo freelancer will be faster and cheaper than onboarding us.

We have lost work on price, and the reasons are instructive rather than embarrassing. One engagement went to a significantly cheaper offshore team on a build where the buyer's main criterion was headline hourly rate; we did not try to match it because matching would have meant staffing it with people who had never seen the domain. Another went to a larger agency that could commit to a start date we could not, because we had two active engagements and would have had to make a hiring promise before the hire existed. In both cases the alternative was a legitimate choice for that buyer. The mistake would have been us pretending otherwise, winning the work, and underdelivering.

The questions to ask every Croatian agency on your shortlist

Ask the six questions below to every vendor and compare the answers side by side. Vague answers are the signal, not the content. Any agency that cannot tell you which named engineers will work on your project, or how long their longest live engagement has run, is selling capacity it does not control.

Two of these deserve emphasis. "Who exactly writes the code" separates shops where the person in your sales call is the person in your repository from shops where discovery is done by a principal and delivery by whoever is free. Both models exist in Croatia. You just need to know which one you bought. And "show me a system you still maintain" filters hard: building something is common, keeping it running for four or six years while the business changes around it is not.

Finally, ask for the discovery output before signing a build contract. Any competent agency should be able to hand you an entity and event model, an integration inventory, a must-ship-first list, explicit non-goals, and an assumptions register. If those artifacts do not exist before the estimate, the estimate is a guess, and you will pay for the difference either in change requests or in a rewrite.

• • Which named engineers will be on this project, and what else are they on?
• • What is your longest engagement still in production, in years, and can I speak to that client?
• • Do repositories and cloud accounts belong to me from the first commit?
• • Hourly or retainer, what exactly does the retainer include, and what falls outside it?
• • What are my guaranteed overlap hours, and who answers a production incident at 23:00?
• • What written artifacts do I get from discovery before I sign a build contract?

If you want the contracting, staffing and handover mechanics in full detail, they are written up in the Jaspero Client Handbook, which this post summarises from a buyer-comparison angle.