Alec Stephens · Applied AI engineer · Co-founder, Stephens AI

Build portfolio.

Real users on every build, including what was broken, what I built, what the results were, and the engineering behind it on the back of the card.

Clinic knowledge base Of manager interruptions removed each year, estimated ~200 hrs/yr PTO + payroll system Of paper-slip admin gone, with 183 tests in the open 60 to 100 hrs/yr Invoice processing system To read and file a vendor bill on Claude via AWS Bedrock, HIPAA-compliant, inside the clinic's own account 0.9¢ / invoice AI Lab content + outbound systems Sent from a fleet grown from 2 to 10 domains in 3 weeks, with 2.2% human replies 4,349 emails Coaching practice AI system Triaged every day by agents that read one plain-English brain document 13 to 15 emails/day Construction company website Now referring us, off a 6-page rebuild in Japanese 1 industry board Curriculum generation system Of a curriculum team's manual work now handled by AI ~80% My own AI operating system Running the company I test everything on first 9 agents · 51 skills

Healthcare · optometry · Wichita Family VisionLive 2026-08-07

Clinic knowledge base

Front desk knowledge base for an eye clinic: six months of training turned into one search. Wichita Family Vision, an independent optometry practice in Wichita, Kansas.

~200hrs/yr of interruptions off the office manager's desk

Stack

Supabase
PostgreSQL with row-level security
Google OAuth
Vanilla JS PWA
Vercel
GitHub Actions
DOMPurify
Claude Code

The front desk knowledge base home screen: a search box, quick-pick chips, and the four decision tools — The home screen the front desk sees. Clinic logo blurred; everything else is the live app.

Compliance. Built for a HIPAA-covered clinic with zero patient data in it by design: protocols and prices only, sign-in locked to the clinic's domain, a business associate agreement in force with the practice.

My role. I built it: the content model from the clinic's front-desk documents, the 35 pages and 4 decision tools, in-app editing with revision history, and the tests. A second engineer ran the pre-merge security review and the deployment.

Open the build

How it's built

How it's built · Clinic knowledge baseLive 2026-08-07

Who uses it: The front desk and 2 office managers, daily since August 2026.
Architecture: Static PWA on Vercel reading page content, prices, and revisions from Supabase over the REST API. Editors are a Postgres table; RLS gives everyone read and 2 named emails write. Rendering sanitizes at read time, not only at save, so a REST write can never reach a reader unfiltered.
Where it runs: Vercel (app), Supabase free tier (content, auth, revisions), Google Workspace sign-in locked to the clinic's domain. Installed as a PWA on the front desk iPad and PCs.
Tests and evals: 21 regression tests plus a DOM-free sync-logic suite (31 assertions) covering restore, refresh, and the offline editor guard. Every test was written from a bug we actually hit.
Cost and latency: $0 a month to host. The clinic pays a small monthly retainer for the editing feature and a pass-through for the database tier.
Guardrails: A pre-merge security review caught 2 cross-site-scripting holes: page HTML was sanitized on save but not on render, and the editor parsed pasted HTML into the live DOM before cleaning it. Both fixed by sanitizing at render, failing closed. Monthly JSON export is the backup because the free tier keeps none.
The tradeoff we chose: Why this way and not the other
We built a plain PWA with search instead of the AI assistant layer the first scope had. Search on 35 well-structured pages answers the front desk's question faster than a chat box, costs nothing to run, and never invents a rule. The assistant is on the roadmap only if search ever fails a real staff question.
Code: github.com/alecstephens3-stack/supabase-team-knowledge-base
The pattern, rebuilt without any clinic content: RLS, domain-gated auth, revision history, sanitizer, offline sync.

Open the build

Healthcare · optometry · Wichita Family VisionLive April 2026

PTO + payroll system

Time-off and payroll for an independent eye clinic: paper slips to a system that runs itself. Wichita Family Vision, an independent optometry practice in Wichita, Kansas.

