How a localproject becomes aglobal one

These are different projects and teams confuse them constantly. Going wider means selling the same thing to more people who are broadly like your current customers. Going global means selling to people whose working week, payment rails, legal obligations and expectations of a vendor are not yours.

Wider is a marketing problem. Global is a product problem with a marketing bill attached. The reason to be precise about which one you are doing is that they have almost nothing in common operationally — wider needs more leads, global needs a product that does not quietly assume things.

Say it out loud in the first meeting, and write down which markets you mean by name. "International" is not a market. "The UK and the UAE by Q3" is.

The fastest diagnostic we know is to describe a customer's week in your current market in plain sentences, then hand it to somebody in the target market and ask which sentences are wrong.

It is remarkable what comes back. The working week starts on a different day. Invoices are expected before the work, not after. A phone number is the primary contact and email is the backup, or the reverse. A signature means a stamp. The price is quoted including tax, or it absolutely is not. None of these are in anybody's requirements document because at home they are not requirements, they are air.

Every wrong sentence is a piece of work. Collect them before you estimate anything, because the estimate built on the home-market week is the one that slips by a quarter.

Payments are not an integration, they are a market structure. The method people trust differs by country and so does what they consider normal — card on file, bank transfer, a local wallet, cash on delivery, an invoice with thirty-day terms. A checkout that offers only what worked at home converts a fraction of what it should and nobody can tell you why, because the people who bounced did not fill in a survey.

Currency is the easier half. The harder half is that pricing is positioning: the same number that reads as premium in one market reads as suspicious in another, and a straight conversion of your home price is almost always wrong in one direction or the other.

Build the money layer so the method is a configuration rather than a branch in the code. The second market is the one that teaches you this; the third is the one where you pay for not having learned it.

Translating the interface is the visible part and the smallest part. What actually breaks is everything around the words: a layout that was designed for a language that is thirty per cent shorter, a date that reads as a different day, a name field that assumes a given name and a family name in that order, an address form with the fields in the wrong sequence and a postcode that is mandatory in a country that does not use one.

There is a deeper version too. Tone is local. The confident, informal register that reads as friendly in one market reads as unserious in another, and the formal one reads as cold where the first one worked. This is not something a translation vendor fixes, because it is not a translation problem.

The engineering move is to stop hard-coding format. The product move is to have one person in each market read the whole thing and tell you where it sounds wrong.

In your home market you have accumulated trust without noticing: people have heard of you, somebody they know has used you, your address is a real place they can picture. None of that crosses the border with you. In the new market you are an unknown vendor with a foreign domain asking for a card number.

What substitutes for it is unglamorous and specific. A local phone number that a human answers. A named person on the website rather than a form. A customer in that market who will take a call. A page that states where you are, who runs the company, and what happens if something goes wrong. Published, boring, specific.

The mistake is to treat trust as a brand exercise. It is an evidence exercise, and the evidence has to be local.

A support promise is measured in the customer's working hours, not yours. "We reply within a day" means something very different when your day begins as theirs ends. The first bad review in a new market is almost never about the product; it is about waiting.

You do not need round-the-clock staffing to fix this. You need an honest, published window — these hours, this timezone, and here is what happens outside them — and then you need to hold it. A narrow promise that is always kept builds more trust than a wide one that is kept most of the time.

Where it does need to be covered around the clock, say so and staff it. Where it does not, stop pretending.

Where the data lives, what may be collected, how consent is captured, how long records must be kept, what must be shown on an invoice, who may be marketed to and how — these differ by market and they are gates. You do not launch and then comply.

The practical approach is to find out the three constraints that would change the architecture, and only those, before you build. Usually they are: where personal data may be stored, whether you need a local legal entity to take money, and what the invoice must contain. Everything else can be handled at launch. These three cannot, because each one is a rewrite if it arrives late.

Get an answer from someone local and in writing. The internet's answer to this question is confidently wrong about half the time.

The failure mode we see most often is three markets entered at forty per cent each. Every one of them is almost working, none of them is referenceable, and the team has three sets of half-solved problems to maintain.

One market, taken to the point where a customer there would recommend you to another customer there, is worth more than three partial entries — because the second market is enormously easier once you have a product that has stopped assuming, a payment layer that is configurable, and a reference somebody will actually call.

Order matters as well. Pick the first market for how close its working week is to yours, not for how big it is. The biggest market is the worst place to learn what you did not know you assumed.

Everything above is a decision, and the engineering follows it. That is the point I would most like to leave: going global is not a stack upgrade, a CDN, or a translation plugin. It is the discipline of finding the sentences in your own product that are only true where you happen to be standing.

Teams that treat it as infrastructure ship a fast, well-architected product that still assumes the wrong week. Teams that treat it as a question about people ship something slightly messier that works, and then clean it up with the revenue.