White label backend development for agencies and software houses

I sign yours. I have no template to impose and I don't run long negotiations on standard confidentiality and non-solicitation clauses covering the end client. The NDA is signed before I receive briefs, access or names: if you need to describe the project anonymously first to find out whether it is in my range, that works perfectly well.

Only if you tell them. I don't appear in the documentation you hand over, I don't write to the client and I don't receive communications from them. If a technical person is needed in a meeting, I attend as part of your team and, if you prefer, on an email address at your domain. The condition does not lapse when the project ends.

You do, from the first commit, on your repository. You can change it, resell it and hand it to the end client as your own work. I leave no encrypted components, no libraries of mine with restrictive licences and no production services in my name. Third-party dependencies are listed with their licences, so you know what you are reselling. The same goes for the standards and the reusable components that come out of the project: they stay yours and you use them without me.

On three things, and price is not one of them — an offshore day rate will be lower and pretending otherwise would waste your time. First, the time zone: I am inside your working day, so a blocked milestone gets an answer the same afternoon rather than the next morning. Second, who you talk to: the person doing the analysis, the architecture and the review is the person on the call, and they don't rotate off the account. Third, capacity: mine is finite and declared, which is a limitation when you need twelve developers next month and an advantage when you need the same person to still understand the system in a year. If what the project needs is volume, an offshore team is the right answer and I say so.

Milestones have estimated dates and written acceptance criteria. If a date is at risk I say so as soon as I see it, with the cause and the impact on the following ones. What I don't do is promise capacity I don't have: analysis, architecture and code review are not delegated, so my capacity is finite, and if I can't hold your dates I tell you before signing.

Me and a small network of selected people I have worked with for years, bound by the same NDA. Analysis, architecture and code review are not delegated: they are the point at which it is decided whether a project gets done once or gets redone. That puts a ceiling on my capacity, and it is why I sometimes say no — I would rather turn a project down than take on three and deliver one.

I quantify them and send them back as change requests, with their impact on time and price. I don't absorb them silently: that is the mechanism by which subcontracted projects run out of time without anybody ever having said anything. Deciding whether a change goes in or slips is your commercial call, not mine.

By the project, at a fixed price with milestones. An open hourly rate moves the risk of my bad estimates onto you, and that is not an honest way to work with somebody reselling to a client at a closed price. For short engagements — a code review, an architectural assessment, a process assessment — the price is per engagement, defined in advance.

Yes, and it is how I work by default. I use your repository, your conventions, your ticket tool and your environments. If you have an internal code review process, my code goes through it like everything else. If you don't have one, I propose the bare minimum — branching, review, a test environment — and we put it in writing instead of improvising it halfway through.

The code and the documentation, obviously, but also the things that usually don't stay: the requirements put into a verifiable form with their acceptance criteria, the pattern the integration was built on — authentication, retries, mappings, errors, logs — and the components that recur on every project, kept separate and with a declared owner. They are the reason the next engagement costs less than this one: your team doesn't rebuild what it already had.

Yes, it is a separate engagement. We look at a real project, live or just delivered, see where the cost was formed and change one thing at a time starting with the most expensive. It is not a course and it is not a manual to adopt: the work happens on the project while you are doing it, with the people who then have to use it. That said, most collaborations start from the other end — an engagement to deliver — and a first white label project is also the fastest way to show your team how an integration is held together without redoing it next time.

No, and it wouldn't work. If your team already has conventions that work, they stay and I work inside them. Where there are none, I propose the bare minimum and we write it with the people who then use it, otherwise it stays a document nobody opens. What I don't do is arrive with a process built for a hundred-person company that you wouldn't adopt anyway.

I won't give you a percentage, and that is a choice. It depends on what rework, redone integrations and requirements discovered late cost you today: those are quantities almost no agency measures, so any number I gave you on a call would be invented — and you could reasonably ask me to prove it. What I can do is the opposite: look at a real project, tell you at which points the cost was formed and estimate what fixing each of them is worth. If the numbers come from there they are yours, and you can reproduce them without me. The same goes for time: standards, reuse and documentation cost in the project where you introduce them and pay back in the ones after.