For support, operations, enablement, and product teams

Knowledge Base Builder With an Operable Article Lifecycle

Describe the articles, collections, access rules, review path, search behavior, freshness policy, redirects, attachments, and retention boundary your team needs. Playcode builds the custom web app and can add database-backed records, protected actions, publishing, tests, export, and recovery.

No credit card required · No coding needed

Quick answer

Can I build a custom knowledge base with Playcode?

Yes. Playcode can build a custom knowledge base with public and private articles, versioned revisions, collections, taxonomy, permissions, search, freshness reviews, redirects, attachment records, export, deletion, and recovery. A same-release deterministic model exercises stale edits, duplicate publishing, private access, and search-index failure without claiming a packaged helpdesk or AI assistant.

1.1M+users
26M+projects
Since 2016

Used by people at

Counts registered accounts using corporate email domains from the companies above. Playcode is a self-serve product, not a contracted vendor to these brands.

From Article Policy to a Searchable Knowledge Base

Model the record and lifecycle first, then prove that permissions and derived search stay consistent

01

Define Articles, Revisions, and Taxonomy

Name the stable article ID, public slug, visibility, collection, tags, owner, freshness review date, access lists, current revision, published revision, record version, and lifecycle states. Keep attachment metadata and rights records separate from article copy.

Use collections for navigation and tags for cross-cutting discovery. Decide which fields are public, which require an authenticated reader, and which are editorial-only before building the screens.

Preview
AI Chat
Publish
I'm a realtor in Miami. I need a website to show my listings and get buyer leads.
4 Questions
2 / 4
What's the main style for your real estate site?
AModern & minimal with clean lines
BLuxury feel with large property photos
CProfessional & corporate
DI'll describe my own style below
Or type your own answer...
Skip
Next
Describe what you want to change...
Economy
Build Progress
4/6
✓
Site layout & navigation
3s
✓
Hero section with CTA
5s
✓
Property listings grid
8s
Building contact form...
About page & bio
Footer & SEO meta
miami-homes.playcode.io
Miami Dream Homes
Your trusted partner in Miami real estate
Search by neighborhood...
Featured Listings
NEW
$1,250,000
Coral Gables Villa
4 bd|3 ba|2,400 sqft
OPEN
$890,000
Brickell Condo
2 bd|2 ba|1,200 sqft
Get in Touch
02

Build Review and Publish as Version-Bound Actions

Save every edit as a revision created from an expected article version. Route draft to review, require a reviewer decision, then let an authorized publisher expose only the approved revision. Give publish attempts a durable idempotency key so a slow retry cannot create two releases.

Treat search as a derived index, not the article source of truth. Queue an index update after publication, expose pending or failed freshness, keep the last valid index readable, and retry the index job independently.

03

Operate Freshness, Retirement, and Recovery

Track the next review date, change slugs with explicit redirects, retire stale content, and remove retired or deleted articles from search. Require rights confirmation before a referenced attachment publishes and keep private files behind the same article access decision.

Export owned records before destructive work, test deletion, and restore a bounded snapshot when recovery is required. Recheck public, signed-out, private-reader, editor, reviewer, publisher, and unrelated-account paths on the published HTTPS app.

Your website is live!

https://
miami-homes.playcode.io
Site is secure - SSL certificate active
Or connect your domainmiami-dream-homes.com
Miami Dream Homes
Your trusted partner
Miami Dream Homes
Your trusted partner
A folder of pages is not an editorial system

Replace Overwritten Articles With Explicit Records and States

Make the source revision, public visibility, search freshness, and recovery path observable

A fragile document library

  • The current page is overwritten, so nobody can explain what changed or restore it
  • Draft, reviewed, and public content share one status or browser-side toggle
  • Private articles and attachments rely on hidden links instead of server authorization
  • Search silently drifts from the published source when indexing fails
  • Renamed and retired articles become dead links with no redirect or retirement record

