DEV Community: Wbcom Designs 💡

When the big platforms close their doors, what should your community keep public?

Wbcom Designs 💡 — Sat, 31 Oct 2026 15:38:18 +0000

Two things keep happening at the same time, and they pull in opposite directions.

Big discussion sites are putting more of their threads behind a login. People who used to find a fix through a search engine now hit a sign-up screen instead. Meanwhile, some chat platforms are moving the other way, making conversations from large servers visible to search, even though plenty of members joined thinking they were talking in a closed room.

Across the communities we follow, the reaction has been mixed and surprisingly personal. One person said it plainly: every forum ends up behind a login eventually. Another pointed out that when one site closes up, the AI answer tools simply cite the next forum that's still public, so the knowledge doesn't vanish, it just moves to whoever kept the door open. Someone asked, half joking, whether we can have forums back now. A support lead said their team runs help in a chat server and nobody can find last month's answer. Someone else wrote that they felt conflicted: glad that chat knowledge might finally be findable, uneasy that members never agreed to it.

If you run your own community, on your own site, none of this is decided for you. You get to choose. That's exactly what makes it hard.

Which camp are you in?

We keep seeing three positions. Most people we talk to lean toward one but borrow from the others.

Camp 1: Open by default

Answers are public. Anyone can read without an account; you need one only to post. The reasoning: knowledge that helps people should be findable, search traffic is how new members arrive, and a public archive is the best marketing a small community has. Forums that took this route years ago still get visitors from threads written long ago.

The trade-off: members may say less when every word is indexed. Scrapers and AI crawlers read everything. Moderation has to account for outsiders landing on old threads with no context. And "public" is hard to undo once a search engine has it.

Camp 2: Members only

Everything sits behind a login. The reasoning: people share more honestly in a room they know is closed, a paid community has to offer something the open web doesn't, and members, not search engines, are the audience. For many paid communities, privacy is the whole product.

The trade-off: you become invisible. New people can't see what they'd be joining, good answers can't help anyone outside, and the community depends entirely on referrals and your own marketing. If the community closes one day, everything it knew can disappear with it.

Camp 3: Split by purpose

Some spaces are public, some aren't. Typically, help and how-to categories are open and indexable, while introductions, member-only discussion, paid content and anything personal stay behind a login. The reasoning: different conversations carry different expectations, so the settings should match them.

The trade-off: someone has to decide where every category goes, explain it clearly, and stick to it. The worst version of this camp is one where the line moves quietly and members only find out from a search result.

What we think matters more than the camp

Whichever way you lean, a few principles seem to hold up in every discussion we've read:

Members should know before they post. The problem people describe with chat being made searchable isn't openness itself. It's that the rules changed after people had already spoken.
Changing your mind should be a decision, not a default. If you open a closed space, ask first and give people a way to remove old posts. If you close an open one, think about what happens to the people who relied on finding answers there.
Search and AI are not the same question. Some owners want search engines in but AI training crawlers out. Others don't mind either. It's worth deciding separately.
A public answer needs a good home. A chat snapshot with no title and no accepted answer is technically public and practically useless. If you want answers found, give them a thread title, a clear answer and a stable URL.

We run our own communities and build tools for others to run theirs, and our honest view is that the split camp is where most communities end up. But we've seen strong small communities thrive at both extremes, so we don't think there's one right answer.

Your turn

Is your community open by default, members only, or split? What made you choose that?
Have you ever changed a space from private to public, or the other way round? How did members react?
Do you treat search engines and AI crawlers differently? Where do you draw that line?
When a big site you used put its threads behind a login, did it change where you go for answers, or where you post your own?

Your plugin or platform just raised its price. Six assumptions to check before you switch

Wbcom Designs 💡 — Sat, 31 Oct 2026 15:38:05 +0000

A price change has a way of turning a calm tool into an urgent project. A theme framework drops its cheaper tiers and sells only per-site plans. A course plugin gets folded into a hosting bundle. A course platform's top plan suddenly costs several times what it did. A community platform adds a fee to every member renewal. An automation service charges per task, and the bill grows with every workflow you add.

Across the communities we follow, the reaction looks the same each time. Some people start planning the move the same evening. Freelancers start offering migration services. Others build their own replacement with an AI assistant over a weekend. And a quieter group sits down, reads the new terms twice, and renews.

We've helped a lot of site owners through these moments, and we keep seeing the same assumptions come up. Some hold. Most need checking first.

1. "We have to decide before the renewal date"

Usually not quite. Most renewals don't switch anything off on the day. You'll often have a window where the current version keeps working, even if updates and support pause. That window is worth knowing exactly, because it turns a panic into a plan.

What we'd check: does an expired licence stop the plugin working, or only stop updates? Is there a grace period? Can you renew for one more year at the old price while you test something else? Several people in these discussions found they had more time than the email suggested.

2. "Moving is mostly about the content"

This is the one that bites. Content usually moves. Lessons, posts, listings and pages tend to come across with an importer or a few hours of copy and paste.

What doesn't move as easily is the logic around it. One site owner leaving a course plugin had 25 courses that all relied on group enrolment codes, and the importer they were looking at skipped groups entirely. Others found the same with certificates, coupons, past orders, drip schedules and member permissions. Before you price a move, list the things your site does, not just the things it holds.

3. "Building our own will be cheaper"

Sometimes, for the first month. We understand the pull. One creator left a course platform costing a few hundred a month and built a custom lesson site instead. Others are building with AI help and are genuinely pleased with the first version.

The cost shows up later, in the edge cases: failed card renewals, someone who needs re-enrolling, a certificate reissued with a corrected name, a refund that should remove access, a security update nobody scheduled. If you build, budget for year two, not just launch week. If you don't want to own those edge cases, that's a very good reason to pay someone who does.

4. "Self-hosted means free"

Self-hosted means you pay differently. People moving off per-task automation pricing make a fair point: running the same workflows on your own server can cost far less. But someone now owns the retries, the logs, the failure alerts and the 2am "why didn't that email send?" That someone is usually the person who suggested the move.

Self-hosting is often the right call. Just write down who handles failures before you switch, so it isn't decided by whoever notices first.

5. "Everyone is leaving, so we should too"

Loud isn't the same as most. Price changes produce a lot of noise, and the angriest posts travel furthest. Many people quietly renew because the tool still fits and the switching cost is higher than the increase.

A useful exercise: work out what the new price costs you per member, per student or per client site, then compare it with what a move costs in hours. Sometimes the increase is a rounding error. Sometimes it changes your margins completely. Agencies with many client sites on per-site licences tend to feel it most, which is why they're often the first to move.

6. "The next tool won't do this to us"

Any tool can change its pricing. That includes the one you move to, and it includes ours. What you can control is how painful the next change would be.

