A public website and members-only portal for an online community I founded and run.
17members using it
14applications processed
v1.4.13from v1.2, all with changelogs
938automated checks run before the migration
Discord login with role-based permissions; member data kept behind login
Moved the backend from Google Sheets to Cloudflare Workers, D1 and R2: typical server response time went from 2.21 s to 39 ms
Ran every change as a planned release or a hotfix, each with test notes
Installable phone app: one-time-code sign-in and push notifications for alerts, events, awards and support replies
How it was built: Built with AI coding agents. The agents wrote the code; I designed the product, wrote the specs, tested every release, and deployed it.
A personal pilot to test running a brand with an AI agent team before spending real money. It was never launched publicly.
Pilot project · not launched
4role-based AI agents, planned launch budget $200–300
2 scheduled AI automations: daily content ideas and weekly check-ins
44-file brand kit and a 24-month financial model
How it was built: Built with AI agents. The agents produced the drafts; I set the direction, reviewed every output, and made the calls.
Claude Projects
Scheduled AI tasks
screenshot coming
CreatorMay 2025 – Present
APEX Command Link
An AI-powered interactive game app with an AI game master.
1,400line system prompt behind the game master
Economy mode trims the context sent to the model each turn
Migrated from ChatGPT to Claude, adapting prompts to the new model
How it was built: Built with AI coding agents. The agents wrote the code; I designed the product, wrote the specs, tested every release, and deployed it.
Claude
System prompt design
Link coming soon
Process
Spec to release, every time
The same loop runs on every project. AI agents do the build step. I own the spec, the testing, and the call on what ships.
release log · Project Six
01Specme
02BuildAI agent
03Testme
04Shipme
1 / 4
01 · Define
Write the spec
Requirements, edge cases, and a clear definition of done.
02 · Build
Direct the agents
Specialized agents work from one shared knowledge base, so they share the same context.
03 · Verify
Test every release
Nothing ships untested. Each release gets written test notes.
04 · Release
Version and log it
Planned release or hotfix, decided per change. Changelog for every version.
Currently learning
Going deeper on the code
I'm building my own coding skills alongside the products. Progress goes on GitHub as it happens.
I'm Brandon G., known online as Snow. I'm a Computer Science student at Southern New Hampshire University. I build products with AI coding agents: I design the product, write the specs, test every release, and deploy it.
I'm learning Python, n8n, and the Claude API. My goal is AI engineering first, then AI research.
School
Southern New Hampshire University, B.S. Computer Science
GPA
3.7 · President's List and Dean's List
Graduating
January 2029
Targeting
AI engineering, automation, enablement, and research roles
Deep dive · Founder & Product Lead · Jun 2025 – Present · 4 min read
Project Six
A members-only portal and installable phone app for an online community: shipped, used by 17 members, tested every release, and moved off spreadsheets to Cloudflare.
17members
14applications processed
v1.4.13latest release, from v1.2
56×faster server response time
projectsix.dev, public homepage
The problem
The community needed one place where members could log in and see members-only information, and where new people could apply to join. It started on Google Sheets with Google Apps Script. As the portal grew, every request took about 2 seconds, and Discord was rate-limiting Google's shared servers.
What shipped
A public site at projectsix.dev and a members-only portal behind Discord login
Role-based access, now used by 17 members
A recruitment pipeline that has processed 14 membership applications
An installable phone app (PWA): members add it to their home screen, it opens full-screen, signs in with a one-time code from the portal, and sends push notifications for alerts, events, awards and support replies
Public site on desktop; members portal installed on a phone
Key decisions
Permissions follow Discord roles
Members sign in with Discord, and their Discord role decides what they can see and do. I set the rule that access always follows Discord roles, so promoting someone in Discord updates the portal automatically.
New memberTheir own application and onboarding only
MemberThe full portal
Team leadReviews their team's applications, runs its onboarding, follows up with its inactive members. Never sees another team's people.
AdminsSee every team; the only group that can remove members
OwnerThe only one with the setup tools
Public vs. members-only data
My test: would this member be fine with a stranger reading it? If not, it's members-only.
Public
Teams, leaders, major events, the newsletter, the Code of Conduct
Behind login
Applications, member records, moderation reports, onboarding, activity
Release vs. hotfix
New features and changes ship as a planned release with the next version number (v1.4.12 → v1.4.13) and a changelog posted to Discord. A hotfix repairs something broken in the current release, keeps the same version number, and ships right away.
If it adds or changes how something works, it waits for a release. If it only makes the current version behave as promised, it's a hotfix.
Move the backend before launch
I moved to Cloudflare on October 7, a week before the public launch on October 15, so members would start on the fast system and there'd be a week to catch problems.
Testing and releases
Every release was tested before it shipped.
A suite of hundreds of automated checks ran on every build, and I tested each release on the live site before announcing it. I shipped v1.2 through v1.4.13, each with a changelog and test notes.
v1.2v1.3v1.4v1.4.13
The backend migration
In a live test on migration day, typical server response time dropped from 2.21 s on Google Apps Script to 39 ms on Cloudflare.
Typical server response time~56× faster
Google Apps Script
2.21 s
Cloudflare Workers
39 ms
How we measured it
The same three request types were timed against both servers on Oct 7, 2026, run from a cloud environment, not a home connection.
Homepage data1.83 s→43 ms
Portal request2.09 s→38 ms
Health check2.65 s→39 ms
Compatibility runtime
Instead of rewriting the backend, we built a runtime layer that lets the original Google Apps Script code (~7,600 lines) run on Cloudflare Workers unchanged. Each Google service got a replacement:
Lock service→A Durable Object that saves one write at a time (tested: 30 simultaneous writes, none lost)
Outside requests→Real fetch with a pause-and-replay step that never saves anything twice
Drive uploads→R2 storage
Hourly trigger→Cloudflare scheduled job
A custom test harness ran all 938 existing automated checks against it before the switch. Zero data was lost, and Google was kept frozen as a backup with a written rollback plan, which was never needed.
Also checked before switching over
A full rehearsal of the move matched every tab row for row, including a 5,200-row tab
A restore round trip came back identical
Data survived a server restart
The real homepage and portal loaded and saved against the new backend
My part: I designed the plan and chose the approach: migrate without rewriting, keep a frozen backup, test everything before switching. The AI coding agent wrote the runtime, build pipeline and test harness. I deployed and verified it live.
How it was built
Built with AI coding agents. The agents wrote the code; I designed the product, wrote the specs, tested every release, and deployed it. Three specialized agents work from one shared knowledge base, so specs, decisions and release history stay in one place.
Agent 01
Website & portal
Builds and maintains projectsix.dev, the member portal, its phone app, and the Cloudflare backend. Writes the code, runs the test suite, and hands me each release as a package with push notes and a changelog.
Agent 02
Application
Designs the separate desktop "terminal" app the org uses during live ops and training.
Agent 03
HQ & strategy
Handles operations writing: recruitment plans and ads, the newsletter, meeting minutes and briefing templates.
What I learned
Specs with screenshots beat descriptions.
My best results came from showing exactly what was wrong and what I wanted. Vague requests led to rework.
Automated tests don't replace real use.
Several bugs passed every check and only surfaced when members used the live site, such as error messages that were invisible inside editors. Testing on the live site after every release became non-negotiable.
Plan the way back before you move.
The migration went smoothly because there was a rehearsal, a backup and a rollback plan. Having a way back made the switch low-risk.
Decide permissions early.
Settling who can see what up front made every later feature easier, because each one plugged into rules that already existed.