A bounded knowledge workflow

  • Stable article IDs point to immutable revisions and one current published revision
  • Draft, in review, approved, published, retired, and deleted states have named actors
  • Public and private reads use the same server-side access decision as attachments
  • Search reports pending, current, failed, or removed state and retries independently
  • Redirects, freshness dates, export, deletion, and snapshots preserve operating context
A complete first release

What Your Custom Knowledge Base Can Include

Start with one article-to-retirement loop before adding more channels or automation

01

Public and private articles

Serve published public articles to anyone while limiting private collections, articles, and referenced attachments to authenticated, authorized readers.

02

Versioned revisions and editorial roles

Keep immutable revision records, expected-version edits, authors, reviewers, publishers, readers, and a separate published revision so draft work cannot leak.

03

Collections, taxonomy, and canonical slugs

Organize navigation through parent and child collections, apply normalized tags, and keep stable article ownership when a public slug changes.

04

Search with freshness health

Index the authorized published projection, expose the source and indexed revision, keep the last valid result during an outage, and retry failed updates separately.

05

Attachment rights and access

Record filename, media type, size, checksum, uploader, article owner, and rights confirmation before an attachment joins a published revision.

06

Retirement, export, deletion, and recovery

Remove retired content from public resolution and search, export owned records, test deletion, and restore a saved application state when recovery is required.

Same-release deterministic proof

The Record and Failure Contract Runs Without a Provider

The downloadable provider-neutral TypeScript reference passes 13 deterministic tests for workspace ownership, lifecycle continuity, malformed inputs, and failure recovery. ZIP SHA-256: e873ca654d16859cd7982656f261d8d983a3001cb8ccb17c27f8617efb8acd88. It is not a packaged product, live service-level proof, or external search provider.

Draft to retired
Version-bound article lifecycle
Workspace-scoped
Access-checked article and attachment reads
Pending to recovered
Observable search-index failure and retry
Export + snapshot
Deletion and bounded recovery evidence

Download the tested knowledge-base reference

Lifecycle map

Picture the Article System Before You Build the Screens

The central source article moves through review and publication while taxonomy, search, access, revisions, retirement, and redirects remain separate concerns.

Illustrative knowledge-base lifecycle from draft through review, publication, retirement, taxonomy, search, private access, revision history, and redirect
Illustrative conceptIllustrative lifecycle diagram generated for this page. It is not a product screenshot or proof of a deployed knowledge-base service. The actual result depends on your brief, data, access policy, search design, attachment rules, and operating process.
Record contract

What the Source of Truth Must Decide

Separate durable article facts from derived search and delivery behavior

ConcernFragile shortcutCustom knowledge-base contract
Article identityThe slug is the record ID, so renaming breaks every referenceA stable article ID owns revisions, while old slugs become explicit redirects
EditingLast write wins and silently overwrites another editorEvery revision names its base version; stale edits fail with a reload instruction
PublishingA double click can publish twice or repeat downstream workThe approved revision publishes under a durable key; exact retries return the prior result
SearchThe index is trusted as current even after an update failsHealth names source and indexed revisions, preserves the last valid index, and retries independently
Private accessAn unlisted URL or client-side filter hides private contentThe server checks the reader on article, search, redirect, and attachment paths
Content retirementDeleting a page leaves stale search entries and unexplained broken linksRetirement removes public resolution, queues index removal, and preserves an auditable state
One record model, different access jobs

Knowledge Bases Teams Can Shape Around Their Workflow

Use one bounded article system, then change the taxonomy, roles, and public/private mix

Public customer education

Readers find maintained answers

Publish product and process articles with review ownership, searchable current revisions, freshness dates, canonical slugs, and retirement redirects.

Private operations library

Internal procedures stay access-checked

Limit collections and attachments to named team readers while authors, reviewers, and publishers keep separate version-bound actions.

Partner enablement hub

External readers see only their scope

Give partner accounts access to scoped articles, expose only rights-cleared attachments, and export or delete records under a documented lifecycle.

