A white-label development partner does the work your client thinks you do. If they miss a deadline, ship a bug or contact your client directly, it is your reputation that takes the hit. Choosing one deserves the same care as hiring a senior person, because in effect you are.
Use this checklist before you commit a real client project.
1. Evidence they can deliver what you sell
- Relevant work. Ask to see work in the technology and type of project you plan to sell. Many partners cannot name clients because of their own confidentiality obligations; a walkthrough of a live product or anonymised code is a reasonable substitute.
- The people, not just the company. Who exactly would work on your project? Meet the lead developer and project manager, not only the sales contact.
- Capacity. Can they staff your project when you need it, and what happens if a key person leaves mid-project?
- References from agencies they have delivered for, where those agencies are willing to speak.
2. Comfort with working invisibly
Some development companies are used to being the face of the project. White-label work needs a different habit.
- Will they work under your brand, in your project tools and email domain?
- Will they keep their name out of code comments, documents, repositories and environments?
- Will they agree, in writing, not to contact your client directly? See NDA, non-solicit and IP clauses explained.
3. Communication and working hours
- How often will they report, in what format, and to whom?
- What overlap in working hours can they offer with you and your client? This matters more than distance. See offshore and nearshore delivery.
- How fast do they answer a message today, during evaluation? It rarely gets faster after the contract is signed.
4. How they scope and estimate
Give them a real, anonymised brief and ask for an estimate with assumptions. Good partners ask questions, list what they are assuming, flag risks and say what is out of scope. A partner who returns a single number with no questions is a risk on a fixed-price project. Compare how they handle this with the SOW guide.
5. Quality practices
- Code review: is every change reviewed by a second developer?
- Testing: what is tested automatically, and what manually, before a delivery reaches you?
- Environments: do they keep separate development, staging and production environments?
- Version control: will the code live in a repository you own and can access at any time?
- Documentation: what will they hand over so another team could take the system on?
6. Security and data handling
- How do they manage access to client systems and credentials, and remove it when someone leaves the project?
- Do they use company-managed devices and accounts?
- If the project involves personal data, will they sign data-handling terms? Under India's Digital Personal Data Protection Act, 2023, a Data Fiduciary may engage a Data Processor to process personal data on its behalf only under a valid contract (section 8(2)). Your client's obligations need to flow down to the partner in writing.
7. Contract terms they will sign
Before any project, confirm the partner will sign:
- A mutual NDA.
- A master services agreement with white-label terms, non-solicitation of your clients, and IP assignment of everything written for your projects.
- Clear terms on their own pre-existing components and any open-source code.
- Payment tied to milestones your client accepts.
Reluctance on any of these is useful information early.
8. Commercial fit
- Which pricing models do they offer: fixed price, time and materials, retainer?
- Do their rates leave you a workable margin after your own project management and account costs?
- Do they offer support after launch, so you can sell BAU as well as the build? See BAU support.
More on this in white-label software development pricing explained and fixed price vs time and materials.
Warning signs during evaluation
- An estimate with no questions. If they priced your brief without asking anything, they have not understood it.
- Everyone is senior in the pitch, nobody is named for the work. Ask who will actually write the code.
- Reluctance to put code in your repository. You should be able to see the work at any time, not only at handover.
- Pushback on non-solicitation or IP assignment. These are standard in white-label work. A partner who resists them may plan to keep the client or the code.
- Promises that sound too round. Guaranteed dates before scope is clear, or "no bugs", are signs of a sales process, not a delivery process.
Questions to ask in the first call
- Which projects like ours have you delivered, and can you show us one?
- Who would lead our project, and how much of their time would it get?
- How do you report progress, and what do you do when something slips?
- Will you work in our tools and under our brand, and not contact our clients?
- What do you hand over at the end, and who owns it?
- How do you handle access to client systems and personal data?
Write down the answers and compare partners on the same questions. The way they answer, and how specific they are, tells you as much as the answers themselves.
9. Start with a pilot
Do not make your biggest client the test. Start with a small, well-defined piece of work: an internal tool, a single feature, or a fixed-price module with clear acceptance criteria. Judge the partner on what actually happened: did they meet the dates, ask the right questions, report honestly when something slipped, and deliver code your own reviewer was happy with?
A single partner or a network?
A single partner is simple to manage, but your capacity and skills are capped by theirs. An enablement network matches each project to suitable partners, so you are not limited to one team's bench. That is how BitLab India works. Whichever route you take, the checks above apply to whoever does the work.