The habits that help are boring ones. Keep your data in formats you can export. Keep payments in an account you own, so money doesn't sit with a middleman. Avoid features that only exist inside one vendor's world unless they're worth it. Keep a short document of what your site depends on. That way the next renewal email is a decision, not an emergency.

A simple order of work

When a price change lands, this is roughly the order we suggest:

Read the new terms and find out exactly what stops on the renewal date.
Work out the real yearly difference for your setup.
List what your site does (enrolment rules, payments, permissions, automations), not just what it stores.
Test one alternative with a copy of real data, including the awkward parts.
Decide with the full cost of moving in front of you, including your own time.
If you move, move in stages and keep the old setup readable until you're sure.

None of this needs to happen in a weekend.

Your turn

When a tool you rely on raised its price, did you move, renew, or build your own? Would you make the same call again?
What turned out to be the hardest thing to migrate, the part nobody warned you about?
For those who built a replacement themselves: what broke first, and how long after launch?
How do you work out whether an increase is worth the effort of moving: per seat, per site, per hour of your time, or gut feel?

Flat-fee WordPress care plans: where does maintenance end and paid work begin?

Wbcom Designs 💡 — Fri, 30 Oct 2026 15:47:06 +0000

Every time a big security story hits the WordPress world, the same thing happens. Site owners get nervous, and freelancers and agencies start offering to look after their sites for a flat fee.

We've watched this play out across the communities we follow. One freelancer offers a single yearly price per site for updates, backups and monitoring, with online stores explicitly carved out because they need more work. An agency owner with nearly two decades on WordPress says the real problem isn't the tooling at all: you can lock down hosting, automate updates and standardise plugins, but if clients can administer their own sites, something eventually breaks, and nobody is paying for that hour. A reply to that same point was blunt: bill full rate for it, and the people who rely on the site for their business pay without complaint.

Other people keep raising the gaps a care plan can quietly swallow. "Update all" in the dashboard doesn't touch the PHP version the host runs, and plenty of owners don't know who is responsible for that. A restored backup after a hack can bring the backdoor back with it. One freelancer charges extra for weekend support and finds that sets expectations better than any contract clause. And a reader of one of our earlier pieces described a habit we liked: when a request comes in, reply the same day with which bucket it falls into, so "can you just..." never becomes unpaid work by default.

So the questions aren't really about price. They're about where the line sits.

Two honest positions

Flat and simple. One price per site per year covers a defined list: core, theme and plugin updates, offsite backups, uptime and security monitoring, a set number of small fixes. Clients understand it and can budget for it. The provider accepts some months will cost more than others and prices for the average. Anything outside the list is quoted separately.

Scoped and metered. The plan covers the routine work, but any breakage caused by the client, a new plugin, a theme change or a host decision is billable at an hourly rate. This protects the provider, but clients can feel nickel-and-dimed, and the conversation about every incident starts with "whose fault was it?"

Most real plans sit somewhere between these, and the hard part is writing down where.

The grey areas we see most

Client-caused breakage. The client installs a plugin, edits a template or gives admin access to a nephew. Covered or not?
PHP and server upgrades. Is moving a site to a newer PHP version maintenance, or a small project with testing?
Security cleanup. Monitoring is in the plan. Is cleaning up a hack, rotating every credential and checking for backdoors also in the plan?
Online stores and member sites. Logged-in users, payments and personal data multiply the risk. Separate tier, separate price, or not offered at all?
Content edits. "Can you change this paragraph?" sounds tiny. Fifty a year isn't.
Response times. Next business day, same day, or weekends at a premium?
Who keeps admin access. Some providers refuse to maintain a site where the client also has full admin rights. Others think that's unreasonable for a site the client owns.

What we'd put in writing either way

Whichever model you pick, a few lines in the agreement save most of the arguments later. Name what's included in plain words, not "general maintenance". Say who owns the hosting account and who decides on PHP upgrades. State what happens after a hack: what the plan covers, what's quoted, and that restores are checked for leftover access. Give a response time and say whether weekends cost more. And agree on the "which bucket" reply, so every request gets labelled as included, quoted or out of scope before anyone starts work.

The bigger question underneath

Some developers are reaching a sharper conclusion: if you're not going to be in charge of a WordPress site, don't run it at all, and point clients with simple needs toward something with fewer moving parts. Others argue that's exactly why care plans exist, and that the platform's flexibility is the reason clients want someone looking after it in the first place.

We build on WordPress every day, and our own view is that both camps are right about different clients. A one-page site with no logins doesn't need a care plan. A site with members, payments or a busy editorial team needs one, priced honestly. What doesn't work is a plan sold on peace of mind with no written line between routine work and new work.

We'd like to hear how others draw that line.

Your turn

What does your care plan explicitly exclude, and how did you decide on that list?
When a client breaks their own site, do you fix it inside the plan, bill hourly, or something else?
Do you price stores and member sites as a separate tier, and how big is the difference?
Has a security scare ever turned a retainer into far more hours than it paid for? What did you change afterwards?

Closing a quiet forum without losing what it knows

Wbcom Designs 💡 — Fri, 30 Oct 2026 15:46:53 +0000

A lot of forums don't end with an announcement. They end with an owner who is tired.

The pattern we keep running into across the communities we follow goes like this. A hobby site has run a message board for years. Activity has thinned to a handful of regulars. Spam takes more moderation time than real posts do. One evening the owner turns the board off "temporarily", and a few weeks later admits it is probably permanent.

Then comes the part almost everyone regrets. The board had years of answers in it. Questions about obscure products, repair steps, local history, how a tool behaved before an update. Once the board is off, those pages stop answering anyone. One owner put the worry plainly: the old discussions would only survive in a web archive that search engines don't send people to.

At the same time, a louder conversation is running in the other direction. Big platforms are putting answers behind logins or letting them be scraped on terms the community didn't pick. And a steady stream of people are saying the fix is to put knowledge back on websites: forums and wikis that anyone can read without joining anything.

Those two things sit uneasily together. People want public, findable answers. The people who host them are burning out. So here is how we would think about closing a forum well, from a team that builds community software and has watched a few of these wind down.

Separate "the community" from "the archive"

The first mistake is treating the forum as one thing. It's two.

The community is the live part: new threads, replies, moderation, accounts, private messages, spam. This is where the cost is.

The archive is the record: every thread that already exists, with its title, answers and links. This costs almost nothing to keep if you strip away the live parts.

Most owners who shut a board down want to stop running the community. Very few actually want to destroy the archive. They delete both because the software doesn't make it obvious how to keep one without the other.

Your realistic options

Here are the paths we see people take, from least work to most.

1. Read-only mode. Close registrations and posting, keep every thread readable at its existing URL. Most forum software can do this with a setting or a small permission change. Spam stops because nobody can post. Search engines keep finding the old answers. This is the option we'd suggest considering first, and it's the one large open-source projects have used when they moved their discussion elsewhere.

