Can Qooling be vibe coded?
Cloud platform for quality, health, safety and environment management: documents, risks, incidents, audits and ISO certification evidence in one place.
You can absolutely build a register: incidents in, corrective actions out, documents with version numbers, a dashboard that looks convincing. What you cannot build in a session is the thing anyone actually buys, which is an evidence trail an external ISO auditor will accept without argument, plus a mobile flow that a warehouse worker will actually use to report a near miss. Compliance software lives or dies on immutable audit logs, controlled document approval with signatures, retention rules and the fact that the vendor, not you, is the one explaining the system during a certification audit. A personal replacement also makes little sense here: this is inherently multi-user, and the value appears only when an entire site logs into it. Build the register if you want to understand your own processes; do not put your certification on top of it.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
medium editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause.
- Prototype the workflow, but rely on audited libraries and established security tools.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- Auditor familiarity: external certification bodies have seen the commercial tools and know what to click
- Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category
- A field-usable mobile app for incident and near-miss reporting with photos, offline
- Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch
- Compliance, licensing, and legal accountability are core features.
- Permissions, presence, and shared workflows are difficult to simplify.
Build, switch, or keep paying
Narrower, with trade-offs
A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause.
Use the build brief ↓No checked option yet
Compare the prior art below or build only the workflow you need.
Recommended
Because compliance is a social process, not a data model. Getting fifty people across three sites to report incidents, sign off documents and close corrective actions requires a tool that everyone tolerates, a mobile app that works in a loading bay, and a paper trail that survives an auditor picking a random clause and asking for proof. Companies also pay for someone to blame: if the certification audit goes badly, a vendor with ISO-shaped templates and support is a better story than a spreadsheet-plus-side-project maintained by whoever built it before they left.
Visit Qooling ↗Why people still pay
Because compliance is a social process, not a data model. Getting fifty people across three sites to report incidents, sign off documents and close corrective actions requires a tool that everyone tolerates, a mobile app that works in a loading bay, and a paper trail that survives an auditor picking a random clause and asking for proof. Companies also pay for someone to blame: if the certification audit goes badly, a vendor with ISO-shaped templates and support is a better story than a spreadsheet-plus-side-project maintained by whoever built it before they left.
Compliance, licensing, and legal accountability are core features.
Permissions, presence, and shared workflows are difficult to simplify.
Years of history, configuration, and habits make migration costly.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Qooling
Context
Qooling — Cloud platform for quality, health, safety and environment management: documents, risks, incidents, audits and ISO certification evidence in one place.
You can absolutely build a register: incidents in, corrective actions out, documents with version numbers, a dashboard that looks convincing. What you cannot build in a session is the thing anyone actually buys, which is an evidence trail an external ISO auditor will accept without argument, plus a mobile flow that a warehouse worker will actually use to report a near miss. Compliance software lives or dies on immutable audit logs, controlled document approval with signatures, retention rules and the fact that the vendor, not you, is the one explaining the system during a certification audit. A personal replacement also makes little sense here: this is inherently multi-user, and the value appears only when an entire site logs into it. Build the register if you want to understand your own processes; do not put your certification on top of it.
This brief describes a focused, single-operator replacement for the part of Qooling 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 single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause.
Prototype the workflow, but rely on audited libraries and established security tools.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
A machine or small VPS to host it.
File storage for document attachments and photos.
Someone willing to define the clause-to-evidence mapping by hand.
Backups you actually test, since this data is the audit.
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 self-hosted single-organisation QHSE register. This is a learning and internal-tracking tool, not a certification system, and it should say so on the dashboard.
Stack, no substitutions:
Next.js (App Router) with TypeScript and Tailwind
SQLite via Prisma, file at ./data/qhse.db
Local disk storage for attachments under ./data/uploads
Single shared password from AUTH_PASSWORD in .env, cookie session, no user accounts, no OAuth, no cloud services, no telemetry
Data model:
Person: name, email, site
Incident: type (incident, near miss, unsafe situation), date, site, reporter, description, severity 1-5, photos, status (open, investigating, closed)
Risk: hazard, activity, likelihood 1-5, impact 1-5, computed score, existing controls, owner, review date
Action: title, source (incident or risk or audit), owner, due date, status, closure note, closed date
Document: title, code, current version number, category, owner, review date, uploaded file per version, status (draft, approved, retired)
AuditLog: append-only table, every create and update writes actor, timestamp, entity, field-level before and after JSON. Never allow deletes on this table in application code.
Screens:
Dashboard: open incidents, overdue actions, risks above score 15, documents past review date
List and detail views for each entity, with inline forms, no modals-only flows
Risk matrix view: 5x5 grid, colour by score, click a cell to see the risks in it
Evidence pack: pick a date range, get a single printable HTML page with all incidents, actions, risks and document versions in it, plus the relevant audit log rows
In scope: seed script with two sites, five people, sample incidents and risks. CSV export for every list. Overdue highlighting.
Out of scope: mobile app, offline capture, email notifications, e-signatures, multi-tenant, ISO clause libraries, permissions and roles.
On the dashboard, print a fixed banner: "Internal tracking only. Not an audited compliance system."
Include README with setup, .env.example with AUTH_PASSWORD, and a backup script that copies ./data to a timestamped folder.
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:
Auditor familiarity: external certification bodies have seen the commercial tools and know what to click.
Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category.
A field-usable mobile app for incident and near-miss reporting with photos, offline.
Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch.
Someone else being accountable when the system fails during an audit or a serious incident investigation.
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.
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? · Full report: https://www.canitbevibecoded.com/qooling
You still own the product
- 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.
Projects built from this idea
No reviewed implementation has been linked for Qooling yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Qooling?Submit the project as evidence for this report.
Before you start
Can Qooling be vibe coded?
Not faithfully. You can absolutely build a register: incidents in, corrective actions out, documents with version numbers, a dashboard that looks convincing. What you cannot build in a session is the thing anyone actually buys, which is an evidence trail an external ISO auditor will accept without argument, plus a mobile flow that a warehouse worker will actually use to report a near miss. Compliance software lives or dies on immutable audit logs, controlled document approval with signatures, retention rules and the fact that the vendor, not you, is the one explaining the system during a certification audit. A personal replacement also makes little sense here: this is inherently multi-user, and the value appears only when an entire site logs into it. Build the register if you want to understand your own processes; do not put your certification on top of it.
What can an AI coding agent reproduce from Qooling?
A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause. Prototype the workflow, but rely on audited libraries and established security tools. A responsive interface with real empty, loading, success, and error states.
What will a DIY Qooling replacement still be missing?
Auditor familiarity: external certification bodies have seen the commercial tools and know what to click; Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category; A field-usable mobile app for incident and near-miss reporting with photos, offline; Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch; Compliance, licensing, and legal accountability are core features.; Permissions, presence, and shared workflows are difficult to simplify.
What do I still own after building a Qooling alternative?
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.