The Real Secret to Winning Bigger Budget RFPs

I curate a weekly list of website, branding, and digital RFPs at omariharebin.com/rfps, so I spend a lot of time reading these opportunities.

The more I read them, the more obvious it becomes that bigger budget RFPs are not usually won by the most impressive portfolio alone.

Bigger budgets usually mean more stakeholders, more approvals, more constraints, and more risk for the person or committee making the decision.

So the real secret is not just proving that you can design or build the thing.

It is learning to read the RFP from the buyer’s side of the table.

Most people respond to RFPs from their own side. They read the request as a chance to prove themselves. They try to show how talented they are, how impressive their portfolio is, how many services they offer, and how much experience they have.

All of that can matter.

But the organization reviewing the proposal is usually asking a different question:

Can we trust this person or team to get us to the other side of this project without making our lives harder?

That is the real work of a good RFP response.

The goal is to reduce risk for the person, committee, board, or department responsible for making the decision.

A strong proposal does not simply say, “We can build this.”

It says, “We understand what could make this project difficult, and here is how we would guide it to a smooth launch.”

The RFP is a map of their concerns

An RFP is not just a design brief. It is a map of the buyer’s priorities, constraints, fears, and internal responsibilities.

When an organization mentions accessibility, content migration, CMS training, online forms, payment integration, hosting, security, analytics, stakeholder approvals, documentation, or post-launch support, those are not filler details.

Those are places where the project can go wrong.

Maybe their current site is difficult to update. Maybe staff members are tired of relying on one person to make changes. Maybe the previous redesign dragged on for months. Maybe the board cares about compliance. Maybe the public depends on the site for accurate information. Maybe donations, registrations, or public notices need to work without drama.

A lot of designers read those details as requirements to check off.

A better proposal reads them as concerns to address.

If the RFP says they need training, show them what training looks like. If the RFP mentions accessibility, explain how accessibility will be considered throughout the project. If the RFP includes content migration, describe how content will be reviewed, moved, cleaned up, and tested.

The more clearly you address the concerns inside the RFP, the less risky your proposal feels.

Put your project manager hat on before your designer hat

When responding to an RFP, put your project manager hat on before your designer hat.

The proposal is not only a pitch for your creative ability. It is your first demonstration of how you think through the project.

Before you write, ask yourself:

• What needs to happen first?

• What could slow this project down?

• Who needs to provide content?

• Who needs to approve design?

• How many stakeholders are involved?

• What needs to be migrated?

• What needs to be tested?

• What does the client need to understand before launch?

• What happens after launch?

That thinking is the foundation of the proposal.

A lot of proposals spend too much time saying, “Here is what we do.”

A stronger proposal says, “Here is how we will help this project move.”

That shift matters. The buyer is not just choosing the person with the best taste. They are choosing the person they believe can manage the path from where they are now to where they need to be.

Design matters. Development matters. Strategy matters.

But for many RFPs, especially nonprofit, municipal, education, and public-facing projects, the winning edge is often clarity, organization, communication, and trust.

Pay close attention to the evaluation criteria

Most RFPs tell you how the proposal will be judged.

Do not skip that section.

If the evaluation criteria mention relevant experience, project approach, timeline, accessibility, support, cost, or references, your proposal should make those answers easy to find.

Do not make the reviewer hunt.

If they are scoring proposals, they may be reviewing several at once. Your job is to make it easy for them to see that you understood the assignment.

Use their language. Mirror their priorities. Organize your response around what they said matters.

This does not mean copying and pasting the RFP back to them. It means showing that you are paying attention.

If accessibility is part of the criteria, do not bury accessibility in one vague sentence. If timeline matters, show the phases clearly. If support matters, explain what happens after launch. If experience matters, include examples that relate to the type of organization and project they are describing.

A proposal feels stronger when it is clearly shaped around the buyer’s stated priorities.

Use the Q&A period

If there is a Q&A period, use it.

A lot of people skip this part, or only ask basic technical questions. But the Q&A period is one of the best opportunities to understand how the buyer is thinking.

You can ask about the current pain points with the existing site. You can ask what would make the project successful from their perspective. You can ask who will be involved in approvals. You can ask what content already exists and what content still needs to be created. You can ask whether there are known accessibility, integration, hosting, or maintenance concerns.

