Referring to a Web Agency: What It Actually Changes for Your Agency
In brief
Referring a web project to a specialized agency doesn't mean handing over your client. It changes three things for your agency: you keep your client relationship and stay the orchestrator, you widen your offering without hiring developers or paying commission, and technical liability stays with the partner who builds the site.
- Two models, zero commission: you re-invoice your client adding your management fee, or the partner bills your client directly and you charge your management and strategy hours.
- Either way, you stay the orchestrator and keep the client relationship.
- Technical liability stays with the partner who builds the site.
You've built your agency around a clear expertise: branding, PR, strategy, whatever your lane is. Then a client asks if you do websites. You say no, they look disappointed, and you wonder if you just left money on the table. Or worse: you say yes, stretch your team thin, deliver a mediocre site late, and damage the relationship you spent months building.
Most agencies solve this two ways: turn down web work, or force their way through projects they're not equipped to deliver. There's a third path almost no one talks about openly: hand the execution to a specialized web agency while keeping your client. Referring doesn't mean losing your client. It means keeping them while a specialist builds the site, and earning on the value you add.
This article breaks down what actually changes when you start referring web projects: the revenue model, the client relationship dynamics, and the specific questions you need answered before you hand your client to anyone. The goal isn't to convince you to refer. It's to give you the information to decide whether it's a strategic move for your agency or a risk to avoid.
Why do so many agencies still avoid referring web projects out?
The main blocker is the fear of looking incompetent. Agencies worry that admitting "we don't build websites" signals a gap that makes clients wonder what else they can't do. The worry isn't irrational, clients do ask the question. But the framing decides whether it lands as a weakness or a strength. "We don't do web" sounds like a limit. "We work with a Webflow specialist because sites are a technical discipline and we want you to get the best result" sounds like a strategic decision.
The second reason is control anxiety. Referring means putting your client relationship in someone else's hands for weeks. If the partner misses deadlines, ships buggy work, or goes quiet during revisions, your client blames you. You're the one who made the introduction. And it's a fair fear: when a web project goes sideways, the agency that referred takes part of the reputational hit even if it never touched the execution. That's exactly why the structure of the partnership matters more than the partner itself.
The third blocker is the fog around money. Most agencies don't know how compensation is structured in a web partnership: who bills whom, how they make their margin, and whether they'll get charged something along the way. Without a clear model, it's simpler to turn down web work than to navigate an unfamiliar arrangement. We come back to this below, because it's exactly where the model we stand behind at GALAPA breaks from what most agencies assume.
Finally, there's a real poaching risk. You introduce your branding client to a web agency for a site build. Six months later, the agency pitches them a full redesign, SEO, or maintenance, cutting you out of the loop. It happens often enough that many agencies treat referring as a way to hand clients to a competitor rather than partner with a specialist. That's exactly what a good partner eliminates in writing.
How does an agency-to-agency referral model actually work in practice?
A partnership rests on two questions: who bills whom, and who keeps the client relationship. Answer both clearly and the rest falls into place. This is also where the model we stand behind at GALAPA splits from the usual "I refer, I take a commission" reflex. We don't work that way, and we don't accept a partner charging us one either.
First model: white-label. The web partner bills you directly, and you re-invoice your client adding your management fee. The partner stays invisible, you present the work under your brand, and your client only ever deals with you. You keep full control of the relationship and you decide yourself what your management is worth. In exchange, you carry more load and more liability toward the client, since it's your name on the project.
Second model: co-delivery. The web partner bills your client directly for the technical portion, and you bill your management and strategy hours separately. Both names are visible. The partner handles the technical conversations (CMS training, hosting, integrations), you handle strategic direction and approvals, and your client knows they have two teams focused on what each does best. Your compensation comes from your time, not a percentage skimmed off someone else's work.
What both models share: no commission changes hands. You pay nothing to the partner for the privilege of sending them a client, and a serious partner charges you nothing to receive a qualified lead. Each is paid for what they actually bring: you for your management, strategy, and client relationship, them for the technical execution. A commission, in either direction, is a signal to watch: it usually means one of the two parties is looking to get paid for work it doesn't do.
Whatever the model, define the channels in writing before kickoff: who owns which client touchpoints, how often status updates land, and what triggers an escalation to you. Liability gets settled in advance and in black and white: timeline with milestone dates, number of revision rounds, post-launch support window, and what counts as a serious breach. An agreement that leaves these points vague is an agreement that ends up landing back on you.
What questions should you ask a web agency before referring your first client?
Start with the delivery track record. Ask for three recent projects comparable in scope to what your client needs, not their prettiest project, their most relevant one. Ask for the real timelines: when the project started, when launch was planned, when it actually happened, and what caused the gap if there was one. Then ask for references you can call, not testimonials pulled from their site. If they hesitate or only offer references from two years ago, that's a signal.
On the business side, clarify the billing model right away. Do they bill you, or your client directly? Do they accept white-label if that's what you want? And above all: do they require a commission to receive your client? A partner who charges you a percentage for a qualified lead has already told you how they see the relationship. The right arrangement lets you structure your margin yourself, with no skim in either direction. Put it in writing before you make the introduction.
On the technical side, confirm their specialty matches your client's real needs. If your client is launching an online store and the partner only does Webflow, it's a bad match. If they claim to "do everything," Webflow, Shopify, WordPress, custom code, ask what share of their last year's projects ran on each platform. A specialist delivers faster and cleaner than a generalist stretching across tools they barely know.
On process, ask how they handle scope changes: do they freeze scope at signing and charge for additions, or do they build in flexibility? Neither answer is wrong, but you need to know it to set your client's expectations. Also ask, in black and white, what happens when a deadline slips or the client isn't satisfied at launch: is there a remedy in place, and is it written down? A partner with no clear answer to that isn't ready for partnership.
Finally, test their responsiveness before you refer anything. If they take four days to answer your first email, they'll take four to answer your client's revision request. Responsiveness during the sales conversation is the best predictor of responsiveness during delivery.
Why does the right web partner strengthen your credibility instead of threatening it?
The fear that referring web work makes you look less capable rests on a false idea: that clients hire agencies for breadth. They don't. Clients hire agencies for depth in the thing they actually need, and they respect focus. When you say "we work with a Webflow specialist because sites are a technical discipline and we want you to get the best result," you're demonstrating strategic judgment. You know what you do well, you know what you don't, and you're solid enough to bring in the right expertise instead of stretching your team into mediocrity.
Compare that with the other scenario: you take on a web project you're not equipped to deliver well, you're three weeks late, the site lags on mobile, and the client can't figure out how to update their own content. You've just proven you can't deliver websites and chipped away at trust in your core services, because the client wonders what else you're overselling. The reputational hit from a bad site you delivered yourself is far worse than the perceived gap of having handed the web to a specialist.
Agencies that refer successfully don't hide the partnership, they sell it as an advantage. "You get our strategic oversight on message and positioning, plus the technical execution of a team that only builds Webflow sites. That's a better result than a generalist agency trying to do it all and doing none of it well." Clients care about outcomes: speed, quality, autonomy after launch. Whether one agency or two deliver those outcomes matters little to them. If you present referring as a strategic advantage rather than a limit, they'll trust the decision.
The right partner also widens your offering without forcing you to hire developers or learn a new platform. You can credibly say "yes, we do websites" because you have a reliable delivery partner behind you. That keeps your clients from shopping elsewhere the moment they have a web need. And if the partnership is well structured, clear communication, reliable delivery, no poaching, you're not risking the relationship. You're deepening it by solving more of your client's problems without overloading your team.
Referring well is a skill. It takes finding a partner you genuinely trust, defining the relationship in writing so both sides know what to expect, staying involved enough to catch issues before they escalate, and presenting the partnership to your clients as a strength rather than a workaround. Done badly, it's a reputational liability. Done well, it's a way to widen your offering, keep your clients, and make your margin on what you genuinely bring, without ever giving up the relationship you built.
FAQs
You have two ways to get paid, and neither runs through a commission. First option, white-label: the web partner bills you, and you re-invoice your client adding your management fee. What you earn is whatever you decide your management is worth. Second option, co-delivery: the partner bills your client directly for the technical portion, and you bill your management and strategy hours separately. Either way, you earn on the value you bring (relationship, management, strategy), not on a percentage skimmed off someone else's work. And you pay nothing to the partner to send them a client. At GALAPA, that's non-negotiable both ways: we don't charge a commission and we don't accept being charged one.
It depends on what your agreement provides, which is exactly why you put it in writing before the first project. A good agreement spells out the timeline with its milestone dates, what counts as a serious breach, and the remedy when it happens. If the delay comes from your client (late content, slow feedback, scope additions), the partner should send you the revised timeline right away so you can manage expectations. If the partner is the one dropping the ball, your agreement should already say what happens. The real safeguard is visibility: you need regular updates, not only when a problem surfaces. A partner who tells you about delays only once the deadline has passed isn't ready for partnership.
It depends on the model. In white-label, the partner is invisible: all communication goes through you. In co-delivery, the partner handles the technical conversations while you keep strategic direction and approvals. Whatever the model, define the channels in writing before launch. The red line is the same in both cases: a serious partner never pitches new services to your client behind your back. If they reach out to sell or propose new work while bypassing you, it's a breach of the agreement and grounds to end the partnership.
Frame it as specialization, not a gap. Most of your clients respect focus: they hired you for branding, PR, or strategy because that's your expertise. Positioning web the same way is consistent. You can say something like "we work with a Webflow specialist so you get the best on the technical side, while we stay focused on your strategy." Avoid apologetic language like "we're not technical enough." Your clients care about the result (speed, quality, autonomy after launch), not whether one team or two deliver it. Presented as a strategic choice, the partnership strengthens your credibility instead of denting it.
Start with the track record: ask for three recent projects comparable in scope, with the real timelines and what caused any gaps. Ask for references you can call, not testimonials on their site. On the business side, clarify who bills whom, whether they accept white-label, and above all whether they require a commission to receive your client (a partner who charges you a percentage for a lead has already told you how they see the relationship). On the technical side, confirm their specialty matches your client's real needs, for instance don't refer an online-store project to a team that only does Webflow. On process, ask how they handle scope changes, what happens if a deadline slips, and whether it's written down. Finally, test their responsiveness: how fast they reply during the sale predicts how fast they'll reply during delivery.
Only if you present it as a limit rather than a choice. Clients hire specialists every day: an accountant refers to a tax lawyer, a general contractor brings in an electrician. The framing that protects your credibility is specialization and partnership. When you say "we work with a web specialist because sites are a discipline of their own and we want you to get the best result," you're demonstrating strategic judgment. When you say "we don't really do sites," you're admitting a gap. The difference is in the positioning. Agencies that refer well don't hide the partnership, they sell it as an advantage: your strategic oversight plus sharp technical execution.
Yes, that's the white-label model. The partner builds the site, bills you, and you present the work to your client under your brand adding your management fee. Your client only ever deals with you. Contracts, invoices, and communication come from you, and the partner operates behind the scenes. This model works when you want to widen your offering without hiring developers or learning a new platform. The trade-off: you keep the relationship and the revenue under your control, but you also carry the liability toward the client, since it's your name on the project. White-label therefore takes a genuinely reliable partner, because it's your reputation on the line.
Both keep your client relationship intact and involve no commission. The difference is visibility and who bills. In white-label, the partner is invisible: they bill you, you re-invoice your client with your management fee, and you handle all communication. You keep the most control, but you carry the most liability. In co-delivery, both teams are visible: the partner bills your client for the technical work, you bill your management and strategy hours, and each owns their portion. Choose white-label when you want web as a full service under your brand. Choose co-delivery when you'd rather stay the strategist without carrying the technical delivery alone.
Ownership should pass to your client on final payment, that's the standard and it protects everyone. The agreement should state that the partner transfers the design files, code, and content once the invoice is settled, with nothing held back. If you work white-label, the agreement should also confirm you can present the work as your own, while ownership of the site still transfers to your end client. Be wary of a partner who tries to hold onto ownership or charge to reuse the site: that's a signal not to ignore. Internal tools or components the partner reuses from project to project can stay theirs, but the specific site they build for your client must be fully transferable. Put it in writing before you start.
The honest answer: it depends mostly on you and your client, not on the partner. A standard SMB site follows four beats: discovery and structure, design, build and CMS setup, then revisions and quality control. An online store stretches longer, because of the product catalog, the payment gateway, and the shipping logic. But delays almost always come from the client side: content delivered late, slow feedback, scope added mid-project. When you set expectations with your client, build in a margin for the inevitable back-and-forth and keep the content ready ahead of time. The simple rule: under-promise on the timeline, over-deliver on the result.
Related Articles /
Related Articles /
Related Articles /
Related Articles /
Related Articles /
Related Articles /
