Licensing Roadmap: research becomes a product

01 / A WEBSITE BECOMES A PRODUCT

Start with the checkout. Discover the product hiding before it.

Convenient Licensing already had a way to buy licensing help. The bigger opportunity was helping a visitor understand what they needed before asking them to buy it.

This build began as an audit of a Durable website, an embedded checkout, and a replacement Astro site. It grew into Licensing Roadmap: a research experience that explains likely pathways, documents, fees, and uncertainties, then saves the useful result as a shareable guide. From that foundation came fifteen tools for renewals, continuing education, prescribing, and working across states.

02 / PRESERVE THE CONTRACT

The same event names do not mean the same analytics.

The Durable site and future Astro site shared a payment backend but maintained different checkout interfaces. Both had the same ten analytics event names. Yet Astro was missing historical step names and numbers, route positions, cart details, and attempt counts.

The repair preserved Durable’s parameter contract while keeping Astro’s richer diagnostics. Currency, value, and items returned to the checkout-start event. Step completion included the final review submission. Retry counts followed submission outcomes. Most importantly, a throwing analytics helper could no longer prevent the redirect to Stripe.

Compatibility contract—not copied implementationtext

Preserve: step number/name, route position/length, navigation direction
Restore: currency, value, items, checkout attempt number
Retain: reason, validation fields, from/to step, action
Protect: analytics exceptions must never interrupt checkout

Two copies of global GA/GTM header snippets were also observed on Durable. The embed itself did not initialize those integrations. But duplicated HTML did not establish duplicated collected events, so the investigation ultimately recommended verifying actual collection before changing the header. The GTM noscript fallback was not itself another active JavaScript initialization.

03 / MODEL THE BUSINESS ENTITY

A customer is not a checkout attempt.

When a visitor started checkout twice and paid once, the backend created two customer records. One became paid; the abandoned one stayed initiated. This was a data-model problem, not an Airtable display bug, affecting both main and self-service bases.

01Start checkoutCreate an attempt with its order details.

02Complete paymentThe signed webhook handles payment success.

03Resolve customerCreate or reuse a customer by normalized email.

04Keep historyLink the paid attempt; retain unfinished attempts separately.

Separate identity from transaction historyStart checkout → Complete payment → Resolve customer → Keep history

Checkout Attempts tables, retry protection, expiration handling, and older-checkout compatibility preserved history without treating every abandoned cart as a customer. Email normalization was a practical matching rule, not complete identity resolution.

This backend change was reported released through develop, staging, and main, with 230 tests passing and production API checks. No live payment was made during verification. Existing duplicate records remained for a separate cleanup.

04 / GIVE RESEARCH A DESTINATION

Meet a visitor before they are ready to buy.

The first interaction asked for profession, current licensing state, and destination state. Selections started blank, with query parameters for shared or prefilled links. Brave Answers researched the route; OpenRouter organized findings into a scannable result.

The guide separated likely pathway, requirements, government fees, processing information, compact considerations, and sources. Useful but unconfirmed details retained their explanations. Repetitive warnings later became small markers and one shared footnote, without removing section-specific qualifications.

The tool became Licensing Roadmap, with “Find My Licensing Path” as the secondary call to action. “Get Started” remained primary. A homepage form, contextual links, and guide-to-checkout selection handoff made research useful across the site rather than burying it in a menu.

05 / FROM ANSWERS TO EVIDENCE

Save what the model read before saving what it concluded.

The later experiment switched from synthesized Brave Answers to Brave LLM Context. It retained passages, titles, URLs, query provenance, and retrieval timestamps before model extraction. Evidence became reusable rather than disappearing behind generated prose.

01DiscoverBrave retrieves relevant source passages.

02PreserveStore identity, text, provenance, and retrieval time.

03StructureOpenRouter extracts requirements and conditions.

04ReviewCheck missing topics, quotations, support, and applicability.

The evidence-first research pipelineDiscover → Preserve → Structure → Review

Conceptual fact contract—not the literal API schematext

fact
  value: what the source says
  condition: when it applies
  status: supported or unresolved
  evidence: source identity + exact quotation

review
  jurisdiction, profession, pathway, applicant conditions
  support for numbers and dates
  conflicting evidence and missing topics

publish
  retain supported facts; withhold unsupported assertions
  explain unresolved coverage

Early trials retrieved 93 passages for an NP route and 96 for an RN route. Those counts were observations, not quality scores. The results still omitted requirements and left a fee unconfirmed. More context improved the input; it did not establish completeness.

06 / TEST THE OMISSIONS

A quotation can be accurate while the guide is incomplete.

Live review found omitted practice-history and prescribing-related conditions. Another trial exposed the need to distinguish an existing multistate license, a single-state license, and a change of primary residence. A simple state-to-state answer could hide a materially different pathway.

The response combined fuller official-source reading, bounded follow-up searches, structured eligibility conditions, and a separate review comparing the draft with evidence and required topics. Regression cases tested incorrect additions as well as omissions.

Topic profiles generalized the work. Renewal research needed first-renewal exceptions, recurring versus one-time training, and late or lapsed routes. Prescribing research separated professional authority, collaboration, state registration, and federal requirements. Nursing compact evidence could not establish prescribing authority.

07 / RESEARCH ON DEMAND

Let actual questions grow the library.