You are not just gathering information. You are learning how to write a better proposal.

You are also showing how you think.

Good questions can communicate experience before the proposal is even submitted. They show that you are not only thinking about the website as a final product. You are thinking about the project as a process that has to work for the people involved.

Only propose the ones you actually want

Not every RFP is worth responding to.

Some are a great fit. Some are not. Some are too vague, too rushed, too bloated, too underfunded, or too misaligned with the kind of work you actually want to do.

You do not need to propose everything.

In fact, you probably should not.

A proposal takes attention. A good one requires research, thought, positioning, and care. If you are not interested in the project, that usually comes through. The proposal starts to sound generic because the energy behind it is generic.

But when you find an RFP you actually love, take it seriously.

Read the organization’s website. Look at their current structure. Understand the audience they serve. Notice what is broken, unclear, outdated, or hard to use. Think through what a smoother version of the project might look like.

A thoughtful proposal for a project you actually want is usually stronger than five rushed proposals for projects you barely care about.

A lost proposal can still become an asset

You will not win every RFP.

That does not mean the work was wasted.

If you only propose projects you actually want, every serious proposal can become an asset.

You now have language for that type of organization. You have a project approach. You have assumptions. You have a scope structure. You have a way of explaining the value. You have thought through the needs of that kind of buyer.

If you loved the project but did not win it, look for similar organizations.

Reach out. Ask about their procurement process. Ask how they usually find vendors. Ask whether they have upcoming website, branding, accessibility, content, or digital infrastructure projects.

The RFP becomes more than a single opportunity.

It becomes research.

It becomes a market signal.

It becomes a starting point for future outreach.

This is one of the best reasons to be selective. If you propose projects you do not care about, there is not much to reuse. But if you propose projects that reflect the kind of work you want more of, even a loss can help you build a better path to the next opportunity.

Write the proposal from their side of the table

The person reviewing your proposal may need to defend the decision to a board, director, committee, procurement team, or internal stakeholder group.

They may be responsible for keeping the project on budget. They may need to coordinate feedback from people who do not agree with each other. They may be nervous about choosing the wrong vendor.

So write in a way that helps them feel confident.

Make the process clear. Name the risks. Show how decisions will be made. Explain what you will need from them. Make the next step obvious.

They do not only need to know that you can do the work.

They need to believe that choosing you will make the project smoother.

The real goal

Winning an RFP is not about sounding the most impressive.

It is about becoming the clearest, most relevant, least risky choice for the project in front of you.

Read the RFP as a map of their concerns. Pay attention to the criteria. Use the Q&A period. Only propose the ones you actually want. Think through what would make the project smooth.

Then write that down.

That is the proposal.

---

If you want a place to practice reading RFPs this way, I keep a weekly list of open website, branding, and digital opportunities here:

omariharebin.com/rfps

But don’t just scan for projects you might be able to win.

Look for the ones you would actually want to carry.

Then put your project manager hat on, think through what would make the project smooth, and write that down.

That is the proposal.

Questions to Ask Before Hiring a White-Label Squarespace Partner

Looking for possible providers?

Start here: White-Label Squarespace Design & Development Partners.

A white-label partner works behind the scenes under your brand. Your client keeps working with you, while the partner helps you deliver the website, development, updates, custom code, launch support, or ongoing production work. That can be a smart way to expand your capacity without hiring in-house, but it also introduces a new risk: someone else’s work now shapes how your client experiences your brand.

That is why the decision should not be based on portfolio alone. A white-label partner is not just a vendor. They become part of your delivery process. Before you hire one, you need to understand how they work, what they own, where their limits are, and whether their process fits the way you manage client relationships.

Here are the questions worth asking before you trust a white-label Squarespace designer or developer with client work.

1. What kind of help do you actually provide?

“White-label Squarespace partner” can mean different things depending on the provider. Some partners design websites. Some build from finished Figma or XD files. Some handle custom CSS and JavaScript. Some offer full website builds. Some are better for smaller tasks, edits, migrations, or overflow support.

Before you compare providers, define the role you actually need filled. A designer who can create beautiful layouts may not be the right person for technical troubleshooting. A developer who can build your exact design may not be the right person to shape the creative direction. A subscription production team may be helpful for ongoing tasks, but less appropriate if you only need one carefully scoped build.

