A Note from the Editor
Hi there,
Last time, we talked about the "just a little change" requests, and I promised we'd come back to AI. Here we are.
More and more of my conversations start the same way: "We want to rebuild our website. Someone on the team has been playing with AI and had a homepage up in an afternoon. Do we really need a tech partner?"
It's a fair question, and that afternoon homepage is genuinely impressive. But a homepage is a demo, and a website isn't a demo. It has to stay secure, stay visible on Google, keep years of links working, let your team publish without calling anyone, and keep running after the person who built it moves on.
So before you say "we'll just build it ourselves with AI" (yes, "just" is back), let's walk through what happens after launch day.
One thing up front: this is not an anti-AI issue. AI is now part of our own engineering flow, and it has made us faster. That's exactly why I'm writing this.
The question isn't whether to use AI. It's who's holding it, and who will still be holding it a year from now.
Let's go.
What to expect
Four hidden costs of rebuilding your website in-house with AI: the ones that never show up in the demo.
Before you prompt: Three questions to answer before you rebuild, whoever ends up building it.
Behind the Scenes: What the Storkers were up to this week.
Launch day is the cheapest day
AI has changed what it costs to start a website. It hasn't changed what it costs to own one.
Let's be fair about the scorecard. On speed to launch, the in-house AI build wins: you can have something live in days, while even an AI-accelerated professional build takes weeks. I won't pretend otherwise.
But speed to launch is one line on a much longer list: who can edit what, how safe it is, who fixes it when it breaks, and whether it can grow with you. That's where the real bill arrives, usually a few months after launch and at the worst possible moment.
A website is there to last , not just for launch day.
The 4 hidden costs of building it yourself with AI
When the build gets cheaper, the costs don't disappear. They move to after launch, and onto your team's desk. Here are the four I see most often:
1. The cost of "set and forget"
A website is not a "set and forget" asset. Once it's live, it needs security patches, plugin and software updates, backups, hosting and server tuning. With a partner, that's someone's job; in-house, it's usually nobody's job until something breaks.
And things break at the worst time. The true cost of a website is the opportunity lost when a page fails during your biggest moment: the donation page on giving day, the sign-up form during a product launch, the campaign page during a global summit. The AI that wrote your code won't be the one who notices, at 2am, that your contact form stopped sending emails.
My advice: Before you build anything, name the person who will own updates, backups and monitoring, their backup, and the hours per month they'll spend on it. If the answer is "we'll figure it out", you've just found your first hidden cost.
2. The cost of the black box
AI is very good at writing code that works. Whether that code is safe is a different question, and the answer depends on someone knowing what to ask for and what to check.
When nobody on your team can read what the AI produced, you have a black box. That's fine for a prototype, but not for a page that takes payments, collects donations or stores your customers' or supporters' personal data. A breach there isn't a technical problem: it's a reputational catastrophe that can undo years of trust overnight.
My advice: Don't reinvent what already exists. Build on a widely used, well-maintained foundation, so a large community is finding and fixing security holes alongside you. And never ship anything that touches payments or personal data without a review from someone who knows what a vulnerability looks like.
Unpopular opinion: If nobody on your team can explain how your website works, you don't really own it.
3. The cost of Bus Factor
The Bus Factor is the number of people who'd have to disappear (hit by a bus or, more likely, hired away) before your project stalls. With in-house AI builds, it's usually one: the person who wrote the prompts.
Here's the irony. Most teams rebuild because every small change on their current site needs a developer, and that bottleneck slows everything down, from urgent campaign responses to product updates. The in-house AI rebuild rarely removes that bottleneck. It just moves it, from "we need a developer" to "we need the one colleague who built it", whose only documentation is their chat history.
And every change still means going back to the AI and hoping the fix doesn't break three other things. (Remember the domino effect from two issues ago?)
My advice: Judge any rebuild with one test: can the least technical person on your team publish a new page on their own, without breaking anything? If not, you haven't removed the bottleneck, you've just renamed it. And whoever builds it, insist on documentation and recorded training sessions.
4. The cost of starting from zero
A website is an asset with history: years of search rankings, links from partners and press, and reports people have bookmarked and shared. None of that lives in the design. It lives in your URLs, your structure and your content.
A rebuild that "just starts over" can quietly erase all of it. Old links hit dead ends, rankings drop, and the report your partners link to every year disappears. AI can generate a beautiful new site in an afternoon, but it has no idea which of your old pages bring in most of your traffic unless someone checks.
My advice: Start with an honest audit: what's working (protect it) and what's broken (that's what you're actually fixing). Before you touch anything, pull your top pages from your analytics and make sure every URL that matters either survives or redirects to its new home. And treat migrating old content, like past reports and data, as real work, not an afterthought.
AI or a partner? Wrong question.
The real choice isn't between AI and a technology partner. It's between AI used as a shortcut and AI used as a tool, by people who will still be accountable for the result a year from now.
That's how we work now. We use AI to prototype custom building blocks in days, so the budget goes into the parts that decide whether a site survives: the audit, the structure, the migration and the security.
Here's what that looks like in practice. We recently put together a proposal for a global advocacy network with country alliances on several continents. The honest audit was clear: their content and the trust they'd built over years were working; rigid templates that needed a developer for every small change were not, and that hurt most when a campaign needed an urgent response.
So instead of "a new website", we proposed moving them from managing a website to operating a platform:
Drag-and-drop blocks, so communications staff can build and change complex pages without touching code.
Regional publishing, where each country alliance posts its own events and reports, and they appear automatically on the global site.
Tiered access, so every team can edit what it owns, and nothing it doesn't.
An auto-generated monthly bulletin, built from the same content, with no copy-pasting.
A migration plan that protects years of search rankings, links and reports.
None of that is hard to demo. All of it is hard to get right, and even harder to keep right.
Before you decide who builds it, answer these three questions:
What's actually broken? "It looks outdated" is a symptom; "we need a developer to change a headline" is a problem. The more specific your answer, the clearer it is what to build, and sometimes it isn't a whole new website.
What will it cost over three years, not three weeks? Add hosting, updates, security monitoring, fixes and staff time to the build price. That's the number to compare.
Who is accountable when it breaks? Not which tool: which person. If it's someone on your team, make sure it's in their job description, not just their goodwill.
Thinking about a rebuild right now, or weighing whether to do it in-house?
Just reply to this email. I read every one, and I'm happy to give you an honest second opinion, no pitch.
News from the Nest (Muhammad)
Last month was extremely busy but it did not stop of from building yet a new internal tool.
Muhammad's idea was to start where the team already lives (Slack) and build an AI layer on top of it to help us write better proposals. It brings together each person's know-how and our large bank of past projects and proposals, and splits the work between the right people on the team.
But the tool is only half the story. Muhammad also sparked valuable conversations about how we build proposals, how we put our competitive edge front and center, and where AI fits in the way we run Polar Stork.
