The problem: a services business is an information system
A web engagement produces an enormous amount of state — requirements, decisions, approvals, files, deployments, incidents, invoices — and most small studios store that state in places that cannot enforce it: inboxes, chat threads, memory. The client experience degrades exactly where it matters most: visibility. What is my status? What was decided? What happens next?
Backend.ly is the answer we built instead of assembling one: a platform where the business process is the product. Every engagement on this site flows through it — the request form you can see, the workspace clients log into, the releases and incident records behind the public status page.
The working phases, as engineered
Intake compiles intent into structure. START A PROJECT is a six-step wizard ending in a structured engineering brief — the business need, constraints, and scope lane — not a free-text message into a void. The brief expands into requirements and definition-of-done items with explicit approvals. Build starts from agreement, not from assumptions.
Build is gated. Projects carry tasks, milestones, change requests and approvals as first-class records. A change of scope is a change request with an audit trail — the mechanism that keeps "small favors" from silently swallowing a schedule.
Delivery is instrumented. Releases and deployments are records, not rituals; incidents and their events are tracked to resolution. The public status page reads the same data — real probes, real incident history — because curated status pages are theater.
Commerce is part of the system. The digital market sells products with orders, payments, a ledger and a licensing API for delivered software. Proposals and invoices are documents the platform generates from the same data the work runs on.
Architecture notes
- One application, one database. Marketing site, client workspace, admin command center, APIs — one Next.js application over one Prisma-managed database. The "sync between website and project tool" class of failure does not exist here because there is nothing to sync.
- CMS as structured settings. Site copy — including this page's siblings — is stored as structured settings with code defaults, editable without deploys, incapable of altering application behavior. Content lives under content; process lives under process.
- Auth as infrastructure. Custom JWT-based authentication with email verification, password reset and role-scoped access. Protected APIs are covered by a route-parity guard that runs before every deployment — a route that exists locally but not in the build (or the reverse) fails the release.
- Deploys with a safety manual. Standalone builds, pre-deploy integrity checks, a hard rule that production databases are never overwritten by deploys, and backups before swaps. The deploy of this very release followed that runbook.
Decisions we would defend
Build versus assemble. The workflow — brief, requirements, build, review, ship, operate — is the differentiation. Owning it end-to-end is expensive and compounding; renting six SaaS tools for it is cheap and incoherent.
SQLite over a database server. One writer, one machine, strict integrity needs. A single-file database with built-in integrity checks removes a class of operational failure this scale does not need, and backup becomes a file operation.
Public evidence over curated polish. The status page, this case study, and the WooAccount project page exist because verifiable work is the strongest signal a small vendor can send. No invented metrics — the platform either demonstrates itself or it does not.
What it demonstrates for clients
The platform is the argument: if a one-engineer operation can run structured intake, gated builds, instrumented delivery and public incident history, your project gets the same machinery — not a promise of professionalism, but the system that produces it.
If that operating model fits what you need built or fixed, the front door is the same wizard every client uses.