Useful questions to ask:

• Do you handle design, development, or both?

• Can you work from a finished Figma or XD file?

• Do you prefer to design directly inside Squarespace?

• Do you handle full builds, smaller tasks, or ongoing support?

• What kinds of Squarespace projects are you best at?

• What kinds of projects are not a good fit?

The goal is not to find someone who says yes to everything. The goal is to find someone whose strengths match the work you are actually handing off.

2. Is Squarespace one of your main platforms?

A general white-label web team may list Squarespace alongside WordPress, Shopify, Webflow, Wix, and other platforms. That does not automatically make them a bad fit, but Squarespace has its own way of working. The platform has specific realities around Fluid Engine, mobile styling, section structure, custom code limits, commerce limitations, collection pages, editor behavior, and client handoff.

A strong Squarespace partner should understand those realities without making the project feel heavier. They should know when to work with the platform, when to add custom code, and when to tell you that a request may not be worth the complexity.

Useful questions to ask:

• How often do you work in Squarespace?

• Do you primarily work in Squarespace 7.1?

• Are you comfortable with Fluid Engine?

• Are you comfortable with custom CSS?

• Are you comfortable with JavaScript and code injection?

• What Squarespace limitations do you run into most often?

• What Squarespace requests do you usually say no to?

The last question is especially revealing. A mature partner will not pretend everything is possible. They can explain what Squarespace does well, where it gets awkward, and how to make the cleanest decision inside the platform.

3. What part of the process do you own?

One of the easiest ways for a website project to go sideways is when ownership is unclear. If you assume the partner is handling something and the partner assumes you are handling it, the client experiences the gap.

Before the project starts, clarify who owns the major parts of delivery: sitemap, wireframes, copy, images, design files, development, mobile cleanup, SEO settings, forms, integrations, domain connection, launch checklist, training, and post-launch fixes.

Useful questions to ask:

• What do you need from me before you can start?

• What does a clean handoff look like?

• Do you need a sitemap, wireframes, copy, images, brand guidelines, or a finished design file?

• Do you handle launch?

• Do you provide training videos or handoff notes?

• Do you add SEO titles, descriptions, and basic page settings?

• What is outside the scope of your work?

This is less about micromanaging and more about preventing hidden assumptions. A good partner should be able to describe their handoff process clearly.

4. How do you communicate during the project?

White-label work depends on clear communication. The partner may be invisible to the client, but they cannot be invisible to you.

You should know where tasks live, where feedback goes, how often updates happen, and how delays or questions get surfaced. Some partners work through email. Some use Notion, Slack, ClickUp, Trello, Google Docs, task boards, or client portals. The specific tool matters less than the clarity of the system.

Marya Nguyen of Yangu Web Studio put this well from the white-label partner side. In her experience, the strongest collaborations usually have a few things in common: the client has a clear sense of what they need help with, there is one central place for communication, and feedback is organized enough for the partner to act on it without guessing.

That is a useful standard to look for before the project starts. If the process depends on scattered emails, vague notes, missing assets, or feedback coming from five different places, the relationship will probably feel heavier than it needs to. Clear communication is not just a convenience. It protects the timeline, the scope, and the client relationship.

Useful questions to ask:

How do you prefer to communicate during a project?

What system do you use to track tasks, revisions, and approvals?

How often should I expect updates?

How do you handle feedback?

How do you handle unclear requests?

How do you flag delays or scope issues?

How quickly do you usually respond during active projects?

Do you prefer all feedback in one place?

What makes a handoff easy for you to act on?

A strong partner does not need an elaborate process, but the process should be easy to understand. If communication feels scattered before the project starts, it will probably feel worse once client feedback begins.

5. Will you communicate with my client?

Some white-label partners stay completely behind the scenes. Some are willing to join client calls as part of your team. Some prefer to speak directly with clients when technical decisions need to be made.

There is no single correct answer. The important thing is alignment. If your brand owns the client relationship, the partner needs to respect that structure and understand how visible or invisible they are supposed to be.

Useful questions to ask:

• Will you ever communicate directly with my client?

• If yes, how are you introduced?

