In Haikyū!!, Hinata is too short to play volleyball at a high level. That's a fact; he isn't going to grow. So he doesn't work on his height: he works on speed, on his jump, on reading the game. The constraint doesn't disappear — it forces a different game, and that game ends up being unstoppable.
I'm not writing this to complain. The obstacles below are real, and I live them every week. But each one has an answer, and some of those answers made me better than I'd have been without the problem.
That's what's missing from most writing on the subject: the "here's what I do" part.
1. Power
The problem. Outages. Sometimes announced, often not. An hour, half a day. And the worst isn't the outage: it's the micro-cut that reboots the machine mid-build.
What I do. A UPS that holds the workstation and the router. A laptop whose battery life is a purchase criterion, not a bonus. And the rule that changed my life most: I commit early and often, on a branch, even when it isn't finished. An outage now costs me a forgotten git stash.
Total cost: a few hundred euros, repaid by the first incident avoided. This isn't comfort, it's the difference between "he sometimes disappears" and "he's reliable".
2. Data, not connectivity
The problem. Contrary to the cliché, fibre exists here and it's decent. What costs is volume.
An npm install on a React project is several hundred megabytes. A Docker image, one or two gigabytes. An Android SDK, more. When data is metered, every reflexive rm -rf node_modules becomes an expense.
What I do. Aggressive local caching: npm config set cache, a proxy registry, Docker images built in layers so only what changed is re-pulled. I don't delete node_modules "just to see". And I keep a mobile hotspot as backup, because a fibre outage on delivery day isn't negotiable.
Unexpected benefit: this discipline makes me attentive to the weight of what I ship. I notice oversized bundles because I download them. My users benefit.
3. Hardware
The problem. A decent machine costs the same here as in Europe, sometimes more with customs, against a very different local income. And repairs are a lottery: a part can take three weeks.
What I do. I buy less often and better: RAM and SSD over CPU, because that's what actually limits our workloads. I keep the old machine as a backup rather than selling it. And I use a genuinely low-end phone as a test device, not a flagship: that's what my users actually have.
That last point went from budget constraint to professional advantage. I see the screens that stutter because I suffer them.
4. Getting paid
This is the most concrete obstacle, and the least discussed.
The problem. Receiving a transfer from Europe or Canada means fees, delays, and sometimes a flat refusal. Some freelance platforms don't serve our countries. Some clients give up when they discover they can't pay through their usual process.
What I do. I keep several channels, never one, and I put them in the quote rather than discovering the blockage at the first invoice. I bill in euros or dollars with an explicit line on who bears the transfer fees — otherwise they're deducted from your amount and you find out by receiving less than expected.
The detail that changes everything: negotiate the fees in the contract, not afterwards.
5. The prejudice
The problem. At equal skill, the rate offered varies with where you live. It's called a "cost-of-living adjustment". It's a discount applied to geography rather than to the value produced.
And there's the initial mistrust: a developer in London gets the benefit of the doubt, I have to prove it.
What I do. I make the proof easy to observe. Ship small and often — three merge requests a week build more trust than one big monthly delivery. Write down what I'm doing, daily, in the ticket. Flag problems early.
And I don't undercut. A low rate attracts clients who are shopping on rate, and those are the hardest ones. That's the point that took me longest to understand.
After six months with a client, the prejudice disappears entirely. You just need to know you have to walk through it.
6. Isolation
The problem. No colleague to show a piece of code to. Few accessible conferences. A real but small local community. On a sharp problem, you're alone with the documentation.
This is the most insidious obstacle, because it's invisible and it wears you down slowly.
What I do. I write. These articles aren't only content: explaining something to someone remains the best detector of what you haven't understood. I ran a React Native study group where we reviewed each other's code — building locally what doesn't exist yet.
And I re-read my own diffs the next morning before merging. The delay is enough to recover a fresh eye. Imperfect, better than nothing.
7. Paperwork
The problem. Legal status, tax on foreign income, international invoicing, proof of income when a bank asks. None of it is taught, and the available information contradicts itself.
What I do. I keep everything, systematically: contracts, invoices, statements. One folder per client, per year. It looks excessive until the day someone asks for three years of history.
And I paid an accountant. It's the expense I put off longest and the most profitable one.
What the constraint actually gives back
I won't romanticise it: these obstacles cost time and money, and some are unfair.
But something real comes out. When your daily context includes power cuts, metered bandwidth and modest devices, you develop reflexes your colleagues don't have. You notice screens that block on a network call. You design apps that work offline because that's your life. You know what a Mobile Money payment really does when it fails.
Those reflexes benefit the whole product, London users included.
The constraint is a competitive advantage — provided you present it as one rather than apologising for it. It's Hinata's speed: it only exists because the height was missing.
To someone starting out here
In the order I'd do it again:
- UPS before second monitor. Reliability before comfort.
- A portfolio that shows real work — context, what you built, outcome. It works while you sleep, and it beats ten applications.
- Write. One serious article on a subject you know positions you better than a CV.
- A short engagement first. Nobody hands six months to a stranger; two weeks executed well open the rest.
- Settle the payment channel before the first invoice, not after.
- Don't undercut.
My full background is on the home page, and I've written elsewhere about working from Bafoussam for European clients. If you're starting out here and have a question, it's welcome.