60 to 100hrs/yr of admin time returned

Stack

Google Apps Script
Google Forms
Google Sheets
Google Calendar
Gmail
clasp
Node test runner

Diagram: one form feeds an Apps Script engine that writes the attendance sheet, shared calendar, approval email, balances, and payroll report — One form, one engine, five outputs.

Compliance. Employee data only, no patient data, kept entirely inside the clinic's own Google Workspace. Built under the same business associate agreement as the clinic's other systems.

My role. I built it: the engine, the accrual and date math, the migration, the payroll report, the tests, and the guides. A second engineer added the employee-management dialogs and audited the sheets.

Open the build

How it's built

How it's built · PTO + payroll systemLive April 2026

Who uses it: Every employee files from a phone; the office manager approves; the bookkeeper runs payroll from it. Live since April 2026.
Architecture: Form submit trigger into a bound Apps Script project of about 7,000 lines: validation, weekday and anniversary math, attendance-sheet writes, a calendar owned by a Workspace user the script runs as, approve and deny links served by a pinned web-app deployment, and a payroll builder on a time trigger.
Where it runs: Entirely inside the clinic's Google Workspace. No server, no SaaS bill, $0 a month.
Tests and evals: 183 regression assertions in the public repo, run with Node, no dependencies. Sections cover accrual routing, weekend-aware date math, partial days, recompute-on-write balance integrity, and the migration.
Cost and latency: $0 a month to run. Built at an hourly rate for the clinic.
Guardrails: The web app URL is read from a config sheet, never from the script API, because the API returns a hidden test deployment. Every change that touches the approve button rolls the pinned deployment; skipping that once put new code on form-submit and old code on approvals. Error emails go to me, action emails go to the manager, so a test can never land in her inbox.
The tradeoff we chose: Why this way and not the other
Apps Script over a hosted app. The clinic already paid for Google Workspace, the office manager lives in Sheets, and the data never leaves their account. A hosted app would have meant a login, a bill, and a vendor for a 26-person office. The cost of that choice is a deployment model with sharp edges, which the tests and the runbook now cover.
Code: github.com/alecstephens3-stack/apps-script-pto-payroll
Anniversary-aware period routing, recompute-on-write balances, no dependencies, 183 tests.

Open the build

Healthcare · optometry · HIPAA · Wichita Family VisionBedrock live 2026-09-16

Invoice processing system

Invoice filing for a clinic's bookkeeper: HIPAA-compliant on Claude via AWS Bedrock, at 0.9 cents an invoice. Wichita Family Vision, an independent optometry practice in Wichita, Kansas.

0.9¢ per invoice, 3.4 seconds a file, measured on Claude Sonnet 4.6 in the clinic's account

Stack

Claude on AWS Bedrock
Python
boto3
PyMuPDF
QuickBooks Online bill capture
Windows

The review table: 12 files, proposed names and folders, vendor read, date, amount, and a note per row — The review page on 12 synthetic invoices. Amounts are invented; nothing moves until Go.

Compliance. HIPAA-compliant by design. Business associate agreements in force with the clinic and with AWS; the model runs in the clinic's own AWS account with retention off; patient-named documents never reach QuickBooks or a chat window.

My role. I built it: the runner, the Bedrock path and the BAA setup in the clinic's account, the compliance finding that moved the architecture, and the synthetic test set. A second engineer ran the QuickBooks trial tests.

Open the build

How it's built

How it's built · Invoice processing systemBedrock live 2026-09-16