• If no, how do we handle technical questions that would be easier to answer live?

• Are you comfortable working completely behind the scenes?

• Can all communication come through me?

• Are you willing to sign an NDA or white-label agreement?

This is a boundary question. White-label work can get messy when the partner’s role is not clear, especially if the client starts treating them like the main point of contact.

6. How do you price the work?

The cheapest partner is not always the most profitable partner. The pricing model has to fit the way you sell.

Some partners price per project. Some price per page. Some charge hourly. Some use subscriptions. Some scope each project individually. Each model can work, but each model creates different implications for your margin, timeline, and sales process.

Useful questions to ask:

• Do you charge per project, per page, hourly, or monthly?

• What is included in the base price?

• How many revision rounds are included?

• How do you handle extra pages?

• How do you handle scope changes?

• When is payment due?

• What happens if the client delays content or feedback?

• What types of projects usually go over scope?

If you sell fixed-fee website projects, you need a partner whose pricing can be scoped clearly before the client signs. If you have steady client work, a monthly partner may make more sense. If your needs are irregular, hourly or task-based support may be safer.

Choose the pricing structure that fits your delivery model, not just the lowest number.

7. How do you handle revisions and scope changes?

Most website project problems come from unclear scope. White-label work adds another layer because your client gives feedback to you, then you pass that feedback to the partner. That can work well, but only if revision boundaries are clear.

A good partner should help you keep the project contained. They should be able to explain what counts as a revision, what counts as a new request, and how out-of-scope work gets approved.

Useful questions to ask:

• How many revision rounds are included?

• What counts as a revision?

• What counts as a new request?

• How do you estimate extra work?

• Do you require approval before doing out-of-scope work?

• How should feedback be organized?

• Do you prefer Loom videos, written notes, screenshots, or task comments?

A risky partner will quietly absorb unclear requests until the project becomes frustrating for everyone. A strong partner will help you protect the scope without making the client experience feel rigid.

8. How do you handle quality control before launch?

A white-label partner’s work carries your name. Before trusting someone with a full client project, understand how the work gets checked.

Quality control is not only about whether the site looks good. It is about whether the client can use it, update it, and trust it after launch. That includes mobile responsiveness, browser behavior, forms, links, buttons, image sizing, SEO settings, custom code, and handoff documentation.

Useful questions to ask:

• What do you review before launch?

• Do you check desktop, tablet, and mobile?

• Do you check multiple browsers?

• Do you test links, buttons, and forms?

• Do you check image sizing?

• Do you check basic SEO settings?

• Do you test custom code?

• Do you provide a launch checklist?

• Do you document anything unusual about the build?

A clean build reduces the number of awkward post-launch messages you have to manage. It also protects the client’s confidence in your process.

9. What happens after launch?

A website project does not end the second the site goes live. There may be DNS issues, broken links, form issues, small client requests, or questions about how something works.

Before launch, clarify what happens next. Some partners include a support window. Some charge hourly after launch. Some offer ongoing support blocks. Some only handle the build and expect the agency to manage everything afterward.

Useful questions to ask:

• Do you offer post-launch support?

• How long is support included?

• What counts as a bug?

• What counts as a new request?

• Can I come back for future updates?

• Do you offer ongoing support blocks?

• Do you offer monthly support?

• What happens if something breaks after launch?

This helps you understand whether the partner is a one-time builder or someone who can become part of your longer-term delivery system.

10. Can we start with a small paid test?

Before handing off a full client site, consider testing the relationship with a smaller paid project. The goal is not to get free work. The goal is to see how the partner works before your client relationship depends on them.

A good test could be:

• building one tricky section from a design file

• cleaning up mobile layout issues

• recreating one page in Squarespace

• fixing a custom CSS issue

• setting up a small landing page

• migrating one page from Squarespace 7.0 to 7.1

• handling one round of overflow edits

Pay attention to the working relationship, not just the final output. Did they understand the brief? Did they ask smart questions? Did they communicate clearly? Did the work come back clean? Would you feel comfortable putting your name on it?

A small paid test can reveal more than a portfolio.

Red flags to watch for

A few things should make you pause. None of these automatically mean someone cannot do the work, but they are worth noticing before you hand over a live client project.