2. Static export. Turn the forum into plain HTML pages and switch the software off entirely. No database, no logins, no updates to apply. This is more work up front, but it's the cheapest thing to keep online for a decade. The trade-off is that search inside the archive needs a separate solution, and any fixes later are manual.

3. Hand it on. Find a co-admin or a member who wants to keep the live community running. This works when there is still a core group. It fails when the handover is just "here's the password", so write down where the domain, hosting, backups and spam settings live before anyone takes over.

4. Merge it into something bigger. Move the active discussion into a larger community site, a wiki or a members area on the main site, and keep the old board as a read-only archive linked from it. People who still care have a place to go; the history stays put.

5. Shut it down completely. Sometimes this is right: legal risk, personal data you shouldn't keep, or content nobody would search for. If you do it, export a full backup first and decide deliberately rather than by default.

Before you flip any switch

A short checklist we'd run through regardless of the option:

Export everything. A full database dump plus attachments, stored somewhere that isn't the same server.
Keep the URLs. The value of an old forum is that links to it still work. If the structure changes, set redirects from old thread URLs to the new ones.
Check what's private. Private messages, hidden sections and email addresses should not end up in a public export.
Post a closing notice. A pinned thread explaining what happened, where people can go next, and how long the archive will stay up.
Remove the attack surface. If the software stays online, turn off accounts and posting, remove unused plugins and keep it patched. A forgotten forum is a common way into an otherwise healthy site.
Tell the regulars personally. The handful still showing up deserve a heads-up before the switch, not after.

Why it went quiet matters

It's tempting to say forums died because chat apps and feeds won. That's part of it. But owners also describe a quieter cause: the board itself got harder to use and harder to keep clean. Old interfaces, no mobile layout, notification settings nobody understood, and spam that outran a single volunteer moderator.

That's worth noticing if you're planning what comes next. Some people argue a modern forum that handles spam well and feels current on a phone could bring people back, especially as more platforms lock their content behind logins. Others think the moment has passed and small groups will stay in chat. We don't think there's one answer. But if you're keeping or restarting a forum, the moderation load and the reading experience are the two things to fix first, because they're usually what killed the last one.

A simple rule of thumb

If people still land on old threads from search, keep them readable. If nobody does and the content carries risk, archive it privately and close it. And if a few regulars are still active, give them a home before you lock the doors.

The answers in an old forum were written by people who took time to help strangers. Keeping them findable is often the least expensive kindness a site owner can do.

Your turn

If you've closed or frozen a forum, which option did you pick and would you choose it again?
Has read-only mode worked for you over the long run, or did the old software become a security problem?
What finally made your forum go quiet: chat apps, spam, the interface, or the people running it?
If you were starting a forum again, what would you do differently from day one?

Open the doors to everyone, or seed one side first? The empty-community debate

Wbcom Designs 💡 — Thu, 29 Oct 2026 15:40:44 +0000

Every builder of a community, marketplace or job board meets the same wall. The product works. The signup flow works. And the first visitors land on a page with nothing happening, so they leave, which keeps it empty for the next visitor.

We see this question constantly across the communities we follow. A language-exchange app reaches the top of a launch board and still has almost no active users a week later. A niche job board founder asks how to get employers to post when there are no posts to show them. A developer collaboration platform has signups but no projects. A small community build log celebrates its first dozen members and then asks what to do with them. Someone launching a new voice community asks what the first thing a new member should do even is.

The advice people give splits into two camps, and they disagree more than you'd expect. So this one is mostly questions.

Camp 1: Seed one side first, and do it by hand

The argument here is that a two-sided product is really two products, and you can't launch both at once. Pick the side that's harder to get, and make the product worth using for them even when the other side is empty.

What this looks like in practice:

A job board posts the first listings itself, from public openings, with a clear note that they were gathered and a way for employers to claim them.
A directory seeds hand-checked listings before asking anyone to submit, so the first visitor sees something useful.
A marketplace recruits a small group of sellers personally and gets their first orders through people the founder knows.
A community invites a few people who already talk to each other and asks them to show up in the same week.

People in this camp say opening to everyone on day one wastes your launch. The few curious visitors you get see emptiness and never come back.

The pushback is real, though. Seeded content can feel fake, and listing people who never signed up raises consent problems. Hand-recruiting doesn't scale, and it can hide whether anyone would come on their own.

Camp 2: Open the doors, but give people a job

The other camp says seeding is often a way to avoid finding out whether the idea works. Open up early, accept that it will be quiet, and make the first visit useful without other people.

The key point we kept seeing: people join communities when they know how to participate. An empty space with a vague "introduce yourself" thread asks newcomers to do the founder's job. A space with one clear first action (answer this question, post your setup, claim your profile, book one session) gives them something to do even when it's quiet.

People in this camp also argue that a small, real group beats a big, staged one. A dozen members who actually talk can carry a community for a long time, if the founder shows up every day and doesn't pretend it's bigger than it is.

The pushback here: "useful when empty" is easy to say and hard to build, and some products simply don't work until both sides exist. A marketplace with no buyers isn't a smaller marketplace. It's a list.

Where the two camps actually agree

Read enough of these threads and a few points come up on both sides:

Pick one narrow audience before you pick a launch tactic. "Everyone who learns languages" is a hard cold start. "People learning one language for work in one city" is an easier one.
The founder is the first active member. Early communities that worked had someone answering, welcoming and posting every day.
Launch-board spikes are a test, not traction. Top of the board and zero active users is a common pairing.
Be honest about the size. Small communities that said "this is new and small, here's what we're building" kept more people than ones that faked activity.

If you're building on WordPress, tools like BuddyPress, bbPress, Discourse or a directory or job-board plugin will all give you the structure. None of them solve the empty room. That part is still people work.

The questions we can't settle

This is where we'd like your experience, because we've seen both camps work and both fail.

On seeding:

Is seeding listings, jobs or posts yourself honest groundwork, or a shortcut that hides whether the idea works?
Where's the line between seeding and faking activity? Is it disclosure, or something else?

On the first visit:

What's the single first action you ask a new member to take, and did it actually change whether they came back?
Does an "introduce yourself" thread help, or does it just make the quiet more obvious?

On two-sided products:

Which side did you start with, and would you pick the same side again?
Did you ever open to both sides at once and have it work?

On numbers:

At what size did your community stop needing you to post every day?
Did a launch spike ever turn into steady activity for you, or did it fade the way many people describe?

Your turn

Seed first or open the doors: which camp are you in, and what made you pick it?
What was the first thing that made a stranger come back to your empty community, marketplace or board a second time?
If you've listed people or businesses who never signed up, how did you handle consent and claiming?
What would you tell someone about to launch their first two-sided product, in one sentence?

Where a fundraising night actually breaks: a walkthrough from ticket page to the front door

Wbcom Designs 💡 — Thu, 29 Oct 2026 15:40:32 +0000

