Skip to content

About

I work where operations meets architecture.

I'm Janna Wong, a remote AI Automation & Systems Architect working with teams globally. I design and build the technical operating layer behind growing teams: automations, AI workflows, APIs, cloud-backed tools, CRM systems, dashboards, databases, and internal applications.

My advantage is that I approach technology from the operating workflow. I care about what people are doing manually, where information breaks, what should be automated, what should remain a human decision, how the system fails, and whether another person can maintain it after handover.

Janna Wong

AI Automation & Systems Architect

Technical systems partner for remote and growing teams.

Focus
AI · automation · systems architecture
Builds
Workflows · APIs · cloud · internal tools
Delivery
Async-first · documented · remote
Certified
18 Anthropic credentials
Base
Remote · Global
Async-first · open to selected workView credentials →

Principles

How I think about systems

The value is not knowing the most tools. It is knowing what should exist, which layer should own it, and how to make it reliable enough for a team to trust.

01

Structure before automation

Automating a messy process just moves the mess faster. I clean the data model, ownership, statuses, and decision points before automating the workflow.

02

Architecture follows the problem

Sometimes the right answer is Make or Apps Script. Sometimes it is an API, database, cloud function, or custom Next.js tool. I do not force every problem into the same layer.

03

Design for failure, not demos

Rate limits, duplicate events, missing fields, stale credentials, permissions, retries, timeouts, and edge cases belong in the architecture conversation from the start.

04

Observability creates trust

A workflow that nobody can see or diagnose is fragile. I prefer logs, review queues, exception views, and alerts that make system behavior visible.

05

Documentation is infrastructure

Technical decisions, diagrams, runbooks, and walkthroughs are part of the system. If context only exists in my head or in meetings, the handover is incomplete.

06

Async should increase clarity

Written specs and recorded walkthroughs create reusable context. Meetings are useful for selected technical decisions, but they should not be the database for project knowledge.

Across the stack

The systems layer is bigger than automation

Automation is one part of my work. I also operate across AI, APIs, cloud, databases, application development, CRM architecture, operational reporting, and technical direction.

Automation & orchestration

Make, n8n, Zapier, Google Apps Script, Power Automate, and custom workflow logic with validation, retries, and monitoring.

AI & agentic systems

OpenAI, Claude, AWS Bedrock, AI-assisted operational workflows, human review, structured prompts, and agentic patterns where they make sense.

APIs & integration engineering

REST APIs, webhooks, HTTP, JSON, OAuth, Postman, rate-limit handling, batching, retries, and direct system-to-system data movement.

Cloud & infrastructure

Google Cloud Platform, AWS, Cloudflare, Vercel, Render, serverless functions, deployment, DNS/edge concerns, and managed service architecture.

Data & backend

Supabase, PostgreSQL, Airtable, Google Sheets, Python, Node.js, and structured data layers that support reliable operational workflows.

Internal tools

Next.js, React, TypeScript, Vue, Tailwind, admin dashboards, operational UI, and focused applications when spreadsheets stop being enough.

CRM & business systems

Zoho CRM, GoHighLevel, HubSpot-style workflows, ClickUp, Notion, Slack, Google Workspace, lifecycle logic, and operational handoffs.

Technical direction

Systems audits, dependency mapping, architecture tradeoffs, implementation roadmaps, technical priorities, and ongoing fractional systems ownership.

Working model

Clear context without meeting-heavy overhead

Async work is not low communication. It is communication that stays documented, reviewable, and useful after the conversation ends.

Async-first by default

Written requirements, architecture diagrams, Loom walkthroughs, documented decisions, and structured updates are the main source of alignment. Meetings are used when a live technical discussion is genuinely more efficient.

Built for distributed teams

I work remotely with international teams without requiring constant synchronous overlap. Important context stays written, searchable, and reusable across time zones.

Hands-on plus architectural

I can inspect the workflow, choose the technical approach, implement the system, troubleshoot production behavior, and document what the next maintainer needs to know.

Have a system that has outgrown the way it was built?

Send me the workflow and what is not working. I'll review the context asynchronously and help determine what the next technical layer should be.