Who uses it: Built for the clinic's bookkeeper. Tested end to end in the clinic's own AWS account on 2026-09-16; her desk install is the next step.
Architecture: A local Python runner: PDF pages to PNG at 150 DPI (3 pages max), one prompt with two backends (Bedrock for production, OpenRouter for synthetic tests only), a deterministic vendor matcher (exceptions, normalized exact, unique containment), a plan step that names files and resolves collisions, a review page on 127.0.0.1, then move, log, and queue for QuickBooks.
Where it runs: On the bookkeeper's PC against the clinic's network drive. Only the reading step leaves the building, to Bedrock in the clinic's own AWS account (us-east-1), under the AWS BAA. Stephens AI operates it through an access key scoped to one inference profile.
Tests and evals: 12 synthetic invoices mirroring her real nine plus the untested cases: 5 rotated image-only scans, a bare-date receipt, a paid invoice, a statement with a period end, an unknown vendor, a same-name collision, 2 patient-data documents. 12 of 12 on Sonnet and on Haiku. Full run, undo, and the browser Go path all proven.
Cost and latency: 0.9 cents an invoice on Sonnet 4.6, about 0.3 on Haiku 4.5. At any plausible clinic volume that is $2 to $13 a month of AWS.
Guardrails: HIPAA: a business associate agreement between Stephens AI and the clinic, the AWS BAA on the clinic's own account, retention set to none in Bedrock, logging off, the Anthropic use-case form filed. No patient name is ever written to the log or the proposal. Nothing is deleted or overwritten, ever; the tool never creates a folder; a stop-on-first-failure move with a full undo.
The tradeoff we chose: Why this way and not the other
We moved off Claude Team and Cowork mid-build. They are the easier surface, and the first version ran there, but neither carries a BAA, so the runtime could never read a patient-named file. The Bedrock path costs a compliance program and a Windows installer; it is the only path where the clinic's data stays inside its own boundary. Also chosen: QuickBooks' own capture for the accounting entry, because a model should not touch a ledger when a deterministic feature already does it.

Open the build

AI education · content and outbound systems · AI Lab, iPhone Photography SchoolMarch to September 2026

AI Lab content + outbound systems

An AI education channel run as a system, then an outbound machine built in 3 weeks and instrumented so the data could say no. AI Lab, the AI education brand inside iPhone Photography School (a 1M+ audience company, Latvia). Contract, March to September 2026.

4,349emails to 2,661 businesses, a 2.2% human reply rate, from a fleet grown 2 to 10 domains and 104 to 320 mailboxes in 3 weeks

Stack

Claude Code
Codex
MCP
Python
Wistia API
Circle
Customer.io
Smartlead
Clay
Apify
Google Workspace
Slack
Kie image API
Whisper

My role. I built all of it as the in-house AI engineer, alongside a second educator on the content side. The sending stack was inherited from a departing contractor and rebuilt.

Open the build

How it's built

How it's built · AI Lab content + outbound systemsMarch to September 2026

Who uses it: 2 educators, an operations lead, and a leadership team reading the weekly numbers; members watching the tutorials.
Architecture: A shared context layer (voice, rules, trackers, decisions) synced to both Claude Code and Codex, so any agent picks up where the last one stopped. Skills for each job: video ideas, post-video, newsletter build and publish, KPI report, lead enrich, lead check, email capacity. MCP and API connections into Wistia, Circle, the email platform, Google Workspace, and Slack.
Where it runs: On the educators' machines, with a person pressing start. Sending ran on Smartlead over Microsoft mailboxes; sourcing on Apify and free registries; the KPI report published to a stable link.
Tests and evals: A rule gate on every cold email (no years, no street names, no clinical language, no 'AI', sign-off matches the inbox), run as a script before any batch. A lint on the KPI report before publish, with a corrections trail when a number was wrong. Every capacity number came from the script, never from memory.
Cost and latency: About $1 per 30 researched leads. The content pipeline ran on existing subscriptions.
Guardrails: A human approves every send: newsletters stage a verified test, campaigns stay drafts until a person activates them. Capacity rules (2 emails per inbox, 100 per domain per day, 14-day warm-up) enforced in code. The whole outbound system was wound down in 2 days with a full export and a restart guide.
The tradeoff we chose: Why this way and not the other
The opinion question beat the direct pitch in every A/B pair, so we stopped pitching. And when the numbers said cold email was not the channel for this buyer, we reported that instead of optimizing the copy again. The system's job was to make that finding checkable.
Code: The live proof pages (offer chains, ICP decision, KPI report, savings calculator) are still up on Vercel; links on request.