Nonprofit event threads are some of the most honest ones we read. Nobody is selling anything. A development director, a volunteer coordinator or a board member who got handed "the website bit" describes what went wrong at last year's dinner and asks how not to repeat it.

We've collected a lot of these from across the communities we follow: galas with a line out the door, first fundraisers stuck between a free invite and a ticketed dinner, golf days with an auction bolted on, organisers waiting on payouts from a ticketing platform, and small teams trying to staff a Sunday event with volunteers who can't commit to weekends.

What stands out is that almost none of these events failed on the big decisions. The venue was fine. The cause was clear. Things broke at the handoffs, the places where one person's spreadsheet becomes another person's clipboard. So instead of a feature list, here's a walk through one composite fundraising night, stage by stage, with what people told us went wrong and what they changed.

Stage 1: Deciding what you're actually selling

The first fork comes before any ticket page exists. Is this an open event where you hope people give on the night, or a ticketed dinner where the ticket is the donation?

People who ran their first fundraiser described this as the decision they wished they'd made on purpose. Open invites bring a bigger crowd but make headcount a guess, which hurts when catering is per plate. Ticketed dinners give you a number to plan around but can shut out the supporters who would have given more once they were in the room.

A middle path that came up more than once: a free RSVP for supporters and volunteers, paid tickets or tables for everyone else, and a clear "give on the night" option for people who registered free. The important part is that free and paid sit in the same list. If they live in two tools, nobody knows the real headcount until the night.

Stage 2: Table captains and give-get goals

Many galas don't sell most tickets through a public page at all. They sell them through table captains or board members with a goal: fill a table, or bring in a set amount.

This is where reporting quietly breaks. The ticketing tool knows which tickets sold. The development team's spreadsheet knows which captain promised what. Nobody can answer "how close is each captain to their goal?" without a manual merge, usually the week before, when there's no time.

What helped: give every captain their own link or code so sales attribute themselves, and decide early whether a captain's comped seats count toward their goal. That second question sounds small. It turned into a real argument in more than one organisation.

Stage 3: Comps, sponsors and the leaky guest list

Comped seats for sponsors, speakers, honourees and volunteers are normal. The trouble starts when they're handed out by email, text and conversation, and never land in the same list as paid tickets.

People described comp leakage as a slow drip: a sponsor's table of ten becomes twelve, a speaker brings a partner, a board member "just adds a couple". None of it is wrong on its own. But catering, seating and the door list all assume one number, and nobody owns it.

The fix people landed on was boring and effective. Every seat, paid or comped, goes in one guest list with a type attached, and only one or two people can add comps. If someone wants an extra seat, it goes through them.

Stage 4: Add-ons that slow the door

Drink tickets, raffle entries, parking passes, dinner choices and auction paddles are all reasonable to sell ahead. The surprise is how much they slow down check-in when the door team has to hand out the right extras to each guest.

One pattern that came up: add-ons sold to people who never bought a ticket, which leaves the door team with someone who has a drink voucher and no seat. Another was a single check-in line where every guest needs three different things handed over.

What helped:

Only sell add-ons attached to a ticket, never on their own.
Pre-pack extras per guest or per table before doors open.
Keep a separate desk for problems (walk-ins, wrong names, payment issues) so the main line keeps moving.

Stage 5: The check-in line itself

The most vivid story we saw was a dinner for a few hundred guests with two volunteers holding printed lists, and a half-hour line in evening wear. That's not a volunteer failure. Printed lists don't scale past a certain number of guests, and that number is lower than people expect.

What people changed afterwards:

More stations than seemed necessary, split by surname or table number.
QR codes on confirmation emails, scanned on phones or tablets the team already owns.
A list that syncs, so two stations can't check in the same guest twice.
A paper backup anyway, because venue wifi is never as good as promised.

Stage 6: Volunteers and shifts

Behind the door team is a volunteer schedule, and that's often a spreadsheet plus a group chat. Small teams told us the hardest part isn't finding volunteers. It's group sign-ups (a company or a church group bringing several people), knowing who's actually confirmed, and filling gaps when partners can't do weekends.

Fixed shifts with a set number of slots, a captain who can sign up a whole group, and a waitlist when a shift fills all came up as things people wished they'd had from the start.

Stage 7: After the night: payouts, refunds and the report

The last handoff is money. Organisers on hosted ticketing platforms described payouts that arrived later than expected, lump-sum deposits with little detail, and refund requests they couldn't control themselves. For a nonprofit that needs to reconcile every gift for the board and for donors' tax receipts, unclear payouts turn a good night into weeks of admin.

Questions worth asking before you pick any tool:

Does the money land in our own payment account, or does the platform hold it first?
Who decides refunds, and how fast can we issue one?
Can we export a guest list with ticket type, comps, add-ons and check-in status in one file?

Where tools fit

There's no single right stack here. Some teams use a dedicated fundraising platform for the auction and keep simple tickets elsewhere. Others run tickets, RSVPs and check-in on their own website and keep the auction in a specialist tool. Smaller events do fine with a form, a spreadsheet and a disciplined door team.

If you run your site on WordPress, event plugins like The Events Calendar, Events Manager or our own Eventonomy cover tickets, RSVPs and QR check-in on your own site. Disclosure: we build Eventonomy. It doesn't run auctions, so a gala with a big silent auction would still pair it with an auction tool.

The tool matters less than the rule underneath it: one guest list, one owner for comps, and a door plan built for the real headcount.

Your turn

Where did your last fundraiser actually break: tickets, comps, add-ons, the door or the payout?
How do you track table captains against their goals without a last-minute spreadsheet merge?
Do comped seats count toward a captain's goal in your organisation, and how did you decide?
What's the one change that made your check-in line noticeably shorter?

Completion rate is not proof: what to measure when training actually has to work

Wbcom Designs 💡 — Wed, 28 Oct 2026 15:48:57 +0000

There's a point we keep hearing from people who run training for a living: a near-perfect completion rate can simply mean that nearly everyone clicked Next.

It comes up in different ways. An HR and operations leader said teams should stop celebrating completion and start measuring how quickly behaviour changes on the job. A continuing education provider needed proof of who actually finished which lessons before issuing credits. A course creator moving to a subscription model found that putting an old course behind a monthly fee did nothing for completion on its own. Someone running a customer academy wanted to show its value with something better than completion numbers. And learners keep describing how little of a finished course they remember a few weeks later.

These are different situations, but they point at the same gap. The number most platforms put front and centre is the one that says least about whether the training worked.

So here's a myth vs reality pass on what to measure, drawn from the people we've been listening to. No code, and nothing tied to one tool.

Myth 1: "If they finished, they learned it"

Reality: completion tells you someone reached the end. It doesn't tell you they can do the thing.

The setups that get closer to the truth add one step after the content:

