Replay
Browser business phone (console dialer)
A real run, replayed: the browser phone uses four outside libraries and passes 44 of 44 of its own checks. [Node]
How it's built: what is written here and what runs underneath.
For technical reviewers and CTOs: what is written here, what runs underneath, and the checks behind both. 1,611 automated tests pass across five packages; five databases restored clean in a documented drill.
What is written here and what runs underneath
Some of this software is written here, and some is open-source software that is run and configured here. We direct AI coding agents and check their work with tests and gates before anything ships.
Written here: the browser phone, the call desk and its console, the chat widget and the site-building pipeline. [JavaScript, TypeScript, Python] The customer dashboard started as a publicly shared MIT-licensed starter with 8 pages. It now has 35, and at most 8.3% of its TypeScript is still the starter's. [Next.js, React, Drizzle ORM]
Run here, written by others: the customer tracker, the chat inbox and visit counting. [EspoCRM, Chatwoot, Umami] We configure and operate these. The dashboard and the chat service are separate programs, and a check fails the build if the dashboard reaches into the chat service's internals. [ESLint import rule, nine ports, five adapters built]
Replay
DuckDB console: tables, SQL, saved queries, CSV export
A real run, replayed: the database console accepts only a single request to read data. [SQL SELECT] It has 14 security tests and 11 tests of simultaneous requests.
Written here
- The browser phone
- The call desk and its console
- The chat widget
- The site-building pipeline
TypeScript on Node 22 and Python, in one pnpm and Turborepo workspace.
Run here, written by others
- The customer tracker [EspoCRM]
- The chat inbox [Chatwoot]
- Visit counting [Umami]
Configured and operated here, not written here.
The customer dashboard grew from a publicly shared MIT-licensed starter: 8 pages then, 35 now, and at most 8.3% of its TypeScript is still the starter's.
Checked every time code is shared
Automatic checks run before new code can be shared. A change that fails a type check, a test or the boundary rule is stopped before it reaches the shared code. [pre-push gate, boundary lint]
1,611 automated tests pass across five packages. The dashboard and chat service share definitions of the data they exchange. Those definitions are their only connection through data types. [shared contracts package]
The full run takes 42 seconds with no failures. A test also requires a written reason for adding an outside library.
The software applies repeated messages once. A backup that has never been restored is a guess, so restores run weekly.
See how the live demos run for the caps and limits on each demo.
Messages that arrive twice or out of order
Your customer record should not change twice because another app repeats a message. Incoming messages need a signature only the sender could have made. If signing secrets are missing, the system refuses the messages. [HMAC-SHA256]
Signatures cover the timestamp and message body. Messages have a 300-second acceptance window. Late messages face that same timestamp check.
The system saves each message before processing it. The message's source and event identifier prevent repeats from applying twice. The system reports failures so the sender can retry. A rush of messages is handled the same way: each one is saved first, and the job queue gives each job to one worker.
The database assigns pending jobs in a single statement, so separate workers cannot take the same job. The system checks conditions again before acting and refuses runs over their cap. A tag added by an automation cannot start another automation.
Live
Live API-to-CRM integration showpiece
An interactive example: public feeds become records in a small customer tracker. Checks cover signed messages and repeated events. [SQLite]
Databases
Customer records, phone calls and land research use different databases. Customer records use a server database; the phone app stores its records in a local database file. [Postgres, SQLite]
Land research uses a database for analysis, including checking whether a point falls inside a mapped boundary. Another database lets you search research text. [DuckDB, spatial point-in-polygon, SQLite FTS5]
Encryption seals stored secrets and detects changes to the sealed data. [AES-256-GCM]
Numbered instructions describe repeatable database changes and record their sequence for customer records. [migrations, Drizzle]
For a web app, we plan the stored records around the work you need to do.
Replay
Databases: PostgreSQL, DuckDB and SQLite in one console
A real run, replayed: one console over PostgreSQL, DuckDB and SQLite. The builds behind it hold 27 repeatable migrations across two PostgreSQL databases of 18 tables each.
Running, watched and backed up
Backup checks verify files after upload. Weekly restores put them into a scratch database to compare row counts. Full copies and copies of changes only go to remote storage with checksums. [Cloudflare R2, Postgres]
Server processes run with restricted permissions, behind a firewall and a web server. Visit counting runs in containers that automatically roll back updates. [Linux VPS, systemd, UFW, nginx, Umami, Podman]
Live
VPS operations: nginx, systemd, Podman, certs, firewall, backups
This site's apps run on one VPS behind Cloudflare. The firewall admits only Cloudflare's address ranges, and certificates are valid to 27 Jan 2027. [Certbot, Cloudflare]
Checked
Live
Live demo API and runner sandbox
One Node service runs all seven demos, each with its own state, caps and a kill switch. Each weather run starts in a fresh container with read-only files and reaches only the forecast provider. [Podman, api.weather.gov]
Live
Live code runner
This is a live run: the last 33 recorded runs had a median of 1.63 s. The runner's 11 sandbox checks, including file writes and memory use, all passed.
Where it runs
Your app needs a place to run, and its stored data needs a separate backup destination. The documented setup uses a rented server with a service manager and web server. Apps run in containers. [Linux VPS, systemd, nginx, Podman]
Service settings stop processes from gaining extra privileges and keep system files read-only. A firewall controls network access. Another tool blocks repeated failed access attempts. [systemd, UFW, fail2ban]
Traffic passes through a service in front of the server. Backups go to remote storage that holds files as objects. [Cloudflare, Cloudflare R2]
We host your app the same way, on a Linux VPS behind Cloudflare, with the checks and backups described here.
The capabilities and builder background pages help you choose what to discuss.
Tell us what you would change
We build a custom version around your changes. Describe what you would change and the tools it needs to connect.