DEV Community: Wbcom Designs 💡

Static, AI-generated or WordPress: who edits the site in year two?

Wbcom Designs 💡 — Sun, 25 Oct 2026 15:47:59 +0000

The "is WordPress finished?" argument never really goes away, but the shape of it keeps changing.

Across the communities we follow, we keep seeing the same split. On one side: someone replaces a years-old client site with a static build generated from a single AI prompt and declares the CMS era over. An agency moves dozens of small client sites to a static framework over a long weekend. Developers point out that a brochure site has no reason to run PHP and a database, and a big security scare makes that point louder.

On the other side: a volunteer at a small nonprofit explains that every text change on their site takes a week, because only one person can make it. A designer moves to WordPress from a hosted builder because they want ten to fifteen client sites on one stack they control. Someone asks whether a site with member logins and a shop can go static at all, and the honest answer is "not really".

Both sides are describing real sites. They're just describing different sites. Here's how we see the two cases, and then the parts we genuinely don't know.

The case for static (and AI-built) sites

Fewer moving parts. No database, no plugin updates, no login page to attack. For a site that is a few pages and a contact form, that's a real win, and the maintenance bill drops close to zero.

Speed and hosting cost. Static files are fast almost anywhere and cheap to host. For agencies with many small, rarely changing sites, that adds up.

Security posture. Every time a widely used plugin or core component has a serious hole, people who run lots of sites spend a stressful day patching. Static sites mostly skip that day.

AI changed the build cost. Generating a clean marketing site from a prompt or a design file is now quick. If the build is nearly free, the argument for a heavy CMS "in case they need it" gets weaker.

Honest about who edits. Many small business owners never log in after launch. If the agency makes every change anyway, a CMS is overhead nobody uses.

The case for keeping a CMS

Someone else has to edit it. This is the one we hear most. The site isn't for the developer, it's for the owner, the volunteer or the marketing hire who joins next year. If they want to add a post, swap a photo or publish an event without opening a ticket, the editing screen is the product.

Logged-in people change everything. The moment a human logs in to do something, buy, enrol, post, apply, RSVP, comment, a static site needs a backend anyway. At that point you're either bolting services onto static pages or running an application, and a CMS with users and roles starts looking simpler, not heavier.

Migration is the hidden cost. People who moved sites to static generators talk about the hurdles: forms, search, redirects, old URLs, image handling, and content that lived in shortcodes or page builders. The site was easy to rebuild. The content wasn't.

Ownership and handover. When a project ends, who owns updates? With a CMS that question is loud and usually lands in a care plan. With a static site it's quieter, but it still exists: someone has to own the repo, the build, the hosting and the domain.

Rewrites are rarely worth it. Builders who have done full rewrites tend to say the same thing: the only ones they didn't regret were the ones where the underlying data model was wrong. Moving a working site to a new stack because the old one feels unfashionable is a different decision.

Where we land, for now

Our rough rule: static for sites nobody edits, a CMS once someone non-technical edits, and an application once logged-in people do things. Most arguments we see are people applying the right answer for their kind of site to someone else's kind of site.

But that rule leaves a lot of grey area, and we'd rather hear how you handle it than pretend we've figured it out.

The questions we can't settle

Does AI editing replace the editing screen? If a client can say "update the opening hours" to an assistant and it edits a static repo, do they still need a CMS? Or does that just move the "one person who can make changes" problem from a developer to a tool?

What does year two look like? Most launch decisions are made for launch day. We'd love to hear from people who went static two or three years ago. Did the client stay happy, or did small change requests pile up?

Is security a stack problem or a habits problem? One view says the CMS is the risk. Another says lean plugin lists, auto-updates and off-site backups make most of that risk go away, and that static sites have their own weak spots in build pipelines and third-party form services. Which matches your experience?

Where's the line for member features? A site with gated PDFs, a members' area or a small shop is in between. Some people bolt on hosted services, some keep a CMS for just that part, some run two sites. What's worked for you?

Who decides? Often the developer picks the stack because they'll maintain it. Should the person who edits the site in year two get the deciding vote instead?

Your turn