Open the build

Professional coaching · solo founder · A business coachLive May 2026

Coaching practice AI system

An AI operating system for a one-person coaching practice: 4 agents that read one document. A business coach and HR consultant in California (kept anonymous at her request until her testimonial lands).

13 to 15emails/day triaged with zero noise, each decision citing its source message

Stack

Claude
ClickUp Super Agents
ClickUp Brain
n8n (then)
Google Calendar
Google Sheets

Diagram: one brain document read by four agents, with a maintainer agent as its only editor — One document, four agents, one maintainer.

My role. I built all of it.

Open the build

How it's built

How it's built · Coaching practice AI systemLive May 2026

Who uses it: The founder, daily, April to July 2026; she owns and edits it herself.
Architecture: No-code agents configured in plain English inside ClickUp, all pointed at one Brain Doc as shared knowledge. A maintainer agent is the only writer to that doc. One integration workflow for calendar to sheet, because that step crosses tools.
Where it runs: Inside her own ClickUp and Google accounts. She owns every piece; the exit shipped a portable 7-file operating system and a 15-page printed system tour.
Tests and evals: A regression test per agent after a scope-creep incident, where the maintainer rewrote unrelated sections; instructions hardened with a self-check step. The 115-task sweep was rehearsed in a sandbox before it ran.
Cost and latency: About $20 a month in tooling.
Guardrails: Every agent defaults to skip, forces the assignee and a source stamp on every task it creates, and must cite the inbox message it acted on. No agent sends email.
The tradeoff we chose: Why this way and not the other
Native ClickUp agents instead of a custom stack. Less power, but she can read and change every instruction herself, and there is nothing of ours to maintain. A one-person practice needs a system she owns, not a vendor.

Open the build

Construction · Japan · Kamata KoumutenLive 2026-05-09

Construction company website

A Japanese construction company's site, rebuilt in its own language, then referred to the whole industry board. Kamata Koumuten, a construction company in Miyagi, Japan.

6pages rebuilt for mobile and desktop, verified live 6 of 6 on every deploy

Stack

HTML
CSS
JavaScript
lftp deploys
Google Search Console
Google Business Profile
Kirby CMS (next)

The rebuilt homepage on desktop — The rebuilt homepage.

My role. I built all of it, with the company's own photography.

Open the build

How it's built

How it's built · Construction company websiteLive 2026-05-09

Who uses it: The company's storefront; its owner and her customers. Live since May 2026.
Architecture: A static site on the client's existing shared PHP host, deployed by mirror with a backup taken first and a health check of every page after.
Where it runs: The client's own hosting. Nothing of ours in the loop.
Tests and evals: Every deploy verifies all 6 pages return 200 and the search-console verification file is intact.
Cost and latency: The client's existing hosting. No new subscriptions.
Guardrails: Never delete the search-console verification file. Backup before every mirror. The deploy script changes into the directory first, because the mirror tool silently no-ops on paths with spaces.
The tradeoff we chose: Why this way and not the other
Kept their host and a static site instead of moving them to a builder. The owner's team is not technical; the cheapest thing to maintain is a folder of HTML they own, plus a small CMS later for the one job they actually do themselves: posting a finished project.

Open the build

Education technology · Korea · 2020 to 2024 · KiwiOPIC2020 to 2024

Curriculum generation system

A test-prep company that now generates its own curriculum: about 80% of the manual work handled by AI. KiwiOPIC, an English test-prep company in Seoul.

~80% of the manual curriculum work now handled by AI

Stack

LLM APIs
speech-to-text APIs
prompt pipelines
automated review cycles

