Selected work / 05

Argent Matchmaking

A human-led matchmaking concept spanning a discreet public experience, member mobile surface, matchmaker workspace, shared design system, and the beginnings of a production-minded platform.

My role: Product engineer and system designer
Scope: Product strategy, interface art direction, platform architecture, and implementation
Stage: Synthetic concept prototype
Core technologies: Next.js · TypeScript · Fastify · Flutter

Argent Matchmaking product system showing design tokens, public web, mobile introduction, and matchmaker review workspace

Case study

Designing for judgment, discretion, and human review.

The problem

A private matchmaking service cannot borrow the mechanics or tone of a swipe-based marketplace. Applicants, members, matchmakers, consent decisions, and introductions each need a different surface, while sensitive policy and data must stay out of public and mobile bundles.

What I built

I shaped the product strategy and built the current synthetic concept alongside a multi-app foundation: public and staff web surfaces, a Flutter mobile client, Fastify API, worker, generated contracts, server-only domain and database packages, Docker verification, and a shared cross-platform design system.

Key decisions

01Human-led by design
The interface centers matchmaker judgment, consent, provenance, and review state instead of presenting an autonomous matching score as the product.
02Separate public and staff surfaces
The operational workspace is a distinct application boundary rather than an admin route hidden inside the public experience.
03Share contracts and tokens, not sensitive policy
Generated clients and semantic design tokens can cross web and mobile, while authorization rules, matchmaking policy, and provider credentials remain server-only.

Inside the work / 04 views

A private-service world across every surface

The concept pairs a restrained Nocturne interface system with campaign imagery designed for discretion, intimacy, and a high-touch service rather than mass-market dating mechanics.

Argent campaign image of a couple overlooking the coast at sunset — 02
**Relationship direction**
The selected campaign direction presents mature chemistry and privacy without drifting into generic dating-app imagery.

Argent coastal residence image used for the private-service concept — 03
**Service environment**
A quiet coastal residence establishes the restrained, place-specific atmosphere behind the public introduction experience.

Argent gallery interior image with sea view and a sculptural branch arrangement — 04
**Nocturne image system**
Architectural imagery gives the brand room to feel considered and editorial while the interface remains disciplined and legible.

Technical view

Architecture

Private-service product foundation12 components · 16 connections

The current synthetic concept is split into public, staff, mobile, API, worker, contract, and server-only policy boundaries without implying a live matching service.

Cross-platform surfacesSynthetic experience layer

Service + contract boundaryVersioned and generated

Server-only foundationNo real profiles or matching

Next.js
Public experience
Editorial concept and application story
Next.js · separate app
Staff workspace
Separate matchmaker review surface
Flutter
Member mobile
Cross-platform introduction concept
OpenAPI · TypeScript · Dart
Generated clients
One contract for web and mobile
Fastify
HTTP service
Versioned workflow boundary
Web + Flutter tokens
Nocturne system
Shared semantic tokens and adapters
Framework-light TypeScript
Domain policy
Server-only rules and calculations
Node.js worker
Background worker
Process and delivery foundation
PostgreSQL 18
Data foundation
Migrations and synthetic fixtures
Redis 8
Queue foundation
Local background coordination
Docker Compose
Isolated runtime
Five-service smoke verification
GitHub Actions
Supply-chain gates
Secrets, scanning, SBOM, containers

surfaceservicedataaiintegrationcontrolruntime

Read system connections

Public experience → Generated clients
Staff workspace → Generated clients
Member mobile → Generated clients
Nocturne system → Public experience
Nocturne system → Staff workspace
Nocturne system → Member mobile
Generated clients → HTTP service
HTTP service → Domain policy
HTTP service → Data foundation
HTTP service → Queue foundation
Queue foundation ↔ Background worker
Background worker → Data foundation
Isolated runtime → HTTP service
Isolated runtime → Background worker
Isolated runtime → Data foundation
Supply-chain gates → Isolated runtimeverify

Built so far

Organizes public web, separate staff web, Flutter mobile, API, worker, domain policy, database, generated contracts, and design-system packages in one monorepo.
Keeps generated client contracts and design tokens cross-platform while reserving authorization rules, sensitive policy, and provider credentials for server-only packages.
Includes Docker smoke verification across five local services plus quality, secret, dependency, code-scanning, container-security, and SBOM checks in CI.

Where it stands

The current screen uses synthetic content and has no accounts, submissions, stored profiles, real matching, or production workflow.
The broader architecture is a reviewed direction and implementation foundation; provider selection, production identity, real data, and launch remain separate work.

Repository

Continue exploring

Next case study

View all selected work

AI agents / Knowledge systems

Jolene AI

Deployed career-wide public delegate

Open case study