How to vet a white label development partner.
10 questions to ask, and my answers.

Ask before the first brief.

Ownership, confidentiality and sign-off are easy to settle while nothing is at stake. In the middle of a project, each of them becomes a negotiation.

Listen for specifics.

A good partner explains how the work actually runs: who, which document, which meeting. “Don’t worry, we handle that” is not an answer.

Get the answers in writing.

Anything your client contract depends on, such as ownership, scope, acceptance and support, belongs in the agreement, not only in a call.

1. Will you work under our brand, and what will our client see?

Why it matters. Left unagreed, it gets decided in the moment: a developer emails your client directly, or another company’s name turns up in a repository. Either can cost you the relationship.

A good answer. The partner asks how you want it handled instead of applying one fixed rule, and agrees it before the project starts: how they are introduced, who joins client meetings and how approvals flow.

My answer. Before the project begins, we agree how I am introduced to your client, or whether I am introduced at all, who joins client meetings and how approvals work. You keep the client relationship. I work inside the boundaries we set.

2. Who will actually do the work?

Why it matters. A white label agency can sell with a senior person and deliver with whoever is free. If you don’t know who writes the code, you can’t judge the quality you are putting your name on.

A good answer. Names, not a headcount. A clear answer to who leads the project, who reviews the code, and who you talk to when something goes wrong.

My answer. I lead every project personally and I am your single point of contact. When the scope needs more hands, I bring in developers I already work with. They work under my review and sign the same NDA and code-ownership terms I do, and you still deal with one accountable person: me.

3. How will we communicate, and will our working hours overlap?

Why it matters. Most delivery problems start as communication problems: a question that waits two days, or a decision nobody remembers making. A large time difference makes both worse.

A good answer. A concrete rhythm: where tasks live, how often you get written updates, when reviews happen and who makes decisions on each side.

My answer. You work directly with me on technical scope and delivery. We agree a shared task board, written updates, review meetings and a named decision owner, and I use your existing tools where practical. I work from Niš, Serbia, on Central European time, which overlaps a normal working day with the UK and most of Europe, and the morning with the US East Coast.

4. Who owns the code and intellectual property?

Why it matters. Your client contract probably says what the client owns when the project ends. If your partner’s terms say something different, you have promised something you can’t deliver. Pre-existing code and third-party licences are where this usually goes wrong.

A good answer. Ownership in writing before work starts: when it transfers, what happens to code the partner already had, and which third-party licences apply. You should be able to check it against your client contract.

My answer. Your agency does. Once the project is paid, everything written for it (source code, designs, documentation and repository history) belongs to your agency, and you can transfer it to your client as your contract requires. If you prefer, the repository lives in your or your client’s account from the first commit. Tools I built before the project stay mine, and you get a permanent, royalty-free licence to use and change them as part of the delivered system. Open-source and paid third-party components keep their own licences; I list them at handover. Code written for your client is never reused for anyone else. Anyone I bring in signs the same NDA and code-ownership terms I do. If your client contract needs different terms, we write those in instead.

5. Will you sign an NDA before we share the brief?

Why it matters. Agency briefs contain client names, plans and sometimes access to live systems. Sending that to someone you have no agreement with puts your client’s information, and your reputation, at risk.

A good answer. Yes, before anything sensitive changes hands, plus an agreed way to share files and access once it does. Be wary of a partner who asks for credentials or production data in the first email.

My answer. Yes. An NDA can be signed before sensitive material is exchanged. Until then, please keep the first enquiry free of client credentials and confidential files. An outline of the problem is enough to start.

6. Which technologies do you work with, and when do you say no?

Why it matters. A partner who says yes to every stack may be learning on your client’s budget, and a mismatch found halfway through means rework or a codebase your team can’t take over.

A good answer. A specific list, an honest line where it ends, and a habit of flagging specialist needs before quoting, not after.

My answer. TypeScript, React and Next.js, Node.js and NestJS, SQL and document databases, API integrations and AI workflows. I choose technology around the existing system and the brief, and I flag specialist requirements before committing. For agencies, that means custom web applications behind a marketing site, and integrations between the systems a client already uses.

7. How do you scope and price a project?

Why it matters. Vague scope is where budgets break. If nobody wrote down what is excluded, every “small extra” becomes an argument.

A good answer. A written proposal with deliverables, exclusions, responsibilities, fees and acceptance criteria. Prices you can see before the first call, and an estimate based on the real system rather than a one-paragraph brief.

My answer. I start by understanding the brief, then check feasibility and dependencies. The first scope goes into a written proposal with deliverables, exclusions, responsibilities, fees and acceptance criteria. My prices are published: a feasibility review is a fixed €490, the day rate is €450, and larger projects get a fixed quote after the feasibility review. Prices in EUR, excluding VAT.

8. How will we see progress, and who decides the work is done?

Why it matters. If you only see the software at the end, you find the problems when there is no time left to fix them. Without agreed acceptance criteria, “done” means something different to you, your partner and your client.

A good answer. Working software at regular milestones, not only status reports, tested against criteria agreed at the start. And one named person on your side who accepts each release.

My answer. I build in reviewable milestones, so you see working software and written progress along the way. Risks and decisions stay visible, and changes are agreed before they enter the scope. Before release, I test the complete workflow against the agreed criteria, including failures and permissions. Your nominated owner reviews and accepts the release.

9. What happens after launch?

Why it matters. Software needs care after it ships: updates, fixes, small changes. If handover and support were never agreed, your client calls you, and you have nobody to call.

A good answer. A real handover with documentation, access and the code itself, so someone else could take over. Support agreed separately, with clear coverage and response times, not “we’ll be around”.

My answer. At handover you get documentation of the setup, operation and technical decisions, plus deployment access and the code, which is yours once the project is paid. Ongoing maintenance runs under a separate support agreement, with coverage, response times and infrastructure responsibilities agreed up front. Round-the-clock support is not included by default.

10. Can we start with something small before we commit?

Why it matters. No list of questions replaces seeing how a partner works on real software. Committing to months of capacity on the strength of a sales call is the most expensive way to find out.

A good answer. A paid, bounded first project with a clear finish line, so both sides can judge the collaboration on working software.

My answer. Yes, and I recommend it. An engineering pilot delivers one working workflow or feature against acceptance criteria, from €2,900. If it works for both of us, monthly capacity starts at €3,600 for 8 days a month. A project typically starts 1–2 weeks after agreement, subject to availability.

“We’ll sort out ownership later.”

Later is after your client has signed a contract that promised them the code.

A fixed price before anyone has looked at the system.

A firm number on an unclear brief is either padded or a guess, and you find out which one mid-project.

Progress you can only see at the end.

Status reports without working software tell you how the partner feels about the project, not where it is.

Nobody can say who writes the code.

Then nobody can say who will fix it.

SignageStack

Digital signage platform. Shared rendering connects the editing preview to the player. Saved state and cached media give playback a defined recovery path.

CultureFitr

Assessment platform. Agency-scoped data, code-calculated scores, and background report processing keep distinct responsibilities explicit.

opnlocal

On-device AI app. Fit is estimated before the download and speed is measured after it. A signed model list and verified files keep downloads trustworthy.

Morgenlese

Language learning app. Every word in every story links to a dictionary entry, enforced by a content check. AI drafts are published only after mechanical checks and an AI review both pass.