All ten questions below are also gathered into a single worksheet you can download at the end of this article. It’s handy to print, forward to a colleague, or work through live on a call with a potential partner.
1. Will you ever contact my client directly?
This should get you a firm, immediate “no”. It’s worth asking specifically about the individual people who’ll be doing the work, not just the company as a whole. A partner can have an airtight confidentiality policy on paper while an individual developer, new to the arrangement, still slips up on a call or a support ticket. Ask who on their team will actually touch your project, and confirm the “never contact the client directly” rule applies to every one of them, not just the account manager you’re talking to.
Worth pushing on the practical side of this too. A careful partner builds the site in whatever language you actually work in, and makes sure their own name never surfaces anywhere in the code: not in comments, not in credits, nowhere a client could stumble across it. Less experienced developers forget this more often than you’d expect.
A common slip: the site’s admin settings still list the developer’s contact info, with the partner’s own domain sitting right there in the email address. This is invisible to a client browsing the front end, but one click away from anyone poking around the WordPress admin.
2. Can you work inside our existing tools, not just yours?
Most partners will say yes to this without thinking. The more useful follow-up: how long will it actually take them to get comfortable in your setup? A partner worth trusting will tell you upfront if they don’t know a specific tool and will need some ramp-up time (or a bit of training from your side) rather than pretending every tool is interchangeable. If the answer is an instant, unqualified “no problem,” that’s often a sign they haven’t thought it through.
Even when the partner already uses the exact same tool you do, that’s not automatically a free pass. Every agency sets up its instance a little differently: custom fields, naming conventions, workflow stages that mean something specific to your team. A partner who actually knows what they’re doing will still ask for at least a short walkthrough of how your setup works, rather than assuming their own habits will translate cleanly. If they skip that step entirely, that’s worth noticing too.
3. What does communication actually look like?
This goes further than just agreeing on which tools you’ll both use. You also need to settle who on the partner’s side actually talks to your team, and how. That decides how many licenses you’ll need to provide. A single developer or PM as your point of contact needs one seat in your project management tool; a whole team working directly inside it needs several. Get this clear before you commit, not after you’ve already paid for licenses you didn’t plan for.
It’s also worth asking how coverage works when someone’s out: vacation, sick leave, whatever it is. A partner who hasn’t thought about this will leave you stuck the moment your one point of contact is unavailable. One who has will be able to tell you exactly who steps in and how continuity is handled, without you having to ask twice.
4. Have you built in our stack before? Can you show me a project in a similar setup?
Don’t accept a general “yes, we know WordPress” as an answer. Ask for a concrete example: a real project, in a stack similar to yours: same page builder, same theme approach, same general architecture. A partner with real experience in your setup will have this ready without hesitation. One who doesn’t will either dodge the question or show you something only loosely related, which tells you the learning curve is still ahead of them, not behind them.
Example: Your agency expects client websites to be built using Gutenberg. The partner you are talking to has 50 projects in Elementor but only one in Gutenberg. You need to decide whether this is the right fit for you.
5. Is there a trial period, or are we committing in full from day one?
A trial period is a reasonable thing to ask for, and a confident partner won’t push back on it. Worth asking, too, how onboarding costs are handled: whether you’re paying full price from the very first hour while the partner is still learning your codebase and your process. A partner willing to split that ramp-up cost with you, rather than billing it entirely to you, is signaling that they expect the relationship to last long enough to make that investment worth it on both sides. It usually means the work moves faster once the ramp-up is done.
Our experience shows that for long-term partnerships, investing a few hours in getting to know your clients’ websites (with the time split equally between both parties) can significantly speed up the implementation of changes. When we begin a partnership with a fixed-price project, we always execute the first one at a reduced rate and provide the partner with both figures: the standard price and the discounted price. This allows the partner to see the project’s full cost and better evaluate its quality.
6. How do I manage my hours and what happens if unused hours don’t get used this month?
Before anything else, get clear on what’s actually included in the hours package. Does time spent on quotes and estimates count against it, or is that separate? Does project management, assigning tasks to developers, coordinating the work, eat into your hours, or is that overhead the partner absorbs? These sound like small details, but they add up fast, and assuming the answer without asking is how agencies end up surprised by how quickly a package gets used.
Ask about reporting too. A partner should have some system that shows you exactly how hours are being spent: sometimes that works out of the box, sometimes it needs to be set up to match how you track things. Find out whether they’ll report through your own project management tool or theirs, how often that reporting happens, and what it actually looks like: a real breakdown, or a vague monthly total you have to take on faith.
Once that’s settled, the rollover question matters too, and it needs a clear answer. A responsible partnership sets rules upfront: how the hours package gets reviewed after the first two or three months, and what flexibility exists to adjust it up or down as your actual workload becomes clearer. Don’t assume unused hours automatically roll over indefinitely. A partner may reasonably not want to carry 100 unused hours into next month forever. That’s also on you: communicating early when your workload is lighter than expected, instead of letting hours quietly pile up, is part of making the arrangement work.
7. What time zone is your team in, and how many of our actual working hours do you overlap?
This isn’t just a scheduling detail. A partner in a different time zone can actually work in your favor: pushing critical updates or deployments overnight, when your site sees the least traffic, instead of during your peak hours. But that only helps if you’ve also nailed down availability for the things that need real-time interaction: meetings, urgent questions, anything that can’t wait for an email reply some hours later. Ask about both: the offset, and what hours they’re actually reachable, not just working.
8. What’s your process when something breaks after launch?
Every partner will eventually have something go wrong: a bug that slips through, a plugin conflict, something that only shows up under real traffic. What matters is whether they have an actual process for it: who gets notified, how fast, and what happens next. A partner who can describe this clearly and specifically has clearly dealt with it before. One who answers with “that basically never happens to us” hasn’t been doing this long enough to know better.
Ask about cost too, not just process. Find out whether post-launch fixes come out of your existing hours or fee, or whether they get billed as extra work on top of what you’ve already paid. A partner should be upfront about where that line sits: bugs in work they delivered are usually their responsibility to fix at no extra charge, while new requests dressed up as “urgent fixes” are a different conversation.
9. Who owns the code once it’s delivered?
Don’t expect (or accept) a blanket promise of full copyright transfer on everything. A serious partner distinguishes between two situations.
For a new website build, you should get a perpetual, unlimited license (no time limit, no territorial restriction) to use everything delivered, forever. Full copyright usually isn’t transferred here, because the underlying framework or components a partner builds on top of (their own starter theme, reusable code, internal tooling) get reused across their other clients too. Legally handing over full copyright would mean they could never use that same code again in a future project, which isn’t realistic for any agency running more than one client at a time.
For new code written into an already-existing site (a custom feature, a bespoke integration built specifically for you), that’s different: it’s newly created work with nothing reusable behind it, so full copyright transfer is the standard there.
If a partner promises full IP transfer on everything without this distinction, that’s worth questioning, not celebrating.
10. What don’t you do well?
This is the one question most partners aren’t ready for, which is exactly why it’s worth asking. Nobody is good at everything, and a partner who can name a real limitation without being defensive is telling you more about their self-awareness than any polished pitch could.
Download the checklist
All the questions above are collected into one downloadable checklist. Use it as-is during a meeting with a potential partner, or send it ahead of time and ask them to fill it in before you talk. The same document also includes Brave New’s own answers to every question, so you can see exactly how we’d respond if we were on the other side of the table.