Product and policy library

Change history remains explainable

Track immutable revisions, category changes, review dates, old-slug redirects, search freshness, and recovery evidence for changing reference material.

Knowledge-base operating guide

Build One Article-to-Retirement Loop Before Adding Automation

Prove source records, permissions, publication, search, redirects, attachments, and recovery with fictional fixtures first

Before you build

Prerequisites

  • One versioned editorial and retention policy

    Authors, reviewers, publishers, readers, freshness owners, attachment rights, retirement, deletion, export, and recovery need explicit responsibility before the interface can enforce them.

    Ready when: A named owner has approved one policy version with article states, transition actors, review timing, attachment rules, retention, deletion, export, and incident escalation.

  • One public/private field and access matrix

    Article copy, draft revisions, private collections, attachment metadata and bytes, audit events, and search documents do not share the same audience.

    Ready when: For every field and route, the matrix names public, authenticated-reader, author, reviewer, publisher, or admin access plus the signed-out and unrelated-account result.

  • One authoritative source and derived-search contract

    Search is useful only when the team can tell which published revision it represents and what happens while an index update is pending or failed.

    Ready when: The contract names the article source, published revision, queue identity, source-through revision, indexed revision, freshness state, retry owner, and repair procedure.

Implementation sequence

Do, observe, verify
  1. 01
    Playcode project data and protected server actions

    Create collection, article, revision, access, and attachment records

    Model stable IDs, parent collections, normalized tags, canonical slug, visibility, permissions, immutable revisions, current and published revision pointers, article version, freshness review time, attachment checksum and rights record, timestamps, and audit context. Derive actor identity on the server.

    Expected result

    One fictional draft belongs to one article and collection, carries explicit access, and can reference only article-owned attachments without exposing editorial fields publicly.

    Verify

    Create a nested collection and public plus private fixtures; attempt signed-out, authorized-reader, unrelated-reader, second-author, reviewer, publisher, and admin access to every relevant path.

  2. 02
    Editor, review queue, and server mutation handlers

    Enforce stale-edit and review boundaries

    Save each new revision from an expected article version, reject stale writers, submit the current revision for review, record the reviewer decision, and permit only an authorized publisher to expose the approved current revision.

    Expected result

    Concurrent editors cannot silently overwrite one another, and neither a draft nor an in-review revision becomes public through a client-side state change.

    Verify

    Accept one edit, replay a second edit from the old version, try cross-role transitions, inspect the immutable revisions, and fetch public detail and search before approval and publication.

  3. 03
    Publish handler, search queue, and search health view

    Publish once and reconcile the search projection

    Claim a durable publish key using the article, revision, and expected-version fingerprint. Commit the source publication before indexing, queue one search update, report pending/error/current state, preserve the last valid document during failure, and retry indexing without republishing.

    Expected result

    An exact retry returns the first publish result, changed reuse conflicts, and an index outage is visible without losing the accepted article revision or duplicating the publish action.

    Verify

    Run the happy path, exact duplicate, changed duplicate, second publish key, simulated index failure, stale-result query, recovery retry, public query, and private-reader query.

  4. 04
    Published HTTPS app, operations view, export, and recovery controls

    Rename, retire, export, delete, and recover the fixture

    Change one slug while retaining an access-checked redirect, mark its freshness due, retire it, remove it from search, export owned records, delete the fixture under an admin action, then restore the saved state and repeat the public/private access checks.

    Expected result

    Old links resolve only while the article is published and readable; retired or deleted content leaves search; export is complete enough to inspect; and recovery restores the bounded saved state.

    Verify

    Record article, revision, collection, redirect, attachment, queue, export, deletion, and snapshot identifiers plus the before/after search health without copying private content into logs.

Decisions that change the build

Should an article be public or private?

  • Public published article
  • Authenticated private article

Choose: Choose visibility from the intended reader and field sensitivity, then enforce it on detail, search, redirect, and attachment paths. Use public only when the complete published projection is meant for anyone.

