Projects

01
Messaging infrastructure
Messaging infrastructure
Multi-channel delivery on a database-backed queue
Overview
A messaging system that owns the full lifecycle of outbound communication: audience import and normalisation, templating, multi-stage scheduling, channel routing across email and SMS, suppression enforcement, delivery reconciliation, and reporting. Built as a modular monolith with the send queue inside PostgreSQL, so there is no separate worker fleet or broker to operate.
Architecture
Scheduling is an atomic materialisation step: template, resolved recipients, and the selected provider are frozen into one send row per recipient per stage. A per-minute cron dispatcher claims work with SELECT FOR UPDATE SKIP LOCKED, re-checks global suppression at claim time, and routes through the adapter locked at schedule time, which makes delivery idempotent under retries and safe across concurrent invocations.
Email providers sit behind a formal adapter contract with a registry, so two providers are interchangeable at runtime. Inbound delivery events are verified against the publisher's signing certificate before they mutate state. SMS uses split credentials: a send-only key, a read-only reconciliation key, and a token used solely for webhook signature validation. Status webhooks are made exactly-once through receipt and tombstone tables.
Time is treated as a correctness problem: calendar dates are stored at UTC midnight, stage offsets are computed in UTC and projected into a fixed local send time with DST handled explicitly, and sends are confined to a daytime window. Retry policy, rate limits, and spend caps are persisted and enforced server-side.
Public surfaces are limited to tokenised tracked links and unsubscribe routes. A database-target guard refuses to seed or mutate anything that is not the named local database. Four architecture decision records document the queue, the cloud delivery path, the SMS channel, and the adapter rollout.
Roughly one line of test for every three lines of source, split into unit and real-database projects. CI runs lint, typecheck, unit and database tests against a Postgres service container, and a production build on every push, with pinned actions and least-privilege permissions.
Stack
Next.js 16 App Router, React 19, TypeScript
Prisma 7 on PostgreSQL, 23 models, 35 migrations
Amazon SES v2, SNS signature verification, secondary SMTP provider
Twilio with reconciliation and tombstoned receipts
S3 object storage, sharp, spreadsheet and CSV ingestion
Vercel with a per-minute cron dispatcher
Vitest unit and database projects, GitHub Actions
Multi-channel delivery on a database-backed queue
A scheduling and delivery platform for email and SMS with provider adapters, suppression, reconciliation, and reporting, run on a queue that lives inside PostgreSQL.
Next.js · Prisma · PostgreSQL · SES · Twilio
02
Operational platform
Operational platform
A dual-portal platform with hierarchical visibility
Overview
An operations platform with two faces. The internal portal manages users, hierarchy profiles, a configurable pipeline, tasks, generated documents, and financial calculations. The external portal gives a multi-level network of users a scoped, read-only view of the records they are entitled to see and the figures those records produce for them. Every authorisation decision runs through one server-only data-access layer.
Architecture
Three roles are resolved in a cached, server-only data-access layer that is the single authorisation boundary; the edge proxy is only an optimistic redirect. Stale JWTs whose user row no longer exists are treated as signed out, which closes the classic long-lived-token gap.
Visibility is a hierarchy resolver rather than an ownership flag: a user may see a record only when it belongs to a profile they are a member of and their position order is at or above the originating user's, with pending and archived memberships excluded. The same resolver drives the financial estimates, so the numbers a user sees can never disagree with what they are allowed to view.
The pipeline is a configurable state machine backed by stage and task templates that expand into per-record stages and checklists, with policy-controlled reversal and reordering. Calculations use tiered rates and are written as immutable snapshots so historical results survive later rate changes. Activity and admin audit logs record every consequential mutation, and typed notifications fan out from them.
Release engineering is part of the product. A guarded pre-production environment is rebuilt from main in a temporary worktree and synchronised by a workflow that applies pending migrations plus idempotent fixtures and refuses any host that is not pre-prod or localhost. Production writes require an environment variable equal to the exact database hostname, and every database script must go through the guarded client.
Documents are generated server-side with pdf-lib and stored in signed blob storage; invitation links carry QR codes; rich text is sanitised on the way in. Verification runs unit suites, including a react-server-conditions suite for server-only modules, plus typecheck with no database required.
Stack
Next.js 16 App Router, React 19, Tailwind 4, Zod
Prisma 7 on PostgreSQL, 27 models
Auth.js v5 credentials with a server-only DAL
pdf-lib, QR generation, sanitised rich text
Vercel Blob with signed downloads, transactional email
Guarded pre-prod pipeline on GitHub Actions
Node test runner via tsx, react-server test conditions
A dual-portal platform with hierarchical visibility
One codebase, two portals: an internal side that runs records through a configurable eleven-stage pipeline, and an external side that shows each user only the slice of a tree-shaped hierarchy they belong to.
Next.js · Prisma · Auth.js · State machine · Guarded releases
03
Financial systems
Financial systems
A financial operations suite, rebuilt for many users
Overview
An internal suite for financial reporting and file processing that migrated a set of analyst scripts and a single-user tool into a multi-user application with real authentication, role and company scoping, persistent configuration, and a hardened deployment. The calculation core stayed a pure Python library; the web layer wraps it rather than duplicating it.
Architecture
FastAPI with Jinja2 templates and HTMX partials keeps the interface server-rendered and fast without a client framework. SQLAlchemy 2 models and Alembic migrations run against PostgreSQL in deployment and fall back to SQLite for local work. Sessions are signed cookies with revocable per-device records and a transparent upgrade path for legacy cookies.
Authorisation is company-aware: every report group and feature maps to the set of companies allowed to use it, with per-user feature toggles on top. A dedicated database-safety module performs operation-specific checks for runtime connections, migrations, seeds, and admin creation, so a non-local target must be named together with the exact operation before anything runs.
Cloud file storage is integrated for per-tool import and export folders. Refresh tokens are encrypted at rest with a dedicated AES-256-GCM key that is deliberately separate from the session secret; access tokens live only for the request. OAuth callbacks are tested for redaction, and CSRF, upload validation, and security headers are their own modules with their own tests.
The column mapper learns: manual mappings persist as shared synonyms and auto-match on future uploads, replacing a read-only lookup sheet. Saved groupings, favourites, and configurations are stored in the database so they survive redeploys.
The heavy lifting is pandas over spreadsheets. The repository ships a multi-stage Docker image and a platform deployment manifest; the verification gate runs the full suite against a temporary SQLite database with operational credentials stripped.
Stack
Python 3.11, FastAPI, Jinja2, HTMX, Tailwind
SQLAlchemy 2, Alembic, PostgreSQL with SQLite fallback
bcrypt, signed cookie sessions, CSRF module
Cloud storage API, OAuth, AES-256-GCM token vault
pandas, openpyxl, xlsxwriter
Multi-stage Docker image, GitHub Actions verification
Twenty-two test modules across RBAC, crypto, and safety
A financial operations suite, rebuilt for many users
A set of single-user analysis scripts became a permissioned, server-rendered web suite with company-scoped access, a learning column mapper, encrypted third-party integrations, and hardened deployment.
FastAPI · HTMX · SQLAlchemy · Alembic · pandas · Docker
04
Research tooling
Research tooling
A multi-tenant analysis workspace over a metered API
Overview
A research product in which each account is its own tenant; workspaces hold searches, analyses, and qualified results with frozen evidence. The statistics are conservative by design, API quota is metered locally before the provider would refuse a call, and the language model is confined to restating pre-computed figures.
Architecture
Convex serves as database, function layer, and HTTP endpoint host, deployed in lock-step with the Next.js build. Tenancy is enforced in the data layer: every row carries an owner id and every query filters on it, with the migration path to organisation-level sharing documented rather than improvised.
Third-party credentials are encrypted with AES-256-GCM in Node-runtime actions and never returned to the browser. Two daily quota meters per key reset on the provider's clock and store method-level receipts per operation; a separate meter rate-limits the language model.
Benchmarking uses mature records only, medians rather than means, a 25th-percentile floor, a MAD-based consistency score, and a trend that declines to speak below a minimum sample. One shared statistics module feeds both the workspace and the printable report, so the two can never disagree.
Prompt injection is treated as a security boundary: third-party text is fenced and labelled untrusted, only aggregates are ever sent, and the model is forbidden from calculating. Append-only snapshots are captured at zero marginal quota; qualified evidence is frozen immutably; analysis is cached for twenty-four hours with explicit manual refresh.
Stack
Next.js 16, React 19, Tailwind 4
Convex, 20 tables, Clerk with a Convex JWT template
Batched third-party API enrichment with local quota meters
Cloud monitoring for quota, Gemini for summaries
AES-256-GCM credential vault in Node actions
Vitest, Testing Library
A multi-tenant analysis workspace over a metered API
A workspace where every account is its own tenant, third-party quota is metered locally before the provider would refuse a call, and a language model is confined to restating pre-computed statistics.
Next.js · Convex · Clerk · Rate-limited APIs · LLM guardrails
05
Discovery & architecture
Discovery & architecture
Architecture before construction
Overview
Consulting work that precedes code. Roughly three thousand lines of specification prose across a proposal, discovery findings, a software requirements specification, an architecture document, integration research, a mobile launch plan, and milestone and execution plans, rendered to a set of client PDFs by a scripted pipeline so every revision is reproducible.
Architecture
The proposed system is a modular monolith with explicit trust boundaries and modules for identity and access, tenancy, consent, data ingestion, scoring, period close, and audit. The data model states its invariants and precision rules up front, and tenant isolation is specified as defence in depth rather than a single filter.
Ingestion from mobile and device platforms is designed around normalised facts, deduplication, and late-arriving data, with an idempotency-keyed scoring engine and transactional period close with export guarantees. Mobile architecture covers platform health-data permissions and sync semantics.
The requirements document uses formal language with evidence labels tying each requirement to its source, and per-entity state models. The testing strategy includes property-based tests for the scoring rules.
The document toolchain drives headless Chromium print-to-PDF with embedded fonts and a shared print stylesheet, emits eleven deliverables plus a merged pack, and keeps extracted text and per-page renders for fact-checking the generated output.
Stack
Discovery, SRS, and architecture authorship
Modular monolith and tenant-isolation design
Webhook ingestion, idempotent scoring, period-close transactions
Mobile health-data integration research
Headless-Chromium PDF pipeline with validation renders
Architecture before construction
A complete pre-build pack for a multi-tenant scoring platform: discovery, formal requirements, system architecture, integration research, and a staged execution plan, produced by a reproducible document pipeline.
SRS · Modular monolith · Tenant isolation · Mobile data · PDF toolchain
06
hesham.lol
hesham.lol
One codebase, four hosts, and a VPN control plane
Overview
A deliberately small system that still exercises the full stack: hostname routing onto App Router prefixes, signed admin sessions with version-based revocation, rate-limited public mutations, a content security policy on every route, enforced coverage and accessibility gates, and an out-of-band VPN control plane that never sees a private key.
Architecture
A static host registry maps each public hostname to an internal route prefix; unregistered hosts return 404 rather than leaking another system, and canonical redirects apply only in production so previews stay navigable. Server Components read through cached adapters and Server Actions are the only browser-facing mutation boundary.
Admin sessions are signed HttpOnly cookies carrying a session-version claim, so a password change revokes every existing session. Every privileged Convex function verifies a server secret. Login and public mutations use per-client and global rate limits keyed on HMAC fingerprints; raw client addresses are never stored.
The VPN agent is standard-library Python running as a restricted systemd service with outbound HTTPS only. It polls a command queue and reports server state; its credential can only report and fetch commands. Client keys are generated in the browser, so no private key enters the database. Addresses are reserved transactionally, applies are idempotent and reconciled after lost acknowledgements, and revocation cancels pending additions before removing the peer.
Quality gates run lint, typecheck, coverage thresholds, a production audit, the build, Playwright on desktop and mobile Chromium with axe accessibility checks, overflow detection, and security-header assertions, and a Lighthouse budget.
Stack
Next.js 16, React 19, Convex with crons and HTTP actions
jose-signed sessions, HMAC client fingerprints, CSP
Vercel hosting with per-host routing
WireGuard on AWS, Python agent, systemd hardening
Vitest with coverage thresholds, Playwright, axe, Lighthouse
Visit
One codebase, four hosts, and a VPN control plane
This site: public and private surfaces on one Next.js and Convex codebase with per-host routing, plus a least-privilege agent that manages a WireGuard server from the internal dashboard.
Next.js · Convex · Multi-host routing · WireGuard · systemd
07
Concept
Concept
A site concept, argued from research
Overview
A research-backed prototype used to win the conversation before the build. The written research defines a brand and content engine, benchmarks the information architecture of a leading site in the same category, and lays out a phased plan for a CMS, video ingestion, applications with safeguarding workflow, ticketing, memberships, commerce, and sponsor tracking.
Architecture
The prototype is a Vite and React single-page application with client-side routing and static mock data, so the client can click through the proposed structure rather than read about it.
Every page carries a concept-data badge and the footer labels the build as a concept, so no one mistakes placeholder content for a live product. The phase-two integrations are scoped but deliberately left unbuilt until the commercial decision is made.
Stack
Vite, React 19, TypeScript, React Router
Static content model with generated visual assets
Research document and benchmark analysis
A site concept, argued from research
A pitch-stage concept for a sports organisation: brand system, content engine, a benchmark against a top-tier site, a recommended information architecture, and a phased roadmap, delivered as a working prototype.
Vite · React · Information architecture · Benchmark research