Have you moved a site off a CMS, or onto one? What made you do it, and would you do it again?
For small client sites, who actually edits the content after launch: you, the client, or nobody?
Where do you draw the line between "static is fine" and "this needs a backend"?
If AI can make edits for non-technical owners, does that change your answer?

We build mostly on WordPress, so we know which way we lean. That's exactly why we want the other side in the comments.

You have the expertise and the audience. Here's what you can actually build to teach it

Wbcom Designs 💡 — Sun, 25 Oct 2026 15:47:47 +0000

A question keeps coming up across the communities we follow, from people who are very good at something and already have people listening: "I want to turn this into a course. Which platform should I use?"

We've seen it from a doctor with a large newsletter and a video crew already booked, from developers whose course platform renewal arrived in a year with almost no sales, from people moving off one all-in-one tool because the newsletter side outgrew the course side, and from church and nonprofit teams who just want volunteers to finish a training before they start.

The platform question is real, but it usually comes too early. The better first question is: what are you actually building? "A course" can mean six very different things, and each one wants a different setup.

Here are the setups we see people succeed with, what each one needs, and where each tends to break.

1. The video library people buy once

What it is: a set of recorded lessons, sold once, watched at the buyer's own pace.

Good for: experts with a clear topic and a back catalogue of knowledge. Think a clinician explaining recovery, a designer teaching a tool, a coach with a repeatable method.

What it needs: reliable video hosting, a checkout, a login, and a page that shows progress. That's it. You don't need a community, gamification or a mobile app on day one.

Where it breaks: when the store that hosts your videos changes its terms or shuts down. People who bought a video-on-demand course have found themselves asking "where do I watch what I paid for?" The fix is boring: keep your original video files, keep your own copy of the buyer list, and host the video somewhere separate from the place that sells access. Then either part can be swapped without the other.

2. The newsletter that grows a course

What it is: a newsletter audience that gets offered one paid course or workshop a few times a year.

Good for: writers and experts whose readers already trust them.

What it needs: a way to turn a subscriber into a student without making them create three new accounts. Ideally the same email address unlocks the lessons.

Where it breaks: when the newsletter tool bolts on courses as an afterthought. Several creators have told us the course features felt thin next to the writing tools, and they ended up moving courses somewhere else while keeping the newsletter where it was. That's a perfectly good outcome. You don't need one tool to do everything.

3. The cohort with limited seats

What it is: a group that starts together, meets live, and finishes together.

Good for: anyone whose teaching depends on feedback, discussion or accountability.

What it needs: enrolment that can close, a schedule, live sessions, and a place for the group to talk between sessions. Some teams even want an application step before someone gets a seat.

Where it breaks: when the course tool and the discussion space live in different places and nobody checks both. If you run cohorts, keep the conversation next to the lessons, or at least link them both ways.

4. The private teaching room

What it is: lessons for a small, known group. Clients, members, a church small group, a team.

Good for: people who don't want to sell publicly at all.

What it needs: invite-only access, simple roles, and a way to remove people. Payment may not even be involved.

Where it breaks: leaks. Course creators regularly discover their "private" lessons are reachable from a shared link, or that a preview shows more than intended. Before launch, log out and try to reach a lesson URL. Then try to open a downloadable file directly. If either works, fix that first.

5. The training people have to finish

What it is: onboarding or compliance training where completion matters more than revenue.

Good for: nonprofits with volunteers, agencies onboarding staff, member organisations.

What it needs: clear completion tracking, reminders, and some kind of check at the end.

Where it breaks: the check. A passing quiz score is not proof someone can do the thing. The setups that work add one practical step: a short reflection, a recorded demo, or a supervisor sign-off. It's more work to review, but it's the part that tells you the training worked.

6. The course that lives inside a community

What it is: a membership where lessons are one part, alongside discussion, events and member profiles.

Good for: creators whose audience comes back for each other as much as for the content.

What it needs: a community space, a classroom, and one login that ties them together. Plus a member list you can export.

Where it breaks: when the whole thing is rented. If the community and the lessons sit on one hosted platform, a price change or a rule change hits everything at once.

A quick way to choose

Once you know which of the six you're building, the tool choice gets much smaller. A few questions that help:

