DWL
Back to selected work
Website operationsActive buildContent requestsPublishing reviewClient messages

Case study

Alpinix

A private website-operations workspace for teams managing client and business sites.

Alpinix brings content requests, publishing review, client messages, site health checks, role-based access, analytics brief, and launch/recovery notes into one controlled workspace.

Snapshot

Role
Founder / Product + Full-Stack
Stack / tools
Next.js / Payload CMS / PostgreSQL / Docker / Cloudflare / Resend
Timeline / status
Current / Active build
Core users
Website operators, client teams, and business owners responsible for live sites.
Problem class
Website operations, review state, access control, and launch recovery.
Location
New York, New York

Problem

Website operations often split across CMS screens, inboxes, analytics tabs, launch notes, and status tools. That makes routine updates feel fragile and makes recovery work harder to trust.

It matters because the user is making an operational decision with incomplete context: Teams and operators responsible for keeping client or business sites current, reviewed, and ready to recover when something breaks.

Product decision

The product judgment is to treat a website as an operating surface, not a brochure or a pile of disconnected admin tools. The workspace starts from the work an operator has to trust: what changed, who asked for it, what is healthy, and how to recover.

  • Kept the product centered on website operations: content requests, publishing review, client messages, site health checks, analytics brief, and launch/recovery notes.
  • Made status and audit history first-class so a team can see what changed, what needs attention, and what should happen next.
  • Separated public brand pages from the private control plane so the marketing surface does not dilute the operator workspace.

What I did not build or claim

  • Not positioned as a fintech aggregator or finance dashboard.
  • Not a generic CMS replacement that hides review, access, and recovery work.
  • Not claiming broad agency-scale automation before the core operator workflow is proven.

System / workflow

  1. 01

    Intake

    Content requests and client messages enter one workspace instead of living only in email threads or chat history.

  2. 02

    Review

    Publishing review, roles, and audit surfaces make the next change visible before it reaches a live site.

  3. 03

    Monitor

    Health checks and analytics briefs give operators a compact read on whether the site needs attention.

  4. 04

    Recover

    Launch and recovery notes keep rollback context close to the release history.

Interface mapWebsite operations map
Modules
  • Requests
  • Publishing review
  • Inbox
  • Health
  • Launch / recovery
Workflow
  1. Intake
    content requests / client messages
  2. Operate
    site health / analytics brief
  3. Recover
    launch notes / rollback notes

Prototype flow

A compact model of how a site request becomes reviewed work, a published change, and recoverable operating context.

Operator handoff
  1. 01IntakeRequests + inbox

    Content asks and client messages are captured as operational work instead of scattered notes.

    • source
    • owner
    • priority
  2. 02ReviewPublishing queue

    The next change is checked against role, status, and audit context before it reaches the site.

    • draft
    • reviewer
    • risk
  3. 03PublishRelease note

    Approved work moves into a visible launch record so the team knows what changed.

    • approved
    • scheduled
    • shipped
  4. 04MonitorHealth brief

    Health and analytics views give the operator a short read on whether the site needs attention.

    • status
    • traffic
    • alerts
  5. 05RecoverRecovery log

    Launch and rollback context stay nearby so recovery is a prepared workflow, not a scramble.

    • rollback
    • incident
    • owner
Modules
  • Requests

    Content and client asks enter one work queue.

  • Publishing review

    Changes pass through review before release.

  • Inbox

    Messages stay attached to site operations.

  • Health

    Status and analytics flag what needs attention.

  • Launch / recovery

    Release notes keep rollback context close.

Readout

The prototype shows Alpinix as a website-operations control plane, not a fintech aggregation product.

What shipped / what exists

  • A scoped operations workspace for content requests, publishing review, client messages, site health checks, analytics brief, launch notes, and recovery notes.
  • Role-based access surfaces for workspace members, people management, review queues, settings, and operational audit views.
  • Public positioning, trust pages, and an internal app shell that treats client-site work as an operating system rather than a generic CMS.

Architecture notes

  • Next.js App Router platform with Payload CMS mounted inside the app.
  • PostgreSQL-backed workspace, content, media, leads, health, analytics, task, audit, incident, and launch/recovery collections.
  • Docker-oriented self-hosting path with Cloudflare, Coolify, Resend, R2 media storage, and provider-proof scripts where configured.

Evidence / proof

Open live siteBack to work

Live public site plus private workspace surfaces for requests, review, inbox, health, analytics, launch, and recovery work.

  • Live public site at alpinix.co.
  • Implemented protected app surfaces for work queue, inbox, requests, incidents, audit, settings, content editing, forms, leads, media, sites, analytics, and status.
  • Repo includes dry-run-first operator scripts for provider audits, handoff reports, release rollback, client stack verification, and site-health proof.

Constraints

  • Active build; no public usage, revenue, or customer-count claims.
  • Private workspace details are summarized without exposing client data or private repositories.

Visual artifact

No real project screenshots are tracked in this repository. The interface map is used as an honest structural proof panel, not as a screenshot or invented metric.

Next steps

  • Tighten the first-client onboarding path around fewer decisions and clearer readiness gates.
  • Make operations proofs easier to read from inside the app instead of relying on operator logs.
  • Improve the handoff between launch planning, release history, and recovery notes.

Interested in similar product work?

Reach out for internships, product work, or focused collaborations.

Contact DylanBack to selected work