Tradeoff: Public content is easier to discover and share. Private content adds identity, invitations or membership, session lifecycle, cross-account tests, support, and more careful export and deletion handling.

Should search query live records or a derived index?

  • Live source query
  • Derived search index

Choose: Start with a live source query when the collection is small and filtering is simple. Use a derived index only when ranking or scale justifies its separate freshness, authorization, retry, and repair contract.

Tradeoff: Live queries reduce drift but may limit ranking and scale. A derived index improves retrieval options while creating lag, failure, permission-copying, removal, and reconciliation work.

Before you share it

Test checklist

  • Happy path

    An author creates a rights-cleared article, a reviewer approves the current revision, a publisher publishes it, indexing succeeds, and an intended reader finds the correct result.

    Expected: One approved revision is public or privately readable as configured, search names the same indexed revision, taxonomy is normalized, and freshness is current.

  • Invalid input

    An unrelated account edits or reads private content, an author publishes directly, a slug collides, an attachment lacks rights confirmation, or a stale revision tries to save.

    Expected: The server rejects the action without exposing private data, overwriting the accepted revision, publishing the attachment, changing lifecycle state, or mutating the search index.

  • Duplicate or retry

    The publish request retries with the same key and fingerprint, then changed input reuses that key while a search-index update fails and retries independently.

    Expected: The exact publish retry returns the first result, changed reuse conflicts, no second publication appears, the source remains accepted, and one search retry reaches the current revision.

  • Published smoke test

    A private mobile browser exercises public and private article reads, search, old-slug redirect, attachment access, freshness, retirement, export, deletion, and snapshot recovery on the published HTTPS app.

    Expected: The configured access matrix, revision identity, derived-search health, redirect, responsive layout, removal, export, deletion, bounded logs, and restored state match the accepted fixture.

If something goes wrong

Common failure cases

One editor silently erases another editor’s accepted change

Likely cause
The update writes by article ID without comparing the expected record version or preserving an immutable revision.
Check
Compare both editors’ base versions, accepted article version, created revision IDs, current pointer, and server responses.
Fix
Require expected-version writes, return a specific stale-edit conflict, reload the current revision, and let the author reconcile deliberately.

A slow publish creates two release events or notifications

Likely cause
The publish action and downstream delivery have no durable idempotency identity, or a retry repeats the source mutation.
Check
Compare idempotency keys, request fingerprints, article and revision IDs, lifecycle events, search jobs, and provider attempts.
Fix
Claim the publish attempt durably, return the prior result for an exact retry, reject changed reuse, and retry derived work independently.

Search shows an old, private, retired, or missing article

Likely cause
The derived index lost source revision, visibility, freshness, or removal state, or an index failure was hidden.
Check
Compare source published revision, indexed revision, visibility, reader scope, queue state, last error, retirement state, and source-through time.
Fix
Fail closed on access, expose stale/error health, rebuild or remove the affected document from authoritative source records, and repeat public plus private fixtures.

An attachment downloads through an old public link after the article becomes private or retired

Likely cause
File delivery trusts an opaque URL instead of rechecking the article, published revision, rights record, and current reader.
Check
Fetch the attachment signed out and across accounts before and after visibility, revision, slug, and retirement changes.
Fix
Authorize file delivery against the current published article and referenced attachment, use bounded delivery URLs where needed, and invalidate stale public access.

A renamed or deleted article cannot be explained or recovered

Likely cause
Slug, redirect, export, deletion, and snapshot operations were treated as unrelated page-level actions with no stable article identity.
Check
Inspect the article ID, redirect history, revision export, deletion event, search removal, snapshot time, and restore result.
Fix
Keep stable IDs, export before destructive work, make redirects and deletion explicit, restore the bounded saved state, and rerun access and search reconciliation.
The engine

A software team in one agent

Playcode AI runs the same frontier models that power ChatGPT and Claude - and orchestrates them like a team: it plans the work, delegates to sub-agents, runs long jobs in the background, and reviews its own changes.

