DEV Community: T.O.

How I Built a Crowdsourced Luxury Watch Waitlist Tracker with Next.js and Supabase

T.O. — Tue, 05 May 2026 02:47:55 +0000

I got tired of sitting on a Rolex waitlist with zero information. No position, no ETA, no way to know if my wait was normal or if I was getting strung along. When I went looking for data, all I found was Reddit threads with hundreds of anecdotes buried in noise.

So I built unghosted.io, a structured tracker where collectors submit their wait times anonymously. 550+ reports from 62 countries in the first week.

Here's how I built it, what I learned, and what surprised me about the data.

The Problem

Millions of people sit on authorized dealer (AD) waitlists for luxury watches from brands like Rolex, Patek Philippe, Audemars Piguet, and others. The system is deliberately opaque. There's no queue number, no ETA, no transparency. Dealers decide who gets what based on relationships, purchase history, location, and their own internal criteria.

The experience varies wildly depending on where you are in the world. A collector in Dubai might walk into an AD and get a Submariner the same day, while someone in New York waits 6 months for the same watch. But there was no way to know that because the only "data" available was scattered across forum posts and Reddit threads. Someone would post "I waited 8 months for my Submariner" and that was it. No way to aggregate, filter, or compare across regions or purchase history levels.

The Stack

I went with a stack optimized for speed to ship and low ongoing cost:

Next.js 16 (App Router) - ISR for page caching so brand pages revalidate hourly instead of on every request
Supabase (Postgres + Row Level Security) - handles the entries table, subscribers, and all the data layer
Plotly.js (plotly.js-basic-dist-min) - interactive scatter plots showing wait time vs purchase history
Vercel - hosting with automatic deployments from GitHub
New Relic - browser monitoring for Core Web Vitals

Total monthly cost: under $30 (Vercel Pro + Supabase free tier + New Relic free tier).

The Data Model

The core entries table is simple:

- brand (text)
- family (text) - e.g., "Submariner", "Nautilus"
- model (text) - specific reference like "126610LN"
- wait_time (text) - bucketed: "Walk-in / same day", "1-3 months", "1-2 years", etc.
- region (text) - geographic location of the AD
- purchase_date (text)
- purchase_history (text) - "No prior purchases" through "6+ purchases / VIP"
- status (text) - pending/published/flagged
- followup_frequency (text) - how often they follow up with their AD (for long waits)

Region is a critical field. Wait times differ dramatically by location. The same watch can be a walk-in purchase in one city and a 2-year wait in another. Every report captures where the AD is located so collectors can compare their local market against others worldwide.

New submissions default to "pending" for moderation. I built outlier detection that flags entries deviating 3+ tiers from the model average, plus duplicate detection that rejects identical brand/model/wait/region combos within 24 hours.

The Architecture Decisions That Mattered

ISR over force-dynamic. Early on I had force-dynamic on every page, which meant every page load hit Supabase. Switching to ISR with 1-hour revalidation on brand pages and 5-minute revalidation on the homepage cut server load dramatically while keeping data reasonably fresh.

Bucketed wait times instead of freeform. I initially considered letting users enter exact months. But people remember "about 6 months" not "5.7 months." Bucketed options (1-3 months, 3-6 months, etc.) give cleaner data with less friction in the submit flow.

Plotly over Chart.js or Recharts. I needed interactive scatter plots where users could hover over individual data points and see the details. Plotly handles this natively. The trade-off is bundle size, which is why I use plotly.js-basic-dist-min instead of the full package.

RLS for security, service role for API writes. Anonymous users can read published entries through the anon key. All writes go through an API route that uses the service role key after server-side validation. This prevents direct database manipulation while keeping the read path fast.

What the Data Shows

Some things the data revealed that I didn't expect:

Submariners are way easier to get than people think. The median wait is under 3 months, and 25% of reports are walk-ins. The internet narrative of "impossible to get a Sub" doesn't match the actual data.

Purchase history matters more than time. The scatter plots clearly show that collectors with 2-3+ prior purchases get watches faster than first-time buyers waiting years. The system rewards relationship building over patience.

Datejusts are practically available on demand. Most reports show walk-in or under 1 month waits. ADs use Datejusts as relationship starters. They offer you one to get you in the door, then you work toward the sport models.

