I just wanted a message board. That was the whole idea.
Not another SaaS product. Not a full social network with a complicated relationship graph. Just a place where someone could publish a message, attach an image or a PDF, let other people comment, and give an administrator enough control to understand what was happening.
That became Open Message Board. It started small, and then reality kept adding footnotes: file uploads, moderation, email verification, Turnstile, visitor context, retention questions, and the occasional thought of adding a small market widget.
The most important decision was a directory boundary
The first design decision was not a page layout. It was deciding what should be public at all.
The public document root is web/. Database credentials, mail settings, the administrator password hash, and other private configuration belong in private/. That boundary is what lets the project run on an ordinary Nginx, Apache, Caddy, or PHP hosting panel without quietly turning configuration files into downloads.
Making the first install less mysterious
The installer asks for the practical things: site name, base URL, timezone, mail sender, MySQL connection details, the first administrator account, and the upload directory. It imports the schema, generates the administrator password hash, and checks whether the upload directory can actually be written to.
After installation, web/install.php should be deleted or renamed. Even though the installer refuses to run once private/config.php exists, there is no reason to leave an installation entry point sitting in the public web root on a production server.
php -S 127.0.0.1:8080 -t webI like this development path because it is honest. Start the local server, publish a post, add a comment, try an image route, and only then decide whether the project is ready for a domain and HTTPS.
Once a message can contain files, it stops being just a message
Public posts can have a title, author name, email, hashtags, SEO keywords, images, and PDFs. Comments can have image and PDF attachments too. Then the project needs an admin area for reviewing posts, opening a per-post comment drawer, and deleting content.
That means the database has to remember more than one table. Posts, attachments, comments, hashtags, and moderation logs all need to fit together. Upload limits, allowed file types, write permissions, and whether files should live outside the public web root are application concerns, not deployment details to postpone forever.
The privacy questions showed up later, but they mattered
The board can record visitor metadata such as IP address, user agent, browser language, and browser timezone so an administrator has some context when reviewing activity. But storing that information is not a free feature. It raises questions about retention, access, and how much of it the site actually needs.
Turnstile is optional. The Yahoo Finance ticker card is optional too. The ticker uses a cached one-month sparkline instead of pulling fresh data on every page view. Both features can be turned off. They do not need to become permanent just because they were easy to add.
It is still a small message board
I do not want to describe Open Message Board as a complete community platform. It is closer to a public wall that I can actually control. There are fewer moving parts, but I know where the data lives and where the boundaries are. If the project grows later, I know where authentication, notifications, or more complex moderation should fit.
That is the part that feels most like a diary to me. The project keeps a record of all the things I assumed I would not have to think about: someone will upload an odd file, a comment becomes its own piece of content, an administrator needs context, a market card goes stale, and private configuration must never end up in a commit.
A small system does not have fewer engineering problems. It just makes them easier to see.