For agencies and studios
You sold the work.
I write the code behind it.
I am one senior engineer who works white label for design agencies and studios. You keep the client, the invoice, and your name on the work. I stay behind the scenes and build the thing you already sold.
A written reply within 24 hours. No call unless you want one.
When this is useful
If a project is sitting approved and nobody on your team is free to build it, that is the gap I fill. You do not want to turn the work away, and you do not want to hire for a spike that ends in three months.
Same if you sell design and hand the build to whoever is around, and the result comes back late or held together with tape. You can hand it to one senior engineer instead, and keep selling without growing headcount.
How it works
White label, in practice
The client relationship stays yours
The contract is between you and your client. The invoice is yours. My name is not on the repo, the commits, the standups, or the handover. As far as the client sees, your team built it.
I work inside your process
Your GitHub, your board, your branch naming, your review bar. I already work day to day inside a US company's engineering process, so this is the normal way I operate, not a favor.
Requirements come through you
You hold the client thread. Requirements come to me through your team, and questions go back the same way. That is the part that keeps white label actually white label.
What it costs you
One layer of translation
White label is not free on your side. Requirements come through you, questions go back through you, and someone on your team holds the thread with the client. That is real work, and it is the price of keeping your name on the project.
Agencies that try to skip it by putting me in front of the client usually find the white label part quietly stops being true. So I would rather name the cost up front than pretend it is not there.
Hours and overlap
I work from Addis Ababa, on UTC+3 all year. There is no daylight saving here, so the math does not drift much.
That is 2 to 3 hours ahead of the UK, and 7 to 11 hours ahead of the US depending on the city and the season. In practice it means a wide daytime overlap with European hours, and I keep late-afternoon hours to catch the US East Coast morning.
A normal day
- EuropeWide overlap through your day
- UKOverlap your morning and afternoon
- US EastYour morning, my late afternoon
- US WestA few evening hours on my side
The kind of thing I catch early
Judgment is the product.
There are no logos to show you and no case studies I can name. So here are two decisions that separate work that ships from work that gets sent back. Both are checkable. Follow the links.
Two rules that point in opposite directions
Apple guideline 3.1.1 says anything you unlock inside the app has to go through in-app purchase, though since 2025 US-storefront apps can also link out to other payment methods. Guideline 3.1.3(e) points the other way: goods and services used outside the app have to use something other than in-app purchase. Build a payment flow against the wrong rule and the app gets rejected at review, after the work is done. Knowing which rule a given feature falls under before writing it is the difference between shipping on time and a rejection you find out about a week later.
Apple App Store Review Guidelines, 3.1An index that scans thousands to return three
Firestore lets you put range filters on more than one field now, so the availability query a booking system needs will run. But only the first range field actually narrows what the index scans. The rest just filter the results after the fact. The query returns three bookings and reads thousands of index entries to do it, and since you are billed on index entries read, the cost shows up quietly once real data arrives. The fix is ordering the fields by how selective they are, which the docs spell out.
Firestore range and inequality filters, Google Cloud docsWhat I turn down
The fastest way to trust a yes is to see the nos.
Nobody makes up a list of work they refuse. Here is mine.
Estimating a codebase I have not read
A number based on a description is a guess dressed up as a quote. If the work touches existing code, I need to read it before I can tell you what it takes.
Fixed price while requirements are still moving
Fixed price only works when the scope is actually fixed. If we are still discovering what the thing is, a fixed number just moves the risk onto whoever guesses wrong.
Design work
I build. I do not do brand, visual design, or UX from scratch. If you have designs, I will build to them. If you need them made, that is a different person.
Being the only one who understands it at the end
If the arrangement ends with me as the single point of failure and no documentation or handover, it has failed even if it shipped. I write things down so you are not stuck with me.
Work you need built, without a new hire.
Tell me what it is, what is already built, and when it needs to be done. I will tell you honestly whether I am the right person and what it would take.
React, Next.js, TypeScript, Django, Python, Flutter.
Not an agency? If you are a founder hiring directly, that works a little differently. See For Founders.
Send the details