Watch for:

• vague answers about process

• no clear revision boundaries

• no Squarespace-specific examples

• unclear pricing

• slow communication before money changes hands

• no explanation of what is out of scope

• overpromising around platform limitations

• no mobile QA process

• no launch checklist

• no handoff process

• discomfort with written agreements

• no clear boundary around client communication

White-label partnerships require trust. If the early process already feels confusing, the client project will probably feel worse.

The real question

A white-label Squarespace partner is not just a vendor. They become part of your delivery promise.

Even if the client never sees the partner’s name, the client still experiences the work through your brand. That means the real question is not only whether this person can build the site. The real question is whether this person can protect the relationship, the timeline, the margin, and the standard of work you want to be known for.

Choose the partner who protects the relationship, not just the one who says yes to the task.

The Hidden Assets Inside Your Squarespace Design Business

If you’ve been designing Squarespace websites for a while, you probably know the feeling of a business that looks fine from the outside.

Clients hire you. Projects get done. People like what you make. They send the nice email at the end. Your calendar stays full enough to suggest the work is working.

But underneath it, there is still a question that does not fully go away.

Is this sustainable?

Is this the whole thing?

Am I going to keep doing this the same way forever?

That question does not usually arrive as a sudden crisis.

It shows up in smaller ways.

A project drags longer than it should. A client sends scattered copy two weeks late. You find yourself explaining the same homepage problem again, and halfway through the sentence, you realize you have said these exact words before.

Then the project ends.

The client got the benefit.

The work was real.

But your business did not keep enough of what it learned.

That is the hidden cost: a design business can create a lot of value and still fail to capture that value in a form that keeps working.

The project that keeps repeating

Imagine a Squarespace designer named Maya.

Her sites are clean. Her clients trust her. She has enough work to stay busy, but not enough breathing room to think clearly about what comes next.

A new client comes in wanting “a simple website.”

That is how it always starts.

Then the project opens up.

The client has three different audiences. Their services are real, but hard to explain. They want seven pages because seven pages feels like clarity.

Maya can already tell that more pages will not solve the problem.

The problem is not the number of pages.

The problem is that the business does not yet know what needs to be clear first.

So Maya does what she always does.

She gets on the call. She asks better questions. She listens for what the client is actually trying to say. She helps them realize the homepage does not need to hold the entire business. It needs to create the right next step.

Eventually, the site gets cleaner.

Seven pages become three stronger ones.

The homepage stops trying to prove everything and starts guiding the visitor.

The client feels relieved and says, “I never would have figured that out on my own.”

Maya smiles because she has heard that before.

Then the project ends, and the lesson disappears back into her head.

That was not just client work

Most designers would look at that project and say, “That’s just what I do.”

Exacto.

That is where the asset is hiding.

Maya did not just design a website.

She used judgment the client did not have yet.

She saw the real problem underneath the requested deliverable. She helped the client understand why more pages would create more confusion. She turned scattered thinking into a clearer path.

That is not just a skill.

That is knowledge produced through repeated work.

And if that knowledge only lives inside the next client call, then it has to be performed again every time.

A new client arrives, and Maya has to explain the value again. A new homepage gets messy, and she has to recreate the clarity again. A new project starts drifting, and she has to solve the same problem privately again.

That is normal in the beginning.

But after years of doing the work, the business has learned things.

The question is whether those things have become anything the business can use.

Skill has to be performed. An asset can keep working.

Design skill matters.

Squarespace skill matters.

Taste matters.

The ability to take a messy set of client thoughts and turn them into a website that finally makes sense matters.

But skill alone does not create leverage.

Skill has to show up again. An asset can keep working after you leave the room.

In Maya’s case, the hidden asset does not need to be a template shop or a giant course.

It might be much simpler.

It might be an article called “Why Your Homepage Feels Confusing.”

It might be a paid Homepage Clarity Review.

It might be a better section on her service page explaining why she starts with structure before design.

It might be a guide she sends before sales calls so clients understand what makes a website easier to buy from.

The form can change.

The asset is not the format.

The asset is the captured lesson.

Something she used to explain privately now has a place to live.

Something her best clients only understood after working with her can now help future clients understand her before they hire.

That is how the business starts to keep more of the value it creates.