The goal was not to precompute every profession/state combination. Each valid general route received a stable path. A missing guide could start research when visited; concurrent visitors shared a job. Completed guides were saved and returned in server-rendered HTML.

Public route and cache lifecycletext

/license-requirements/registered-nurse/new-york/florida

missing → bounded job → validated guide → sitemap
fresh   → serve saved HTML immediately
stale   → serve prior guide + one background refresh
failure → preserve last successful guide and research date

pending without a usable result → noindex
status polling / sitemap reads → never start research

Redis became the persistent guide store, not merely an expiring cache. Results became stale after 24 hours without disappearing. Leases, retry backoff, and revision-aware storage prevented older deployments from overwriting newer validated research. Persistence, capacity, and backups consequently became operational requirements.

01A valid visitLook up the route and enforce shared limits.

02One research jobTrack progress; retain any previous guide.

03Validated resultPersist usable content and its research date.

04DiscoveryRender HTML and add the canonical guide to the sitemap.

Publish only after there is something worth readingA valid visit → One research job → Validated result → Discovery

Vercel request continuation kept work alive after navigation, with recovery after a lease expired. This was visit-driven work, not an independently scheduled worker. Public and crawler visits could consume budget. Recorded limits were ten attempts per hour per IP outside develop and twenty in develop, plus a shared daily cap. There was no exhaustive crawler or unrestricted prewarming.

Personal residence and compact answers stayed separate from public guide identity. Comparison views avoided duplicate indexable articles. Staging remained a nonproduction surface: server rendering and sitemap support are capabilities, not proof of search indexing or ranking.

08 / FIFTEEN TOOLS, SHARED RESEARCH

Different questions should not repeat the same research fifteen times.

Cost, document, timeline, verification, and compact views could reuse a transfer guide. Renewal and CE shared a profession/state result. Multi-state planning used a small explicitly selected set of routes rather than researching the country.

Keep a license active: Renewal Checklist, CE Requirements, Restore My License.
Understand authority: Prescribing & DEA Roadmap, Compact License Options, Where Can I Practice?
Prepare the work: License Cost Planner, Document Checklist, Licensing Timeline, License Verification Helper.
Plan a change: New Job Licensing Checklist, Multi-State Expansion Planner, Compare State Requirements.
Find the right institution: Find My Licensing Board, International Education Roadmap.

These were specific views over shared research, not fifteen independent chatbots. General renewal guidance did not calculate personal deadlines or CE balances. Job-readiness guidance did not determine a person’s eligibility to work.

09 / DIFFICULT SOURCES

Diffbot helps read a source. It does not become the authority.

Brave discovered sources; a bounded direct reader retrieved approved official pages. Optional Diffbot extraction became a fallback for selected difficult documents, retaining source identity for the application’s own extraction and review.

The integration required explicit enablement and a separate daily allowance, with at most one fallback call per research job and no automatic retry. Access denials and rejected redirects were not routed around. Successful extraction still did not prove every PDF table or hidden section had been captured.

Shared source caching reduced repeat reading. But it was not a complete fact graph with automatic source-to-guide invalidation. Detecting changes, tracing affected claims, and re-reviewing dependent guides remained future work.

10 / MAKE THE WORK VISIBLE

Research should feel active without pretending to be certain.

The waiting form became dedicated guide pages with visible stages: checking saved research, researching sources, organizing findings, and preparing a guide. Blue icons clarified tools and sections; spinners stopped on completion or error. Responsive review caught a homepage section needing centered content, balanced cards, and mobile spacing.

Headings included the profession and route, not just an arrow between states. Sources, dates, expandable checklists, and fee breakdowns gave results structure. Explanatory privacy copy moved into the policy. The goal was a useful next step with visible conditions, not either a wall of warnings or unjustified certainty.

11 / RESULTS AND RELEASE BOUNDARIES

Shipping was staged. Evidence needs the same discipline.

The chat reports these checkpoints. Totals belong to different revisions—and the checkout backend is a different repository. They are not additive or independently rerun for this note.

334 tests: checkout analytics parity promoted to staging.
230 tests: checkout-attempt model released to production; no live payment test.
364 tests: guide pages, progress, persistent storage, and sitemap behavior.
380 → 392 → 408 tests: Context research, structured facts, completeness checks, and four reported live route trials.
602 → 623 tests: expanded tools, saved-result fixes, icons, spinners, and responsive improvements.

The final chat message records develop-to-staging promotion, passing checks, and verification of homepage layout, icons, saved guides, and sitemap behavior. LLM Context and Diffbot fallback were enabled there. Production remained unchanged for the website/tool rollout.

No load benchmark, conversion lift, SEO ranking gain, comprehensive regulatory validation, or production tool launch is established. A renewal trial still had partial coverage and unconfirmed fields. Those limitations belong beside the success criteria.

12 / WHAT REMAINS TO PROVE

The next improvement is not simply a bigger prompt.

The strongest next steps are more human-reviewed routes, explicit coverage and incorrect-claim evaluation, source-change dependency tracking, storage recovery checks, and measured cost and latency. Production promotion needs its own acceptance checks. Existing customer duplicates need a separate migration, and confirmed-payment analytics needs a deliberate implementation.

The reusable lesson: preserve business contracts, separate identities from attempts, save evidence before interpretation, model applicability, reuse research, and publish only what the system can support.

Read the shared build record for decisions, corrections, and releases. This article excludes private account identifiers, configuration values, customer data, and repository code.