Every frontier model

The latest models from every major lab, in one picker. Switch anytime.

ClaudeGPTGeminiGrok

Sub-agents

Big jobs split across specialists - one explores your code, one writes, one audits - working in parallel.

Background tasks

Long builds and migrations keep running while you keep talking. They report back when done.

migration - running

It sees your designs

Have a design in Figma? Paste a screenshot - or a page you like, or a bug - and it builds from what it sees.

Tuned by years of iteration to write production software - structured, typed, maintainable - not throwaway prototypes.

Production code

Real code you can open, read, and edit

Under every project is a codebase the agent keeps production-grade. And you are never locked out of it: open the file explorer and edit any file yourself - server included. No AI required.

Quality is the default

Complete states, secure boundaries, structured code - the bar is what a professional agency would ship.

Every file is yours to open

Browse the whole project - frontend, backend, configuration - and edit directly in the built-in editor.

Developers are welcome

Invite your developer with the right role, or export the project code and files. Nothing is trapped in Playcode.

For teams and organizations

Share it like you share a doc

Playcode is built for organizations, not just solo builders. Workspaces hold your projects, people, and billing; roles and teams decide exactly who sees what.

Workspaces with their own billing

Create a workspace per company, client, or department - each with its own members, projects, and subscription.

Three clear roles

Admins manage, editors build, viewers watch. Set roles on the whole workspace, on a team, or on a single project.

Teams that scope access

Group people into teams and give each team its own projects - or a whole folder of them. Private projects stay private, even inside a shared workspace.

Share outside the workspace

Send a project to any email - a client, a contractor - with exactly the access you choose. No extra seat needed.

Share "Inventory tracker"
Acme Ops workspace
Private
client@partner.co
Editor Invite
Operations team
8 people
Editor
MK
Maya Kowalski
maya@acme.co
ADMIN
JR
Jon Reyes
jon@acme.co
EDITOR
LS
Lena Sato
lena@acme.co
VIEWER
Restricted - only people invited can open it
Real-time

Multiplayer by default

Work on one project together. Write in the same AI chat together. Every message, edit, and setting is fully synchronized - live, for everyone, on every device.

acme-launch · Playcode
MKJR
Maya's laptop
Maya
Add a 'Book a call' button to the hero
Jon
And link it to our calendar, please
Playcode AIDone - button added to the hero and linked to your calendar.Preview updated
Describe the next change...
Jon's phone
Maya
Add a 'Book a call' button to the hero
Jon
And link it to our calendar, please
Playcode AIDone - button added to the hero and linked to your calendar.
Message...
Already there. No refresh.

Same project, same moment

Everyone works in the project at the same time - even in the code editor - without lock-outs or "who has the latest version".

Every device

Start on the laptop, check from your phone: the same live state follows you everywhere you sign in.

Nothing to refresh

Changes arrive over a live connection the instant they happen. Reloading the page is a habit you can drop.

Feels instant

It never makes you wait

Instant

Every click applies immediately on your device. Syncing happens behind you, not in front of you.

Offline

Connection dropped? Your changes queue locally and replay the moment you are back.

Reload-proof

The queue survives closing the tab. Nothing you did is lost while you are away.

Real People. Real Websites Built with AI.

"I built my entire portfolio site in 20 minutes. My clients think I hired a designer. Already got 3 new inquiries this month."
Marcus T. · Freelance Graphic Designer, Austin TX
"We switched from Wix to Playcode. The AI actually understands what we need instead of giving us cookie-cutter templates. Saved us thousands."
Sarah Chen · Owner, Bloom & Petal Floristry
"I update my property listings from my phone while showing apartments. Clients are impressed when I tell them I built the site myself."
David Morales · Real Estate Agent, Miami FL

Simple Pricing

Start small. Upgrade when you're ready.

Starter

$0to start