Projects

01
Messaging infrastructure
Messaging infrastructure
Multi-channel delivery on a database-backed queue
Overview
A messaging system that owns the full lifecycle of outbound communication: audience import and normalisation, templating, multi-stage scheduling, channel routing across email and SMS, suppression enforcement, delivery reconciliation, and reporting. Built as a modular monolith with the send queue inside PostgreSQL, so there is no separate worker fleet or broker to operate.
Architecture
Scheduling is an atomic materialisation step: template, resolved recipients, and the selected provider are frozen into one send row per recipient per stage. A per-minute cron dispatcher claims work with SELECT FOR UPDATE SKIP LOCKED, re-checks global suppression at claim time, and routes through the adapter locked at schedule time, which makes delivery idempotent under retries and safe across concurrent invocations.
Email providers sit behind a formal adapter contract with a registry, so two providers are interchangeable at runtime. Inbound delivery events are verified against the publisher's signing certificate before they mutate state. SMS uses split credentials: a send-only key, a read-only reconciliation key, and a token used solely for webhook signature validation. Status webhooks are made exactly-once through receipt and tombstone tables.
Time is treated as a correctness problem: calendar dates are stored at UTC midnight, stage offsets are computed in UTC and projected into a fixed local send time with DST handled explicitly, and sends are confined to a daytime window. Retry policy, rate limits, and spend caps are persisted and enforced server-side.
Public surfaces are limited to tokenised tracked links and unsubscribe routes. A database-target guard refuses to seed or mutate anything that is not the named local database. Four architecture decision records document the queue, the cloud delivery path, the SMS channel, and the adapter rollout.
Roughly one line of test for every three lines of source, split into unit and real-database projects. CI runs lint, typecheck, unit and database tests against a Postgres service container, and a production build on every push, with pinned actions and least-privilege permissions.
Stack
Next.js 16 App Router, React 19, TypeScript
Prisma 7 on PostgreSQL, 23 models, 35 migrations
Amazon SES v2, SNS signature verification, secondary SMTP provider
Twilio with reconciliation and tombstoned receipts
S3 object storage, sharp, spreadsheet and CSV ingestion
Vercel with a per-minute cron dispatcher
Vitest unit and database projects, GitHub Actions
Multi-channel delivery on a database-backed queue
A scheduling and delivery platform for email and SMS with provider adapters, suppression, reconciliation, and reporting, run on a queue that lives inside PostgreSQL.
Next.js · Prisma · PostgreSQL · SES · Twilio
02
Operational platform
Operational platform
A dual-portal platform with hierarchical visibility
Overview
An operations platform with two faces. The internal portal manages users, hierarchy profiles, a configurable pipeline, tasks, generated documents, and financial calculations. The external portal gives a multi-level network of users a scoped, read-only view of the records they are entitled to see and the figures those records produce for them. Every authorisation decision runs through one server-only data-access layer.
Architecture
Three roles are resolved in a cached, server-only data-access layer that is the single authorisation boundary; the edge proxy is only an optimistic redirect. Stale JWTs whose user row no longer exists are treated as signed out, which closes the classic long-lived-token gap.
Visibility is a hierarchy resolver rather than an ownership flag: a user may see a record only when it belongs to a profile they are a member of and their position order is at or above the originating user's, with pending and archived memberships excluded. The same resolver drives the financial estimates, so the numbers a user sees can never disagree with what they are allowed to view.
The pipeline is a configurable state machine backed by stage and task templates that expand into per-record stages and checklists, with policy-controlled reversal and reordering. Calculations use tiered rates and are written as immutable snapshots so historical results survive later rate changes. Activity and admin audit logs record every consequential mutation, and typed notifications fan out from them.
Release engineering is part of the product. A guarded pre-production environment is rebuilt from main in a temporary worktree and synchronised by a workflow that applies pending migrations plus idempotent fixtures and refuses any host that is not pre-prod or localhost. Production writes require an environment variable equal to the exact database hostname, and every database script must go through the guarded client.
Documents are generated server-side with pdf-lib and stored in signed blob storage; invitation links carry QR codes; rich text is sanitised on the way in. Verification runs unit suites, including a react-server-conditions suite for server-only modules, plus typecheck with no database required.
Stack
Next.js 16 App Router, React 19, Tailwind 4, Zod
Prisma 7 on PostgreSQL, 27 models
Auth.js v5 credentials with a server-only DAL
pdf-lib, QR generation, sanitised rich text
Vercel Blob with signed downloads, transactional email
Guarded pre-prod pipeline on GitHub Actions
Node test runner via tsx, react-server test conditions
A dual-portal platform with hierarchical visibility
One codebase, two portals: an internal side that runs records through a configurable eleven-stage pipeline, and an external side that shows each user only the slice of a tree-shaped hierarchy they belong to.
Next.js · Prisma · Auth.js · State machine · Guarded releases
03
Financial systems
Financial systems
A financial operations suite, rebuilt for many users
Overview
An internal suite for financial reporting and file processing that migrated a set of analyst scripts and a single-user tool into a multi-user application with real authentication, role and company scoping, persistent configuration, and a hardened deployment. The calculation core stayed a pure Python library; the web layer wraps it rather than duplicating it.
Architecture
FastAPI with Jinja2 templates and HTMX partials keeps the interface server-rendered and fast without a client framework. SQLAlchemy 2 models and Alembic migrations run against PostgreSQL in deployment and fall back to SQLite for local work. Sessions are signed cookies with revocable per-device records and a transparent upgrade path for legacy cookies.
Authorisation is company-aware: every report group and feature maps to the set of companies allowed to use it, with per-user feature toggles on top. A dedicated database-safety module performs operation-specific checks for runtime connections, migrations, seeds, and admin creation, so a non-local target must be named together with the exact operation before anything runs.
Cloud file storage is integrated for per-tool import and export folders. Refresh tokens are encrypted at rest with a dedicated AES-256-GCM key that is deliberately separate from the session secret; access tokens live only for the request. OAuth callbacks are tested for redaction, and CSRF, upload validation, and security headers are their own modules with their own tests.
The column mapper learns: manual mappings persist as shared synonyms and auto-match on future uploads, replacing a read-only lookup sheet. Saved groupings, favourites, and configurations are stored in the database so they survive redeploys.
The heavy lifting is pandas over spreadsheets. The repository ships a multi-stage Docker image and a platform deployment manifest; the verification gate runs the full suite against a temporary SQLite database with operational credentials stripped.
Stack
Python 3.11, FastAPI, Jinja2, HTMX, Tailwind
SQLAlchemy 2, Alembic, PostgreSQL with SQLite fallback
bcrypt, signed cookie sessions, CSRF module
Cloud storage API, OAuth, AES-256-GCM token vault
pandas, openpyxl, xlsxwriter
Multi-stage Docker image, GitHub Actions verification
Twenty-two test modules across RBAC, crypto, and safety
A financial operations suite, rebuilt for many users
A set of single-user analysis scripts became a permissioned, server-rendered web suite with company-scoped access, a learning column mapper, encrypted third-party integrations, and hardened deployment.
FastAPI · HTMX · SQLAlchemy · Alembic · pandas · Docker
04
Research tooling
Research tooling
A multi-tenant analysis workspace over a metered API
Overview
A research product in which each account is its own tenant; workspaces hold searches, analyses, and qualified results with frozen evidence. The statistics are conservative by design, API quota is metered locally before the provider would refuse a call, and the language model is confined to restating pre-computed figures.
Architecture
Convex serves as database, function layer, and HTTP endpoint host, deployed in lock-step with the Next.js build. Tenancy is enforced in the data layer: every row carries an owner id and every query filters on it, with the migration path to organisation-level sharing documented rather than improvised.
Third-party credentials are encrypted with AES-256-GCM in Node-runtime actions and never returned to the browser. Two daily quota meters per key reset on the provider's clock and store method-level receipts per operation; a separate meter rate-limits the language model.
Benchmarking uses mature records only, medians rather than means, a 25th-percentile floor, a MAD-based consistency score, and a trend that declines to speak below a minimum sample. One shared statistics module feeds both the workspace and the printable report, so the two can never disagree.
Prompt injection is treated as a security boundary: third-party text is fenced and labelled untrusted, only aggregates are ever sent, and the model is forbidden from calculating. Append-only snapshots are captured at zero marginal quota; qualified evidence is frozen immutably; analysis is cached for twenty-four hours with explicit manual refresh.
Stack
Next.js 16, React 19, Tailwind 4
Convex, 20 tables, Clerk with a Convex JWT template
Batched third-party API enrichment with local quota meters
Cloud monitoring for quota, Gemini for summaries
AES-256-GCM credential vault in Node actions
Vitest, Testing Library
A multi-tenant analysis workspace over a metered API
A workspace where every account is its own tenant, third-party quota is metered locally before the provider would refuse a call, and a language model is confined to restating pre-computed statistics.
Next.js · Convex · Clerk · Rate-limited APIs · LLM guardrails
05
Discovery & architecture
Discovery & architecture
Architecture before construction
Overview
Consulting work that precedes code. Roughly three thousand lines of specification prose across a proposal, discovery findings, a software requirements specification, an architecture document, integration research, a mobile launch plan, and milestone and execution plans, rendered to a set of client PDFs by a scripted pipeline so every revision is reproducible.
Architecture
The proposed system is a modular monolith with explicit trust boundaries and modules for identity and access, tenancy, consent, data ingestion, scoring, period close, and audit. The data model states its invariants and precision rules up front, and tenant isolation is specified as defence in depth rather than a single filter.
Ingestion from mobile and device platforms is designed around normalised facts, deduplication, and late-arriving data, with an idempotency-keyed scoring engine and transactional period close with export guarantees. Mobile architecture covers platform health-data permissions and sync semantics.
The requirements document uses formal language with evidence labels tying each requirement to its source, and per-entity state models. The testing strategy includes property-based tests for the scoring rules.
The document toolchain drives headless Chromium print-to-PDF with embedded fonts and a shared print stylesheet, emits eleven deliverables plus a merged pack, and keeps extracted text and per-page renders for fact-checking the generated output.
Stack
Discovery, SRS, and architecture authorship
Modular monolith and tenant-isolation design
Webhook ingestion, idempotent scoring, period-close transactions
Mobile health-data integration research
Headless-Chromium PDF pipeline with validation renders
Architecture before construction
A complete pre-build pack for a multi-tenant scoring platform: discovery, formal requirements, system architecture, integration research, and a staged execution plan, produced by a reproducible document pipeline.
SRS · Modular monolith · Tenant isolation · Mobile data · PDF toolchain
06
hesham.lol
hesham.lol
One codebase, four hosts, and a VPN control plane
Overview
A deliberately small system that still exercises the full stack: hostname routing onto App Router prefixes, signed admin sessions with version-based revocation, rate-limited public mutations, a content security policy on every route, enforced coverage and accessibility gates, and an out-of-band VPN control plane that never sees a private key.
Architecture
A static host registry maps each public hostname to an internal route prefix; unregistered hosts return 404 rather than leaking another system, and canonical redirects apply only in production so previews stay navigable. Server Components read through cached adapters and Server Actions are the only browser-facing mutation boundary.
Admin sessions are signed HttpOnly cookies carrying a session-version claim, so a password change revokes every existing session. Every privileged Convex function verifies a server secret. Login and public mutations use per-client and global rate limits keyed on HMAC fingerprints; raw client addresses are never stored.
The VPN agent is standard-library Python running as a restricted systemd service with outbound HTTPS only. It polls a command queue and reports server state; its credential can only report and fetch commands. Client keys are generated in the browser, so no private key enters the database. Addresses are reserved transactionally, applies are idempotent and reconciled after lost acknowledgements, and revocation cancels pending additions before removing the peer.
Quality gates run lint, typecheck, coverage thresholds, a production audit, the build, Playwright on desktop and mobile Chromium with axe accessibility checks, overflow detection, and security-header assertions, and a Lighthouse budget.
Stack
Next.js 16, React 19, Convex with crons and HTTP actions
jose-signed sessions, HMAC client fingerprints, CSP
Vercel hosting with per-host routing
WireGuard on AWS, Python agent, systemd hardening
Vitest with coverage thresholds, Playwright, axe, Lighthouse
Visit
One codebase, four hosts, and a VPN control plane
This site: public and private surfaces on one Next.js and Convex codebase with per-host routing, plus a least-privilege agent that manages a WireGuard server from the internal dashboard.
Next.js · Convex · Multi-host routing · WireGuard · systemd
07
Concept
Concept
A site concept, argued from research
Overview
A research-backed prototype used to win the conversation before the build. The written research defines a brand and content engine, benchmarks the information architecture of a leading site in the same category, and lays out a phased plan for a CMS, video ingestion, applications with safeguarding workflow, ticketing, memberships, commerce, and sponsor tracking.
Architecture
The prototype is a Vite and React single-page application with client-side routing and static mock data, so the client can click through the proposed structure rather than read about it.
Every page carries a concept-data badge and the footer labels the build as a concept, so no one mistakes placeholder content for a live product. The phase-two integrations are scoped but deliberately left unbuilt until the commercial decision is made.
Stack
Vite, React 19, TypeScript, React Router
Static content model with generated visual assets
Research document and benchmark analysis
A site concept, argued from research
A pitch-stage concept for a sports organisation: brand system, content engine, a benchmark against a top-tier site, a recommended information architecture, and a phased roadmap, delivered as a working prototype.
Vite · React · Information architecture · Benchmark research

Projects

Multi-channel delivery on a database-backed queue

A dual-portal platform with hierarchical visibility

A financial operations suite, rebuilt for many users

A multi-tenant analysis workspace over a metered API

Architecture before construction

One codebase, four hosts, and a VPN control plane

A site concept, argued from research

Projects

Multi-channel delivery on a database-backed queue

A dual-portal platform with hierarchical visibility

A financial operations suite, rebuilt for many users

A multi-tenant analysis workspace over a metered API

Architecture before construction

One codebase, four hosts, and a VPN control plane

A site concept, argued from research