FP Journe is in a league of its own. With under 900 watches produced per year, the waitlist is essentially an application process. Most boutiques have stopped accepting new names for the Chronometre Bleu entirely.

Location matters more than most people realize. Europe and Asia report different patterns than the US, especially for Tudor and Vacheron Constantin. Some markets have significantly shorter waits for models that are considered "impossible" in other regions. A collector in Singapore might get a Royal Oak in 3 months while someone in London waits over a year. The data makes these regional differences visible for the first time.

The Distribution Strategy

Building the product was the easy part. Getting people to submit data was the hard part.

Reddit was the primary channel. I posted to r/rolex first with the angle "I built a structured version of the AD Wait Time Megathread." That post hit 18K views, 44 upvotes, and 30 comments. The key was framing it as a community tool, not a product launch. No self-promotion, just "here's a thing that solves a problem we all have."

The second post to r/Watches (3.3M members) used a multi-brand data angle and generated 10+ organic submissions overnight from collectors in the US, Canada, Europe, and Asia.

SEO was the long game. I built 65 pages targeting specific search queries: brand pillar pages (rolex-waitlist-times, patek-philippe-waitlist), model pages (rolex-submariner-wait-time), and reference pages (/rolex/126610LN). Each page has JSON-LD schema (Article + FAQPage), canonical tags, and FAQ questions matching Google's "People Also Ask" phrasing.

Within 5 days, I was ranking page 1 for several brand-specific waitlist queries (AP at position 4, Tudor at position 5, Patek at position 6).

Mistakes I Made

Claiming "500+ reports" in the title before I had 500 Rolex-specific reports. A reader called me out. Trust is everything in this niche. I changed it to match reality.

Not having a Content Security Policy that included Google Analytics. When I added GA4, my own CSP blocked the script. Users saw broken analytics and I missed traffic data for a day.

Forgetting to update RLS policies after adding a new column. I added a followup_frequency column to the database and updated the API route, but the Supabase insert failed because the API was using the anon key. Switching to the service role key for writes fixed it. A real user reported the bug in my Reddit thread, which was both embarrassing and fortunate.

What's Next

1,000 reports by mid-May. The dataset is the moat. Everything else is secondary.
Geographic filtering on scatter plots. Users are asking for it in comments. Being able to filter by region will let collectors compare their local market against the global average.
Monthly "State of the Waitlist" report. Publishable data that journalists and bloggers can cite and link to.

The Takeaway for Builders

If you're building a data product:

Pick a niche where information asymmetry exists. Luxury watch waitlists are deliberately opaque. That opacity is the opportunity.
Let the community own the data. I don't scrape. People voluntarily submit because the tool helps them. That makes the data defensible and the growth organic.
Ship the simplest version that proves the concept. My MVP was a submit form, a Supabase table, and a scatter plot. Everything else came after I had 100+ reports.
Distribution is the hard part. Reddit worked because I was a genuine member of the community solving a real problem. If I'd posted a "check out my app" link, it would have been removed.

The site is free, open, and live at unghosted.io. If you're a watch collector sitting on a waitlist, submit your data. If you're a builder, I'd love to hear your feedback on the approach.

Stack: Next.js 16, Supabase, Plotly.js, Vercel, New Relic. Solo build. GitHub.

Stop Treating Credential Generation as an Auditor Scramble

T.O. — Tue, 14 Apr 2026 13:52:20 +0000

How to bake compliance evidence into the process before your next SOC2 or HIPAA audit.

The pattern shows up the same way every time. Audit prep starts and someone asks for proof that credentials were generated securely. Engineers scramble to pull Git history, check deployment logs, and screenshot password manager settings. They end up writing a three paragraph explanation of what they think their generation process does.

The auditor reviews it and says the evidence is insufficient.

Manual reconstruction always turns into pain. Not sometimes. Every time.

Why manual reconstruction fails auditors

Auditors are not asking whether you have a good process today. They are asking whether you had a documented, consistent, repeatable process at the time each credential was generated. Those are two completely different questions.

You can have an excellent process right now and still fail an audit because you cannot prove what was true six months ago. The entropy level, the compliance policy, the timestamp, the system that generated it. If that information was not captured at creation time it effectively does not exist. Retroactive reconstruction is not evidence. It is a story.

What baking evidence into the process actually means