Try the AI website builder and see results

  • AI credits included to start
  • Publish your site instantly
  • Subdomain included
  • Website hosting included
  • No credit card required
Get Started

Pro

Most Popular
$25/month

Everything you need to build

  • 100 AI credits/month
  • All AI models (12+)
  • Visual editing
  • Custom domains
  • Website hosting included
  • Export your code anytime
  • Private projects
  • Unlimited collaborators
Start Building

Cancel anytime. No hidden fees.

How credits work

Credits are used when AI helps you. Simple edits cost less, complex features cost more.

  • "Change button color" ~0.3-0.5 credits
  • "Add a contact page" ~2-3 credits
  • "Build full landing page" ~5-10 credits

Most users never run out. 100 credits = lots of building.

Knowledge Base Builder Questions

It creates a custom web application around your article records and operating rules: public or private reading, collections, tags, revisions, author-reviewer-publisher roles, search, freshness dates, redirects, attachment records, export, deletion, and recovery. The exact result depends on the brief and the access and content policies you provide.

Yes, when visibility is part of the authoritative article record and every detail, search, redirect, and attachment path checks the current reader on the server. A hidden URL or browser-only filter is not a private-access boundary. Private content also needs session, membership or invitation, revocation, cross-account, export, and deletion tests.

Each immutable revision names the article version it started from. The server accepts the edit only if that expected version is still current. A stale editor gets a specific conflict and reloads before reconciling, so a later save cannot silently erase an accepted revision. Review and publish actions use the same version-bound approach.

Publication remains the source-of-truth action and search reports a separate pending or error state with the source and indexed revisions. The last valid search document can remain available if it is still authorized, while the failed index job retries independently. Operators should be able to rebuild or remove one document without republishing or rewinding unrelated articles.

A stable article ID survives slug changes. The old slug becomes an explicit redirect to the current published article, subject to the same access check. Freshness dates mark content due for review without fabricating recency. Retirement removes public resolution and queues search removal while preserving the lifecycle and revision history needed for audit and recovery.

Yes. Model attachment metadata and bytes separately, record the owning article, checksum, media type, size, uploader, and rights confirmation, and publish only references included in the approved revision. File delivery must recheck the current published article and reader. The custom app does not verify copyright or grant rights you do not hold.

No. This page is for building a custom article and knowledge workflow. Helpdesk tickets, broad employee intranets, packaged-software selection, and developer-documentation platforms have different buyers, records, integrations, and operational expectations. Choose or evaluate those systems separately instead of stretching one custom knowledge-base brief across unrelated jobs.

No. Searchable articles do not prove grounded AI answers. A chatbot or RAG layer needs a separate approved-source registry, retrieval permissions, meaningful evidence matching, citations, no-answer behavior, injection and private-source leakage tests, provider setup, rate limits, privacy, retention, outage handling, and human escalation. Build and prove that as a separate application boundary.

A custom build can include structured export, explicit deletion, and snapshot recovery when those contracts are part of the brief. Define whether the export includes collections, articles, revisions, redirects, attachment metadata, and file bytes; define retention and deletion ownership; and test restore from a bounded saved point. Do not assume every external search or file provider follows automatically.

Still have questions? Contact us

Plan the Knowledge Workflow Around It

Explore the builder directory See other custom app, workflow, portal, and website builders.Build internal tools Connect maintained knowledge to the operations workflow behind it.Start with the knowledge base template Define durable article ownership, taxonomy, review dates, freshness, retirement, redirects, and internal references before building the workflow.Compare knowledge-base software Use the dated buyer guide when selecting a packaged platform instead of a custom build.Build an AI chatbot Treat grounded answers, citations, safe actions, and escalation as a separate app contract.

Build the Knowledge Base Your Team Can Operate

Start with one article lifecycle, one access matrix, and one honest search contract. Add more collections only after the first loop survives failure and recovery.

A public customer knowledge base with review, publishing, freshness dates, search, and redirects...Build My Knowledge Base

No credit card required. AI credits included to start.