"Can we add the sermon archive before launch?"
Somebody asks a version of that question on every website project I've ever been part of. Swap "sermon archive" for "case study library" or "customer portal" or "blog migration" and you've heard it too. It sounds harmless. It's how projects die.
Right now, in our delivery pipeline at Chykalophia, we're building a new site for a youth ministry. Good people, real mission, and a goal I can describe in one sentence: help more teens and families find them, find their events, and move from curious to involved without twelve clicks.
Then there was the wishlist.
Sermon archives. Resource libraries. Giving flows. Small group tools. Volunteer portals. Every item had a champion, and every champion had a reason it was must-have for launch.
Here's the math nobody in those meetings wants to say out loud. If everything is must-have, the launch date is fiction. This team would have been stuck in redesign limbo until Christmas, reaching exactly zero new families while the perfect site stayed perfectly unfinished.
This post is about the reframe that got them out, why "Phase 1" deserves a better reputation than it has, and the exact filter we use with clients to decide what ships now and what waits for evidence.
The wishlist problem is not a discipline problem
First, a defense of the people who build these wishlists. They aren't being unreasonable. Every single item on that ministry's list was a real need held by a real person.
The sermon archive matters to the teaching team. The giving flow matters to the finance folks. The small group tools matter to the volunteers who run small groups. Nobody is wrong.
The problem is structural, not personal. A website project is one of the few moments an organization feels permission to ask for everything at once. Budgets are approved, attention is high, and everyone knows that once the site launches, getting changes made will feel harder. So the rational move, for each individual stakeholder, is to push their item into the launch scope.
Individually rational. Collectively fatal.
I've watched this pattern on church sites, B2B service sites, e-commerce builds, and SaaS marketing sites. The wishlist isn't a sign of a dysfunctional team. It's the default physics of any project with more than two stakeholders. Which means you don't fix it with discipline or stricter meetings.
You fix it by changing the question.
The question that breaks the deadlock
The old question, the one that generates wishlists, is: what does the site need?
That question has no natural stopping point. Everything can be justified under "need" if you zoom out far enough. A sermon archive serves the mission. So does a podcast. So does a mobile app. So does a metaverse campus, if you let the meeting run long enough.
The new question, the one we put in front of the ministry team, was this:
What is the one primary action this site should drive in the next 90 days?
One action. Ninety days. Those constraints do all the work.
For this ministry, the answer was clear once we said it plainly. A new family lands on the site, understands who this is for, and knows how to show up this month. That's the whole job.
Once that sentence existed, the work split itself in two.
Phase 1: ship a clear, fast path for that new family. Nothing else.
Phase 2 and beyond: add the deeper features after we can see how people actually use the core flows.
The deadlock broke not because anyone lost an argument, but because the argument changed shape. We were no longer debating whether the sermon archive is valuable. Of course it's valuable. We were asking whether it helps a new family show up this month. It doesn't. Into the bucket it goes, with its value intact and its timing corrected.
What we actually cut, and what it cost
The filter sounds clean in a paragraph. In practice it meant some uncomfortable conversations.
We made ruthless cuts to nice-to-have pages. Pages people had already written content for. Pages with internal champions who had been promised a spot in the navigation.
We simplified the navigation down to three jobs: Visit, Learn, Get Involved. Not because three is a magic number, but because a stressed parent on a phone doesn't browse. They scan, they decide, they leave. Every extra menu item is a small tax on the one action that matters. Twelve menu items means twelve chances to wander off the path.
And we rebuilt the content plan around real events with real dates, not abstract mission statements. "Who we are" pages make the organization feel good. "Here's what's happening Thursday and here's how to join" pages make new families show up. When you only get one phase, you spend it on the second kind.
None of these cuts were fun. All of them were cheaper than not launching.
I want to be honest about the cost, though, because pretending Phase 1 is painless is its own kind of lie. Somebody's project got deferred. Somebody had to walk back a promise they'd made to their team. The delivery lead had to hold the line in meetings where holding the line made her the least popular person in the room. Phase thinking is simple. It is not easy.
Phase 1 is a strategy, not a scope cut
Here's the part I want to push back on, because I hear it in client meetings constantly. There's a quiet assumption baked into how people say "Phase 1." A slightly apologetic tone. The budget version. The compromise you accept until you can afford the real thing.
I think that framing is exactly backwards, and I'll make the case in four parts.
1. Speed to service
A live site that helps one family show up this month beats a perfect site that helps nobody until next year. That's not a platitude. That's arithmetic. Every month in redesign limbo is a month of zero output from your most visible asset.
For a mission-driven organization the cost is measured in people not reached. For a business it's measured in pipeline. Either way the meter runs the entire time you're "almost done." I wrote about a related version of this discipline, moving a date honestly instead of grinding through it, in the bravest thing you can do under a deadline. Same principle, different lever: the schedule serves the outcome, not the other way around.
2. Budget protection
Every week a project sits in "what about this feature" mode, money burns and momentum dies. Scope debates are the most expensive meetings in a services engagement, because they're recurring, they involve everyone senior, and they produce nothing.
A hard Phase 1 line ends most of those debates before they start. The answer is pre-decided: does it serve the primary action in the next 90 days? No? Bucket. The debate that used to take three meetings now takes one sentence. Multiply that across a four month engagement and the savings buy you a meaningful chunk of Phase 2.
3. The stakeholder story
This one matters more for nonprofits and funded organizations than people expect. Your board, your donors, your investors are not evaluating your website. They're evaluating your ability to execute.
"Here's what ships now, here's what's coming next, and here's what we'll learn in between" is a confident plan with a built-in progress report. "We're still working on it" is the sentence that makes funders nervous, six months running.
Same project. Completely different story. The phased version gives you three or four announcements instead of one delayed one.
4. Evidence beats opinion
This is the part I care about most as a CTO. Phase 2 built on real usage data is a different animal than Phase 2 built on conference room guesses.
Once the core flows are live, you stop debating hypothetical futures and start reading actual behavior. Which events page do people actually visit? Where do new families drop off? Does anyone click toward the resources section at all?
Half the wishlist usually dies quietly at this point, because the data shows nobody needed it. That's not failure. That's the system working. The features that survive get built with confidence instead of hope, and the ones that die free up budget for things you couldn't have predicted in the planning meetings.
The most expensive features in any build are the ones nobody uses. Phase thinking is the cheapest insurance against them that I know of.
The Phase 1 filter, step by step
If you're staring at a site project that keeps growing instead of shipping, here's the exercise we ran with the ministry team. It takes an afternoon, not a quarter.
Step 1: Define the one primary action your site should drive in the next 90 days.
One. If you have three primary actions, you have zero. The test for whether you've actually picked one: a stranger should be able to read your homepage and predict what you want them to do next.
For the ministry it was "new family shows up to an event this month." For a B2B services firm it might be "qualified prospect books a call." For a product it might be "visitor starts a trial." Pick the action that, if it happened 50 more times this quarter, would change your year.
Step 2: List every page and feature that directly supports that action.
Be honest about the word "directly." The events page directly supports a family showing up. The staff bios page supports trust, which supports showing up, which is the kind of two-hop reasoning that lets everything back in. If you can't draw a one-step line from the page to the action, it's not Phase 1.
Step 3: Put everything else in a Phase 2 bucket and stop pretending it's launch-critical.
The bucket is not a graveyard. Write every deferred item down, with its champion's name next to it, and commit to reviewing the bucket against real usage data 60 days after launch. That commitment is what makes the cuts survivable politically. People can accept "later, with evidence" far more easily than "no."
Step 4: Decide what you'll measure before you launch.
Phase 2 is supposed to be built on evidence, which means Phase 1 has to produce evidence. Before launch, write down the three or four numbers that will settle the bucket debates. For the ministry: event page visits, clicks on Get Involved, form completions, and where new visitors drop off. Nothing exotic. The point is that when the sermon archive conversation comes back in 60 days, you answer it with a chart instead of a longer meeting. If you skip this step, Phase 2 planning collapses right back into opinion, and the loudest voice in the room wins again.
Step 5: Re-test the navigation against a stressed visitor.
Picture your actual visitor on their worst day. The parent on a phone in a school pickup line. The founder squeezing research between calls. Can they get from your homepage to the primary action in two clicks? If your navigation needs a tour guide, it's not done being cut.
The objections, and what I say to them
"Our stakeholders will revolt if their feature gets cut." They'll revolt at "no." They mostly won't revolt at "Phase 2, reviewed against data in 60 days, here's the written list with your name on it." The bucket with a review date is the political technology that makes phase thinking work.
"Phase 2 never actually happens." Sometimes true, and worth taking seriously. The honest answer: if Phase 2 never happens because launch data showed those features weren't needed, the process worked and saved you money. If Phase 2 never happens because the organization lost interest after launch, that tells you those features never had real organizational weight behind them, only meeting-room momentum. Either way, you learned it for the price of a Phase 1 instead of the price of everything.
"Our project is different. Everything really is essential." I've heard this on every project where we eventually cut 40 percent of the scope and nobody noticed after launch. The feeling that everything is essential is universal. The reality never is. The 90-day primary action question is how you find out which is which.
"Won't a smaller site look unfinished?" A focused site reads as confident, not unfinished. Visitors don't see your wishlist. They see whether the thing in front of them answers their question. Three clear paths beat twelve half-built ones every time a real human is involved.
What this looks like beyond ministries
I've used a ministry site as the spine of this post because it's the project on my desk right now, but the pattern is the same everywhere we apply it.
A B2B services firm rebuilding their site: Phase 1 is the service pages and proof that drive booked calls. The resource center, the podcast hub, the team culture pages all go in the bucket until call volume validates the core.
An e-commerce brand replatforming: Phase 1 is the product pages, cart, and checkout, tuned hard. The lookbooks, the brand story microsite, the loyalty program integration wait for the revenue baseline.
A founder launching something new: Phase 1 might be a single page with one offer and one button. I've seen one-page Phase 1 sites outperform fifty-page palaces because every visitor lands on the only path that matters.
The constant in all of them: one primary action, the shortest honest path to it, and a written bucket for everything else.
Ship the path
The team on this ministry project is now excited about a launch date they can actually hit. I've been doing this long enough to tell you that sentence is rarer than it should be. And when the site goes live, they won't be done. They'll be started, which is better, because everything they build next will be built on evidence.
Your community doesn't need the perfect site. They need a clear path to show up.
Ship the path. The palace can wait, and honestly, once you see the data, you'll probably build a different palace anyway.
If you're in the middle of a never-ending site project and want a second opinion on where your Phase 1 line should sit, that's exactly the kind of engagement we run at Chykalophia. Bring the wishlist. We'll bring the filter.