“Does it come with a CMS?” is one of the first questions business owners ask, and it’s usually asked as though the answer should obviously be yes.
It should not, necessarily. A content management system is a tool for a specific problem: authorised people need to manage content without editing the site’s code. If you do not have that problem, a CMS can add administration, maintenance and another service to govern without improving the customer experience.
The right answer is the smallest process your team can operate confidently. Sometimes that is a full CMS. Sometimes it is a file-based publishing workflow.
This is a separate decision from whether you need a website or application. If that distinction is still unclear, read Website vs Web Application: What Does Your Business Actually Need?.
1. What does a CMS actually do?
Strip away the marketing and a CMS typically provides four capabilities.
It stores content separately from design. Your words and images live in one place, the layout in another. Change the words without touching the layout.
It gives non-developers an interface. A form or an editor, rather than code.
It manages the process around publishing. Drafts, previews, scheduling, who approved what, and version history when something needs undoing.
It serves the same content to multiple places. One product description feeding a website, an app and a printed sheet.
That’s the list. If you need two or three of these, a CMS earns its place. If you need none, you’re buying machinery to solve a problem you don’t have.
2. A static website without a CMS
Content lives in files alongside the site’s code — usually Markdown, a plain text format with simple formatting marks. Someone edits a file, commits it, and the site rebuilds and deploys automatically.
This can provide a small public runtime surface: there may be no content database, administration login or application server exposed to visitors. Pre-built pages are also straightforward to distribute and cache. The build tools, dependencies, forms, third-party services and deployment configuration still require ownership and appropriate updates.
The central limitation is editorial independence: someone comfortable with the file and deployment workflow has to make each change. That can work well for a technical owner or a business using an agreed update service. It becomes restrictive when several non-technical editors need to publish without assistance.
3. A traditional CMS
WordPress and its relatives put content in a database and give editors a full administrative interface, usually with page building, media libraries and user roles.
The benefits are genuine: a mature ecosystem, widely understood editing patterns, media libraries, permissions and extensions for common requirements. Familiarity may also make training and supplier changes easier.
The platform, themes and plugins still require governance and regular updates. WordPress itself advises keeping plugins and themes current for security. Performance and reliability depend on configuration, hosting and extension quality; accumulating overlapping plugins can make changes harder to predict.
A traditional CMS is a reasonable choice when its editing capabilities are genuinely used and its maintenance has a named owner. It is a poor default when nobody plans to manage either the content or the platform after launch.
4. A headless CMS connected to a static website
This is another option that many business owners have not encountered.
A headless CMS separates content management from the public presentation layer. It provides structured content, assets, editorial tools and an API, while a separate website controls how that content appears. In a static setup, the website fetches the content during its build, turns it into finished pages and deploys them as files.
Astro supports this pattern directly. It has built-in content collections for repository content, static route generation and documented integrations with content-management systems, so one site can take content from files, a CMS or both. See the official Astro CMS guidance.
This is the point that surprises people: static and CMS are not opposites. Content can be managed in a friendly editor and still be delivered as pre-built pages, without requiring visitors to query the content database at runtime.
The trade-offs depend on the chosen service. They may include a subscription, a build-and-deploy step after publishing, preview configuration and greater integration complexity. These should be evaluated against the team’s actual editorial workflow.
The editor manages content, the build process produces the site, and visitors receive finished static pages.
5. Comparison
| Comparison item | No CMS (files) | Traditional CMS | Headless CMS + static |
|---|---|---|---|
| Who can edit | Someone comfortable with the file workflow | Authorised non-technical editors | Authorised non-technical editors |
| Drafts and previews | Possible through the repository workflow | Commonly included | Commonly included; integration varies |
| Multiple editors | Possible, but developer-oriented | Designed for editorial teams | Designed for editorial teams |
| Delivery | Pre-built static files | Runtime-generated or cached pages | Commonly pre-built static files |
| Public runtime surface | Usually smallest | Includes CMS, database and login | Public site can remain static |
| Maintenance | Build dependencies and deployment | Core platform, extensions, hosting and access | Integration, access and vendor dependency |
| Publishing path | Edit, review, build and deploy | Publish within the CMS | Publish, then build or revalidate |
| Best fit | Controlled, infrequent changes | Visual page management and editorial workflows | Structured content with a separate front end |
6. Choose no CMS when
Changes are infrequent. If the site changes a handful of times a year, an editing interface sits unused between updates while still requiring upkeep.
One technical person handles publishing. Whether that is you, a developer or an agency working through an agreed change process, a CMS may add a step if the publisher is already comfortable with files and Git.
Simplicity is worth more than self-service editing. Removing a public content database and CMS login can reduce the exposed runtime surface. It does not remove the need to secure forms, dependencies, accounts, third-party services and deployment settings.
The honest version of this choice is that editorial changes depend on someone who can operate the publishing workflow. Document that responsibility and the expected change process before launch.
7. Choose a CMS when
Non-technical staff publish regularly. If routine content changes are repeatedly blocked behind a developer’s availability, a suitable CMS can remove that bottleneck.
Several editors need access. Different people, different sections, different permissions. Managing that through files gets uncomfortable quickly.
You need drafts, previews or approvals. Where someone writes and someone else signs off before publication — regulated sectors, or any business where a wrong published figure is a real problem.
Scheduled publishing matters. Announcements timed to a launch or an event.
The same content feeds more than one place. Website, app, newsletter, internal system. One source beats four copies drifting apart.
8. What if the client only knows Microsoft Word?
This is a common and entirely reasonable scenario. Familiarity with Word is a workflow requirement, not a shortcoming.
Two workable answers.
A headless or traditional CMS with a visual editor. The interface can provide headings, lists, images and structured fields without exposing code. It should be configured around the tasks editors actually perform; unnecessary options make errors and abandoned workflows more likely.
No CMS, with a defined request process. At the start of the project, either the client supplies the approved content or FinTaxTech prepares the complete content; responsibilities should not be split informally. We transfer approved material into the site’s content or constants files. Where appropriate, we can provide the editable content file for requested amendments and publish the returned approved copy. Timelines and charges for future changes should be agreed for each project rather than assumed.
The failure mode to avoid is installing a powerful CMS, handing over a login, and discovering a year later that nobody ever touched it.
9. Blogging with Markdown versus a visual editor
If blogging is central to your plan, this decision matters more than the rest.
Markdown is plain text with lightweight formatting marks. It is portable, works naturally with Astro’s built-in content collections and suits writers comfortable with repository-based publishing. Some editors prefer a visual interface and should not be forced into a workflow they will avoid.
A visual editor shows formatting as it is applied and can manage images, previews and structured fields. Portability depends on the platform’s export formats, data model and how presentation has been coupled to content.
A practical rule is to choose the workflow the named publisher can use consistently. A technical owner may prefer Markdown, while a wider editorial team may benefit from a configured visual editor. A publishing plan built around a disliked process rarely lasts.
10. Ownership, backups and platform dependency
Whatever you choose, three things should be true.
You own the accounts. The hosting, the domain, the CMS subscription, the code repository — all in your company’s name, with your developer added as a user. This is the difference between changing suppliers and starting over.
Your content can leave. Ask directly: how do I export everything, in what format, and how much work is involved? Markdown files in a repository are highly portable. A suitable headless CMS should export structured data. Migration from a proprietary page builder can require additional work when content and layout are tightly coupled.
Backups exist and have been tested. Repository history makes changes traceable and reversible, but it is not a complete backup strategy by itself. A database-backed CMS also needs an appropriate backup schedule, an independent recovery location and a tested restoration process.
11. Security and maintenance responsibilities
Every option carries an ongoing obligation. They just differ in size.
A static site with no CMS still needs its dependencies, domain, forms, analytics and deployment configuration monitored. Some hosting services automate certificates and parts of deployment, but responsibility for checking the complete system remains.
A headless CMS with a static front end can keep content retrieval out of the visitor’s request path. Security is shared: the vendor operates its service, while the customer and developer remain responsible for configuration, integrations, permissions and removing access when someone leaves.
A traditional CMS requires active management of the core platform, extensions, themes, hosting, login protection, backups and monitoring. The precise controls depend on the system and risk, but the responsible party should be named in the agreement.
The question to ask any supplier: after launch, who applies updates, how often, and what happens if something breaks? A quote without an answer is incomplete.
12. Does a CMS improve SEO?
Not by itself. A CMS is a publishing tool, not a direct ranking advantage.
Search visibility depends on many signals. Helpful content, crawlable pages, clear structure, internal links and a good overall page experience all matter. Every option in this article can support those outcomes when implemented well. Google advises prioritising helpful, people-first content and treating performance as part of a broader page experience, not as a guarantee of ranking.
Where a CMS can help is operational: it may reduce publishing friction, improve consistency and make ownership clearer. Publishing more often does not compensate for weak or repetitive material; each page still needs a useful purpose.
Static generation can make a simple delivery path easier to optimise, but static pages can still perform poorly when they contain oversized images, excessive scripts or weak implementation.
The strongest choice is the simplest publishing system that produces useful pages reliably and gives visitors a good experience.
13. How FinTaxTech manages its Astro blog
Our own site is built with Astro and deployed as static pages. Blog posts are Markdown files in content collections, version-controlled alongside the site, so every post has a full history and the writing is portable by default.
Publishing works through Git. A new post is a Markdown file marked ready for publication (draft: false); pushing it to main triggers validation and a static build, and GitHub Pages deploys the finished pages only if those checks pass. There’s no database behind the public site and no admin login to protect.
That suits us because a technical owner oversees the repository and deployment. It is deliberately the smallest workable process for our situation, and it is not an automatic recommendation for every client. For each project, we assess who will publish, how approvals work and whether a CMS would provide meaningful independence.
14. Decision checklist
- Who physically makes content changes — name the person
- How often content actually changes, honestly, over a year
- How many people need editing access
- Whether drafts, previews or sign-off are required
- Whether publishing ever needs scheduling
- Whether the same content is needed anywhere other than the website
- How comfortable the editor is with anything beyond Word
- Whether blogging is central to the plan, and who writes the posts
- Who applies updates after launch, and whether that’s in a contract
- How content gets exported if you change supplier or platform
- Which ongoing subscriptions and maintenance responsibilities are acceptable
If the answers point to controlled, occasional changes handled through an agreed workflow, a CMS may be unnecessary. If several non-technical people must publish independently, evaluate a CMS configured around their actual responsibilities.
Tell us who updates your content
FinTaxTech creates new websites and complete redesigns for clients worldwide. We do not take on isolated repairs to poor-quality legacy code.
Our guided website questionnaire covers content, editors, publishing frequency and integrations. Your answers remain on your device unless you choose to share the generated document with us. We will recommend the smallest process your team can operate confidently, whether that means a CMS or a managed file-based workflow, before preparing an individual quotation.
Planning a new website or complete redesign? Tell FinTaxTech what your users need to accomplish.