The business gets heavier when the asset stays hidden

When the asset stays hidden, the business keeps paying with Maya’s attention.

Sales calls carry too much weight because the website does not explain enough before the call.

Proposals get longer because the value is not clear enough before the proposal.

Onboarding gets messy because clients have not been taught how the process works.

Content feels hard to write because Maya keeps trying to invent ideas instead of noticing what the work is already producing.

So she compensates with more effort.

More calls. More explanation. More customization. More patience with confusion that could have been reduced earlier.

That works for a while.

Then it becomes the ceiling.

Not because Maya is not talented.

Because the business has no memory.

The same lessons keep happening, but they do not accumulate.

The same insight keeps showing up, but it does not become part of the public business.

The same value keeps getting created, but too much of it stays trapped inside private projects.

Hidden assets usually feel ordinary

A hidden asset rarely announces itself.

It usually feels like instinct.

The question you ask because you know it will save the project later.

The moment you can tell a homepage is trying to do too much.

The pause before you say, “I don’t think you need more pages. I think you need a clearer path.”

At first, that just feels like experience.

But instinct is often experience that has become quiet.

And because it feels normal to you, you overlook it.

You think, “Anyone would see this.”

They would not.

That is why clients hire you.

The part of your process you have stopped noticing may be the part your clients most need help seeing.

Capture. Develop. Expose.

The way out starts with a simple rhythm.

Capture.

Develop.

Expose.

First, capture the material.

For Maya, that means paying attention to the project that keeps repeating. She notices the moment when a client’s homepage starts becoming a junk drawer. She writes down the phrases clients use when they are confused. She saves the Loom where she explains the difference between more information and clearer direction.

That is not random noise.

That is the business speaking.

Then she develops it.

She names the pattern. She turns the private explanation into a clearer idea. She starts to see that one of her real strengths is helping service businesses simplify the path from “I’m interested” to “I know what to do next.”

Now the project has taught her something she can use.

Then she exposes it.

She puts the idea where the right people can meet it.

Maybe it becomes an article.

Maybe it becomes a paid review.

Maybe it becomes a stronger service page.

Maybe it becomes the opening message in her inquiry process.

The point is not to post more.

The point is to stop letting valuable insight die inside private projects.

This is how the business starts to compound

Once Maya captures the lesson, the next client does not meet the same business.

Her website has more to say because it is carrying what the work has taught her.

Her sales calls get cleaner because some of the explaining has already happened.

Her content becomes easier because she is not pulling ideas out of nowhere.

Her offer gets sharper because she can see what people actually come to her for.

The business starts to feel less like a string of disconnected projects and more like a body of work.

Past work starts supporting future work.

The business starts remembering what it has learned.

The next level may already be inside the work

It is easy to assume the next level is somewhere outside the business.

More traffic. A new platform. A better niche. A different offer. A social media plan that finally sticks.

Sometimes one of those things is needed.

But often, the next level is much closer.

It is inside the project that went unusually well.

It is inside the client who felt the most relief.

It is inside the thing you keep explaining on calls.

It is inside the old piece of work that still contains a path forward, even though you moved on from it.

Most designers do not need to invent a completely new business from scratch.

They need to notice what their current business has already been teaching them.

Where to start

Start with one project.

Not your whole business.

Not your entire content strategy.

Not the big offer you think you should launch next.

One project.

Choose a project where the client got real value.

Then look at what actually happened:

• What did the client think they needed?

• What did they actually need?

• What did you see that they could not see yet?

• What did you explain more than once?

• What would have helped them trust you sooner?

Somewhere in that project, there is probably an asset.

Maybe it is not big yet.

That is fine.

A hidden asset does not need to arrive fully formed.

It just needs to be noticed.

Then captured.

Then developed.

Then exposed.

That is how the value already inside the work starts becoming visible.

That is how your experience becomes easier to trust.

That is how the business begins to keep more of what it has been creating all along.

Not more hustle.

Not another shiny tactic.

A better relationship with the value already inside the work.

If you want help finding the hidden asset inside your Squarespace design business, start with a Hidden Asset Review.

We’ll look at your work, your clients, your offers, and the patterns you may be too close to see.

Then we’ll find the asset that wants to become clearer.