Mobile-First Development: Building ShabelleHub Entirely From a Phone

ShabelleHub was built, debugged, deployed, and maintained entirely from an Android phone — no laptop, ever.

ShabelleHub was built, debugged, deployed, and maintained entirely from an Android phone. No laptop. No desktop. No external keyboard or monitor. Just a phone, a mobile data connection, and a set of tools that made it possible.

This is the honest account of how that workflow actually functions — what works well, what is genuinely difficult, and what we learned about mobile development that applies beyond this specific project.

The Stack

Termux — a free Android app that provides a Linux environment on the phone without root access. Termux gives access to git, node, npm, python, bash, and a full package manager. It is the foundation of the entire workflow.

GitHub — version control, code review, and the bridge between Termux and Vercel. Every code change goes through GitHub.

Vercel — deployment. Every push to the main branch on GitHub triggers an automatic build and deployment. No deployment commands needed on the phone — push to GitHub and Vercel handles the rest.

Claude — the primary development assistant. Building on a 6-inch screen in a terminal environment creates specific constraints: you cannot easily have three browser tabs open for reference, you cannot copy-paste between an IDE and documentation, and you cannot quickly scan a large file for the relevant section. Claude retained context across long debugging sessions and provided step-by-step terminal commands specific to the Termux environment.

Supabase dashboard — database management through the browser. Writing SQL migrations in the Supabase SQL editor from a mobile browser is slow but functional for the query volumes ShabelleHub requires.

GitHub web editor — for small, targeted file edits. When a change affects one or two lines in one file, the GitHub web UI is faster than pulling, editing in Termux, and pushing.

The Termux Setup

After installing Termux from F-Droid (the Play Store version is no longer maintained):

# Update package list and install core tools
pkg update && pkg upgrade -y
pkg install git nodejs python wget unzip -y

# Allow access to phone storage
termux-setup-storage

# Configure git
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

The termux-setup-storage command creates a ~/storage symlink that provides access to the phone's Downloads folder. This is used to access files downloaded through the browser — ZIP files, image uploads, and similar.

Node.js in Termux runs the same npm and node commands as a desktop environment. npm install, npm run build, and npm run dev all work. The main limitation is speed — building a Next.js project on a mid-range phone takes several minutes rather than seconds.

The Git Workflow

Every code change follows the same sequence:

cd ~/shabellehub

# Pull latest changes (important when edits were made in GitHub web UI)
git pull origin main

# Make changes (nano, sed, or direct file creation)
nano pages/contact.js

# Stage and commit
git add pages/contact.js
git commit -m "fix: wire contact form to real API endpoint"

# Push — triggers Vercel deployment automatically
git push origin main

Authentication uses a Personal Access Token. The token is stored in the remote URL:

git remote set-url origin https://USERNAME:TOKEN@github.com/USERNAME/shabellehub.git

Once set, git push does not prompt for credentials. The token is stored in the remote URL in Termux's local git config — not in a credential manager, which is not available in the Termux environment.

Editing Files on Mobile

Three approaches, each suited to different edit sizes:

GitHub web editor — for edits to a single file affecting a few lines. Navigate to the file on GitHub, tap the pencil icon, make the change, commit. No terminal involved. The browser's find-in-page (⋮ → Find in page) substitutes for a code editor's search. This was used for all the Firebase-reference fixes after the Supabase migration.

sed in Termux — for replacing specific strings across files. Faster than opening each file in nano for targeted changes:

# Replace all instances of a string in a file
sed -i 's/Firebase Admin SDK/Supabase Admin SDK/g' pages/admin/users.js

# Replace across all JS files
find . -name "*.js" -not -path "*/node_modules/*" \
  -exec sed -i 's/Configure Firebase/Configure Supabase/g' {} \;

sed -i edits files in place. The -i flag means in-place — no temporary file, changes applied directly. Combined with find, it scans entire directory trees in seconds.

nano in Termux — for adding new sections, writing new functions, or making larger structural changes to a file. Nano is a terminal text editor that works well on mobile when the Termux keyboard is configured correctly.

Key Termux keyboard shortcuts for nano:

• CTRL+W — search within the file
• CTRL+O → Enter — save
• CTRL+X — exit (prompts to save if unsaved changes exist)
• CTRL+K — cut a line
• CTRL+U — paste a cut line

The volume-down key in Termux acts as CTRL. VOL_DOWN+X is CTRL+X, VOL_DOWN+O is CTRL+O. Learning this key mapping removes the main friction of terminal editing on mobile.

What Actually Goes Wrong

Merge conflicts from editing in two places. When a file is edited in the GitHub web UI and then pulled into Termux, git handles it correctly. But when changes are made in Termux without first pulling the latest from GitHub, the push fails:

error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do not have locally.

The fix:

git pull origin main --rebase
git push origin main

--rebase replays local commits on top of the remote changes rather than creating a merge commit. For a solo developer, this keeps the history clean.

Accidental node_modules commits. Early in the project, git add . staged node_modules — the entire dependency tree — before .gitignore was correctly configured. The push attempted to send hundreds of megabytes to GitHub and timed out on mobile data.

The fix requires forceful history rewriting:

# Remove node_modules from tracking without deleting the files
git rm -r --cached node_modules
echo "node_modules/" >> .gitignore
git add .gitignore
git commit -m "fix: remove node_modules from git tracking"
git push origin main

git rm --cached removes files from git's index without deleting them from disk. After this, node_modules is untracked and the directory remains available locally for development.

Build failures from missing dependencies. Packages installed locally with npm install update node_modules but do not automatically commit the updated package.json and package-lock.json. Pushing code that imports a package that was not committed to package.json causes a build failure on Vercel.

The fix is always to commit both files after an npm install:

npm install framer-motion
git add package.json package-lock.json
git commit -m "fix: add framer-motion dependency"
git push origin main

Token authentication failures. GitHub no longer accepts passwords for git operations — a Personal Access Token is required. When the token is entered correctly but authentication still fails, the most common cause is that the token was pasted with a leading or trailing space from the mobile clipboard. Regenerating the token and setting the remote URL again usually resolves it.

The Vercel Loop

The deployment workflow after any code change:

• Push to GitHub
• Open Vercel dashboard in the browser
• Watch the deployment status (takes 30-90 seconds for ShabelleHub)
• If the build fails, copy the error from the Vercel log
• Paste the error into Claude or diagnose directly
• Fix the code in Termux or the GitHub web editor
• Push again — repeat from step 2

Build errors from Vercel logs were the primary debugging input during development. The ability to copy a log excerpt from the Vercel mobile dashboard and paste it directly into a conversation with an assistant — which then provides the exact terminal command to fix it — compressed the debugging cycle considerably.

What the Workflow Cannot Do Easily

Being honest about limitations:

Hot reloading. npm run dev works in Termux, but viewing the local development server at localhost:3000 requires either a separate browser window or a tool like ngrok to expose the port. On a single phone screen, switching between Termux and the browser is slower than having both visible simultaneously on a desktop.

Large file diffs. The GitHub mobile app and web UI show diffs, but reviewing a 200-line change to a complex component on a phone screen is slow and error-prone.

Debugging UI issues. Browser DevTools on mobile are limited compared to desktop. Chrome DevTools on Android through USB debugging is possible but requires the USB connection to a desktop — which defeats the mobile-only constraint.

Simultaneous terminal sessions. Termux supports multiple sessions through its notification panel, but switching between a running npm run dev, a git operation, and a file editor is more friction than desktop split-screen.

What the Workflow Does Well

It ships. ShabelleHub went from an idea to a live production site with 88 tools, a full CMS, and a Lighthouse Performance score of 98 — entirely from a phone. The constraint of mobile-only development did not prevent any of the core functionality from being built.

Forced simplicity. When copying and pasting code between files requires switching apps and potentially losing clipboard contents, you think more carefully about whether a code change is necessary. Mobile development is naturally averse to unnecessary complexity.

sed for batch changes is underrated. The mobile constraint made sed the primary tool for batch text replacements — something that gets done with a GUI find-and-replace on desktop. sed is faster, more precise, and scriptable. It is now used for batch changes even when a desktop would be available.

AI assistance scales differently on mobile. On a desktop, the reference documentation is one tab away. On mobile, context-switching to a browser tab loses the terminal session context. An AI assistant that can hold the full context of a debugging session — the file structure, the error, the attempted fixes — and suggest the next step without requiring a new description of the problem is more valuable in a constrained environment than in one with full screen real estate.

The Takeaway

Mobile-first development is not optimal. It is slower than desktop development, harder for certain tasks, and requires more deliberate workflow design. But it is functional — genuinely, practically functional for building and maintaining a production web application.

If you have a phone and need to build something: the tools exist, the workflow is learnable, and the constraints are real but not prohibitive. The limitation is not the phone. The limitation is learning the workflow well enough that the phone stops being a barrier.

ShabelleHub is evidence that the workflow works. The code, the CMS, the database, the deployments — all of it from a 6-inch screen. What it took was not special equipment or unusual skill. It took understanding the tools and building the habit of using them correctly.

*This article is the final entry in the ShabelleHub Building in Public series.*

*Thank you for reading. The full series covers 18 articles documenting the real technical decisions, mistakes, and fixes made while building and launching ShabelleHub — an independent AI tools directory — entirely from a mobile device in 2026.*

📬 Get the latest AI tool reviews

Expert picks and comparisons, weekly. No spam.