Aurawave Studio Contract

Private Directory Platform

A confidential, production-facing directory platform built across data engineering, backend systems, product interfaces, media infrastructure, and release QA.

EngagementConfidential freelance client platform
RoleFull stack engineering, data pipeline, UI/UX
TimelineMarch — July 2026
StackNext.js, TypeScript, Neon/PostgreSQL, Python, Cloudflare

01 / Project at a Glance

A full product system, shown without the client surface.

I was hired by Aurawave Studio to turn inconsistent third-party directory records into a reliable product database and build the application around it. The client, industry, brand, domain, repository, and raw UI remain intentionally omitted.

Client need
Transform inconsistent directory data into a searchable, map-enabled product.
My ownership
Import pipeline, schema-facing APIs, accounts, search, maps, media, admin workflows, and UI/UX.
Delivery
First workable release reached in July 2026 after repeated workflow and edge-case checks.
Public boundary
Architecture and implementation patterns are sanitized; client-specific names and screenshots are excluded.

02 / Data Flow

From inconsistent source records to product-ready data.

The import process established a canonical data foundation before search, map, account, media, and administrative surfaces consumed the records.

  1. Source records

    Third-party directory pages and semi-structured fields.

  2. Python pipeline

    Scrape, parse, normalize, validate, and generate stable identifiers.

  3. Neon/PostgreSQL

    Canonical listings, relationships, coordinates, and lifecycle states.

  4. Server layer

    Typed repositories, services, rate limits, and Next.js route handlers.

  5. Product surfaces

    Search, maps, profiles, uploads, moderation, and admin review.

  • Normalize phones, addresses, hours, regions, and tags before insert.

  • Generate deterministic slugs with duplicate-safe fallbacks.

  • Backfill coordinates and repair malformed imported records through operational scripts.

  • Preserve correction and moderation paths instead of silently mutating production data.

03 / Sanitized Architecture

A relational model built for discovery, contribution, and oversight.

This portfolio-safe schema map is derived from the original ERD using generic names. It preserves the relationship patterns while removing the client vertical and domain vocabulary.

Sanitized entity relationship diagram for the private directory platformAccounts connect to entitlements and optional listing ownership. Taxonomy classifies listings. Listings connect to people and media, user-generated content, communities, and trust and safety workflows.Accountsaccountsaccount_profilesaccount_sessionsEntitlementsplansaccount_subscriptionsTaxonomy & filterscategoriescapabilitiesservice_typesListingslistingslisting_addresseslisting_hoursPeople & medialisting_entitiesentity_mediamedia_assetsUser contentreviewscommentsvotesCommunitiesgroupspostspost_commentsTrust & safetyreportsmoderation_actionsaudit_logs
  • Accounts own optional listings and carry profile, session, and entitlement state.
  • Listings remain canonical while taxonomy and join tables supply filterable attributes.
  • Media and contributions attach through explicit relationships instead of living inside listing rows.
  • Trust and safety preserve reports, moderation actions, and audit history around sensitive changes.

Canonical directory data

Listings, categories, addresses, hours, coordinates, filterable capabilities, services, and payment-style attributes remain normalized instead of collapsing into one record.

Accounts and contribution

Profiles and sessions connect to optional listing ownership, reviews, comments, votes, community posts, and saved activity.

Media lifecycle

Cloudflare-backed assets store ownership, dimensions, checksums, delivery references, and moderation status separately from the entities that use them.

Trust and operations

Reports, moderation actions, correction workflows, fraud signals, and audit logs give sensitive changes an inspectable lifecycle.

04 / Code Evidence

Two implementation patterns from the core risks.

These examples are rewritten from the real implementation to show the engineering approach without exposing client-specific names, data, or domain logic.

Normalizing Imported Directory Records

The import scripts cleaned inconsistent source data before inserting it into Neon, including phone normalization and duplicate-safe slug generation.

scripts/import_records.py (anonymized)
def normalize_phone(raw_phone: str | None) -> str | None:    if not raw_phone:        return None     digits = re.sub(r"\D", "", raw_phone)    if len(digits) == 11 and digits.startswith("1"):        digits = digits[1:]     return digits if len(digits) == 10 else None  def make_record_slug(name: str, city: str | None, region: str | None, used: set[str]) -> str:    base = slugify(" ".join(part for part in [name, city or "", region or ""] if part))    slug = base or "record"    counter = 2     while slug in used:        slug = f"{base}-{counter}"        counter += 1     used.add(slug)    return slug

Cloudflare Image Upload Guardrails

Image uploads were validated, hashed, uploaded to Cloudflare Images, and stored with moderation metadata instead of trusting the raw form upload.

src/lib/services/mediaUpload.ts (anonymized)
export async function uploadModeratedImage(params: UploadParams) {    const validated = await validateImageFile(params.fileEntry);    if (!validated) return null;     const decision = params.user.role === "admin"        ? null        : moderateImageUpload({            context: params.context,            mimeType: validated.file.type,            fileName: validated.file.name,            fileSizeBytes: validated.fileSizeBytes,            caption: params.caption ?? null,        });     const image = await uploadImageToCloudflare({        file: validated.file,        creatorUserId: params.user.id,        metadata: { context: params.context, entityId: params.entityId },    });     return createMediaAsset({        uploaderUserId: params.user.id,        cloudflareImageId: image.id,        imageUrl: getCloudflareDeliveryUrl(image.id, "public"),        checksumSha256: validated.checksumSha256,        moderationStatus: decision?.mediaStatus ?? "pending",    });}

05 / Testing & Release

Test continuously across implementation and release.

Testing ran alongside implementation rather than waiting for a final QA pass. Each feature was checked against expected use, edge cases, and invalid inputs, then exercised end to end through the same workflows a user would follow. Issues found during those walkthroughs were fixed, released, and retested until the application behaved reliably.

Data integrity

Imported duplicates, malformed addresses, missing coordinates, slug conflicts, primary media, and repaired Cloudflare URLs.

Product workflows

Search and filtering, map behavior, detail pages, accounts, verification and reset paths, profiles, and responsive navigation.

Operational paths

Upload validation, moderation states, correction flows, admin review queues, rate limits, and production-facing edge cases.

Approach
Manual end-to-end workflow and edge-case verification
Release point
First workable release in July 2026

06 / Outcome

A cohesive product built across the full stack.

The first workable release connected the data foundation, backend services, product workflows, media pipeline, and operational tooling into one system. Together, these pieces support the full path from imported records to production-facing user and administrative workflows.

  1. Turned inconsistent imported records into a searchable, geocoded, media-enabled relational data foundation.

  2. Connected backend APIs, accounts, map UX, uploads, moderation, repair tooling, and interface design into one product.

  3. Reached a public release in July 2026 and has since been crawled by Google, Bing, and Yandex while the client builds its audience through social promotion and planned advertising.