“We need a CMS” is often shorthand for something more concrete: someone needs to update the site without changing code.
That is a good requirement. It does not yet tell us which interface to build. Publishing an article, updating an artist roster and reviewing a booking request involve different fields, permissions and decisions.
A general-purpose CMS, a custom admin panel, or a combination can be appropriate. The useful comparison starts with the work people need to do, not the label on the software.
01 / FIELD NOTESWhat a CMS brings to the project
An established CMS can provide a ready-made publishing workflow and familiar editing tools. When those tools match the content and the team, starting there can avoid rebuilding an editor from scratch.
That does not mean every CMS is restricted to posts and pages. WordPress, for example, explicitly supports custom post types. The relevant question is how well a particular platform represents the content and workflow—not whether custom content automatically rules it out.
The platform still needs to be evaluated: what can staff change, which extensions are involved, and what does ongoing ownership require?
02 / FIELD NOTESWhat a custom panel is for
Southside Records is the example in this collection. The published project has a staff interface for artists, releases, events and photos, alongside other operational views. It is built around those records rather than a generic page editor.
The value of a custom interface is that its controls can follow the team's task. That advantage has to be weighed against the work of building, testing and maintaining it. Removing a CMS plugin does not make the replacement application free of dependencies or upkeep.
Use the examples below to compare the responsibilities, not to receive an automatic recommendation:
COMPARE THE RESPONSIBILITIES
What does the editor need to do?
Select an example brief. These are explanations, not an automated recommendation.
Give the editor the right tools.
- Title + body
- Media
- Publication state
WHAT NEEDS TO BE TRUE
An established CMS may fit an editorial workflow. Compare its content model and editing experience with what staff actually need to publish.
CMS platforms can support custom content. A custom field is not an automatic reason to build everything.
Read the explanation without interacting
Editorial publishing
An established CMS may fit an editorial workflow. Compare its content model and editing experience with what staff actually need to publish. CMS platforms can support custom content. A custom field is not an automatic reason to build everything.
Operational work
A bespoke interface may fit records, states and approvals that are awkward in the chosen platform. Southside’s staff console is the project example. Custom software still has dependencies and maintenance. Audit behavior needs its own verification.
Both kinds of work
Publishing and operations can use separate tools. Define which system owns each record and how people move between the two interfaces. MRoot’s two content presentations are not evidence of a CMS-plus-admin deployment.
A more complicated workflow is a reason to examine the fit carefully. It is not proof that an established CMS cannot support it or that custom development will always be less expensive.
03 / FIELD NOTESAudit history is a behavior to verify
Southside's content-write excerpt provides a useful example of why feature names are not enough. It saves the artist, then separately attempts to write an activity-log row. The logging attempt has its own caught failure.
A successful content change can therefore exist without that log row. The activity log is best-effort, not evidence that every mutation is guaranteed to be recorded.
LOCAL FAILURE EXPLORER
Saved content ≠ saved history.
Create an artist
Staff submits a change.
Save the artist
Ready to illustrate.
Attempt the log
After a successful insert.
Try the failure path.
The artist is inserted first. The log is attempted in its own try / catch. Select an outcome to inspect what remains.
Read all three outcomes
- Both writes succeed
- The artist and activity row are saved. This illustrates one successful execution, not a guarantee for all changes.
- The log write fails
- The artist remains saved. The logging error is caught and written to the console. The function returns the artist without a corresponding audit row.
- The content write fails
- The insert error is thrown before the log attempt. The function does not reach the log write.
That distinction matters when someone asks for an audit trail. A workflow that requires complete logging needs more than a separately attempted log write; its failure behavior has to match that requirement.
04 / FIELD NOTESAsk who owns it after launch
Both options need an owner. For a CMS, that conversation includes the platform, extensions, permissions and update process. For custom software, it includes the application code, dependencies, hosting, access and the ability to make or recover from changes.
“Who will maintain this?” is therefore a real requirement, not a final footnote. A panel that fits the team's work but has no workable maintenance arrangement is not finished merely because its screens look right.
There is no source evidence here for a universal cost comparison. Scope the actual workflow and support responsibilities before claiming that either approach will be cheaper over time.
05 / FIELD NOTESThe middle ground
A site can use a publishing platform for editorial content and separate custom tools for operational tasks. The important questions are where each record lives, who can change it, and how the interfaces relate.
MRoot's documented shared-content pipeline is an example of one collection feeding two presentations. It does not establish that MRoot runs the CMS-plus-custom-panel arrangement just described. Those are different architectural patterns.
06 / FIELD NOTESMake the brief concrete
Describe one real editing task from start to finish. Name the record, the fields, the people allowed to change it, any approval step, and what should happen when saving fails.
That gives a platform comparison something to test against. The goal is an editing experience the team can use and maintain, whether it comes from an existing CMS, a focused custom panel, or a well-defined combination.
Source, dates, and what this page verifies
This page describes the supplied project account and related full article. Original publication dates remain attached to the source version. No production repository, message provider, Google Sheet, user account or game service was accessed.
The diagrams are newly implemented teaching examples, not screenshots or re-creations of complete application logic. They use fictional data and memory-only state; the CraftNet fragment carries bounded numeric example settings only. Original code excerpts are preserved and are not executed as production code here.
Technical clarifications and source corrections are identified in the article and in docs/batch-3/SOURCE-REVIEW.md. They do not constitute a new application security, performance or deployment audit.