Ask HN: Which tech-stack requires the least knowledge and complexity?

You could do a custom WP plugin that provides a single page with everything they need. It doesn't have to be in the admin section, just a password-protected page. That way you stay with WP (which will likely be supported for many more years) and PHP (which will never, ever die) :)

If you are looking for low maintenance overhead, I would suggest django solely for the reason that they still have online documentation for unsupported versions released 10+ years ago.

I don't thing there's a framework or library that does that.

Time spent learning django is time well spent in my book.

I hate to write this, but what if instead of writing it yourself, you would ask ChatGPT to do it for you, and instead of documenting the code, you would archive and document your prompts for the future maintainer?

# Regarding Option A:

HTTP basic auth to gate access to an admin PHP page that contains a custom form that lets one make the required changes makes sense to me. I've done it for some (recent) microsites where I didn't want more technical overhead than it was worth (or where I didn't know how to do better more easily).

The worst that will happen is the web host's PHP gets upgraded and breaks the site, and a computer person has to go in and fix the PHP (maybe with a little help from an LLM). Or, the PHP was insecure and the site gets hacked, in which case I hope the web host had auto backups turned on set at a suitable cadence.

Either generate static HTML files, or render as PHP files that read from a single SQLite db file. No RDBMS dependencies. The PHP writing and reading the SQLite may get updated and break some scripts in the future, but LLMs may be able to fix it even.

One more concept, I stage my rollouts. So, I edit as admin from PHP form, then I can check the changes in the admin section's viewing page to make sure it all looks good. Then, once satisfied, I can promote the updated changes to the publicly visible section. This may be too much effort for your workflow/users, but it gives me peace of mind that I never royally mess something up with this process. I usually don't preview my changes, since I am now confident my scripts work. But I make this available to myself in case I make some weird changes.

# Consider Option B: Think about DokuWiki as a CMS.

Make the pages the site needs. Make a Sidebar page for navigation. Make the settings work for the site. Assign users to admin and editor roles that can edit/create pages and upload media (your PDF calendars) as they require. Make user accounts so only your club can read certain pages, etc.

I think that should be really stable over time. No database to think about. All site content is stored in a hierarchy of files, which could be backed up and restored to a fresh DokuWiki install if ever needed.

For Calendar, I would run a separate system though, and link to that (or embed that). I imagine there is at least one decent FOSS PHP calendar system available, probably available on cheap hosting and installable through cPanel/Softaculous.

If the Calendar ever gets borked, I would just forget about any entries on it, reinstall a fresh Calendar solution, and let required entries get re-made.

# As for hosting

I would pick a "fast" (NVME), inexpensive, and trustworthy web host for the main site and for the Calendar system. Last I checked, r/webhosting was making good recommendations in this regard.

I've set up many of these sites for individuals (including several elderly folks) and small nonprofits. I'd very strongly advise against self-hosting any sort of stack in a situation like this. Whatever you set up is going to be obsolete in 2-3 years, and the club will have to find some poor soul to migrate it to another framework. I've seen that cycle happen so many times already.

If you build something yourself, it's going to be even worse, because nobody in the club will have any idea how to find help for it once you're gone. They wouldn't even know what to call it, and "stack" means nothing to them. Even if you want to write it in vanilla HTML, even that is a rarer skill in today's dev landscape, and that usually means you have to manage hosting and deployment on your own too... good luck explaining SFTP or SSH or HTTPS to whoever inherits the site.

IMHO Wix is the way to go, especially if the club has someone technical at all. Then you can make that one person the admin (probably whoever pays for it) and use their roles system to assign "blog writer" roles to limit the complexity for everyday users who just need to post new articles (https://support.wix.com/en/article/roles-permissions-overvie...).

Wix also offers a single-vendor experience with support, so if the club has issues with anything, they know who to reach out to. Wix will be able to help them with everything from the user experience to domain issues (register the domain through them too).

As devs we always want to go cheap and easy (for us) and self-host on simple clouds... but that creates a completely unmaintainable situation for the client where they have no single vendor to reach out to and need to hire a web dev to make any changes. That web dev has often been me, and I've migrated a lot of people to Wix and they've stuck with it years later.

Don't overthink and over-engineer this. It's not about what's FOSS, it's about what a bunch of non-techie people have to work with years after you're gone. That requires a relationship with some single vendor who cares about them, not a mishmash of soon-to-be obsolete software and ever-changing deployment schemes.

Even if Wix isn't perfect, two years later, it's going to be a LOT more supported than any self-hosted stack.