The scalable answer is not better documentation or more screenshots. It is making evidence generation automatic and inseparable from the credential generation itself.

Every time a credential is created these five things should be captured automatically in the same operation:

The generation method. Not just the library name. The specific cryptographic function, the entropy source, and the parameters applied.

The compliance policy. Which standard was active at the moment of creation. NIST 800-63B, SOC2, HIPAA, or your internal standard.

The entropy bits. The mathematical proof of randomness. This is the specific number auditors increasingly demand and most teams cannot produce.

The timestamp. Exact ISO format with timezone. Not an approximation reconstructed from logs.

The environment and caller. Which system requested the credential and in which environment.

When these are captured automatically in every generation event you move from telling stories to providing compliance artifacts. The auditor asks for proof. You pull the log. Finding closed.

Here is what that structured log event looks like in practice:

{
  "event": "credential.generated",
  "generated_at": "2026-04-13T14:32:01.847Z",
  "compliance_profile": "SOC2",
  "entropy_bits": 116,
  "length": 20,
  "method": "crypto.randomInt",
  "environment": "production",
  "caller": "user-provisioning-service",
  "calls_remaining": 49847
}

Every field exists at creation time. Nothing reconstructed. Nothing approximated.

The written standard most teams skip

Before you can automate evidence you need a written standard. Most teams skip this because it feels like paperwork. It is not paperwork. It is the specification your automation implements.

Your standard should answer these questions in writing:

Minimum credential length per environment
Entropy threshold that constitutes compliance with your applicable standard
Which compliance profile applies to which system type
Log retention period and access controls
Who can query the audit log and under what conditions

Without written standards your automation is generating evidence for a policy that does not exist on paper. Auditors will note that gap separately.

The shift that changes everything

The teams that handle audits well are not necessarily the ones with the best security. They are the ones whose security controls speak auditor language automatically.

A credential generated with crypto.randomInt is objectively more secure than one generated with Math.random. But if neither produces a compliance artifact at creation time they look identical to an auditor. Zero evidence is zero evidence regardless of which function generated the credential.

The goal is not just generating secure credentials. The goal is generating secure credentials that prove their own integrity the moment they are created. That proof has to exist at creation time. Not when your auditor asks for it.

Why Math.random() Will Fail Your Next Security Audit

T.O. — Fri, 10 Apr 2026 16:38:41 +0000

If you have ever written something like this in a production codebase:

const secret = Math.random().toString(36).slice(2);

You have shipped a credential that will fail a security audit.
Not might fail. Will fail.
Here is why that matters and what to do about it before your auditors find it first.
With the renewed focus on Executive Order 14028 and software supply chain security, auditors are no longer just looking at what libraries you use. They are looking at how you use them to generate internal secrets. Credential generation is now explicitly in scope for supply chain security reviews in ways it was not three years ago.
The problem with Math.random()
Math.random() is not a cryptographic function. It was never designed to be. It generates pseudorandom numbers that are fast and statistically distributed enough for things like shuffling a playlist or generating a random color. It is completely wrong for generating secrets, API keys, passwords, or any credential that needs to be unpredictable to an adversary.
The specific problem is predictability. Math.random() uses a deterministic algorithm seeded by the JavaScript engine. In some environments that seed is observable or reconstructible. In all environments the output fails the entropy requirements defined in NIST 800-63B, the federal standard for digital identity and credential strength.
When an auditor runs entropy analysis on your generated credentials and finds Math.random() in the generation path, the finding looks like this:

AUDIT FINDING — CRITICAL
Control: SC-28 / NIST 800-53

Finding: Credential generation function Math.random()
identified across microservices.

Impact: Generated secrets fail entropy requirements
for NIST 800-63B compliance. Cryptographic randomness
cannot be verified.

Status: OPEN - 90 day remediation required

That finding stops deals, delays launches, and costs engineering time to remediate retroactively. The fix at that point is expensive because you have to find every place Math.random() was used, replace it, rotate the affected credentials, and produce documentation proving the new generation method is compliant.
The right function is already in Node.js
You do not need a library. You do not need a third party service. Node.js ships with a cryptographically secure random number generator in the built-in crypto module:

`const { randomInt, randomBytes } = require('crypto');

// Generate a random integer between 0 and charset.length
const index = randomInt(0, charset.length);

// Generate random bytes for a hex token
const token = randomBytes(32).toString('hex');`