Who needs to own the student list? If the answer is "me, always", favour setups where you can export students, progress and purchases, not just video files. Videos are the easy part to move. Students, progress, renewals and certificates are not.
How much will you build yourself? An expert with no spare time is usually better served by a simple hosted setup or a developer friend than by a weekend of plugin research.
What happens when you stop paying? Ask this of every tool. Some keep your content readable, some lock everything, and some quietly let buyers keep access. You want to know which before launch, not after.
Where does the conversation happen? If students will talk to each other, plan that space now.

The tools people mention most often split into three groups: hosted course platforms (fast to start, least control), newsletter or community tools with courses added (great if that's where your audience already is), and courses on your own site using an LMS (most control, a bit more setup). All three are valid. The mistakes we see come from picking one before deciding which of the six setups you're building.

Disclosure: we're the Wbcom Designs team, and we make Learnomy, an LMS for your own WordPress site. It's one option in that third group alongside several other good ones.

A simple walkthrough for your first version

If you're starting from zero, this order keeps you from overbuilding:

Write the outcome in one sentence. "After this, you can ___."
Pick one of the six setups above.
Record or write three lessons before choosing any tool.
Choose the smallest setup that covers checkout, login, progress and your export needs.
Invite five people from your audience to go through it for free or at a discount.
Watch where they stop. Fix that before adding anything else.

Most courses don't fail because of the platform. They fail because the first version tried to be a library, a cohort and a community at once.

Your turn

If you've taught online, which of the six setups were you really building, and did your tools match it?
What's the one thing you wish you could have taken with you when you left a course platform?
How do you check that people actually learned something, beyond a quiz score?
For experts with no time to build: hosted platform, own site, or hire someone? What would you tell them?

We'll read every reply. If you've moved a course from one home to another, we'd especially love to hear what broke.

Building the directory or job board was the easy part. Here's what 20 builders say comes next

Wbcom Designs 💡 — Sun, 25 Oct 2026 06:12:32 +0000

If you hang around indie-builder corners of the internet right now, you'll notice a wave of niche directories and job boards: local services, AI tools, peer reviewers, football jobs, nonprofit resources, even a club's book catalogue.

We read posts from about twenty different people building these, across the different communities and forums we follow, including a couple of candid founder write-ups. One builder summed up the mood better than we could: the code was the easy part, and getting people to find the thing and trust it is the real work.

So instead of another "how to build a directory in a weekend" tutorial, here's a guide to the five decisions that came up again and again. For each one we've included where these builders disagreed, because they often did.

Decision 1: Seed it yourself, or wait for submissions?

This was the most-asked question. A local-directory builder asked it straight out: did people wait for businesses to submit, or build a starter database themselves? Job-board founders asked the same thing about their first listings.

The case for seeding: an empty directory looks dead, and nobody submits to a dead site. Most people who replied seeded by hand or imported a list, then invited owners to claim their listings.

The case against (or for caution): seeded listings are thin by default. One builder's directory launched, peaked within about a month and then dropped after a Google spam update. Thin, look-alike pages are exactly what those updates target.

Our take: seed, but seed fewer, better listings. Fifty hand-checked entries with real details beat five thousand scraped rows. Treat "claim this listing" as a growth loop, not an afterthought.

Decision 2: Can Google actually see your listings?

This one surprised people. One builder ran their directory on a no-code database and found that Google was seeing the same blank page for every listing, because the content loaded client-side. Others asked how to grow a brand-new site's domain authority and earn first backlinks.

What builders agreed on:

Each listing needs its own indexable URL with server-rendered content.
Category and location pages matter as much as listing pages.
Badges or "featured on" link-backs for listed makers and businesses earned more useful links than mass directory submissions.

Where they split: some swear by launch roundups and submission sites for early links. Others, including one painfully honest founder write-up about a software directory that got one real visit in its first month, suggest that most of those links send no humans at all.

Decision 3: How do you earn trust?

A directory is a promise that the information is right. Several voices made this concrete:

A builder of a verified directory for the Gulf region made verification badges and claimed status the whole pitch.
In community discussions, the top objection to a new directory launch was upkeep: what happens when a business moves or closes? Suggestions included a last-confirmed date, a "report moved/closed" button, and nudging owners to update.
A job-board founder made a strong case for auto-expiring stale postings, because nothing kills candidate trust faster than applying to a job that was filled three months ago.
One builder described fighting AI-generated junk to keep a job board trustworthy, which is a newer problem that's showing up fast.

The trade-off: every trust feature (verification, moderation, expiry) adds work for you. Small teams have to choose. If you can only do one, people suggested freshness signals, since they're visible and cheap.

Decision 4: Views aren't leads

One of the most useful posts was from a local senior-services directory owner. Providers' pages got almost 200 views and only 17 clicks out. If you charge providers, that ratio is your business.

Ideas from the replies:

Put tap-to-call and an inquiry form on the listing, not behind a "visit website" link.
Show reviews with owner replies, which reassure people more than star averages do.
Report leads to listed businesses, because that's what makes them pay or renew.

Decision 5: How does it make money?

Here the voices split cleanly into three camps:

Paid or featured listings. One builder described getting a niche directory to meaningful monthly revenue fast through paid listings plus outbound sales. A reply pushed back, asking how to monetise without cold calling. The answer from others was claim buttons, featured spots and lead forms that sell themselves once you have traffic.
Ads. A directory owner with 20k+ monthly pageviews asked which ad network pays best. The replies were gloomy about Q4 rates, and some argued that selling a sponsor slot for each category directly beats network ads at that size.
Job boards: charge employers. A recruiter building a football-industry board already had dozens of roles live and was working out employer self-posting and paid listings. Another founder asked for honest feedback and got the usual list: salary ranges, job alerts, employer profiles.

Nobody claimed one model wins. The pattern we saw is that the monetisation model should decide the features, not the other way round. Lead-based pricing needs lead tracking. Featured listings need traffic first.

Tools: briefly, and honestly

People built on everything: no-code databases, custom code, AI-agent scaffolds, WordPress plugins. The no-code builders hit indexing limits. Custom builders spent their time on admin screens and spam. Plugin users wrestled with bloated stacks. One commenter said that after spending hundreds of dollars on a directory system, they built their own.

If you're on WordPress, there are several directory and job-board plugins worth comparing, including Directorist, GeoDirectory and HivePress, and Listora, which is made by the team I work at. (Disclosure: I work at Wbcom Designs.) Whichever you pick, check the indexing and claim-listing workflow before the feature list.

Your turn

If you've launched a directory or job board: did you seed listings yourself, and how did you keep them from looking thin to Google?
What's your view-to-lead ratio? Did anything on the listing page change it?
How do you handle upkeep? Freshness dates, owner nudges, community reports, or just accept some decay?
What actually paid first: featured listings, ads, lead fees or employer postings, and what would you do differently?

Drop your numbers in the comments, even rough ones. Twenty builders' notes got us this far, and a few hundred would make a much better guide.

Rented land: what 30+ creators told us about leaving Skool, Whop, Discord and YouTube

Wbcom Designs 💡 — Sun, 25 Oct 2026 06:12:31 +0000

Every week our team reads a lot of posts from people who run communities, sell courses or build an audience online. We build community and membership software for a living, so it's partly our job and partly our habit.

Again and again, one theme keeps turning up, from people who don't know each other and don't agree on much: "I don't actually own this."

We counted. More than 30 different people across the networks and communities we follow raised some version of it in a short space of time. None of this is a survey. It's a pattern we kept seeing, and below is our attempt to sum it up fairly, disagreements included.

The four ways people got the wake-up call

1. The account just disappeared.
This was the loudest group. A creator woke up to find YouTube had removed the channel, with very little explanation. Another person had a Discord account hacked and lost a server with more than ten thousand members. Someone else spent over a month waiting on Discord support after losing access to several community servers. A WhatsApp group with hundreds of leads was suspended right before a webinar. Elsewhere, a founder said their new communities were banned almost as soon as they started them.

What struck us was how calm the advice from other people in those threads was. Over and over it came down to one line: keep your content and your member list somewhere you control, so a ban is an inconvenience and not the end.

2. The money got held.
A smaller group, with sharper pain. Several sellers described a payments platform holding most of their revenue in reserve for months, with support that seemed to be automated. Other people asked the obvious follow-up, "so should I use Skool or Whop?", and replies split.

The honest correction, which a few people made too, is that running checkout on your own site doesn't make you immune. Card processors can still hold funds. What changes is that one layer between you and your money is gone, and you deal with the processor directly.

3. The fees started to add up.
Several people did the math out loud. One asked at what point handing a tenth of a big newsletter's revenue to the platform stops making sense. Another pointed out a growth fee that's turned on by default and takes a cut of every renewal. Others just called the fees ridiculous.

But here's the disagreement: plenty of replies argued the fee is the product. The platform handles payments, discovery and the network effect, and for a lot of people that's worth it.

4. The structure didn't fit.
This one's quieter but interesting. A coach said they'd been paying around $99 a month for a platform where they couldn't change how content was organised. A finance creator with a big following weighed Discord against Substack because they weren't ready to take on the problems that come with chat, like moderation and messages scrolling away. And a surprisingly nostalgic thread asked whether anyone else missed old-school forums. Lots of people did, and several replies pointed out that those communities haven't gone away. They've just moved into private servers that nobody can find.

Where the voices disagreed (and why that matters)

If this were only a "leave the platforms" story, it would be easy to write. It isn't.

Convenience is real. One creator building on their own site worried that joining a platform like Patreon is simply easier for fans. They're not wrong. Every extra sign-up step costs you members.
"Just vibe-code it" has a cost. One builder admitted they'd coded their own Skool clone to avoid the platform fee and found it slower than they needed it to be. Billing, failed renewals, moderation and spam are dull problems, and they're the problems that eat weekends.
Self-hosted chat isn't a free win. One person moved a community to self-hosted chat because at least they owned it, then admitted it felt clunky.
Spreading out can just mean more landlords. One creator put it as five platforms meaning five landlords, and then picked one hosted platform anyway, deciding that a single, deliberate dependency beats five accidental ones.

So the useful question isn't "platform or own site?" It's: which parts of your community can you not afford to lose?

A practical way to think about it

Here's the framework we'd suggest after reading all of this. It works whatever tools you use.

Things you should own no matter what:

Your member list and their email addresses, exported regularly
Your paid content (videos, lessons, files), backed up somewhere you control
Your domain, so links survive a platform move

Things it's fine to rent:

Discovery and reach (social feeds, YouTube, marketplaces)
Real-time chat, if your members like it there
Payments infrastructure, as long as you know the reserve and payout terms before you scale

Things worth deciding on purpose:

Where the archive lives. Chat is great for "right now," but bad for "how did we fix this last March?" That's why several people who run help channels said they'd moved support to something searchable.
Who you can reach if you get banned tomorrow. If the answer is "nobody," that's the gap to close first.

A lot of the calmest people in these threads had a simple setup: reach on the big platforms, a home on their own domain, and an email list that connects the two. It's not exciting. It works.

The bit we're still unsure about

We build tools for the "own your home" side of this, so we're biased. We'll say that plainly. We still don't think owning everything is right for everyone. A first-time creator with 50 members probably should use the easiest hosted option and focus on the people. The maths changes at some point: a certain revenue, a certain member count, or the first time an account gets flagged. We don't think anyone has a clean answer for where that point is.

That's why we'd rather ask than tell.

Your turn

Have you ever lost access to a channel, server, group or payout? What did you wish you'd backed up beforehand?
Where's your line? At what member count or revenue did a platform's fee or rules stop feeling worth it, or has it never happened?
Chat vs forum vs feed: if you run a community, where does your archive live, and do your members actually search it?
For those who moved off a platform: what was harder than you expected, and what turned out to be easier?

We read every comment, and we'd especially love to hear from people who tried owning it and went back to a hosted platform. That side of the story is under-told.

Create a Website to sell online Courses at no cost with BuddyX and TutorLMS

Wbcom Designs 💡 — Wed, 07 Jul 2021 09:54:50 +0000

Now with BuddyX theme support for free WordPress LMS plugin TutorLMS . Checkout BuddyX theme features and TutorLMS Demo
https://buddyxtheme.com/demos/
https://lms-demos.buddyxtheme.com/tutorlms/