Engineering guides / Angular applications and AWS infrastructure
By Arte Soft engineering · 24 October 2026
Headless content architecture: choose the editorial contract first
A headless content system separates content storage from its presentation, but that separation does not automatically improve publishing. It creates a contract between editors, frontend code and delivery infrastructure. Before choosing a CMS, identify what editors need to change without a developer and what must remain a controlled product or legal decision.
Model information instead of page fragments
Start with durable entities such as services, case studies, authors and guidance pages. Give them stable identifiers and explicit relationships. A collection of arbitrary HTML blocks can recreate the same maintenance problem in a new tool, particularly when many pages repeat a product capability or price. Decide which fields are required for publication and which have safe defaults. Store references to media with descriptive text and usage context. Avoid making editors paste URLs into free-form prose when a structured reference can prevent broken relationships and make future migrations easier to manage.
Make preview reflect publication
An editor should see the same layout and data rules that the public site will use. Define preview authentication, draft visibility and cache behavior, especially for unpublished commercial or legal content. A public preview URL with an obscure token is still a potential exposure. Establish who can approve, schedule and remove content. If the website is prerendered, specify how a content update triggers a build and how failures are reported. If it renders live, plan dependency outages and response caching. The appropriate design depends on update frequency and operational ownership rather than on the popularity of a CMS vendor.
Test changes across the boundary
Deliver the schema, sample records, preview route and publication pipeline as a working slice. Acceptance should cover publishing an article, updating a shared product fact, withdrawing a page and replacing an image. Check that each change reaches the correct public URL and that stale copies expire as intended. Validate missing references instead of allowing a broken build to reveal them late. Exportability matters: obtain a sample content export and document media ownership. A well-designed content API is useful only if the business can recover or move its information without reconstructing it from rendered pages.
A content change should have an identifiable owner and revision. When several sites reuse the same fact, the publishing system should reveal which outputs depend on it rather than requiring an editor to remember every place it has appeared.
Keep the tool proportionate
A small technical team may publish more reliably from structured repository files than from a separate CMS. A larger editorial team may need roles, translation workflows and scheduled publishing that justify the additional service. Compare the actual editing tasks, subscription cost and support responsibilities. Arte Soft’s product websites give concrete examples of structured product and guide content, not a universal recommendation for one platform. Bring sample pages and the people who maintain them. A scoped architecture engagement can establish the content contract first, allowing CMS selection to follow evidence instead of driving the entire website around a tool.
Relevant Arte Soft work
GPT Realtime Assistant — our own product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.
Sources and further reading
Need help with Content architecture discovery?
Send the current app, system or brief, the behaviour you need and your constraints. We can agree a discovery, implementation or repair scope with concrete acceptance criteria.
Discuss this with Arte Soft