crypto.randomInt() uses the operating system's cryptographically secure pseudorandom number generator. On Linux that is /dev/urandom. The output passes NIST entropy requirements because the source of randomness is designed for exactly this purpose.
The fix is a one line change in most cases. The problem is that most teams never make it because nobody flags it until an auditor does.
A copy-paste utility for your codebase

If you want a drop-in replacement you can put in your utils/ folder today, here is a minimal version using only Node.js built-ins:

`const { randomInt } = require('crypto');

const CHARSETS = {
uppercase: 'ABCDEFGHJKLMNPQRSTUVWXYZ',
lowercase: 'abcdefghjkmnpqrstuvwxyz',
numbers: '23456789',
symbols: '!@#$%^&*'
};

function generateSecureCredential(length = 20, options = {}) {
const {
uppercase = true,
lowercase = true,
numbers = true,
symbols = false
} = options;

let charset = '';
if (uppercase) charset += CHARSETS.uppercase;
if (lowercase) charset += CHARSETS.lowercase;
if (numbers) charset += CHARSETS.numbers;
if (symbols) charset += CHARSETS.symbols;

if (!charset) throw new Error('At least one character set required');

return Array.from(
{ length },
() => charset[randomInt(0, charset.length)]
).join('');
}

// Usage
const secret = generateSecureCredential(20, {
uppercase: true,
lowercase: true,
numbers: true,
symbols: true
});`

This gives you cryptographic security but not compliance documentation. For NIST 800-63B audit trails, entropy calculation, and machine-readable compliance metadata, that is what you need to add on top of this foundation.
The documentation gap nobody talks about
Switching from Math.random() to crypto.randomInt() is the technical fix. But it does not solve the audit problem completely.
Auditors do not just want secure credentials. They want documented proof that credentials are secure. That means:

Entropy bits calculated per credential
Generation method documented at the time of creation
Compliance profile recorded alongside the credential

Most internal credential generation systems do not produce this documentation automatically. Engineers have to build it separately, maintain it, and make sure it stays accurate as the codebase evolves. Most teams never complete that work.
This is the gap that causes audit findings even when the underlying generation is technically correct. You fixed Math.random() but you have no proof you fixed it that satisfies an auditor asking for evidence.
What shift-left credential security looks like
The concept of shifting security left means solving security problems at the earliest possible point in the development workflow, not after auditors find them.
For credential generation that means every credential that ships should come with documented proof of how it was generated, what entropy it has, and which compliance standard it meets. That documentation should be automatic, not something an engineer produces manually six months later when someone asks for it.
If you want to automate that documentation piece entirely, this is how we structured the Six Sense API to handle it:

`const response = await fetch('https://api.sixsensesolutions.net/v1/generate', {
method: 'POST',
headers: {
'Authorization': 'Bearer your_api_key',
'Content-Type': 'application/json'
},
body: JSON.stringify({
length: 20,
quantity: 1,
compliance: 'NIST',
options: {
uppercase: true,
lowercase: true,
numbers: true,
symbols: true,
exclude_ambiguous: true
}
})
});

const { passwords, meta } = await response.json();

console.log(meta);
// {
// length: 20,
// entropy_bits: 120.4, // <-- This is your audit evidence. 120+ bits exceeds NIST minimum.
// generated_at: "2026-04-10T14:57:35Z",
// compliance_profile: "NIST",
// calls_remaining: 49999
// }`

Every response includes entropy_bits and compliance_profile in the metadata. That metadata is the audit documentation. Your auditor asks for proof that credentials meet NIST 800-63B. You show them the response metadata. The finding closes.
The free tier
If you want to test this in your own codebase, there is a free tier at sixsensesolutions.net with 500 calls per month and no credit card required. Signup generates a real API key instantly.
The NIST and SOC2 compliance profiles enforce minimum lengths, character requirements, and ambiguous character exclusion automatically. The strong profile respects whatever options you pass directly.
The takeaway
If your codebase contains Math.random() in any credential generation path, you have a finding waiting to happen. The technical fix is one line and the copy-paste utility above gives you that today for free. The documentation fix is what most teams skip and what auditors actually ask for.
Both need to be in place before your next audit, not after.