a short task based on real work ("draft the reply you'd send this customer")
a scenario question instead of a recall question
a supervisor or peer sign-off for skills that can't be checked by a quiz

It's more work to review, which is exactly why it gets skipped. But it's the step that turns "finished" into "can do".

Myth 2: "The quiz score is the outcome"

Reality: a passing score is a snapshot taken minutes after the lesson, when memory is at its best.

A more honest signal is the same question asked again a few weeks later. The pattern is simple:

a short check at the end of the module
a follow-up check two to four weeks later
a comparison between the two

If scores drop sharply, the course taught people to pass a quiz, not to remember. That's useful to know, and it costs almost nothing to set up.

Myth 3: "Video views prove attendance"

Reality: a play count isn't a record of who watched what.

This matters most where there's a credit or compliance requirement attached, as in the continuing education case. The needs there tend to be specific:

one login per person, so views can't be shared
access that expires after a set number of days
a report showing which person finished which lesson

A video host on its own usually can't give you that. It's a learning-records problem, not a video problem, and it's worth knowing that before you pick tools.

Myth 4: "Subscriptions will fix completion"

Reality: the payment model doesn't change behaviour. What happens inside it does.

The creator who switched to monthly pricing said as much: an old course behind a monthly fee doesn't justify the price. What tends to move completion is rhythm and visibility:

