We reviewed our own launch. Here is what the evidence showed.
A working site was only the beginning. We checked access, data persistence, outbound controls and operational readiness, then separated verified behavior from unfinished work.
Decision summary
The tested owner-access, persistence and paused-send controls behaved as intended. Email reply handling and independent backup recovery still needed follow-through. The evidence supported specific controls; it did not support calling every workflow ready.
Scope and method
We reviewed relevant source code and deployment configuration, ran unit and workflow tests, exercised sessions and concurrent updates in disposable PostgreSQL, and checked selected production journeys with controlled test data.
The scope included owner access, request persistence, outbound-mail controls, a database restore and mailbox delivery checks. It excluded an exhaustive penetration test, load testing, third-party provider internals and a full disaster-recovery exercise.
Code references identify the implementation reviewed. Public excerpts omit credentials, customer data and infrastructure access details. A private client report would include the agreed repository revision and reproduction evidence.
Admin access is checked on the server
Why it matters
A private workspace needs to reject unauthorized requests even when someone bypasses the sign-in screen.
Evidence
The authentication implementation stores hashed session tokens with an expiry, checks the configured owner and revokes sessions on logout. Workspace and discovery APIs perform their own authorization checks.
lib/auth.ts · app/api/workspace/route.ts · app/api/discovery/route.ts
Verification and limits
The deployment audit records successful owner login/logout, wrong-password denial and protected API checks. This confirms the tested access paths, not every possible authorization scenario.
Recommended next step
Keep unauthorized API requests and session revocation in the release checks whenever authentication or admin routes change.
Overlapping updates have a conflict check
Why it matters
Two operations reading the same workspace snapshot could otherwise overwrite one another and silently lose a request or status change.
Evidence
Workspace writes include the version read with the snapshot. The update succeeds only if that version still matches; conflicting mutations retry against fresh data.
lib/store.ts · workspace version check
UPDATE workspace
SET data = $1::jsonb, version = version + 1
WHERE id = 1 AND version = $2Verification and limits
Concurrent storage updates were exercised against a disposable PostgreSQL instance during the deployment audit. Intake persistence after an application restart was also checked in production.
Recommended next step
Retain the concurrency check and persistence tests. Revisit the storage model before expanding to a larger multi-operator workload.
A draft cannot silently become a sent email
Why it matters
An outreach workspace must not send messages just because drafts, automation or SMTP settings exist.
Evidence
The send function rejects requests unless sending is explicitly enabled. It also requires approval of the current saved draft revision before reserving a send attempt. Deployment configuration keeps cold sending off.
lib/mail.ts · sendApproved() / deploy/compose.yaml
if (process.env.MAIL_SENDING_ENABLED !== "1")
throw new Error("Email sending is paused.");Verification and limits
Paused-mail behavior passed the production smoke checks. Provider acceptance is recorded separately from inbox delivery; the code does not treat the former as proof of the latter.
Recommended next step
Before enabling outbound mail, verify the complete approval, send, reply and opt-out flow with controlled test messages.
Outbound delivery does not prove the reply path
Why it matters
A prospect can receive a message while their reply fails to reach the business. That makes an apparently connected mailbox an incomplete customer journey.
Evidence
On 20 October 2026, a test message from our domain reached the owner's Gmail account. The owner sent a reply, but repeated checks of the domain mailbox's Inbox and Junk did not show it during the test window.
Manual mailbox test · 20 October 2026
Verification and limits
Outbound receipt was confirmed. Inbound delivery remained unverified. The test did not establish the cause, so this is an unresolved delivery issue rather than a diagnosed DNS fault.
Recommended next step
Trace the reply and any delivery failure with the provider, then repeat an external send-and-reply test. Close this item only when the reply is visible in the receiving mailbox.
A restore test is only part of a recovery plan
Why it matters
A valid backup can still be unavailable during a wider hosting or account incident. Recovery depends on where copies live and whether the operator can retrieve them.
Evidence
The deployment audit records a successful restore into a disposable database and daily logical backups. An independent off-server backup destination was still outstanding at the review date.
deploy/backup.sh · deployment audit and restore check
Verification and limits
Backup creation and one restore path were verified. Independent recovery from loss of the hosting environment was not demonstrated.
Recommended next step
Add an encrypted copy in an independent destination with defined retention and access. Rehearse recovery from that copy and record the result.
What we would change in the development flow
- Define “done” as a tested user journey, including failures and permissions.
- Keep an explicit list of unverified integrations and operational dependencies.
- Re-run relevant checks after changes to authentication, persistence or deployment.
- Record a reproduction and acceptance check for every repair task.
- Separate provider acceptance, delivery and a successful customer response.
These are recommendations from this review. This report does not claim that every recommendation has already been implemented.
Get this clarity for your product.
Start with a free, focused review. Receive verified findings and evidence within one business day of the agreed start date. Capacity is limited; we confirm scope, access and availability before starting.
Get your free review