This interview is with Nick Baudoin, Founder & President, Alkali.
As Founder & President of Alkali, what do you want enterprise readers to know about your expertise in B2B solutions, partner collaboration, and custom web development?
Most of what we do is rebuild websites for established B2B companies that are much better than they look online. Manufacturers, distributors, equipment makers, and specialized service firms. Companies with thirty or fifty years of real work behind them and a site a first-time buyer can’t read.
We know the shape of that problem because we measured it. We analyzed more than 55,000 US B2B websites and found 68% don’t state what the company does within the first five seconds, and 71% show no proof a first-time buyer can verify above the fold. That’s decades of credibility, with none of it visible on the page where the decision actually gets made.
On custom development, the thing worth knowing is that scale isn’t the interesting variable. We’ve built for iHeart, UCLA, and 1Password, and we’ve built for machine shops. What moves the number is the same in both: say what you do in plain words, make the next step obvious, and put verifiable proof where someone comparing three vendors will see it.
On working with internal teams, we’re better as a collaborator than as a vendor you hand a brief to. The people who know why a buyer picks you over another company offering something similar usually already work there, in sales, not in marketing. Our job is getting that out of their heads and onto the page.
What key moments or decisions led you to launch Alkali and shape your current approach to serving enterprise B2B brands?
I started out as a freelancer and contractor. Clients I worked with enjoyed collaborating with me, but as a contractor you’re often moving on to the next project. What we’ve found, though, is that established B2B companies need someone they can rely on for ongoing support.
After a few of those conversations, I realized I needed to create a situation where we could say yes to continuous engagements and ensure that the problem we solved for a client in the first place didn’t resurface later.
That’s how Alkali grew, and how it continues to grow. We’re brought in for a specific job and then become the digital go-to for these businesses. Once they work with us, they realize they need someone who can continue helping them, and they know we’re a partner who genuinely wants them to succeed. We give them the advice and recommendations we believe are best for their business, not simply the ones that make us the most money.
You’ve analyzed more than 55,000 B2B sites—what is one counterintuitive finding from that dataset that enterprise teams can act on this quarter?
The counterintuitive finding is that the number that most teams report is the one that flatters them the most.
We measured 56,005 US B2B homepages with Lighthouse. The median PageSpeed score is 59 out of 100, and the median first paint is 3.7 seconds. Those are the two numbers that end up in dashboards.
The number that doesn’t is Largest Contentful Paint (LCP), the moment the main content actually finishes loading. The median there is 9.3 seconds, and 87% of the sites we measured exceed Google’s four-second threshold.
So, on a median B2B homepage there’s roughly a five-and-a-half-second gap between “something appeared” and “the thing they came for appeared.” A buyer who waits out the first flicker is often still waiting. On a phone, that’s where they go back to the search results.
Two actions follow that an enterprise team can take this quarter, and neither is a rebuild.
-
Change the metric you report. If your team reports a composite PageSpeed score, you’re reporting the most forgiving measure available. 26.3% of sites land in Google’s poor band on the score, but 87% fail on LCP. Same sites, completely different story. Report LCP.
-
Fix the LCP element rather than the whole page. It’s almost always one asset—usually the hero image or whatever renders in the first screen. Compressing and properly sizing that single asset improves LCP more than a quarter of general optimization work.
One more point, because the instinct here is usually wrong: 43% of our sample runs WordPress, and the reflex is to blame the platform. The platform isn’t the villain; the accumulation is: uncompressed images, a slider nobody remembers installing, a theme from 2014 still pulling fonts it no longer uses. Replatforming to fix speed is an expensive answer to a maintenance problem.
And on being average: the median is 59. If you score in the high 50s you’re not behind your peers—you’re exactly average, and average is slow enough to lose buyers. Only 5.6% of the sample reaches Google’s good range, so the bar to clearly beat your category is lower than most teams assume.
When you start with a new enterprise client, how do you align product, marketing, sales, and engineering in the first 30 days so web design and development move in lockstep?
Not with a kickoff meeting. A big all‑hands kickoff produces agreement that isn’t real, because nobody wants to be the person slowing things down in front of the client’s leadership.
What works is a short sequence of artifacts that force the disagreements out early, while they’re still cheap to resolve.
Week one consists of separate conversations—one per function—recorded. Product, marketing, sales, and engineering describe the same company differently, and you only hear that when they aren’t in the room together. Sales will tell you the three objections they answer on every call. Engineering will tell you which integration is fragile. Marketing has a positioning doc nobody else has read. We record these and share the transcripts back, so no single version quietly wins.
Week one also includes read access to analytics and Search Console. If you don’t take a baseline before you build, nobody can tell afterward whether the new site actually did anything, and every function goes back to arguing from opinion.
Week two is the sitemap, and that’s the real alignment tool. Not design, not a moodboard. A proposed sitemap is a list of claims about what the business sells and who it sells to, and it’s the cheapest place to have the argument. On a recent engagement we put the nine real pages that existed next to 38 proposed, split into two paths for two different audiences. That one document surfaced more real disagreement in an hour than a month of status calls would have. When sales insists on a page and product says that line is being sunset next quarter, you want that in Week two on a shared doc, not in Week nine in staging.
Week three is naming owners and being blunt about the bottleneck. It is never engineering; it’s content, approvals, and product photography. That’s what turns a six‑week build into a five‑month one, and it’s almost always underestimated. So every section gets one named owner and a date, and we say out loud that this is the risk.
Throughout, we review asynchronously with recorded walkthroughs instead of meetings. Four functions can’t reliably share a calendar, and a five‑minute video gets watched by all of them. Written feedback on a video also tends to be more specific than verbal feedback in a room.
One small thing with an outsized effect: Instrument the handoff to sales before launch, not after. A hidden field capturing which page a lead came from ends the recurring argument about lead quality, because it replaces the argument with data.
When you embed your team alongside a client’s, what operating cadence do you set to prevent scope creep while increasing velocity?
Scope creep rarely means someone is being unreasonable. It’s what happens when there’s no cheap way to say yes. If every request has to become a change order, people stop asking and start smuggling things into other tickets. So the cadence has to make small changes easy and large ones visible.
We run two lanes: the defined build is fixed price against milestones with a live date. Everything else—the “while you’re in there, could you also” work—goes into a separate pool of banked hours that gets drawn down transparently. That turns most scope arguments into a budgeting decision the client makes for themselves, which is a far better conversation than a contract one.
The mechanics underneath it:
-
One thread per workstream, never one mega thread. This sounds trivial and it’s the single biggest velocity gain we’ve found. Decisions stop getting buried, and it becomes obvious when a request is actually a new workstream rather than a tweak. That’s the earliest scope signal you get.
-
Same-day acknowledgment, always, even when the answer is “got it, Thursday.” In an embedded setup the client’s team is blocked on you more often than they’ll say. An acknowledgment costs nothing and removes the follow-up email.
-
Async review by recorded walkthrough instead of meetings. We record a short video against the actual work and they leave written notes on their own time. Written feedback on a video is consistently more specific than verbal feedback in a room, and it doesn’t require four calendars to line up.
-
One standing weekly sync, for decisions only. Status goes in writing. If the agenda turns out to be only status, we cancel it.
-
Hours reported per project as we go, not at invoice. Nobody should find out what something cost at the moment they’re being billed for it.
-
A written recap at the end of every phase: what shipped, what’s still open, who owns each open item. Most of what surfaces later as scope creep was actually assumed by someone early and never written down.
The part people miss is that some scope change is correct. Discovery turns up a better path, or the business shifts mid-build. The goal was never zero change. It’s that every change is visible, priced, and chosen rather than quietly absorbed.
What decision framework do you use to choose between custom development and off‑the‑shelf platforms for enterprise web projects?
The default is off-the-shelf. Custom has to earn it, because the real cost of custom isn’t the build; it’s the decade of owning it.
Five questions, roughly in this order.
-
Is this actually a platform problem? Most requests for custom turn out to be message and structure problems wearing a technical costume. If what’s broken is that the site doesn’t say what the company does, no platform choice fixes that, and you’ll have spent six figures relaunching the same confusion on a better stack. It’s the most common and most expensive misdiagnosis we see.
-
Does the thing you do differently live in the software? If the differentiation is how you manufacture, source, or serve, the website is a shop window and off-the-shelf is genuinely fine. If the differentiation is the interface itself—a configurator, quoting logic, a customer portal, punchout into a buyer’s procurement system—that’s where custom earns its keep.
-
Count the fights, not the features. Feature checklists mislead because any platform can be bent. What matters is how often you’re bending it. One workaround is normal; a pattern of workarounds means the platform’s model of the world doesn’t match your business, and that gap only widens.
-
Who maintains it in year three? This is the question people skip. Custom means you own the dependency upgrades, the security patches, and the bus factor. If nobody internally can own it and there’s no retained partner, off-the-shelf is the right call even when custom is the better build on paper.
-
What does being wrong cost in each direction? Choosing off-the-shelf wrongly means a migration later, which is painful but survivable and well understood. Choosing custom wrongly means owning an asset nobody wants to touch, and that has a much longer tail.
In practice, the answer is usually a split rather than a side. Commodity parts come off the shelf; custom is reserved for the narrow piece that’s genuinely yours: a marketing site on a CMS your team can actually edit, with custom work limited to the quoting or portal layer. That’s what composable architecture is for, and it keeps the custom surface small enough to maintain.
One caution from our own data: 43% of the B2B homepages we measured run WordPress, and the reflex when one is slow is to blame the platform and rebuild. The platform usually isn’t the villain; the accumulation is. Replatforming to solve a maintenance problem is an expensive way to reset the clock on the same habits.
Describe one recent enterprise project where that choice materially changed speed, cost, or ROI.
A financial services client for whom we’d built previously returned, wanting a custom platform to sit alongside their core service. The brief, as it arrived, was to build the whole thing—full functionality, production ready.
Before scoping it, we asked why and, specifically, who would see this first. The answer changed the project completely: the first audience wasn’t customers but their existing investors, and the goal was buy-in for the idea.
That’s a different objective. A product has to be complete, maintainable, secure, and handle every edge case a real user will eventually find. A demonstration has to be convincing, and it has to exist soon. Those two things overlap far less than people assume, and confusing them is how budgets get spent in the wrong order.
So we stopped scoping the custom build and assembled something off the shelf that got roughly 70% of the way there, with custom work only where the idea itself had to be legible. We focused on the parts an investor would actually be judging.
What that changed:
- Cost and speed — greatly reduced. A fraction of both, because most of what a production platform needs—authentication, permissions, data handling, an admin layer—already exists in tools you can buy.
- Sequencing — Building the full custom platform first would have meant spending the money that the investor buy-in was supposed to unlock before the buy-in existed. If the investors passed, they’d own a bespoke platform nobody had funded and no user had asked for. Done the other way, the expensive decision only gets made once its justification is real.
There’s a version of this conversation that’s uncomfortable, because it means telling a client who arrived ready to spend that they should spend less right now. That’s usually the right call, and I’d argue it’s the reason they came back to us in the first place.
The general lesson: the most expensive build-versus-buy mistake isn’t picking wrong. It’s answering the question before you know what the thing is actually for. Ask who sees this first, and what has to be true after they see it. Sometimes the answer is a platform. Often it’s an argument, and an argument is far cheaper to build.
How do you instrument a B2B website so CRM, marketing automation, and analytics share a reliable customer identity and event layer?
In B2B, the hard part isn’t tagging; it’s that the sales cycle outlives the technology. First touch and closed-won can sit a year apart. Cookies don’t survive that, so identity has to be deterministic.
Email is the join key, and everything else is a helper. The email address captured during form fill is the only identifier that reliably exists in the CRM, the marketing automation platform, and analytics at the same time. Design around it and the rest gets simpler.
Then capture the context that exists before identity does, and attach it at the moment identity appears. Persist first-party session data: first landing page, first referrer, most recent landing page, the UTM set, any click IDs, and write all of it into hidden fields on every form. We do this on every build, starting with the page the visitor was on when they submitted the form. Skip it and your CRM will report that nearly every lead came from direct, which is the most common reason B2B attribution is useless.
Write the event dictionary before building anything. Most failures here aren’t technical — the problem is that “lead” means three different things in three systems and nobody noticed. Define the event names and their required properties once, then make every system emit the same names.
Send the events that matter server-side. Client-side tags get blocked and consent tooling drops a meaningful share of the rest. Form submit, qualified, opportunity created, and closed-won should fire from your form handler and your CRM, not from a browser.
Push CRM stage changes back into analytics. This is the step teams skip and it’s the one that pays. Marketing systems see form fills, sales systems see revenue, and if closed-won never returns to analytics keyed to the same ID, you optimize for lead volume instead of pipeline. More leads, less revenue, and the reporting looks healthy the entire time.
Two practical things:
- Give every form its own confirmation URL, because it makes conversion measurable without debugging events.
- Instrument the phone with dynamic number insertion, because a real share of B2B inbound arrives by call and otherwise your strongest channel reports as zero.
Model at the account level as well. The email domain is a workable account key. Three people from one company are one buying process, not three leads.
When collaborating with other agencies, systems integrators, or internal teams, how do you define ownership and handoffs to reduce rework and keep accountability clear?
Rework in multi-party projects almost never comes from bad execution. It comes from two teams, each assuming the other owned something. The work is finding the gaps, not policing the overlaps.
Ownership gets assigned per artifact, not per phase. Phases have fuzzy edges; artifacts don’t.
- The design file
- The content
- The staging environment
- DNS
- SSL
- The analytics property
- The redirect map
- The final export from the outgoing vendor
Assign one name to each and write it down. Most launch emergencies turn out to be an ownership question nobody asked.
Every handoff has a definition of ready agreed on before it happens. Design-to-development is where most rework lives, so before we build we ask:
- Are the states defined: empty, error, loading, unusually long content?
- Are mobile breakpoints included or are we inferring them?
- Are these final assets or placeholders?
We use a flagging convention for placeholders specifically, so nothing ships as final because someone forgot.
Do a feasibility review before design approval, never after. The cheapest hour in a multi-party project is a developer looking at a comp and saying that an animation won’t hold up on the real dataset and showing what will instead. If that hour happens after the client has signed off, it becomes a change order and somebody loses face, which quietly makes the next flag less likely.
Use one thread per workstream. When three companies are on a single email chain, the default assumption is that someone else will answer. Split communication by workstream, with a named decision-maker on each.
On other people’s artifacts, comment rather than edit. That sounds like etiquette, but it’s really about accountability, because the history stays legible and nobody has to reconstruct who changed what.
Prior vendor handoffs need an explicit final state. Ask for a dated final export and confirm what’s actually in it. “We got a backup a few days before launch” is how form submissions and content quietly go missing, and you find out weeks later when someone asks where the entries went.
Then provide a written recap at the end of each phase: what shipped, what’s open, and who owns each open item.
The part that matters more than any of it: accountability only works if raising a problem early is safe. If flagging a risk gets treated as blame, people stop flagging and you find out at launch instead. In partner work especially, you want it to be cheap for the other team to tell you bad news.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
One thing has changed faster than most teams have adjusted to, and it’s worth checking this quarter.
A meaningful share of B2B buyers now start with an AI assistant instead of a search box. What surprised me is the shape of the questions: they’re rarely asking which vendor to use. They’re asking whether something can be done at all. Who can make a custom version of this? What’s the right approach to that? Solution questions, not vendor questions.
That matters because the page getting surfaced isn’t your homepage or your about page. It’s whichever page describes the specific capability in plain text. On one client’s site, it turned out to be a work category page nobody had thought of as a marketing asset.
Two consequences.
-
If your capability lives in a downloadable spec sheet or a PDF line card, you’re close to invisible to this. Models read pages. The fix isn’t a new initiative; it’s moving what you already have out of an attachment and onto a page, which is usually an afternoon of work.
-
And this is the one I’d flag hardest: you probably can’t see this traffic. It often arrives with no useful referrer, so in analytics it looks like direct. The only place we’ve reliably caught it is a self-reported “how did you hear about us” field on the form. That’s how we found it in the first place, by reading form notifications after a launch.
So the cheap thing to do this quarter:
-
Add that field if you don’t have one, and actually read the answers.
-
Then go ask ChatGPT, Claude, and Perplexity the questions your buyers would ask, phrased as problems rather than company names, and see who gets named. If it’s never you, that’s a real gap now rather than a curiosity.
None of this is exotic. It’s the same discipline that has always worked in B2B: describing what you do plainly enough that someone who has never met you can tell whether you can help. The audience for that clarity just got bigger, and part of it isn’t human.