# Build brief — a focused alternative to ServiceNow

> **Verdict:** Not faithfully · **Buildability:** 13/100 · **Category:** Automation
> **Source:** https://www.canitbevibecoded.com/servicenow
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from ServiceNow. Verify current pricing and capabilities before acting.

## Context

**ServiceNow** — Enterprise platform for IT service management, employee and customer workflows, and the endless approval chains around them.

You can build a ticket tracker with a focused implementation. You cannot build ServiceNow, because ServiceNow is not a ticket tracker: it is a CMDB, an approval engine, a change management workflow that auditors accept, and a discovery agent crawling every asset on a corporate network. Nobody buys it because the forms are nice, they buy it because Sarbanes-Oxley auditors and ISO reviewers already know what a ServiceNow change record looks like. The personal version of this makes no sense either, since a single human does not need a change advisory board. If you genuinely want the shape of it for yourself, build a small request queue with states and an audit log and stop there.

This brief describes a focused, single-operator replacement for the part of ServiceNow that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

A local ticket queue with typed request forms, state transitions, an append-only audit log, and a tiny asset table you can link tickets to.

- Automate a small number of known workflows with logs, retries, and manual recovery.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Node 20+.
- A browser.
- Nothing else, it runs on local SQLite.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a local, single-user request queue called "Deskless". This is a personal consolation build for ServiceNow, not an ITSM platform. Be honest about scope.

Stack, no substitutions:
- Next.js 15 App Router, TypeScript, Tailwind.
- SQLite via better-sqlite3, file at ./data/deskless.db, schema created on boot if missing.
- Server Actions for all mutations. No API routes unless needed.
- No auth, no accounts, no telemetry, no cloud. It runs at localhost:3000 for one person.

Data model:
- assets: id, name, kind (laptop, service, subscription, account), owner_note, created_at.
- tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at.
- events: id, ticket_id, at, kind (created, state_change, comment, field_change), from_value, to_value, note. Append only, never edited or deleted.

Features in scope:
- Ticket list with filters by state, type, priority, and a text search over title and body.
- New ticket form where the fields shown change by type: change tickets additionally ask for rollback_plan and planned_window, stored as JSON in an extra_fields column.
- Ticket detail page: state transition buttons, comment box, linked asset, and the full audit log rendered as a timeline.
- Assets page: create, list, and see all tickets touching an asset.
- A "Weekly" view: tickets closed in the last 7 days and anything still open past its due date.
- Export everything to a single JSON file via a button, and a CSV export of tickets.

Explicitly out of scope, do not build: SLAs, approval chains, discovery agents, email ingestion, multi-user roles, SSO, a workflow designer.

Deliver: a README with setup in three commands, a seed script that inserts 12 sample tickets and 5 assets, and one Vitest file covering that state changes always write an events row.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Automated discovery and a real CMDB that maps thousands of assets and their dependencies.
- Change management and approval workflows that auditors and compliance frameworks already recognize.
- Hundreds of prebuilt integrations into AD, Okta, Jira, SAP, monitoring tools and everything else in a corporate stack.
- Role based access, SSO, data residency, and the enterprise security paperwork that comes with it.
- An ecosystem of certified admins, partners and store apps, which is often the real reason the contract renews.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**High consequence.** Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/servicenow