In November 2025, I started building KaryoSpace on a local Windows machine. Over the next four months, I committed 53 times. In March 2026, I moved to a pair of Oracle Cloud free-tier VMs and switched to developing from a browser. That month alone, I made 438 commits.
That jump — 53 commits over 4 months to 438 in one month — is not a reflection of working harder. It is a reflection of removing the wrong constraints from the system.
Serious software development, the conventional wisdom goes, requires a serious workstation. A MacBook. A second monitor. Docker running locally. A full IDE. Enough RAM to compile Go and run MongoDB simultaneously. You need to be at your desk.
I could not always be at my desk. I have a full-time job. I have a family. The idea I was trying to build had been with me for twenty years and I was not going to let it wait for a free evening at a dedicated desk. So I asked a different question: what is the minimum I actually need to write and ship production code?
The answer was: a browser and an internet connection.
Two Oracle Cloud Always-Free VMs. Both ARM64, 4 OCPU, 24 GB RAM. One runs the Go app, nginx, Claude Code (in a persistent tmux session), and ttyd. The other runs MongoDB. The app VM is reachable via HTTPS at karyospace.com. The DB VM is reachable only on the private network at 10.0.0.40:27017.
Component | Cost | What it does
-------------------|-------|---------------------------
Oracle VM (app) | $0 | Go binary + nginx + Claude
Oracle VM (DB) | $0 | MongoDB
Let's Encrypt SSL | $0 | HTTPS on karyospace.com
Groq API | $0 | LLM inference (free tier)
Brevo SMTP relay | $0 | Outbound email (free tier)
GitHub Actions | $0 | CI/CD (free minutes)
Oracle egress | $0 | Traffic within free capThe product being built replaces Slack, Jira, Confluence, Outlook, and ServiceNow. The infrastructure to build it costs less than the domain registration.
Claude Code runs persistently on the app VM inside a tmux session. The systemd unit restarts it automatically if it exits. The session is always alive, always in context, always ready.
# claude-dev.service
[Unit]
Description=Claude Code Dev Session
[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/WorkSpace
ExecStart=/bin/bash /home/ubuntu/start-claude-dev.sh
Restart=on-failure
# start-claude-dev.sh
while true; do
claude
echo "Restarting Claude in 3s..."
sleep 3
doneThis is not a story about using AI to autocomplete code. That framing dramatically understates what is happening. Claude holds the full context of every module, every architectural decision, every past bug, and every pending task. It does not write code when asked. It proactively flags security issues, questions redundant features before building them, and operates the full pipeline from commit to deploy to notification without being told to.
At the end of every session, four things happen without prompting: a structured log entry is appended to .md/claude-query-response.md, the code is committed and pushed to GitHub, the binary is built and the service is restarted, and an email lands in my inbox confirming what shipped.
I get that email on my phone. Seconds after a feature is live. Without touching a keyboard.
Session memory is the critical piece that most people miss when they think about AI-assisted development. Every session builds on every previous session. Claude maintains structured memory files: who I am, how I prefer to work, past architectural decisions, what approaches failed and why.
A human senior engineer leaves the company. Forgets context. Needs onboarding. Needs a two-week handover. Claude never does. The session log file is now over 600 entries. Every bug fixed, every design decision, every security concern raised is permanently encoded. The accumulated knowledge of 53 days of active development is always present in the next session.
That is not autocomplete. That is institutional memory that compounds.
I can reach the development environment from three places:
The terminal is embedded in KaryoSpace itself. The product was built inside the product. The same security model that protects enterprise users also protects the development environment.
Month | Commits | Setup
-------------|---------|------------------------------
Nov 2025 | 14 | Local Windows machine
Dec 2025 | 3 | Local Windows machine (holiday)
Jan 2026 | 12 | Local Windows machine
Feb 2026 | 24 | Local Windows machine
Mar 2026 | 438 | Oracle VM + Claude Code ← inflection
Apr 2026 | 160+ | Oracle VM + Claude Code
Total | 650+ |438 commits is not a grind. It is what happens when the friction is gone. When you do not need to sit down at a machine to ship. When deployment is one command that Claude runs for you. When tests run in CI automatically on every push.
The 53 commits over 4 months were not slow because I was building slowly. They were slow because I was building in windows of opportunity at a fixed location, constrained by physical proximity to a computer. The March inflection was not a change in effort. It was a change in access.
KaryoSpace is 138 Go source files, 22 HTML templates, 15 production modules, 6 external integrations, a full email stack (SMTP inbound + outbound + IMAP), WebRTC voice/video with coturn relay, and a three-layer knowledge refinement engine.
All of it was designed, written, tested, deployed, and documented without a local IDE, without a local compiler, without a local database, and without ever needing to be at a desk.
A funded startup with a 3-person engineering team, $15,000 a month in salaries, and a full local development environment would be proud of this output in this timeframe. This was built by one person, on free infrastructure, in 53 active coding days.
I am 40 years old. I have an arts degree. I spent twenty years in enterprise IT at CSC, DXC, and Cognizant before I built this. The barriers that kept me from building sooner were not skill and they were not intelligence. They were infrastructure cost, local tooling requirements, and the assumption that serious software required a serious workstation.
Those barriers are gone now. They are gone for everyone.
I expected velocity to improve when I moved to the VM setup. I did not expect the quality to improve.
When you are developing locally, you accumulate context in your head. You remember why you made a decision three weeks ago. You remember which approach you tried and discarded. That context evaporates when you close the laptop. When you return to the project a few days later, some of it is gone.
When Claude holds the context, it never evaporates. Every decision is logged. Every rejected approach is recorded with the reason it was rejected. Every security concern raised is tracked until it is resolved. The session log is the institutional memory of the project, and it is always current.
I am not building faster because I am working harder. I am building better because I am not losing context between sessions. That is the change no commit graph can show you.
Questions about KaryoSpace or this article? We'd love to hear from you.