I'm setting up a small independent research and publishing organisation and need to build its website mostly by myself. I have no developer, designer, or IT team available, and my budget is limited. I've used AI tools to learn and draft a sitemap and workflow, but I'm worried about choosing a foundation that will become difficult to maintain later.
The site will need institutional information, research topics and categories, structured publication pages, authors, abstracts, keywords, dates, downloadable PDFs, articles, opportunities such as fellowships, application forms with file uploads, review workflows before publication, and possibly certificate or ID-related processes. I also need to be able to add content and categories without editing code each time.
I'm trying to decide between WordPress, Ghost, another CMS, or a combination of hosted services. I'd like to understand whether a normal CMS can handle structured publications and review workflows, whether I need a custom database or backend, how submissions and uploaded files should be handled securely, and which services are worth paying for.
My main concern is avoiding decisions I'll regret later. If you've built sites for small research organisations, nonprofits, publications, or think tanks, how would you approach this as a solo, non-technical person? What would you build first, what would you keep separate from the main website, and what questions should I answer before choosing a platform?
5 Answers
You probably don’t need AWS, MongoDB, or a bespoke server architecture for this starting point. Structured publications, searchable metadata, PDFs, forms, and approval before publishing are standard CMS territory. A custom backend would add deployment, security, backups, updates, and debugging responsibilities without providing much benefit at this scale.
Do pay for a good domain, dependable managed hosting, automated backups, security updates, and any form or file-storage service that handles sensitive data appropriately. Cheap hosting can become a problem if a report suddenly receives attention, but overengineering is an even more likely source of maintenance trouble.
The requirements go beyond a simple brochure site. Content pages are relatively easy, but uploaded applications and internal workflows bring privacy, security, retention, and permissions into the picture. A polished first version made with AI is possible, but maintaining it safely without understanding the underlying systems is much harder.
Either reduce the first release to a straightforward content site using a hosted visual CMS, or budget for expert help with the parts involving personal data and submissions. The biggest risk is scope creep—treating every feature as “just one small addition” when the combined system becomes an application.
WordPress is a practical starting point because it is widely used, has a large support ecosystem, and can handle most of this with carefully selected extensions. A publications content type with custom metadata can cover authors, abstracts, keywords, topics, and PDFs, while forms can collect submissions and hold them for approval.
Keep the installation as simple as possible, use reliable managed hosting rather than the absolute cheapest plan, and avoid adding plugins just because they sound useful. The fact that other people can eventually maintain a common platform may matter more than choosing a newer or more technically elegant stack.
Start with the smallest useful version instead of trying to implement the entire diagram. Separate the project into phases: an institutional site and publication catalogue first, then opportunities and basic forms, followed by more complicated certificate, identity, or internal workflow features.
Before selecting technology, document the user journeys and data fields for authors, readers, applicants, reviewers, and administrators. Build a small proof of concept that you can operate yourself, then test whether another person could understand and maintain it. That will reveal more than comparing hosting providers or debating a custom database.
Make publications a proper content type from the beginning rather than ordinary blog posts with PDFs attached. Define the fields for one publication—title, authors, abstract, keywords, topic, publication date, and file—then compare platforms based on whether you can create and manage those fields without coding. Most mainstream CMS options can do this, sometimes with an extension, and adding new topics should be a simple administrative action.
I’d keep application forms, file uploads, and review queues in a separate service if possible. That makes security, storage, and future replacement much easier than building the whole workflow into the website.
That approach also avoids building a custom backend before there’s a genuine need. A CMS already provides the database, administration screens, user roles, and publishing workflow; custom infrastructure is usually justified only by requirements the CMS and its extensions truly cannot support.