CentriWebOffshore software development means paying a team in another country, usually far away and in a different time zone, to build your software. It can lower the hourly rate, but it moves cost into places an hourly rate does not show: time zones, how precisely the work is specified, and who is accountable when something breaks.
This article is for owners deciding between a local developer and an overseas one. It does not claim either is better. It sets out where the savings come from, where the costs reappear, and what to check before you sign. It gives no rate comparisons, because rates move and differ for every team.
Offshore, nearshore and onshore: what the terms mean
- Onshore: a team in your own country, working in your time zone and under your country’s law.
- Nearshore: a team in a nearby country with a similar time zone, so working hours overlap.
- Offshore: a team in a distant country, with little or no overlap in the working day.
Each suits different projects. The right question is not which is cheapest but how much of the work depends on talking to the team during your day.
Where offshore software development saves money
The savings are real in three places. The hourly or daily rate may be lower where living costs are lower. A team may be able to start sooner or grow faster than a local one. And you may reach skills that are scarce at home.
That last point matters. If a local team simply cannot be found for what you need, the comparison is not a price comparison at all.
Where the cost comes back
A lower rate only saves money if the hours stay the same. Hours go up when any of the following happens.
- Waiting. A question sent at the end of your day gets an answer at the start of theirs, and the team may be stuck for a day. A project with many small questions can lose a lot of time this way.
- Misunderstanding. Language, business customs and assumptions about how your industry works all differ. A rule that is obvious to you may never have occurred to them.
- Rework. If the specification is thin, the team builds what it understood, you see it a week later, and part of it is redone.
- Your own time. Early-morning or late-night calls, extra review and chasing all cost you time that does not show on the invoice.
- Handover and turnover. If the people who built it leave the team, the next ones have to learn it from the code alone.
Worked example: a time-zone overlap that is too small
Suppose your business runs from nine to five and the team you are considering works a day that overlaps with yours by only one hour. The example is invented, but the pattern is common.
In that hour you can ask and answer a handful of questions. Anything unresolved waits for the next day. If a feature needs six questions, that is potentially six days of waiting. Now suppose the same project is written down so precisely that only two questions arise. The delay drops to two days, and the rate saving is real.
So the overlap you can afford depends on how well the work is specified. That brings us to the part most buyers skip.
Specifications matter more offshore
When a team sits down the corridor, a vague brief gets sorted out by walking over and asking. When the team is twelve hours away, every ambiguity costs a day. An offshore project needs the requirements written down before work starts, with examples, sample data, and testable statements of what done means. Our guide to the software requirements document shows the sections to include.
If you cannot yet describe what you want in that detail, you may be better off with a team close enough to work it out with you, then hand the clear plan to anyone, anywhere.
Accountability: who answers when it goes wrong
This is where the arrangements differ most. Check each of these in writing before work starts.
| Question | Why it matters |
|---|---|
| Who is the contracting party, and in which country? | It decides which courts and which law apply if you disagree. |
| Who owns the code and the data? | Some contracts leave ownership with the developer until paid in full, or reserve rights to reuse parts. See who owns the code. |
| Who holds the hosting and third-party accounts? | They should be in your name, so you can change provider without permission. |
| Who fixes faults after launch, and how fast? | A fault at 3pm your time may be in the middle of the night for them. Agree the cover in advance. |
| Where is customer data stored and who can see it? | Privacy rules for personal data differ between countries, and some limit sending it abroad. Check the rules where your customers live. |
| What happens if the team changes? | You want named people, notice of changes, and written handover notes. |
Not legal advice: contracts that cross borders deserve a lawyer in your own country to read them before you sign.
When offshore software development works well
- The scope is clear and mostly stable.
- You have someone in your business who can answer questions quickly and make decisions.
- The work is largely self-contained, such as a defined feature or a well-documented component.
- You or an adviser can review the code and the test results.
- You have worked with the team before, or you are starting with a small paid trial.
When it tends to go badly
- The idea is still forming and the requirements will change weekly.
- Nobody on your side has time to answer questions or review work.
- The project depends on deep knowledge of your local rules, such as tax, building or health regulations in your country.
- The price is far lower than every other quote and nobody can explain why.
- You cannot see the code or the working software until the end.
See also why software projects fail, since the common causes apply wherever the team is.
A sensible way to test the arrangement
Start with a small, paid piece of work: one defined feature with clear acceptance tests. It shows you how the team asks questions, how often it shows progress, how it handles a change, and whether the quality is what you expected. It costs little if it goes badly and tells you a great deal if it goes well.
Ask for working software in small steps and look at it each time. A team that shows you a working screen every week or two is far less likely to surprise you at the end than one that disappears for two months.
Questions to ask an offshore team before you sign
- Who exactly will work on my project, and will those people stay on it?
- How many hours a day overlap with my working day, and what will we do in that time?
- How do you handle a change to the scope in the middle of the work?
- Can I see working software every week or two, on my own test site?
- How do you test, and can I see the results?
- Will the code, hosting and accounts be in my name from day one?
- What support do you offer after launch, and in whose working hours?
Clear, specific answers are a good sign. Answers that avoid the question or promise everything are not.
Keep a record of every decision and answer in a shared document, with dates. Across a time difference, the record is what stops the same question being asked and answered twice, and it protects both sides if a disagreement comes up later.
A middle option
Some businesses use a studio that works with them in their own time zone and language and is accountable for the whole system. CentriWeb is a founder-led studio in New Zealand working online with businesses worldwide, and we build custom software with one team responsible for the whole system. That is one option among several, and for a well-specified, self-contained piece of work an offshore team can be the right call. For the building cost side of the decision, read our guide to custom software cost.