●System Online/Portfolio

Ting Tze Jian, Raymond
SENIOR SOFTWARE DEVELOPER
Three years shipping CMS-driven web platforms end-to-end, frontend, backend, infrastructure, deployment. I take work from requirement to running production, and stay on the pager when it gets there.
Focus
Full-stack · Infra
Stack
React · .NET · Linux
Cloud
Azure · AWS · Fly.io
Status
Open to conversations

The stack I'm responsible for, top to bottom.

A senior developer is not just a frontend or backend engineer. Each layer below is part of my day-to-day delivery — hover to explore.

Frontend

Render the truth, fast.

React and Next.js apps with server-side rendering and ISR for SEO and CDN-level scalability. Typed API clients, content-driven pages, accessible markup — interfaces that survive contact with real users and real editors.

  • React
  • Next.js 14
  • TypeScript
  • Tailwind
  • Angular

Render the truth, fast.

React and Next.js apps with server-side rendering and ISR for SEO and CDN-level scalability. Typed API clients, content-driven pages, accessible markup — interfaces that survive contact with real users and real editors.

  • React
  • Next.js 14
  • TypeScript
  • Tailwind
  • Angular

From commit to live in one push.

Every change flows through the same automated pipeline — type-checked, built, and deployed without manual steps. This is what shipping reproducibly looks like.

</>
Code
Local dev
GIT
GitHub
Remote
//CI
Actions
Check suite
▲
Next.js
SSG export
◆
Netlify
Deploy
●
Live
rdevting.com
Stack
Next.js 16React 18TypeScript 5CSSApp Router
Pipeline
GitHub ActionsNetlify CDNNode 24npm ci
Output
Static ExportSSGEdge Cache

The systems beneath the work.

Three diagrams that show how I architect, ship, and run software in production — from headless CMS to container lifecycle.

Headless CMS Architecture
EDITORSnon-technicalDIRECTUS CMScollectionssingletonsrelationsPOSTGRESQLsource of truthTYPED API CLIENTcodegenzod schemasSSR fetchNEXT.JS 14SSR + ISRCDN edgeSEO ready
CI/CD Pipeline
PUSHmainBUILDdockerTESTjest · junitPUSH IMGregistryDEPLOYfly.io · azure
Container Lifecycle
SOURCEgit · mainDOCKERFILEmulti-stageIMAGEtagged · :shaREGISTRYghcr · ecrFLY.IOcontainer · prodAZURE VMcontainer · stageLINUX HOSTredhat · debian

I own the work end-to-end.

A senior developer writes code, but the job is wider than that. The work starts before the first commit and continues long after launch.

  1. Requirement

    Sit with stakeholders. Define scope. Translate ambiguous business goals into testable acceptance criteria. Make sure the right thing is being built before a single line of code goes in.

    • stakeholder comms
    • scope
    • acceptance criteria

  2. Planning

    Break down the work. Estimate. Sequence dependencies across multiple concurrent projects. Architecture decisions made up front — schema, hosting target, CMS shape, CI/CD strategy.

    • estimation
    • architecture
    • task delegation

  3. Development

    Build. Frontend, backend, database, integrations — wherever the work lives. Code reviews, typed contracts, schema versioning with Liquibase, tests on the surfaces that matter.

    • react / next
    • .net 8
    • spring boot
    • postgres

  4. Deployment

    Containerize. Wire CI/CD. Provision infrastructure on Azure or AWS. Deploy to RedHat, Debian, IIS, or Fly.io. Verify the third deploy of the day is as boring as the first.

    • docker
    • github actions
    • azure / aws

  5. Maintenance

    Post-launch support. Monitor. Triage. Keep production stable across hosting environments. The system is not done when it builds — it is done when it runs reliably for real users.

    • stability
    • troubleshooting
    • on-call

  6. Iteration

    Feedback loops back into requirement. New scope, new releases, schema migrations, careful refactors. Ownership does not end at launch — it ends when the project does.

    • feedback
    • refactor
    • release cadence

Projects, framed as systems.

Not screenshots. Each project below is a problem statement, an architecture decision, the stack that delivered it, and the pipeline that ships it.

Headless CMS Portal Prototype

A content-driven public portal: server-rendered, CDN-cached, editor-friendly. Built to prove that headless CMS architecture can match the SEO and scale of monolithic platforms.

Problem

Public portals need fast, SEO-friendly pages that non-technical editors can update — without redeploying. Most CMS-driven sites trade one for the other.

Architecture Decision

Headless: Directus owns the schema and editor experience; Next.js renders pages with SSR + ISR for SEO and CDN-level scalability. A typed API client keeps the boundary safe.

Tech Stack

  • Next.js 14
  • TypeScript
  • Directus
  • PostgreSQL
  • Tailwind
  • Jest
  • Docker
  • SSR + ISR

Deployment Flow

  1. PUSH
  2. BUILD
  3. TEST
  4. IMAGE
  5. DEPLOY

Personal Finance Dashboard

A full-stack finance dashboard with Google SSO, real-time budget tracking, savings goals, and spending analytics — built to exercise the full delivery pipeline solo.

Problem

Existing finance apps either own your data or limit categorization. The goal: a self-hosted dashboard with auth, charts, and CI/CD that I could ship and forget.

Architecture Decision

React/TypeScript frontend, ASP.NET Core 8 REST API, EF Core 8 over PostgreSQL. Containerized end-to-end. Deployed to Fly.io via GitHub Actions — a real production pipeline at hobby scale.

Tech Stack

  • React
  • TypeScript
  • ASP.NET Core 8
  • EF Core 8
  • PostgreSQL
  • Docker
  • Fly.io
  • GitHub Actions
  • Google OAuth

Deployment Flow

  1. COMMIT
  2. CI
  3. BUILD
  4. IMAGE
  5. FLY.IO

What three years of shipping taught me.

Five operating principles I keep returning to — the ones that made the difference between code that compiled and software that stayed online.

  1. The system is not done until it runs.

    Build, deploy, and monitor are the same job. A green CI badge is not delivery — sustained production is.

  2. Editors out of the codebase.

    Content models exist so the people closest to the words can ship without engineering. Architect for that, not against it.

  3. Reproducible or it didn’t happen.

    Containers, schema versioning, infrastructure as configuration. The third deploy of the week should be as boring as the first.

  4. Own the boundary.

    Frontend ↔ API ↔ database ↔ host. The most expensive bugs live between layers. A senior engineer reads the whole stack.

  5. Deliver, then communicate.

    Stakeholder trust comes from on-time releases and direct, unembellished updates. Both, every time.

Next: deeper into platform engineering, production reliability, and teams that ship.

Let's talk shipping.

Building a CMS-driven platform, modernising legacy infrastructure, or looking for a senior who can own end-to-end delivery? Reach me directly.

Download résumé (PDF)