a weekly live call or check-in
a visible progress tracker (people don't like breaking a streak)
a small cohort that notices when you go quiet

If you're changing pricing to improve outcomes, change the experience at the same time, or you're just billing differently.

Myth 5: "The training team can measure this alone"

Reality: the most convincing numbers live outside the course.

For internal or customer training, the evidence usually sits somewhere else:

Support: fewer tickets on topics the training covered
Product: adoption of the feature the course taught
Managers: a quick before-and-after rating on one or two behaviours
Time: how long until a new hire handles a task without help

None of these is perfect, and other things affect them. But one or two outside signals, checked a few weeks after training, say more than any dashboard inside the course.

A simple measurement stack

If you want a starting point that doesn't need a data team, this is the version we'd suggest:

Completion, kept as a hygiene metric, not a goal
One applied task per module, reviewed by a person
A delayed check, two to four weeks later
One outside signal that the people paying for the training already care about
A per-learner record if any credit, certificate or compliance requirement depends on it

That's five numbers, and only the first one comes for free. The others take a bit of design, but they're the ones that answer the question people actually ask: did it work?

Where tools fit

Most learning platforms can handle the basics here: per-learner progress, expiring access, quizzes you can repeat, and exportable completion reports. Hosted course platforms, corporate LMS products and WordPress LMS plugins all cover some of this. The difference is usually in reporting and in whether you can attach a real task to a lesson. One option among many is Learnomy, a WordPress LMS (disclosure: we're the team behind it). Whatever you use, check the reporting before you check the course builder. That's where these setups tend to fall short.

The honest trade-off

Measuring real outcomes is slower and messier than counting completions. Applied tasks need reviewers. Delayed checks need reminders. Outside signals need someone in another team to share data. That's why the easy number wins by default.

But the people we've heard from aren't asking for perfect measurement. They're asking for one number they'd be comfortable defending to someone who paid for the training. Completion alone rarely passes that test.

Your turn

What's one metric you track beyond completion, and has it ever changed how you built a course?
Have you tried a delayed check a few weeks after training? What happened to the scores?
If your training carries a credit or certificate, what proof does the body issuing it actually ask for?
For customer or internal training, which outside signal has been most convincing to the people funding it?

We'll read every reply, and we'd love to hear from anyone who's had to defend training results to a skeptical manager.

Should community chat be findable on Google? Two honest sides

Wbcom Designs 💡 — Wed, 28 Oct 2026 15:48:47 +0000

For years the complaint has been the same. A small project moves its support from a forum to a chat server, and within a year the answers to common questions are gone from search. You can't find the fix unless you join the server, scroll back, and hope someone asked it the same way you would.

Then Discord said it would give every Discoverable server a public web page, with summaries of public channels and, later, individual messages that can show up in web search. Admins can opt channels out under Web Presence settings. Members get one account-wide switch to keep their own messages off the web, and it's on by default in most regions. Private servers, DMs and group chats aren't included.

Across the communities we follow, the reaction split fast. More than 20 people we tracked weighed in over a single day, from mod authors and support volunteers to privacy writers and people who simply miss forums. Some called it overdue. Others started looking for somewhere else to take their groups.

We build community software, so we have a stake in where conversations live. But this one doesn't have a clean answer, so here are both sides as fairly as we can put them.

Side 1: "Finally. Answers belong on the open web."

The people in this camp have mostly been on the losing end of chat-only support.

Support shouldn't need a membership. Mod authors and plugin makers said the same thing: people want the answer or the download, not another server to join. Joining a server to ask a question someone already answered is a poor experience for everyone.
Knowledge got trapped. Several developers argued that moving from forums to chat hurt small projects and game wikis the most. Years of troubleshooting turned invisible. Making some of it findable again is, in their words, how the internet is supposed to work.
Public was always public. An IT voice made a blunt point: a public channel on a server anyone can join was never private. Tell clients to treat it like a public forum, because that's effectively what it is.

For this camp the question isn't whether to index. It's why it took this long.

Side 2: "People spoke in a room, not on a stage."

The other camp doesn't dispute that searchable answers are useful. Its problem is how it's being done.

Context changes the meaning. People write differently in a fast chat than in a forum post they expect strangers to read. A half-joking reply at midnight reads very differently as a search result years later.
Opt-out isn't consent. Server owners pushed back hardest on the defaults. They asked for one server-wide switch and for indexing to be opt-in, not something admins have to find and turn off. Others asked who else gets to read those pages, including AI scrapers.
It's the old ownership problem again. At least one community owner shut down a server and moved members to another chat app. That fixes the indexing worry but not the underlying one: the rules can still change without you.

For this camp, the issue is that a conversation was held under one set of expectations and is being published under another.

Where the two sides actually agree

What surprised us is how much common ground there is under the noise.

Almost nobody argued that all chat should be public. The fight is over defaults and consent, not over search itself.
Both camps want reusable answers. They disagree on whether you get them by publishing chat after the fact or by writing in a public format from the start.
Because this only applies to Discoverable servers, plenty of small project servers stay out of it anyway, so the trapped-answers problem won't fully go away.

That last point matters. Even with indexing switched on, a chat log is a poor knowledge base. Answers are spread across messages, the question is phrased five ways, and the accepted fix is often buried under follow-ups. A forum thread, a Q&A page or a plain FAQ was built to be read later. A chat log wasn't.

The trade-offs if you run a community

If you're an admin deciding what to do, these seem to be the real options people were weighing:

Leave it on and say so. Tell members which channels are public, pin a note, and treat those channels like a forum. Useful for support-heavy servers.
Opt everything out. Keep chat as chat and accept that answers won't be found by outsiders. Common for social or sensitive groups.
Split the jobs. Keep chat for real-time talk, and move the answers worth keeping into something designed to be public, like a forum, a docs page or a Q&A board you control.
Move entirely. Some owners are doing this, though moving a community is hard and members don't all follow.

None of these is free. Leaving it on means some members will speak less. Opting out keeps the knowledge trapped. Splitting the jobs means someone has to curate. Moving means starting part of the community over.

Our take, briefly

We lean towards option 3. Real-time chat and searchable knowledge are different jobs, and the trouble starts when one tool is asked to do both after the fact. If an answer is worth finding, it's worth writing once in a place that was meant to be public. But we understand the people who just want the old answers back, and we'd like to hear from admins who've run it the other way.

Your turn

If you run a server or group, which option are you taking, and what decided it for you?
As a member, would you post differently in a channel you knew could show up in search? Would you post at all?
Is opt-out ever fair for conversations that already happened, or should anything published later always need opt-in?
What's the best way you've found to turn good chat answers into something people can find without joining?

We'll read every reply, and we're especially curious to hear from support volunteers who've been answering the same question for years.

AI posts in a quiet community: harmless filler or a broken promise?

Wbcom Designs 💡 — Tue, 27 Oct 2026 15:46:44 +0000

Every community goes quiet at some point. The regulars get busy, a bigger platform pulls people away, and the front page shows the same threads for weeks. For anyone who has run a forum or a member site, that silence is uncomfortable.

A newer answer to that silence keeps coming up in the communities we follow, and it has split people sharply.

One long-running forum admitted to using AI to generate posts to counter falling engagement, and some of those posts appeared under the names of real, long-time members. The reaction was close to unanimous on one point: faking activity is bad, but putting words in real people's mouths is far worse. Yet even in that thread, a few people pushed back on the framing. One argued that "fake activity" is still activity, and that if members don't like it they'll simply leave. Another pointed out that plenty of old forums now exist mainly to collect ad revenue, and that the incentive to keep pages fresh doesn't care who wrote them.

Meanwhile, open source communities have been tightening their rules against AI-generated submissions and low-effort project posts, and some are raising the bar for new projects to be shared at all. Elsewhere, people building community digests are experimenting with showing exactly what an AI summarised and what it left out, so members can see where the machine stepped in.

We build community software, so we have a stake in this. But we don't think there's one obvious answer for every community, so let's lay out the camps and the questions.

Camp 1: "Any AI activity breaks the deal"

The argument here is about the promise a community makes. When you join a forum, you assume the people posting are people. The value of a reply is that someone with real experience took the time to write it.

If members can't tell which posts are real, every post loses value, including the genuine ones.
Faking activity treats members as an audience to be retained, not as participants.
Once trust is gone, a quiet community becomes a dead one very quickly.

People in this camp often say the honest options are better: post less often, say the community is quieter, or close it gracefully.

Camp 2: "Labelled AI help is fine"

This camp separates deception from assistance. An AI that writes posts under members' names is clearly over the line. But an AI that drafts a weekly summary, suggests related threads, or answers a basic question under a clearly marked bot account may actually help a small team keep a community alive.

A clearly labelled helper is no different from an FAQ or a search box.
Small volunteer teams are already stretched thin; burnout kills more communities than AI does.
Summaries can bring old, valuable answers back to the surface.

The line for this camp is disclosure: say what the machine did, every time.

Camp 3: "Members will decide"

A smaller group argues that communities are self-correcting. If generated content is dull, people stop reading. If it's useful, they stay. Rules about origin matter less than whether the place is still worth visiting.

Critics reply that this ignores how members find out. Usually it isn't a slow drift away. It's one discovery, and then a very loud exit.

The questions underneath

Whichever camp you lean towards, a few questions keep coming up.

Where exactly is the line?

Is an AI-written welcome post for new members acceptable? What about an AI-written answer posted by a staff account? A seeded "starter" thread to make a new category look less empty?
Does it matter whether the admin edits the AI draft before posting?

What do you owe members?

Should communities publish a clear policy on AI-generated posts, the same way they publish a code of conduct?
If you used AI in the past without saying so, do you owe members a disclosure now?

How should new projects get a fair hearing?

When open communities tighten rules to keep out low-effort AI content, do genuine newcomers get shut out too?
Is "already has a community" a fair bar, or does it just reward whoever got there first?

What's the honest way to handle a quiet season?

Is a quiet forum a problem to be fixed, or just a phase?
What has actually worked for you: a regular event, a weekly thread, reaching out personally to old members, or simply waiting?

Our take, briefly

We lean towards Camp 2. A community is a promise that the people are real, so anything posted as a person should come from that person. Assistance that is clearly labelled seems fair game; impersonation never is. But we're genuinely unsure where "seeding" ends and "faking" begins, especially for a brand-new community with three members, and we'd rather hear from people who've faced it.

Your turn

Which camp are you in, and has a real experience moved you from one to another?
Have you ever discovered that a community you belonged to was faking activity? What did you do?
If you run a community, do you use AI anywhere in it, and do your members know?
What's the most honest thing you've done to get a quiet community talking again?

We'll read every reply, and we'd especially like to hear from admins who've been tempted and decided against it.

Before you launch a services marketplace, decide how the money moves

Wbcom Designs 💡 — Tue, 27 Oct 2026 15:46:33 +0000

Most people who set out to build a services marketplace start with the fun parts: the listing page, the profiles, the search. Then the first real order comes in and the hard questions show up all at once. When does the seller get paid? What happens if the buyer says the work wasn't delivered? Who pays back the refund if the seller has already been paid?

These questions keep coming up in the communities we follow, from people on every side of the table. Specialist consultants are tired of open marketplaces where the going rate has been pushed down to a fraction of what their work is worth. Sellers on creator platforms are frustrated by high fees, week-long payout holds and support that never reaches a human. Tutors push back on paying a flat monthly listing fee before they've earned anything. A marketplace owner discovers that sellers were paid out instantly, so when a refund lands it comes out of the owner's own account. Event organisers want to control refunds themselves instead of waiting on a ticketing platform. And someone simply asks: how does a big freelance site hold the money until the work is delivered, and how do I do that on my own site?

Different situations, one theme: the money flow is the product. Here's how we'd walk through it before writing a single listing page.

1. Map the life of one order

Before choosing any tool, write down every state an order can be in. For most services marketplaces it looks something like this:

The buyer pays.
The seller receives requirements and accepts the order.
The seller delivers.
The buyer accepts, asks for a revision, or raises a problem.
The order completes, and money is released to the seller.
Or the order is cancelled or disputed, and money goes back to the buyer, in full or in part.

Every rule you need hangs off this list. If you can't say who holds the money at each step, you'll find out the hard way.

2. Decide when the seller gets paid

There are roughly three options, and each one moves risk to a different person.

Pay the seller immediately. Sellers love it. But if the buyer later asks for a refund, the money is already gone, and the marketplace owner usually ends up covering it. This is the trap a lot of people only notice after the first chargeback.
Hold until the buyer accepts the delivery. This is the classic approach. The buyer feels protected, and the seller knows the money exists. The catch is that some buyers never click "accept", so you need an automatic release after a set number of days.
Hold for a fixed window after completion. You release funds a few days after the order completes, which leaves room for late complaints. It protects the platform, but sellers feel it, especially new sellers living order to order.

There's no right answer, only an honest one. Whatever you choose, say it plainly on the seller signup page. Most of the anger we see about payout holds isn't about the hold itself. It's about finding out after the money is already stuck.

3. Decide who eats the refund

This is the question nobody wants to answer before launch. Write it down anyway:

If the seller never delivered, the refund comes from the seller's held funds. That only works if you're still holding them.
If the seller delivered something and the buyer is unhappy, is it a partial refund, a revision, or a dispute?
If the buyer files a chargeback with their bank, the processor takes the money from your account first. Do you recover it from the seller, and how?
Does your commission come back to the buyer on a refund, or do you keep it?

A short, written refund policy that sellers agree to on signup prevents more arguments than any clever feature.

4. Plan disputes as a workflow, not an inbox

Early on, disputes feel rare enough to handle by email. They aren't, for long. What helps:

Keep every message, file and delivery inside the order thread, so there's a record when something goes wrong.
Limit revisions per package, so "one more change" doesn't become unpaid work.
Set a clear window for raising a problem after delivery.
Decide who makes the final call, and what evidence they'll look at.

Sellers in these conversations often say they'd accept a strict policy if it were applied consistently. What drives them away is a decision that feels random.

5. Pick a fee model your sellers can live with

Pricing is where the most heated disagreements happen.

Percentage per order. Fair when sellers earn little, painful when they earn a lot. High percentages are one of the most common reasons we hear for experienced sellers leaving a platform.
Flat subscription. Predictable for you, but a monthly fee before a seller has a single client feels like paying to hope. Tutors and coaches push back hard on this.
Fee after a minimum. Free until a seller earns a set amount, then a percentage or plan kicks in. Gentle for new sellers, more complex to explain.
Buyer-side service fee. Moves the cost to the buyer. It works in some niches and puts buyers off in others.

Many small marketplaces mix two of these. The test is simple: could you explain your fee to a seller in one sentence without them wincing?

6. Know which risks you're renting

If you build on a hosted marketplace platform or a creator platform, you get payments, holds and disputes handled for you. You also accept their fees, their reserve rules and their support queue. Some people are happy with that trade. Others have learned that a platform can freeze payouts or close an account with little warning.

If you run the marketplace on your own site, you own the rules, but you also own the job of enforcing them. Your payment processor can still hold your funds if refunds and disputes pile up, so the clearer your order and refund flow, the safer you are.

Options people mention include hosted builders like Sharetribe, multivendor plugins such as Dokan (built mainly for physical products), custom builds, and service-focused WordPress plugins. One of those is our own WP Sell Services, which handles packages, order threads, revisions and disputes. (Disclosure: we're the Wbcom team and we build it.) Whatever you pick, walk through the six steps above with it before you invite your first seller.

Your turn

If you run a marketplace, when do your sellers get paid, and what made you choose that?
Who ended up paying for your first refund or chargeback, and did it change your rules?
Sellers: which fee model have you found fair, and which one made you leave a platform?
What's one dispute you've handled that taught you something no policy template covered?

We'd love to hear the real stories, especially the ones where the money moved in a way nobody expected.

Forum or group chat: where should a small community actually live?

Wbcom Designs 💡 — Mon, 26 Oct 2026 15:52:32 +0000

There's a conversation that keeps resurfacing in the communities we follow, and it isn't the usual "which platform should I pick" thread.

It's about format. People keep saying they miss forums. Someone says not everything needs to be a chat server. Another person argues that old-school forums were simply better than social media, and a lot of people agree. A post refusing to accept the line "why start a forum, nobody's going to use it" gets far more support than its author expected.

At the same time, the practical side keeps showing up. A small paid community launches with weekly calls and a private chat workspace, because that's where members already are. Someone grows a chat server into a real platform with thousands of active members. A volunteer admin of a self-hosted community steps away, burned out, after a couple of instances in their network go down in quick succession, and the thread underneath turns into a long, honest discussion about whether running a community is sustainable at all. An open source project moves its old forum to read-only. Someone else complains that chat threads are where good answers go to disappear.

We build community software, so we have opinions. But this one genuinely feels unsettled, so instead of arguing a side, we're going to lay out the questions we keep circling.

The convenience question

Chat wins on day one. People already have the app open, a message gets a reply in minutes, and starting a server takes less time than writing this paragraph.

Is "where people already are" the most important factor, or just the easiest? If members won't visit a separate site, does a forum ever stand a chance, no matter how good it is?
Does the speed of chat help or hurt? Fast replies feel alive. They also mean that anyone who wasn't online at the time missed the conversation.
Are small groups different? For twenty people who know each other, does it matter at all where they talk?

The memory question

This is where forum fans have their strongest argument. A forum thread from years ago can still answer a new member's question. It's indexed, linkable and organised by topic. A chat history mostly isn't.

How much does a community's value live in its archive? For support communities and hobby groups, old answers might be the whole point. For a social group, maybe nobody cares about old messages.
Who notices when the knowledge is lost? When a busy chat channel scrolls past a great answer, nobody feels the loss until someone asks the same thing again.
What happens when a forum goes read-only? Is a frozen archive still a community asset, or just a museum?
Can chat platforms fix this? Threads, pinned posts and searchable channels exist. Do they actually change how people use chat, or does everything still end up in the main stream?

The calm question

Several people describe small forums as calmer than feeds. No algorithm, no outrage farming, just people who return because they want to.

Is that calm a feature of the format, or of the size? Would a forum with a million members be any calmer than a busy chat server?
Does slow conversation select for better conversation? Writing a forum post takes more effort than firing off a message. Is that friction good, or does it just keep people out?
Is the forum comeback real, or nostalgia? Many of the loudest voices remember forums from years ago. Do people who grew up on chat apps want them at all?

The stewardship question

This is the one we think gets skipped most. Every community, on any format, needs someone to keep it running. Self-hosted forums need updates, backups and spam control. Chat servers need moderation and someone who owns the account. The thread about admin burnout made it clear that servers are rarely what wears people out. It's being the only person on call.

Who owns the community when the founder steps back? In many small communities, the honest answer is "nobody has thought about it".
Does format change the burden? A forum has more moving parts to maintain. Chat outsources the infrastructure, but not the moderation, and not the risk that an account or group can be suspended overnight with no one to appeal to.
What does a healthy handover look like? We've seen communities survive because two or three admins shared the load and agreed in advance who takes over. We've seen others vanish because one person got tired.
Should every community plan for its own ending? Exporting the archive, telling members where to go next, keeping old links working. Almost nobody does this until it's too late.

The "both" question

A lot of communities end up running both: chat for quick talk, a forum or knowledge base for anything worth keeping.

Does splitting work, or does one side always die? In our experience the quiet side often becomes a ghost town unless someone deliberately moves good answers across.
Who does that moving? It's real work. Is it a moderator job, a volunteer job, or something tools should handle?
Does running both double the stewardship problem?

Where we are, honestly

Our own lean: chat is great for momentum, and something slower and searchable is worth having once a community starts repeating itself. But we've watched both formats thrive and both formats fail, and the difference usually seemed to be people and stewardship, not software.

So we'd rather learn from the people actually running these spaces.

Your turn

If you run or moderate a community, is it on a forum, chat, or both, and would you choose the same again?
Have you lost valuable community knowledge to a chat scrollback, a read-only forum or a closed group? What would have saved it?
Admins: what keeps you from burning out, and who would take over if you stepped away?
Is the forum comeback real where you are, or is it mostly people remembering how things used to be?

Tell us where your community lives and why. We're especially curious about the ones that switched formats and lived to talk about it.

Handing over a website without leaving a mess: a checklist we wish every project started with

Wbcom Designs 💡 — Mon, 26 Oct 2026 15:52:21 +0000

Most website problems we get asked about aren't really technical. They're handover problems wearing a technical costume.

Across the communities we follow, the same story keeps coming back in different clothes. A volunteer takes over the site for a small professional club from someone who ran it for many years, and asks how to set things up so the club owns it, not whoever happens to hold the passwords. An agency owner asks who is supposed to own updates once a project is "done". A client finds out the domain is registered to a freelancer who stopped answering email. A developer who has built client sites for years shares the contract clauses they added one painful lesson at a time. Someone else explains how they monitor a pile of sites without drowning in alerts.

None of these people were asking for a plugin or a framework. They were asking the same question: how do you hand a site to someone else so they aren't stuck?

We've done a lot of handovers, in both directions. Here's the checklist we wish every project started with, and the mistakes we see most often.

The idea: plan the handover on day one

The best time to prepare for a handover is before anyone needs one. If the site is set up as if a stranger will take it over next year, the actual handover becomes a short meeting instead of a rescue mission.

That mindset works whether you're an agency, a solo freelancer, or the one volunteer at a nonprofit or club who "knows computers".

The checklist

1. The organisation owns the accounts, people get access

The domain registrar, hosting, DNS, email sending and any paid plugins or services should sit under an account the organisation controls: a shared role address like web@ or admin@ your domain, paid with the organisation's card.

Individuals, including you, get their own logins with the right permissions. Not a shared password that lives in one person's head or browser.

Test: can someone at the organisation name, in under a minute, whose card pays for hosting and whose email owns the domain? If the answer includes "I think", that's your risk list.

2. At least two humans can get in everywhere

One admin is a single point of failure. Give a second person, usually a board member, owner or office manager, their own admin login on the site, at the registrar and at the host. Check where password resets go and who holds the second factor. A recovery email pointing at an inbox nobody reads is the quietest way to lose a site.

3. Write the one-page "where everything lives" doc

This is the part nobody does, and it's the most useful page you'll ever write for a client. Keep it short:

Where the domain is registered and when it renews
Where the site is hosted and what plan it's on
Where backups go, how often, and how to restore one
Which paid licences exist and when they renew
Who to call for what (you, the host, a plugin vendor)

One page, stored somewhere the organisation can find without you. The next handover then takes minutes.

4. Decide who owns updates, in writing

"Who updates the site after launch?" is one of the most common arguments we see between agencies and clients, mostly because nobody answered it at the start. Pick one:

The client owns updates and accepts the risk
You own them under a care plan with a clear scope
Nobody does, and everyone agrees that's a decision, not an accident

Any of these can work. Leaving it unspoken is what causes the angry email two years later.

5. Updates are more than the "Update all" button

A point we keep seeing from people who maintain sites: clicking update on every plugin and theme does not touch the version of PHP the server runs. Plenty of sites look perfectly maintained in the dashboard while the runtime underneath is years behind. On managed hosting this is often handled for you. On cheaper shared hosting, it's usually left to the site owner.

Add "check the server's PHP version" to the handover doc and to every maintenance routine.

6. Backups that someone has actually restored

A backup nobody has tested is a hope, not a backup. During handover, restore one to a staging copy together. It takes an hour and it tells the new owner more about the setup than any document.

And one lesson people keep relearning: if a site gets hacked, restoring an older backup can bring the backdoor right back. Finding out how the attacker got in comes before the restore, not after.

7. Set support hours and boundaries

Freelancers regularly ask what to charge when a client messages at seven in the morning on a weekend. The cleanest answer we've seen: put normal support hours in the agreement and price anything outside them clearly. Then the client decides whether it really can't wait, and nobody has to feel guilty.

The same applies to volunteers. "I'll help when I can" is fine, as long as everyone knows that's the deal.

8. Keep the plugin list lean and documented

For each plugin or extension, note in one line why it's there. When the next person inherits the site, "contact form", "event calendar" and "nobody knows, don't touch" are very different entries. Remove the third kind before you hand over.

9. Do a real walkthrough

Sit down with the person taking over (or a call with screen sharing) and have them drive: log in, publish a post, change a menu item, find the backup, renew something. Whatever they can't do on their own is what's missing from the doc.

Mistakes we see over and over

Domain in the developer's name. Usually done with good intentions to "make it easy". It becomes a hostage situation the day the relationship ends.
One shared admin password. Nobody knows who changed what, and removing access means changing it for everyone.
"The site is done." Websites aren't done. They're either maintained or slowly decaying.
Handover as an afterthought. Scrambling to find logins in the final days of a contract is how things get missed.
No exit plan for the volunteer. In clubs and small nonprofits, the person who built the site often stays the only one who can change it. That works right up until they move on.

Where to start if you've just inherited a site

If you're the new volunteer or the new agency and the previous person is already gone, work in this order: secure the domain first, then hosting, then the site's admin access, then backups, then everything else. Make a list of every account that costs money, whose card pays for it, and who can actually log in. Anything marked "the old developer" or "not sure" goes to the top.

Your turn

What's the one item you now insist on in every handover, and what taught you to add it?
For small clients, who owns updates after launch in your projects: you, them, or nobody?
Volunteer webmasters: how did your organisation make sure the site didn't depend on just you?
Have you inherited a site with no handover at all? What did you do first?

We'd love to build this list out with your experience, especially the items that only show up after something goes wrong.