A configurable content platform connecting editorial forms, database fields and application APIs.
This headless CMS case study covers a content platform that works from a single configuration. That one definition sets the editorial fields and their validation, and it sets the access rules and the storage alongside them. The platform runs inside the client's web application. Editors manage content there, and application code reads it back through an in-process interface, REST or GraphQL.
Our work tied that model to the publishing workflow. It added drafts and revisions, along with per-language status and the scheduled jobs that carry out timed changes.
The challenge
Adding one field touches three places at once. The field shows up in its form, in the stored record and in the API representation. Those three have to stay in agreement as the model changes.
Publication brings decisions of its own. A revision may still be a draft, and one language can be ready before another. A scheduled change needs a worker to run it, because saving a publication date on its own does nothing.
What we built
Collections hold repeatable content, while global records hold shared information. The generated administration interface covers rich text, media and relationships, with structured blocks as well. Developers can extend it with custom components and with field or collection hooks.
Editors get autosave, version history and document locking. Publication status can differ from one language to the next. The publishing step first filters the locales available to the current request, then applies the change.
Technical approach
A create request runs through one shared operation. It checks access, prepares any uploads and runs the hooks and validation. Then it writes the record and saves a version where that is enabled. The database work sits inside a transaction, so a failure cancels the transaction and aborts the file-operation scope with it.
Access rules can apply to a whole collection, to a single record or to one field. Custom endpoints and explicit overrides still need a permission design of their own.
Storage adapters support both document and SQL databases. A SQL adapter maps nested fields, arrays and blocks into related records. A deeper page structure can therefore add more tables and joins, which means the content shape decides how much work each read takes.
Scheduled jobs live in the database. A runner claims a job, keeps a heartbeat and records the outcome. Workflows hold on to completed task outputs so a job can resume, with retries and concurrency controls over how it runs. A serverless deployment needs an external scheduler or an invocation to start that runner.
Project success
Editors can prepare revisions and control publication inside the same content system that serves the application. Developers have one shared definition to extend. The validation and hooks carry through the supported operations. Scheduled work gains a persistent record and a clear execution lifecycle, while starting the runner stays an explicit deployment requirement.
Technology stack
Application and interface
TypeScript, React, Next.js integration
Rich text
Lexical
SQL adapters
Drizzle, PostgreSQL, SQLite
Document adapter
MongoDB, Mongoose
Interfaces
In-process API, REST, GraphQL
Background work
Database-backed task and workflow runner
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