Fig. · The same production line, before and after. Width is share of the work.

My role. I built it, as the English curriculum specialist who became the AI integration lead.

Open the build

How it's built

How it's built · Curriculum generation system2020 to 2024

Who uses it: The curriculum team and thousands of learners preparing for the OPIc speaking test, 2020 to 2024.
Architecture: Prompt pipelines per content type, a human-last review cycle, and a transcription-plus-scoring loop for spoken answers.
Where it runs: Inside the company's own tooling at the time.
Tests and evals: Model-first, human-last review on every published item; accuracy tracked on the feedback loop.
Cost and latency: Not recorded.
Guardrails: A human signed off on every published lesson.
The tradeoff we chose: Why this way and not the other
Generate the first draft, never the final. The register of the test is narrow enough that a model drafts it well and a teacher's last pass keeps it honest.

Open the build

Stephens AI · our own tooling · Stephens AIv2 live 2026-03-01

My own AI operating system

The AI operating system my own company runs on: 9 agents, 51 skills, 15 connected services. Stephens AI, our own consultancy.

9agents each on a least-privilege tool list, plus 51 reusable skills and 15 connected services

Stack

Claude Code
Claude Agent SDK
MCP
Python
Three.js
Playwright
Fathom
Google Workspace
launchd

The Bridge dashboard: a 3D graph of the vault beside today's calendar and inbox — The Bridge, the dashboard over the whole company. Two panels blurred.

My role. I built all of it.

Open the build

How it's built

How it's built · My own AI operating systemv2 live 2026-03-01

Who uses it: Me and my co-founder, every day since March 2026.
Architecture: A markdown vault with frontmatter as the database, a generator that rebuilds the index, sub-agents defined as files with tool allow-lists, skills as files with the gotchas at the top, a local dashboard server, and scheduled jobs on the Mac that deliver to iMessage.
Where it runs: On my Mac, with connectors into Google Workspace, Slack, Fathom, and the clients' tools.
Tests and evals: A weekly lint over the vault (contradictions, stale facts, orphans), a layout lint on every branded page, and a two-reviewer gate (adversarial fact-check plus a domain reviewer) before anything client-facing ships.
Cost and latency: One subscription plus about $10 a month of API credits.
Guardrails: Every agent runs on a least-privilege allow-list. Nothing is sent, deleted, or deployed without a fresh yes. Every scheduled job leaves a trace.
The tradeoff we chose: Why this way and not the other
Files over a database. A vault of markdown is slower to query than Postgres, but every agent, every human, and every future rebuild can read it, and the whole thing is in git.

Open the build

About

Alec Stephens

Applied AI engineer. Co-founder, Stephens AI.

I build systems that get my clients real results, and I absolutely love doing it.

My experience runs across the board: healthcare clinics, coaching businesses, a nine-figure education company, construction firms in Japan, and more.

I got here sideways, hired in Seoul to write English lessons and leaving with the company's curriculum running on an AI production line.

What I do best is diagnose where a build will make a client money or save them time, then work alongside them to make it happen.

Today I run Stephens AI with my co-founder Jusheen Kim, an ex-J.P. Morgan lead engineer. Our home turf is healthcare, where the work has to be HIPAA-compliant: a business associate agreement in force with the clinic, and the AI running on Claude via AWS Bedrock inside the clinic's own account, so patient data never leaves it.

Outside Stephens AI, I also take contracts as an applied AI or forward-deployed engineer. And if you're ready to grow your business, it would be my pleasure to get you the results you need.

Upwork: 5+ years, 100% Job Success
Stephens AI LLC, Kansas

Get in touch

Email: alec@stephensai.co
Call: Book 30 minutes
GitHub: github.com/alecstephens3-stack
LinkedIn: Alec Stephens
Upwork: @AlecStephens, 5+ years, 100% Job Success

Co-founder: Jusheen Kim, ex-J.P. Morgan lead software engineer. LinkedIn