Bloomin' Brands runs on Sitefinity. SaVida Health runs on WordPress. Aussie Grill runs on Next.js. We picked each of those stacks separately, for separate reasons, after the discovery conversation made the right answer obvious. None of those clients would have been well-served by getting whatever stack we happened to be selling that quarter.
Most agencies operate the other way. They specialize in one stack, usually whatever the founder learned at the agency they came from, and they sell that stack to every client regardless of fit. The Squarespace shop sells you Squarespace. The WordPress shop sells you WordPress. The Webflow shop sells you Webflow. The shop that does Shopify is going to find a way to put your law firm on Shopify if that's what they have on the menu.
The platform decision is the most important decision on a custom-build engagement. It locks in performance ceilings, editorial workflow, integration paths, security posture, and the cost of every change you'll make for the next five years. Picking the wrong platform doesn't doom the project, but it does make every later decision harder. Picking the right one is leverage you can't get back later.
This is a piece about how we make that decision.
What "custom" actually means
Before the platform conversation, the word custom needs a clean definition. Most agencies use it to mean "a Squarespace template with the colors changed." That's not custom. Custom means:
The component library is yours, owned by you, transferable to another agency or in-house team without licensing strings. Not a vendor's framework you can't take with you.
The CMS structure was modeled around the way your team writes and the way your prospects search. Not a generic blog template with a shop bolted on.
The performance, accessibility, and instrumentation layers were engineered against your real conversion paths, not a bundled "best practices" checklist.
The visual identity was designed for your brand from the ground up, not a stock template colored to match. The photography is yours. The typography is licensed to you. The design tokens are documented in code.
That's the bar. If a "custom website" engagement isn't shipping all four of those, the word custom is being used to mean expensive. They're different.
The stack decisions we actually make, by use case
Below is the live decision tree we walk through during week-one discovery. Not a pretend tree. The actual one.
Sitefinity for enterprise corporate sites
Bloomin' Brands runs on Sitefinity. It's the right answer when the corporate IT department lives in the .NET ecosystem, the HR and finance integrations are SAP or similar enterprise stacks, and the editorial team is an internal communications group that's used to enterprise CMS patterns. The Sitefinity license is meaningful budget, and it's worth it when the firm's existing infrastructure is already Microsoft-aligned.
When Sitefinity is wrong: a three-attorney law firm doesn't need it. A regional services business doesn't need it. The license cost alone is more than the entire build budget for those engagements. Sitefinity is right when the rest of the stack is already enterprise-grade and the new site needs to fit into it.
WordPress when the editorial team writes there daily
SaVida Health runs on WordPress. The reason isn't that WordPress is the most performant CMS we ship. It isn't. The reason is that SaVida's content team, the clinicians who write the medical E-E-A-T content, knows WordPress fluently. We could ship them a faster CMS. They'd write three posts and abandon it because the editor UX was unfamiliar. The CMS the team will actually use is worth more than the CMS that scores better on a benchmark.
We ship WordPress without the page-builder Frankenstein. Custom block library written for the brand. Performance plugins audited and minimal. Security hardened against the WordPress vulnerability surface I've written about elsewhere. Core Web Vitals at Good across every template. WordPress done properly is a fine production CMS. WordPress done as a page-builder stack is structurally hostile to performance, security, and your sanity.
Next.js for headless commerce, content platforms, and product surfaces
Aussie Grill runs on Next.js. The decision was driven by three things: the brand needed page transitions and animation states that a templated CMS can't deliver, the product menu needed to read from a real data layer the marketing team could update without redeploying, and the multi-region rollout (Tampa, Saudi Arabia, Hong Kong) needed locale-aware content infrastructure. Next.js with a headless CMS underneath was the cleanest fit.
This is also our default stack for anything that touches commerce, search, or AI primitives. Headless content, edge rendering, real component composition, a deployment story that doesn't depend on a managed-WordPress host. When the project is going to need real engineering after launch, new features, custom integrations, an internal tool that runs against the same auth, Next.js is the correct floor to start from.
.NET for proprietary integrations and legacy enterprise
Less common, but real. The case where the firm's core operating system is a .NET internal application and the new public site has to talk to it natively. We ship .NET when that's the right answer. The number of agencies still working in .NET that aren't running an enterprise consulting practice is small. We're one of them because we hire that way.
Squarespace and Webflow when the project doesn't need a custom build
This one's important because it's where most agencies blur the conversation. Squarespace is fine for a five-page consultancy site that won't have content velocity past the launch. Webflow is fine for a designer-led marketing site that won't need engineering. We don't sell those engagements ourselves because they're not what we do, but we'll point a prospect toward them when they're the right fit.
Where they're wrong: any project where editorial workflow, performance ceiling, integration count, or instrumentation discipline is going to matter past month six. Squarespace can't carry a multi-region brand. Webflow can't carry a content-velocity content business. Both ship slow JavaScript bundles that fail Core Web Vitals on mobile. They're the right tool for a narrow set of jobs and the wrong tool for everything else.
The decision tree we walk through during discovery
Three questions, in this order. The answers point us at the platform.
Where does the editorial team live, and what are they fluent in? If they're publishing daily and they're already comfortable in WordPress, that's the platform unless something else overrides it. If they're not writing daily and the site is mostly static, the question becomes a performance and integration question instead. If they're an enterprise IT team that runs SAP, Sitefinity is on the table.
What integrations does the site have to live with? A site that needs to talk to Salesforce, NetSuite, or a proprietary case-management API has different needs than a site that just needs to fire form submissions to HighLevel. The integration map drives the platform choice more than people realize. We've turned away "rebuild on WordPress" requests because the integration count made WordPress structurally wrong, even when the editorial team was fluent there.
What's the post-launch engineering velocity going to be? If the firm plans to ship new features quarterly, run A/B tests, build internal tools that share auth with the public site, or grow the product surface meaningfully, that's a Next.js or full-stack engineering project. If the firm plans to update content monthly and otherwise leave the site alone, a CMS-driven WordPress or Sitefinity build will cost less and fit better.
The answers to those three questions converge on a platform within about ninety minutes of discovery. The conversation we have is rarely "Sitefinity or WordPress." It's "given how you operate, which platform will you regret in six months." That's the only useful framing.
What custom photography buys you
Every custom build we ship includes a real photography shoot. Five days on location, art-directed and color-graded to the brand palette. The Aussie Grill shoot was four days across two flagship locations with food styling on the menu hero shots. The SaVida shoot was three days across two clinics with patient consent for the brand storytelling. The Bloomin' Brands corporate shoot was a day in the corporate office with custom product styling.
The photography is on the critical path, not in the budget options. The reason: stock photography is the single most reliable signal that a brand is templated. Visit any law firm's site that uses the stock-photo handshake-in-a-conference-room hero image. Visit a competitor that has real partner photography on their hero. Tell me which one reads as the established firm. The visual brand decision is downstream of the photography decision.
We license the photography to the client outright. They own the negatives. The shoot is theirs forever, not a CC-licensed stock image they're sharing with their three nearest competitors.
The bill for the shoot week sits at $8,000 to $18,000 depending on scope, photographer, and travel. That's a meaningful budget line, but it's the line that buys the brand its visual ownership. Skipping it means the rest of the rebuild is wearing somebody else's clothes.
Why one client at a time
Two to four bespoke builds a year. Total. We do not run parallel builds. The senior who scopes is the senior who ships, and that senior is shipping one site per quarter at most.
This is a real constraint. We can't take you on if we're full, and we will tell you that during the first conversation rather than commit and rough-ship. The reason for the constraint is the same reason the engagement looks the way it does: bespoke means the senior is on the project all the way through. The engagement that runs in parallel is the engagement that quietly hands off to a junior at week four. That's not what we sell.
If our slot timing doesn't work for your business need, we'll point you at the kind of agency that can ship in three weeks. They exist. They're a real product. They're not us.
What this article isn't
It isn't a "your business needs a website" article. Your business almost certainly already has a website. The question is whether the one you have is the right one for where the business is going. Three diagnostics for that:
If the editorial team can't update the site without engineering help, the platform is wrong.
If the integrations needed for closed-loop attribution aren't possible to wire on the current platform, the platform is wrong.
If the performance ceiling on mobile is structurally below 2.5 seconds for Largest Contentful Paint, the platform is wrong.
If any of the three is true and the business case justifies a real rebuild, the conversation we'd have is about the discovery week, the platform decision, and which slot in the year is the right fit. If none of them are true, we'd point you at the audit conversation instead and you'd save sixty thousand dollars.