NailScannailscan.ai
Platform & data

Everything the scanner has ever seen, kept.

The scan is the part clients notice. The part that compounds is the record it leaves behind — structured findings, attribution, contact linkage and full history, in a store that belongs to the salon and exports at any time.

01 Architecture

Serverless at the edge. No box to maintain.

The system runs on a global edge network rather than a server in one region. Nothing for a salon to host, patch or restart.

Figure 01 — Request path and durability model
Client device Assessment worker Verdict Core Ledger Integrations CAMERA · LEAD GATE CONSENT CAPTURE EDGE · APERTURE + ONYX-5 CONFIDENCE GATE PREP · SERVICE CARE GRAPH BIND SCAN + RELATIONAL NO EXPIRY CRM · SMS · EMAIL AD CONVERSION EVENTS HTTPS WRITE THEN GATE HALT → RESHOOT REQUEST FAILED WRITE → BOUNDED RETRY QUEUE · CAPPED ATTEMPTS, CAPPED AGE DURABILITY BOUNDARY
Read the diagram right to left. Everything downstream of the Ledger can fail — messaging gateway, email provider, the operator's CRM — and the assessment survives, because it was already written. Systems that deliver first and persist afterwards lose records to other people's outages and never find out.
Capture layerclient side
Scanner interface
White-labeled, mobile-first, on your domain. Camera capture with pre-flight checks.
Lead gate
Consent captured and remembered, so returning clients are not re-prompted.
Behavior tracking
Clicks, scroll depth and drop-off at every step of the flow.
↓   HTTPS   ↓
Compute layeredge workers
Assessment worker
Validates the image, runs the locked schema, enforces the confidence gate.
Rules engine
Prep steps, wear type, care calendar, recommended service and price. Pure deterministic code.
Delivery worker
Renders the report, issues the link, dispatches email and SMS, fires events.
↓   WRITE BEFORE DELIVER   ↓
Storage layerdurable · no expiry
Scan store
Every record, keyed and timestamped. Indefinite by default; deletion is explicit.
Relational store
Contacts, consent, sync state and the retry queue, with referential integrity.
Event store
Interaction events per surface, feeding the friction analysis below.
↓   SYNC + RETRY   ↓
Integration layeroutbound
CRM sync
Contact upsert, findings to named fields, opportunity and stage.
Messaging
Compliant SMS and WhatsApp, plus transactional email for the report.
Ad platforms
Conversion events at the correct funnel moments, so optimization has real signal.
↓   ACCESS-GATED   ↓
Operator layerstaff only
Staff console
Look up any record by ID or phone, read the findings, force a re-sync.
In-chair scanner
No lead capture, no CRM push, no tracking. For existing clients.
Friction board
Where prospects hesitate and abandon, ranked by impact rather than dumped as a heatmap.
02 Data model

What a single scan actually stores.

Readable identifiers, structured findings, and enough context to reconstruct where the client came from and what they were told.

Phone numbers are normalized to E.164 at write time in every component, which is why one client scanning from two surfaces resolves to one contact rather than two.

03 Reliability

Built by people who treat your client list like it is the business.

Not features on a roadmap. Each exists because something failed in production and the fix was made structural rather than manual.

Write before deliver

The record is persisted before any email, SMS or CRM call is attempted. A downstream outage can delay a notification. It cannot destroy a scan.

Bounded retry queue

Failed writes are queued and re-attempted on a fixed schedule, bounded on attempts and age — so a queue cannot grow forever or hammer a recovering service.

No silent expiry

An early build carried a 180-day expiry that quietly deleted completed reports. Found, removed, every affected record migrated. Retention is now explicit and tested.

Post-deploy assertions

Field mappings, workflow state and event wiring are checked automatically after every deployment, because all three have shipped broken before and none fail loudly.

Reconciliation tooling

Records are matched against CRM contacts by identity and timestamp window to find orphans. Run at scale in production: 287 historical records reconciled in one pass.

Environment isolation

Test paths are environment-gated after a hardcoded test address once created a phantom contact in a live CRM. Staging cannot write to production.

04 Security & data handling

Whose data this is, and what happens to it.

Clients are photographing their own hands and handing over a phone number. That deserves a clear answer, not a privacy policy nobody reads.

Ownership
The salon owns its records. Scan data, contacts and findings belong to the deploying salon, and full structured export is available at any time — including after a contract ends. No hostage clause.
Images
Processed, not traded. Photographs produce that client's assessment. Not sold, not licensed, not used to train anyone's model. Retention is configurable per deployment, including a mode that discards the photograph once the findings are extracted.
Consent
Captured at the point of capture. Marketing consent is collected at the lead gate and referenced on the scan record, so what a client agreed to and when is answerable from the record rather than from memory.
Access control
Identity-gated staff tooling. Console, in-chair scanner and analytics board sit behind an allow list and one-time codes. Not a shared link, not a shared password.
Transport
Encrypted in transit, with the assessment running on the edge network rather than relayed through intermediate servers you cannot see.
Deletion
Explicit and honoured. A deletion request removes the record and the contact linkage. Deletion is never a side effect of a storage policy — nothing disappears without someone deciding it should.
Portability
No lock-in by design. The scanner runs on your domain, the data exports in full, and the CRM integration writes to a system you control. Stop working with us and you keep the asset.
05 Instrumentation

You can see where people give up.

Every surface is instrumented — clicks, rage clicks, dead clicks, scroll depth, exit points and completion, attributed by campaign and device. The output is not a heatmap you squint at: pages are ranked by a friction score and the findings are written in plain language, because the question a salon owner has is “what is costing me bookings,” not “where is it warm.”

  • Ranked by friction, so the worst page is the first thing you see
  • Plain-language findings above the visualisation, not buried under it
  • Per-step drop-off through the scan flow itself, not just page-level
  • Campaign attribution carried to completion, so you know which ad brings people who finish
Figure 02 — Friction score by surface · sample output
/scan · step 2 /scan · step 3 /lander /pricing /report 87 74 52 38 12 FRICTION SCORE — 0 (NO OBSERVED FRICTION) TO 100 (WORST SURFACE IN THE ACCOUNT)
FRICTION BOARD · PLAIN-LANGUAGE FINDINGS
/scan step 231% abandon at camera permission prompthigh
/scan step 3Rage clicks on disabled submit buttonhigh
/landerScroll depth median 42% — CTA below foldmedium
/reportBooking CTA click-through 18%healthy
/pricingDead clicks on non-interactive service rowsmedium
Reading this board: the camera permission prompt is costing more completed scans than any copy change would recover. A heatmap shows you that and never tells you.
Next step

Ask to see the console, not the brochure.

We open the staff console on the call, look up a live record, show you the sync state, and export it in front of you.