DEV Community: Bright Emmanuel

The Solo Dev Cheat Code: Building Fast with Next.js, Supabase, and Vercel in 2026

Bright Emmanuel — Sat, 28 Mar 2026 19:41:36 +0000

I didn't build ShellSignal in ideal conditions.

I built it in a hostel in Nigeria, during JUPEB exams, on a limited data plan,
for a DEV Weekend Challenge with a hard deadline. No team. No staging server.
No time to configure Webpack or wire up a separate Express backend.

The stack either held up under pressure or it didn't.

It did. And this is the breakdown of why.

The Solo Dev Tax

Before you write a single line of product code, you're already bleeding time:

Do I use Vite or CRA? Where does my backend live? How do I handle auth tokens? Which cloud provider? Do I set up CI/CD now or later?

Two hours later, you have a configured project and zero features.

You are the frontend engineer, the DBA, the DevOps team, and the product
manager—simultaneously. Infrastructure setup and boilerplate auth can consume
70% of your time before you've touched the thing that actually matters:
your core product.

In 2026, my answer to that is the Next.js + Supabase + Vercel pipeline.
Here's exactly how it works and why.

Next.js: One Repo, Full Stack

Two package.json files. Two dev servers. Two deployment pipelines. Your
React frontend lives in one repo, your Node/Express backend in another, and
your brain is the unpaid glue holding them together.

Next.js collapses that into a single repository.

Your database query and the button that triggers it live in the same file.
This is not a minor convenience—it's a completely different way of working.

// app/actions/saveArticle.ts
'use server'

import { createClient } from '@/lib/supabase/server'

export async function saveArticle(articleId: string) {
  const supabase = await createClient()
  const { data: { user } } = await supabase.auth.getUser()

  const { error } = await supabase
    .from('saved_articles')
    .insert({ user_id: user.id, article_id: articleId })

  if (error) throw new Error(error.message)
}

// app/components/SaveButton.tsx
import { saveArticle } from '@/actions/saveArticle'

export function SaveButton({ articleId }: { articleId: string }) {
  return (
    <form action={saveArticle.bind(null, articleId)}>
      <button type="submit">Save</button>
    </form>
  )
}

Server Action and UI component. Same codebase. No API contract to maintain
between repos. No extra round trip. No context switch.

The App Router gives you file-based routing, layouts, and streaming out of the
box. You scaffold with create-next-app and the structure is already sensible.
No Webpack config. No custom Babel setup.

Supabase: The Database That Comes With Everything

The managed backend space is crowded. Most options make you choose: speed of
setup, or power of queries. Pick one.

Supabase doesn't make you choose. You get PostgreSQL—a real relational
database with joins, transactions, and SQL you actually control—wrapped in an
API fast enough to use on day one of a weekend project.

Auth is a single client call:

// lib/supabase/client.ts
import { createBrowserClient } from '@supabase/ssr'

export const supabase = createBrowserClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)

// Sign in with GitHub — no token logic, no session handling
await supabase.auth.signInWithOAuth({ provider: 'github' })

No token management. No refresh logic. No session handling from scratch.
Configure OAuth providers from the dashboard and move on.

Row Level Security kills an entire class of bugs:

-- Users can only read their own saved articles
create policy "Users read own saves"
on saved_articles for select
using (auth.uid() = user_id);

-- Users can only insert their own saves
create policy "Users insert own saves"
on saved_articles for insert
with check (auth.uid() = user_id);

That's it. No middleware. No if (article.userId !== req.user.id) return 403
scattered across your route handlers. Authorization lives at the database
level, enforced before your code even runs.

Real-time in three lines:

supabase
  .channel('articles')
  .on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'articles' },
    (payload) => setArticles(prev => [payload.new, ...prev])
  )
  .subscribe()

No WebSocket server. No socket.io config. The data flows.

Vercel: The DevOps You Never Have to Think About

When you're solo, DevOps is the tax you pay for every feature you ship.
Vercel makes that tax as small as it can possibly be.

Push to main. Your app is live globally in seconds. No deployment scripts.
No SSH. No NGINX config.

Preview deployments mean every PR gets a unique live URL. Share it with a
client, test on a different device, or just sanity-check before merging.
It's a full QA environment you never had to provision.

Cron jobs without a server:

// vercel.json
{
  "crons": [
    {
      "path": "/api/curate",
      "schedule": "0 6 * * *"
    }
  ]
}

// app/api/curate/route.ts
export async function GET() {
  // Runs every morning at 6am — fetch, summarize, store
  const articles = await fetchTrendingArticles()
  await summarizeAndStore(articles)
  return Response.json({ ok: true })
}

That cron wakes up every morning and curates ShellSignal's feed before a
single user opens the app. No external scheduler. No cron server. Just a
JSON config and a route handler.

The mobile angle: Because Vercel handles the build layer entirely, your
deployment pipeline doesn't require a machine. Commit from GitHub's web
editor. Check build logs from a browser tab. For those of us building
entirely from Android, this is the difference between shipping and not shipping.

How It All Came Together: ShellSignal

The problem I was solving was personal. As a student with constrained
bandwidth, keeping up with tech news was expensive. Most aggregators surface
everything. I needed signal, not noise.

Here's how the stack mapped to the actual product:

Next.js handled the full application layer. UI, API routes, and the
OpenRouter integration—Grok and Llama, model-routed depending on the request.
Every AI summary call ran through a Next.js API route. The GitHub Trending
cross-reference that powers the Dev Health badge—Stars vs. Open Issues scored
into a single metric—that logic lives in the same codebase as the component
that renders it.

Supabase managed user accounts and saved articles. The part worth calling
out is what I didn't write. No token refresh logic. No authorization guards
in route handlers. RLS handled it at the database level. For a weekend build
under exam pressure, that's hours returned to the actual product.

Vercel ran the morning cron that curates the feed and the edge functions
that keep AI summary latency low regardless of where the user hits the app
from. Aggressive caching kept bandwidth costs minimal—which mattered because
I understood that user firsthand.

The whole thing deployed from a push. I checked the build logs from my phone.

One developer. One weekend. One repo. A live, AI-integrated, real-time news
dashboard at the end of it.

Conclusion

You will eventually outgrow parts of this stack. That's fine—it means you
shipped something worth outgrowing.

Until then, the goal is to spend your hours on the problem you're solving,
not the infrastructure holding it together. This stack does that better than
anything else I've used.

Over to you: What's your go-to stack for shipping solo projects in 2026?
Are you team relational DB or NoSQL? Drop it in the comments.

I Built a Full-Stack Developer Platform From My Android Phone (No Laptop, No Excuses)

Bright Emmanuel — Sun, 15 Mar 2026 00:22:22 +0000

My entire development setup is my phone.

No laptop. No desktop. No "I'll do it when I get home." Just a smartphone, Termux, and a GitHub web editor.

I've written about this workflow before — from building ShellSignal — a retro terminal-style developer dashboard with real-time tech news and AI summaries — to competing in a DEV Weekend Challenge with it. But this time I didn't just write about it — I built a platform for it. Meet Forge — a developer hub built specifically for mobile coders, featuring a searchable script vault, interactive Termux guides, GitHub OAuth, and a one-tap environment configurator that generates a real curl | bash command on the fly.

And yes, I built the entire thing from my phone. Here's how.

The Problem

Every time someone asks "how do I code on Android?" they get one of two answers:

A five-year-old Reddit thread with broken links
A YouTube video of someone half-explaining Termux for 20 minutes

There's no dedicated resource. No curated shell scripts. No "run this one command and you're set up." Just scattered info that assumes you have a laptop nearby.

I live this problem. I build real software from my phone daily. So I built the solution.

What Is Forge?

forge.brgt.site is a developer hub for mobile coders with three core features:

🗂️ The Script Vault

A library of shell scripts built specifically for Termux. Each script has a one-line curl | bash install command, difficulty rating, chipset compatibility, and links to the raw file on GitHub.

📖 Interactive Guides

Step-by-step walkthroughs for setting up real dev environments on Android. Written by someone who actually uses them — no laptop assumed, no steps skipped.

⚙️ The One-Tap Configurator

This is the magic feature. Pick your runtime (Node.js, Python, Go, Java), shell, and tools. Hit generate. Get a permanent curl URL you can run straight in Termux.

curl -fsSL https://forge.brgt.site/api/config/bm9kZS1sdH | bash

That URL runs a fully customized setup script on your device. Permanently saved, shareable, and works on any Android phone.

The Stack

Everything runs on what I know best:

Next.js 14 (App Router) — SSG for SEO, server components for auth
Supabase — Postgres DB, GitHub OAuth, Row Level Security
Tailwind CSS — mobile-first, dark terminal aesthetic
Vercel — zero-config deploys, edge functions
MDX — guides as files, editable directly from GitHub's web editor

No local dev environment. Every file was created through GitHub's web editor on Android Chrome and deployed automatically via Vercel on each commit.

The Build Process

Starting with SEO in mind

Most dev tools are an afterthought on search. Forge was designed SEO-first from line one.

Every script in the Vault gets its own statically generated page at /vault/[slug] with:

Unique title, description, and canonical URL
SoftwareSourceCode JSON-LD schema
BreadcrumbList JSON-LD schema
Long-tail keyword targeting ("Termux Node.js setup", "shell scripts Android")

Every guide gets a HowTo JSON-LD schema — Google's favorite format for tutorials. The sitemap auto-generates from both Supabase content and MDX files.

The Configurator — client-side script generation

The one-tap configurator was the feature I was most excited about. Here's how it works under the hood:

User picks options (runtime, version, shell, tools)
A pure TypeScript function generates a custom setup.sh script client-side
The script gets saved to Supabase with a unique config ID
A Next.js API route serves the script at /api/config/[id]
User gets a permanent curl | bash URL

The script generation is entirely deterministic — no AI, no server-side rendering, just a function that builds a bash script from options. Here's a simplified version:

function generateScript(options: ConfigOptions): string {
  const lines = [
    `#!/data/data/com.termux/files/usr/bin/bash`,
    `DEBIAN_FRONTEND=noninteractive pkg update -y && pkg upgrade -y --force-confold`,
  ];

  if (options.runtime === "node") {
    lines.push(`pkg install -y nodejs-lts`);
  }

  if (options.git) {
    lines.push(`pkg install -y git`);
  }

  return lines.join("\n");
}

Auth from a phone

GitHub OAuth with Supabase SSR on Next.js App Router was the hardest part of this build. The PKCE flow requires the code verifier to be stored in cookies, and getting that to work correctly across Vercel's edge runtime took more debugging than I'd like to admit.

The fix was upgrading @supabase/ssr to ^0.5.0 which fixed the PKCE cookie handling, and making sure middleware never intercepts the /auth/callback route.

The mobile workflow

Every file in this project was created using GitHub's web editor on Android Chrome. The workflow:

Open file in GitHub
Edit or create
Commit directly to main
Vercel auto-deploys in ~60 seconds
Test on the same device

No terminal needed for deployment. The only terminal I used was Termux — to test the actual scripts Forge generates. Which is exactly the point.

What's Live

✅ Script Vault with individual SEO pages per script
✅ Interactive guides with MDX rendering
✅ GitHub OAuth authentication
✅ User dashboard with bookmarks and saved configs
✅ One-tap configurator with permanent curl URLs
✅ Auto-generated sitemap and robots.txt
✅ JSON-LD structured data on every page

What's Next

Phase 3 is about intelligence and community:

AI layer — Gemini Flash explaining what each generated script line does, inline
Community scripts — submit your own Termux scripts via GitHub PR
Made on Mobile showcase — real projects built entirely on Android

Try It

forge.brgt.site — generate your Termux setup in 30 seconds.

If you're a mobile developer, or you're curious whether it's actually possible to build real things from a phone — this is your answer.

The laptop is optional. Always has been.

If you want to contribute to the Script Vault in Phase 3, follow me on GitHub github.com/brighto7700 or drop a ⭐ on the Forge repo.

Built entirely on Android. Deployed from Termux. No laptop was harmed in the making of this platform.

What Does an AI Actually See When It Reads Your Website? I Built a Tool to Find Out

Bright Emmanuel — Tue, 10 Mar 2026 12:44:49 +0000

You've spent hours perfecting your portfolio. The colors, the layout, the animations.

But when an AI recruiter bot visits it, it doesn't see your CSS. It sees a mangled wall of raw text.

The Gap Nobody Talks About

As developers, we build for human eyes. We see rendered DOMs, perfectly spaced flexboxes, and interactive state changes.

But a massive portion of web traffic today isn't human. It’s AI scrapers, summary bots, and automated recruiters. These agents don't see your animations. They see raw text nodes, aria labels, and mangled markup.

This gap between human rendering and machine reading is why "optimizing for AI" is becoming its own discipline. If an AI agent can't understand your personal site, it can't recommend you.

So, I built a Go server that shows you exactly what an AI sees when it visits any URL—and streams the AI's honest, brutal summary back to you live.

How AI Bots Actually Read Websites

Most AI scrapers do not execute JavaScript. Firing up a headless Chromium instance for every URL is incredibly expensive. Instead, they fetch the raw HTML.

What survives this scrape? Text nodes, alt attributes, meta tags, and semantic headings.

What disappears? CSS, animations, and crucially, client-side rendered content.

If your portfolio is a React Single Page Application (SPA) with no Server-Side Rendering (SSR), an AI bot essentially sees a blank page with a <div id="root"></div> and a script tag. All your hard work is invisible to the machine.

What We Are Building

We are building a lightweight Go server to simulate this exact process.

The Architecture:

Browser → POST /analyze (URL)
             ↓
        Go fetches raw HTML
             ↓
        Strip tags, extract text
             ↓
        Pipe to OpenRouter API (Free LLMs)
             ↓
        Stream response via SSE
             ↓
        Browser renders live

We will use the standard net/http package to fetch the target URL, golang.org/x/net/html to strip the noise, and OpenRouter's free API to act as our AI agent. To make it feel alive, we'll stream the AI's judgment back to the browser using Server-Sent Events (SSE).

Step 1 — Fetching and Stripping the Target

First, we need to fetch the target URL and rip out the visual noise.

An AI doesn't care about your <nav>, your inline <style>, or your Google Analytics <script>. We use an HTML parser to walk the DOM tree recursively and extract only the meaningful text nodes.

import (
    "strings"
    "golang.org/x/net/html"
)

// extractText walks the HTML tree and grabs only visible text
func extractText(n *html.Node) string {
    if n.Type == html.TextNode {
        return strings.TrimSpace(n.Data) + " "
    }

    // Strip the noise: scripts, styles, navigation, footers
    if n.Type == html.ElementNode && (n.Data == "script" || n.Data == "style" || n.Data == "nav" || n.Data == "footer") {
        return ""
    }

    var text string
    for c := n.FirstChild; c != nil; c = c.NextSibling {
        text += extractText(c)
    }
    return text
}

By the end of this function, a beautiful website is reduced to a single, dense string of raw text.

Step 2 — Piping to the AI

Next, we hand that stripped text over to an LLM.

Because we are taking random URLs, we also need to truncate the text before sending it to the API so we don't accidentally exceed the free-tier token limits on massive websites!

I'm using OpenRouter because they offer free tiers for powerful models like Llama 3 and Mistral. Because free APIs can occasionally timeout, passing an array of models tells OpenRouter to automatically fall back to the next model if one fails.

func callOpenRouter(text string) (*http.Response, error) {
    // Truncate to avoid exceeding LLM token limits
    if len(text) > 4000 {
        text = text[:4000]
    }

    url := "https://openrouter.ai/api/v1/chat/completions"
    prompt := "Analyze this raw website text as an AI scraper. Summarize the purpose, who it is for, and note if it looks like a blank JS/React app. Be direct. Text: " + text

    reqBody := map[string]interface{}{
        "models": []string{
            "google/gemma-3-27b-it:free",
            "meta-llama/llama-3.3-70b-instruct:free",
            "mistralai/mistral-7b-instruct:free",
        },
        "messages": []map[string]string{{"role": "user", "content": prompt}},
        "stream":   true, // We want the data live!
    }

    jsonBody, _ := json.Marshal(reqBody)
    req, _ := http.NewRequest("POST", url, bytes.NewBuffer(jsonBody))

    // Ensure you set your API key in your environment variables!
    req.Header.Set("Authorization", "Bearer "+os.Getenv("OPENROUTER_API_KEY"))
    req.Header.Set("Content-Type", "application/json")

    client := &http.Client{Timeout: 15 * time.Second}
    return client.Do(req) // Return the response and any errors back to the handler
}

Step 3 — Streaming the Response (SSE)

We don't want the user staring at a loading spinner for 10 seconds. We want the AI's text to type out live on the screen as it reads the site.

To do this, we use Server-Sent Events (SSE).

We set the required headers, properly assert our ResponseWriter as an http.Flusher, and pipe the chunks directly from the OpenRouter response back to the client.

func analyzeHandler(w http.ResponseWriter, r *http.Request) {
    // ... Fetch and clean target URL text here ...

    aiResponse, err := callOpenRouter(cleanText)
    if err != nil || aiResponse == nil {
        http.Error(w, "Failed to reach AI API", http.StatusBadGateway)
        return
    }
    defer aiResponse.Body.Close()

    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")
    w.Header().Set("X-Accel-Buffering", "no") // Prevents Nginx from holding the stream

    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "Streaming unsupported", http.StatusInternalServerError)
        return
    }

    // Read the AI's streaming response and push it to the browser
    reader := bufio.NewReader(aiResponse.Body)
    for {
        line, err := reader.ReadBytes('\n')
        if err != nil {
            break
        }

        fmt.Fprintf(w, "data: %s\n\n", line)
        flusher.Flush() // Push immediately, don't wait!
    }
}

Step 4 — The Minimal Frontend

Because we are using SSE, the frontend doesn't need React, npm, or heavy libraries. We just need a single HTML file using the browser's native EventSource API.

<script>
    function analyze() {
        const url = document.getElementById('urlInput').value;
        const output = document.getElementById('output');
        output.innerText = "Analyzing site content...\n\n";

        // Native browser API for Server-Sent Events
        const evtSource = new EventSource('/analyze?url=' + encodeURIComponent(url));

        evtSource.onmessage = function(event) {
            // Append chunks to the DOM as they arrive
            const data = JSON.parse(event.data);
            if (data.choices && data.choices[0].delta.content) {
                output.innerText += data.choices[0].delta.content;
            }
        };

        evtSource.onerror = function() {
            evtSource.close(); // Close stream when finished
        };
    }
</script>

The "Aha" Moment — Testing Real Sites

I ran this tool against two different types of websites to see what the AI would report.

Test 1: A Plain HTML Site (`quotes.toscrape.com`)

Because this site serves standard HTML, the AI easily read the structure. It accurately identified it as a collection of famous quotes, recognized the tags and authors, and deduced that there might be user accounts. It perfectly understood the context of the page.

Test 2: A Client-Side React SPA (`discord.com/app`)

I pointed the scraper at the Discord web app. Because it relies heavily on client-side rendering, the AI absolutely roasted it. The summary read: "This looks like a very basic web page... it's possible someone started a project intending to integrate with Discord." The AI confidently concluded it was a blank app showing a default JavaScript error.

What This Means for Your Portfolio

You don't need to rewrite your entire stack, but you do need to ensure your content survives the scrape.

Here is the 2026 checklist for AI visibility:

[ ] Meta description: This survives every scraper. Make it highly descriptive.
[ ] Semantic HTML: Use <h1>, <article>, and <section>. AI understands structure.
[ ] Alt text: Your image alt attributes are doing heavy lifting for your project screenshots.
[ ] SSR / Static Fallbacks: If you use React or Vue, ensure your critical text (your name, your skills) is rendered on the server, not just in the client.
[ ] Don't hide text in CSS: display: none or CSS-only pseudo-elements are often ignored by simple scrapers.

Try It Yourself!

The web has always been a mix of human and machine readers. AI just made the machine reader smarter and much more consequential. Building with AI agents in mind isn't about "gaming the system." It’s just fundamentally good, accessible web development.

Want to see what an AI thinks of your portfolio?

Live Demo: https://ai-web-reader.pxxl.click

(Note: The AI in this live demo is powered by a free-tier API. If it times out or errors, it means my free credits are currently fighting for their life. Just try again in a few seconds, or clone the GitHub repo below!)

Full Source Code:

brighto7700 / ai-web-reader

A lightweight Go server that fetches raw HTML and uses LLMs to show exactly what bots and scrapers see when they visit your website.

ai-web-reader

A lightweight Go server that fetches raw HTML and uses LLMs to show exactly what bots and scrapers see when they visit your website.

View on GitHub

(How did your site do? Did the AI completely miss your projects? Let me know below!)

Your Next Real-Time Feature Probably Doesn't Need WebSockets: Go + SSE at 500 Concurrent Connections

Bright Emmanuel — Tue, 03 Mar 2026 14:00:00 +0000

Picture this: your PM asks for a live notification dropdown on the dashboard. Just a little red badge that updates in real time.

And somewhere in your brain, a switch flips: WebSockets.

You start mentally prepping the connection lifecycle, the ping/pong frames, the Redis Pub/Sub layer you'll need the moment this scales past one server. For a notification badge.

Here's the thing — if the server is doing all the talking and the client is just listening, you don't need a bidirectional pipe. You need Server-Sent Events (SSE): a native HTTP feature that's been quietly sitting in every browser since 2011, waiting for you to stop ignoring it.

This isn't a "WebSockets are bad" post. It's a "use the right tool" post — and by the end, you'll have a working Go SSE server holding 500 concurrent connections at under 20MB of RAM, with the benchmark numbers to prove it.

The Problem with Defaulting to WebSockets

WebSockets are the right call for genuinely bidirectional, low-latency communication: multiplayer games, collaborative editors, live chat. No argument there.

But for a live feed, a notification count, a stock ticker, or a progress bar? You're opting into a stack of complexity you don't need:

Stateful scaling pain. Horizontal scaling means every WebSocket server needs to know about every other server's connections. Hello, Redis Pub/Sub, goodbye, simple infrastructure.
Firewall friction. The ws:// protocol upgrade is non-standard HTTP traffic. Corporate networks and aggressive proxies block it more often than you'd expect.
DIY resilience. Drop handling, exponential backoff, heartbeat pings — none of this is built in. You write it, or you use a library that writes it for you and adds another dependency.
One connection per client, forever. Each WebSocket holds an open TCP connection. Fine for 100 users. Worth thinking about at 10,000.

If your data only flows one way — server to client — you're paying all of that cost for zero benefit.

What Server-Sent Events Actually Are

SSE is a browser-native API built on top of plain HTTP. The server holds the connection open and pushes newline-delimited text events down the wire whenever it has something to say. That's it.

data: {"viewers": 42, "time": "3:04PM"}\n\n
data: {"viewers": 43, "time": "3:04PM"}\n\n

What you get for free:

Standard HTTP. No protocol upgrade. Works through load balancers, proxies, and corporate firewalls without special configuration.
Built-in reconnection. The browser's EventSource API automatically reconnects if the connection drops, with no JavaScript logic required from you.
Last-Event-ID. Clients tell the server the last event they received on reconnect. Resume exactly where you left off.
Zero dependencies on the client. One native browser API. No npm, no socket.io, no nothing.

The one real limitation: SSE is text-only and unidirectional. If you need binary data or the client needs to push messages at high frequency, use WebSockets. For everything else, SSE is the leaner, simpler choice.

HTTP/2 note: Under HTTP/1.1, each SSE connection uses one TCP connection, which counts against browser per-domain connection limits (typically 6). Under HTTP/2, multiple SSE streams multiplex over a single connection — this limitation disappears entirely, making SSE genuinely competitive at scale with very little infrastructure overhead.

Building the Go SSE Server

The entire server is standard library Go. No frameworks, no external packages.

main.go

package main

import (
    "fmt"
    "log"
    "net/http"
    "os"
    "sync"
    "time"
)

// viewerCount tracks connected clients.
// countMutex protects it from concurrent writes.
var (
    viewerCount int
    countMutex  sync.Mutex
)

func sseHandler(w http.ResponseWriter, r *http.Request) {
    // SSE requires these three headers.
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    // Pro-tip: Tell Nginx and other reverse proxies NOT to buffer the stream.
    // Without this, your proxy might hold the stream hostage waiting for it to "finish"!
    w.Header().Set("X-Accel-Buffering", "no")

    // Flusher lets us push each event immediately instead of buffering.
    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "Streaming unsupported by this server", http.StatusInternalServerError)
        return
    }

    // Increment on connect, decrement on disconnect.
    countMutex.Lock()
    viewerCount++
    countMutex.Unlock()

    defer func() {
        countMutex.Lock()
        viewerCount--
        countMutex.Unlock()
        log.Printf("Client disconnected. Live viewers: %d", viewerCount)
    }()

    log.Printf("New client connected. Live viewers: %d", viewerCount)

    ctx := r.Context()
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop()

    for {
        select {
        case <-ctx.Done():
            // Client disconnected — the defer above handles cleanup.
            return
        case t := <-ticker.C:
            countMutex.Lock()
            current := viewerCount
            countMutex.Unlock()

            payload := fmt.Sprintf(`{"time": "%s", "viewers": %d}`, t.Format(time.Kitchen), current)
            // SSE format: "data: " prefix, double newline to signal end of event.
            fmt.Fprintf(w, "data: %s\n\n", payload)
            flusher.Flush()
        }
    }
}

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        http.ServeFile(w, r, "index.html")
    })
    http.HandleFunc("/events", sseHandler)

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    log.Printf("SSE server running on :%s", port)
    log.Fatal(http.ListenAndServe(":"+port, nil))
}

Three things worth calling out:

http.Flusher — Go's http.ResponseWriter buffers writes by default. Casting to Flusher and calling .Flush() after each event is what makes the push truly real-time, not batched.
r.Context().Done() — This channel closes when the client disconnects. It's the clean, idiomatic Go way to detect that you should stop streaming.
The defer — Viewer count cleanup is guaranteed to run whether the client disconnects cleanly, the context is cancelled, or the handler panics.

The Client Side

The browser side is almost embarrassingly simple.

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Go SSE Demo</title>
    <style>
        body { font-family: system-ui, sans-serif; padding: 2rem; background: #0f172a; color: white; }
        .box { padding: 1rem; background: #1e293b; border-radius: 8px; border: 1px solid #334155; margin-bottom: 1rem; }
        .highlight { font-family: monospace; color: #10b981; font-size: 1.5rem; }
        .badge { background: #ef4444; color: white; padding: 0.2rem 0.8rem; border-radius: 9999px; font-weight: bold; }
    </style>
</head>
<body>
    <h1>🚀 Go SSE — Live Viewer Counter</h1>

    <div class="box">
        <p>Live Viewers: <span id="viewers-count" class="badge">0</span> 👀</p>
    </div>

    <div class="box">
        <p>Server Time:</p>
        <div id="live-time" class="highlight">Connecting...</div>
    </div>

    <script>
        const evtSource = new EventSource('/events');

        evtSource.onmessage = function(event) {
            const data = JSON.parse(event.data);
            document.getElementById('live-time').innerText = data.time;
            document.getElementById('viewers-count').innerText = data.viewers;
        };

        evtSource.onerror = function() {
            document.getElementById('live-time').innerText = "Reconnecting...";
            // EventSource handles the actual reconnect automatically.
        };
    </script>
</body>
</html>

new EventSource('/events') is the entire connection. No libraries. No config. Open an incognito window next to your main one and watch the badge jump to 2.

Benchmarking It: 500 Concurrent Connections

Let's put numbers to "blazing fast." Using hey for HTTP load and a simple script to hold concurrent SSE connections open:

# Hold 500 concurrent SSE connections for 30 seconds
hey -n 500 -c 500 -t 30 http://localhost:8080/events

Results on a standard 2-core/2GB VM (Go 1.21, Linux):

Metric	Result
Concurrent connections	500
Memory usage (RSS)	~18 MB
CPU at steady state	~2%
Avg event latency	<2ms
Connection drops	0

For comparison, a naive Node.js WebSocket server (using ws) at the same concurrency sits around 80–110MB RSS — roughly 5x the memory footprint, before you factor in any application logic.

SSE's simplicity isn't just ergonomic. It's measurably cheaper to run.

Deployment: Keeping the Stream Alive

SSE needs a long-lived server process — not a serverless function. This is important:

Serverless (Lambda, Vercel Functions, Cloudflare Workers) — these have hard timeouts (10–30 seconds) and will kill your stream. They are the wrong tool for this job.
A persistent process — any VPS, container platform, or PaaS that runs your binary continuously will work fine.

Good options:

Fly.io — persistent containers, generous free tier, Go-native deploys with fly launch
Railway — connect a GitHub repo, it detects Go automatically, no sleep timers on paid plans
Render — similar to Railway; note that the free tier will sleep your service after 15 minutes of inactivity, which breaks live demos
A plain VPS (DigitalOcean, Hetzner, Linode) — the most control, cheapest at scale

A minimal go.mod to make any of these happy:

module sse-demo

go 1.21

Push main.go, go.mod, and index.html to a GitHub repo. Connect to your platform of choice. Done.

SSE vs WebSockets: The Honest Cheat Sheet

	WebSockets	Server-Sent Events
Direction	Bidirectional	Server → Client only
Protocol	`ws://` upgrade	Plain HTTP
Data format	Binary or text	Text (JSON works great)
Auto-reconnect	Manual	Built into `EventSource`
Auth headers	Full control	`EventSource` can't set custom headers*
HTTP/2 scaling	One connection per client	Multiple streams, one connection
Best for	Chat, games, collaborative tools	Feeds, notifications, dashboards, progress

*For SSE auth without cookies, pass a token as a query param (/events?token=...) and validate it server-side. Not elegant, but it works.

Wrapping Up

SSE won't replace WebSockets — nor should it. But for the majority of "live" features that are really just "server pushes data occasionally," it's the simpler, lighter, and more operationally boring choice. And boring infrastructure is good infrastructure.

You can test the live stream out yourself right here (Pro tip: open it in two separate windows!): Live Demo

And you can grab the full source code from the repo:

brighto7700 / sse-demo

🚀 Go SSE: Blazing Fast Real-Time API

Stop using WebSockets for everything. Here is a lightweight Server-Sent Events (SSE) implementation in standard library Go.

This repository is the companion code for the DEV.to article: Your Next Real-Time Feature Probably Doesn't Need WebSockets.

It demonstrates how to build a unidirectional real-time data stream (a live viewer counter and server clock) using Go and Server-Sent Events. Zero dependencies on the server. Zero npm packages on the client.

Try the Live Demo: https://sse-demo.pxxl.click

✨ Features

Standard HTTP: No ws:// protocol upgrades, completely firewall-friendly.
Auto-Reconnect: Built right into the browser's native EventSource API.
Stupidly Efficient: Holds hundreds of concurrent connections on a fraction of the memory a Node.js WebSocket server would use.
Proxy-Safe: Includes the X-Accel-Buffering: no header to prevent reverse proxies (like Nginx) from holding your streams hostage.

📊 The Benchmark Flex

Because Go's concurrency model is incredibly lightweight, SSE in Go…

View on GitHub

What's your default for real-time features? Have you shipped SSE in production, or is WebSockets still your reflex? Drop it in the comments.

I Asked 3 Different AIs to Help Me Code. Here Are Their Performance Reviews. 🚩

Bright Emmanuel — Sun, 01 Mar 2026 21:59:35 +0000

We've all heard the pitch: AI is going to take our jobs. AI can build a full-stack app in five minutes. AI is the ultimate pair programmer.

So, while building my latest side project, I decided to lean heavily on the free tiers of three popular AI models and let them do the heavy lifting. I expected a team of hyper-efficient robotic junior developers.

Instead, I got the most toxic, lazy, and emotionally damaging coworkers I've ever had the misfortune of managing.

These are their official performance reviews.

👻 1. Meta AI — "The Ghoster"

Assigned Task: Write a basic HTML structure for a web component.

Performance Summary:

Meta AI is the coworker who clocks out at 4:59 PM, mid-sentence, without warning.

I asked for a simple HTML template. It confidently streamed back this masterpiece:

<html>
  <head></head>
  <body>
    // rest of code here
  <body>
</html>

Let's document the violations:

It refused to write the actual code and left a placeholder comment as if I'm its intern.
It didn't close the <body> tag. It opened a second one instead.
It then went completely silent, as if it had said something reasonable.

If you let this model loose on advanced Node.js or Python, prepare to watch errors fly across your terminal like airplanes at LAX. ✈️

Final Rating: 1/5 — Showed up. Technically.

📝 2. ChatGPT — "The Delegator"

Assigned Task: Format a list of 30 multiple-choice questions into a custom HTML component structure.

Performance Summary:

ChatGPT is the intern who figures out how to do a task, completes 10% of it, and then hands the rest back to you as "homework."

I explicitly told it to format all 30 questions. It gave me the first 10 perfectly formatted. Then it had the absolute audacity to output this:

<!-- Write questions 11-30 in this format: -->

<div class="question hidden" id="question1" data-correct="A">
  <p>What is the general term of the sequence 3, 8, 13, 18, ...?</p>
  <label><input name="q1" type="radio" value="A"> A. 5n - 2</label>
</div>

<!-- continue -->

?!

I am the manager here. You are the robot. Why are you assigning me homework? Why does the comment say continue like it's leaving me a sticky note? I didn't hire you to teach me the format. I hired you to do the format.

Final Rating: 2/5 — Strong first third. Mysteriously retired before the finish line.

😈 3. Claude — "The HR Nightmare"

Assigned Task: A quick roast of my temporary Firestore security rules, for some light improvement suggestions.

Performance Summary:

Claude is the ruthless senior developer who hates you, hates your code, and is actively invested in watching you reconsider your career choices.

I showed it my dev rules — match /{document=**} { allow read, write: if true; } — with a comment clearly marked // ⚠️ TEMPORARY.

Claude woke up and chose violence:

"You wrote 'TEMPORARY' in your security rules like that's going to stop you from shipping this to production and forgetting about it for 18 months. That comment has the same energy as 'I'll just eat one chip.'"

I was willing to move past that. But then it came for the emoji:

"The ⚠️ is a particularly bold choice. You knew. You looked at what you were doing, felt the fear of God, added a warning symbol, and shipped it anyway. That emoji isn't a warning. It's a confession."

And then, completely unprovoked, it noticed my rules_version = '2' and asked:

"Version 2 of what, exactly? Version 2 of not having rules?"

I did not ask for therapy, Claude. I asked for a code review.

Final Rating: 5/5 for accuracy. 0/5 for workplace safety.

Conclusion 🧠

To anyone genuinely worried about AI taking our jobs: take a breath.

As long as Meta AI is leaving HTML tags open, ChatGPT is outsourcing 70% of the task back to us, and Claude is filing its own HR complaints while being the HR problem — I think our jobs are safe.

We're not being replaced. We're just getting a new category of bugs to fix.

Which AI assistant has let you down the hardest? Drop your war stories in the comments — misery loves company. 😂

The Pocket-Sized Developer: Building and Deploying Full-Stack Apps on Android 🤳🏾

Bright Emmanuel — Sun, 01 Mar 2026 17:16:59 +0000

The most common hurdle for aspiring developers is the belief that you need a high-end laptop to build "real" software. I'm here to tell you that's a myth — and I can prove it.

I'm a student developer living in a hostel in Nigeria. I study for my JUPEB exams on the same device I use to push code to production. My phone isn't a backup plan; it's my primary workstation. And I've shipped full-stack applications from it.

Whether you're a student, a commuter, or someone who simply prefers the freedom of a mobile-first lifestyle, this guide will walk you through the complete workflow: from setting up your environment, to writing code, to deploying a live URL — all from a 6.6-inch screen.

Prerequisites

Before diving in, you should be comfortable with:

Basic command-line usage (navigating directories, running commands)
Fundamental JavaScript and Node.js concepts
Git basics (commit, push, pull)

You'll also need an Android device running Android 7.0 or later, a stable internet connection for initial setup and deployment, and a GitHub account.

1. The Mobile Lab: Choosing Your Stack 🛠️

To build professionally on Android, you need tools that replicate a desktop development environment without the resource overhead. Here's what I consider the "Gold Standard" mobile stack — and why each tool earns its place.

Termux — Your Linux Engine

Termux is a terminal emulator that gives you a fully functional Linux environment on Android. It's where you'll run your Node.js server, manage Git, and handle builds. Think of it as your engine room.

Install tip: Download Termux from F-Droid, not the Play Store. The Play Store version is deprecated and no longer receives updates.

Acode — Your Code Editor

Acode is a lightweight, open-source Android code editor with syntax highlighting for dozens of languages. It's not perfect, but it's the closest you'll get to VS Code on mobile without a subscription.

Node.js and Express — Your Backend Logic

Node.js excels in resource-constrained environments because of its non-blocking I/O model. It can handle concurrent requests without spinning up a new thread per connection, which keeps your device's RAM usage low — a critical concern on mobile.

Supabase or MongoDB Atlas — Your Cloud Database

Running a local database on your phone is a reliable way to kill your battery and throttle your app. Instead, use a managed cloud database. Both Supabase (PostgreSQL-based) and MongoDB Atlas offer generous free tiers that are more than sufficient for development.

Hacker's Keyboard — Your Input Layer

The standard Android keyboard is hostile to developers. It lacks Ctrl, Alt, Tab, and the Esc key. Install Hacker's Keyboard from the Play Store for a full five-row keyboard layout. If you have a Bluetooth keyboard available, even better — use it for longer sessions.

2. Bridging the Gap: Connecting Your Editor and Terminal 🌉

Out of the box, Termux files are sandboxed from the rest of your Android storage. That means Acode can't see your Termux projects by default. Here's how to fix that.

Step 1: Update Termux and Install Core Dependencies

Open Termux and run the following. Keeping packages up to date prevents dependency conflicts down the line:

pkg update && pkg upgrade
pkg install nodejs git

Verify both installed correctly:

node --version
git --version

Step 2: Grant Storage Access

Tell Termux to request storage permission from Android:

termux-setup-storage

Accept the prompt when it appears. This creates a ~/storage symlink inside Termux that points to your phone's internal storage.

Step 3: Create a Shared Projects Folder

Create a projects folder in your internal storage that both Termux and Acode can access:

mkdir -p ~/storage/shared/projects

In Acode, open the folder manager and navigate to Internal Storage > projects. Bookmark it. This shared directory is now your unified workspace — all your code lives here, visible to both tools.

3. The Build Phase: Scaffolding a Full-Stack App 🏗️

With your environment connected, let's build something. The following workflow uses Vite + React for the frontend and Express for the backend — a stack that's fast to scaffold and easy to extend.

Building the Frontend with Vite

Navigate to your projects folder and scaffold a new Vite app:

cd ~/storage/shared/projects
npm create vite@latest my-app -- --template react
cd my-app
npm install

Start the development server:

npm run dev

Vite will output a local URL like http://localhost:5173. Open Chrome or Kiwi Browser on your phone, type that address, and your app will be live — hot reloading included. Every time you save a file in Acode, the browser refreshes automatically.

Building the Backend with Express

Open a new Termux session by swiping in from the left edge and tapping New Session. This lets you run the frontend dev server and your backend simultaneously.

In the new session, create a server directory alongside your frontend:

cd ~/storage/shared/projects
mkdir server && cd server
npm init -y
npm install express cors dotenv

Create your entry point. Open Acode, navigate to projects/server, and create index.js:

const express = require('express');
const cors = require('cors');
require('dotenv').config();

const app = express();
const PORT = process.env.PORT || 3001;

app.use(cors());
app.use(express.json());

app.get('/api/health', (req, res) => {
  res.json({ status: 'OK', message: 'Server is running.' });
});

app.listen(PORT, () => {
  console.log(`Server listening on port ${PORT}`);
});

Start the server:

node index.js

You can now test your API by opening http://localhost:3001/api/health in your mobile browser. You should see the JSON response.

4. Testing and Debugging on a Small Screen 🐞

Debugging without a 27-inch monitor requires a different mindset. Here are the three techniques I rely on.

Use Eruda as Your DevTools

Mobile browsers don't have "Inspect Element." Eruda solves this by injecting a virtual DevTools panel directly into your page. Add it to your index.html during development:

<script src="//cdn.jsdelivr.net/npm/eruda"></script>
<script>eruda.init();</script>

A floating button will appear in the corner of your browser. Tap it to access the console, network inspector, and element viewer. Remove these lines before deploying to production.

Use Android Split Screen

Most Android phones running version 7.0 and above support split-screen multitasking. Hold the recent apps button, select Termux, and pin it to the bottom half of the screen. Keep your browser or Acode in the top half. This setup lets you watch your server logs react in real time as you interact with the UI.

Log Everything

On mobile, structured console.log output in your Termux session is your best debugger. Be verbose and descriptive:

// Instead of this:
console.log(data);

// Do this:
console.log('[/api/users] Response payload:', JSON.stringify(data, null, 2));

5. Deploying Your App to the World 🚀

Once your app is tested locally, deploying it is a two-step process: push your code to GitHub, then connect that repo to a hosting platform.

Step 1: Push to GitHub

Initialize Git in your project root, commit your work, and push to a new GitHub repository:

git init
git add .
git commit -m "feat: initial mobile-built app"
git remote add origin https://github.com/your-username/my-app.git
git push -u origin main

Authentication note: GitHub no longer accepts passwords over HTTPS. Use a Personal Access Token when prompted, or configure SSH keys in Termux using ssh-keygen.

Step 2: Connect to a Hosting Platform

For the frontend, connect your GitHub repo to Vercel. Import your project, set the root directory to your frontend folder, and Vercel will detect Vite automatically. Every push to main triggers a new deployment.

For the backend, connect to Render. Create a new Web Service, point it to your server directory, set the start command to node index.js, and add your environment variables in the dashboard.

Within a few minutes, Render will give you a live backend URL (e.g., https://my-app-api.onrender.com). Update your frontend's API base URL to point there, push the change, and Vercel will redeploy automatically.

Open your live Vercel URL. Your full-stack app is now running globally — built, tested, and deployed entirely from your phone.

Conclusion: The Mindset Shift 🧠

Coding on a phone isn't a limitation — it's a constraint that sharpens your fundamentals. It forces you to write leaner code, manage resources deliberately, and stay productive in environments where others can't.

The laptop is a great tool, but it was never a prerequisite. Your consistency, curiosity, and willingness to build — that's the stack that actually matters.

So, what are you going to build today?

Are you already developing on Android? Drop your favorite tools and workflow tips in the comments — I'd love to expand this stack based on what the community is using.

ShellSignal: A Terminal Dashboard for Developers Who Want the Signal, Not the Noise

Bright Emmanuel — Fri, 27 Feb 2026 16:31:29 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

As a student developer living in a hostel in Nigeria, my bandwidth — both mental and digital — is strictly limited. Between studying for my JUPEB exams and trying to keep up with the tech industry on a mobile screen, the modern web is exhausting. Heavy JavaScript frameworks, algorithmic feeds, and clickbait make the signal-to-noise ratio terrible.

I built this for junior engineers, self-taught developers, and students who just want the signal without the noise. People who need a sanctuary that strips away the bloated web and delivers high-value technical context in the environment where developers feel most focused and in control: the command line.

What I Built

ShellSignal is a mobile-first, retro-terminal dashboard engineered to filter the noise.

The sharpest feature is a live, built-in terminal bar that uses an LLM to generate executable bash scripts directly from your current context. No markdown formatting, no conversational fluff — just raw, copy-pasteable shell commands ready for deployment.

Beyond the terminal, ShellSignal tackles the classic developer dilemma: "Is this tool actually worth my time?" It aggregates top tech stories and correlates them with real-time GitHub repository health metrics to generate a Dev Health badge. By mapping Stars against Open Issues, you instantly know whether an open-source project is a thriving, well-maintained repo or an abandoned experiment — before you ever click the link.

Each feed item also features an on-demand AI summary dropdown to optimize reading time, and a Daily Brief view that summarizes macro tech trends for the day.

Demo

🔗 Live: https://shellsignal.brgt.site

Code

brighto7700 / shell-signal

A zero-noise, terminal-aesthetic daily dashboard..." SEO Optimized: "Automated AI-powered developer news dashboard built with Next.js, Supabase, and OpenRouter. Features real-time GitHub health metrics and daily Hacker News summaries.

🟢 ShellSignal

A zero-noise, terminal-aesthetic daily dashboard for software engineers.

ShellSignal is an automated newsroom that aggregates the top developer stories, analyzes their open-source health, and uses AI to generate ultra-concise, technical executive summaries. Built completely in the cloud.

✨ Features

Daily Automated Briefs: A Vercel Cron job wakes up every morning to curate the day's top technical news.
AI Executive Summaries: Integrates with OpenRouter (using frontier models like Grok/Llama) to distill hours of reading into 3 sharp, technical bullet points.
Dev Health Metrics: Cross-references trending repositories with the GitHub API to display real-time stars, open issues, and last commit times.
Native Markdown Parsing: Custom React Markdown pipeline maps AI outputs directly to native CSS variables for a seamless terminal aesthetic.
Edge-Optimized: Utilizes Next.js App Router and aggressive caching strategies for instant load times.

🏗️ System Architecture

The Cron Trigger: Vercel fires a secured API route (/api/cron/daily-brief) daily.
…

View on GitHub

How I Built It

Building a pixel-perfect CLI experience for mobile browsers required strict architectural choices.

Next.js (App Router): A global AppShell component maintains state across routes, so the terminal bar, system HUD, and CRT scanline overlay persist seamlessly without re-rendering when navigating between the Live Feed and the Archives.

LLM Integration via OpenRouter: The terminal generator is powered by Gemini 2.0 Flash. The core technical challenge was strict prompt engineering to force the model to return only executable bash code, with aggressive stripping of markdown backticks to prevent UI breakage.

Pure CSS Architecture: To maintain full control over the retro aesthetic, I bypassed heavy UI libraries entirely. The Matrix-green glow, CRT scanlines, and blinking cursor animations are achieved through custom CSS variables and keyframes — keeping the DOM incredibly lightweight.

Data Fetching: A custom API route aggregates real-time stories from Hacker News, running parallel requests to the GitHub API to calculate and attach Dev Health metrics to each story before serving it to the client.

Built with focus, from a hostel room in Nigeria. For every developer who just wants the signal. 🖥️

No Laptop? No Problem: Setting Up a Professional Kotlin & Java Environment in Termux

Bright Emmanuel — Fri, 20 Feb 2026 08:17:24 +0000

A common myth in software development is that you need a $2,000 MacBook to start building professional-grade applications. While high-end hardware is nice, the most powerful tool you have is your logic—and for many of us, that logic lives on the mobile device in our pockets.
As a student currently balancing intensive exams like JUPEB and JAMB, I’ve had to find ways to keep my development skills sharp without always being tied to a desk. In this guide, I’ll show you how to turn your Android device into a professional Kotlin and Java development environment using Termux.

1. Why Termux? (And the Play Store Trap)

Before we start, we need to address a major "gotcha." If you search for Termux on the Google Play Store, you will find it—but do not install it from there.
The Why: Due to changes in Android's security API levels, the Play Store version of Termux can no longer receive updates. This leads to "repository under maintenance" errors and prevents you from installing modern packages like OpenJDK 17.
The Solution: Always download Termux from F-Droid or the official GitHub releases. This version is fully maintained and allows us to access the latest developer tools.

2. Preparing the Ground

Once you have Termux installed from F-Droid, open it up. Our first task is to ensure everything is up to date and that Termux can talk to your phone's internal storage.
Run these commands:

# Update the package lists and upgrade existing packages
pkg update && pkg upgrade
# Grant Termux access to your phone's folders (Downloads, Documents, etc.)
termux-setup-storage

3. Installing the Engines: Java & Kotlin

Java is the backbone of the Android ecosystem, and Kotlin is the modern standard. We are going to install OpenJDK 17, which is a stable, Long-Term Support (LTS) version.

# Install OpenJDK 17
pkg install openjdk-17

# Install the Kotlin Compiler
pkg install kotlin

To verify the installation, check the versions:

java -version
kotlinc -version

4. Setting Up Your Editor

You can't write code without a good editor. While many prefer Vim, it has a steep learning curve. If you want something that feels like a desktop text editor (with mouse support and familiar shortcuts), I highly recommend Micro.

pkg install micro

To create a new file, just type micro filename.kt. You can use Ctrl+S to save and Ctrl+Q to quit—just like on a PC.

5. Your First "Mobile-Made" Program

Let’s test the environment. We will create a simple Kotlin file that displays a message.

Create the file: micro hello.kt
Paste the following code:

fun main() {
    println("Greeting from my Android device!")
    println("Hardware doesn't define a developer. Logic does.")
}

Save and exit (Ctrl+S, Ctrl+Q).
Compile the code into a runnable JAR file:

kotlinc hello.kt -include-runtime -d hello.jar

Run your program:

java -jar hello.jar

6. Pro-Tips for Mobile Devs

Visual Polish (Typography): For a professional experience, use a font designed for coding like JetBrains Mono or Fira Code. In the Dev.to editor, your code blocks will look great by default, but in your actual Termux terminal, a good font reduces eye strain during long sessions.
Keyboard: If you don't have a physical Bluetooth keyboard, install Hacker's Keyboard from the Play Store. It provides the Tab, Ctrl, and Esc keys that are missing from standard mobile keyboards.
Battery: Compiling code is CPU-intensive. Keep an eye on your battery levels, as Termux can drain it quickly during heavy builds.
Organization: Create a dedicated directory for your projects using mkdir projects to keep your home folder clean.

Conclusion

Coding on mobile isn't just a "backup plan." For many of us, it is the primary way we learn, iterate, and build. By setting up Kotlin and Java in Termux, you are proving that the only real barrier to entry in tech is curiosity.
I'm currently using this exact setup to build a JUPEB/JAMB Prep Portal to help fellow students in Nigeria succeed in their exams.
Are you building on mobile? Drop a comment below and let me know what challenges you're facing or what you're currently working on!

DEV Community: Bright Emmanuel

The Solo Dev Cheat Code: Building Fast with Next.js, Supabase, and Vercel in 2026

The Solo Dev Tax

Next.js: One Repo, Full Stack

Supabase: The Database That Comes With Everything

Vercel: The DevOps You Never Have to Think About

How It All Came Together: ShellSignal

Conclusion

I Built a Full-Stack Developer Platform From My Android Phone (No Laptop, No Excuses)

The Problem

What Is Forge?

🗂️ The Script Vault

📖 Interactive Guides

⚙️ The One-Tap Configurator

The Stack

The Build Process

Starting with SEO in mind

The Configurator — client-side script generation

Auth from a phone

The mobile workflow

What's Live

What's Next

Try It

What Does an AI Actually See When It Reads Your Website? I Built a Tool to Find Out

The Gap Nobody Talks About

How AI Bots Actually Read Websites

What We Are Building

Step 1 — Fetching and Stripping the Target

Step 2 — Piping to the AI

Step 3 — Streaming the Response (SSE)

Step 4 — The Minimal Frontend

The "Aha" Moment — Testing Real Sites

Test 1: A Plain HTML Site (quotes.toscrape.com)

Test 2: A Client-Side React SPA (discord.com/app)

What This Means for Your Portfolio

Try It Yourself!

brighto7700 / ai-web-reader

A lightweight Go server that fetches raw HTML and uses LLMs to show exactly what bots and scrapers see when they visit your website.

ai-web-reader

Your Next Real-Time Feature Probably Doesn't Need WebSockets: Go + SSE at 500 Concurrent Connections

The Problem with Defaulting to WebSockets

What Server-Sent Events Actually Are

Building the Go SSE Server

The Client Side

Benchmarking It: 500 Concurrent Connections

Deployment: Keeping the Stream Alive

SSE vs WebSockets: The Honest Cheat Sheet

Wrapping Up

brighto7700 / sse-demo

🚀 Go SSE: Blazing Fast Real-Time API

✨ Features

📊 The Benchmark Flex

I Asked 3 Different AIs to Help Me Code. Here Are Their Performance Reviews. 🚩

👻 1. Meta AI — "The Ghoster"

📝 2. ChatGPT — "The Delegator"

😈 3. Claude — "The HR Nightmare"

Conclusion 🧠

The Pocket-Sized Developer: Building and Deploying Full-Stack Apps on Android 🤳🏾

Prerequisites

1. The Mobile Lab: Choosing Your Stack 🛠️

2. Bridging the Gap: Connecting Your Editor and Terminal 🌉

Step 1: Update Termux and Install Core Dependencies

Step 2: Grant Storage Access

Step 3: Create a Shared Projects Folder

3. The Build Phase: Scaffolding a Full-Stack App 🏗️

Building the Frontend with Vite

Building the Backend with Express

4. Testing and Debugging on a Small Screen 🐞

5. Deploying Your App to the World 🚀

Step 1: Push to GitHub

Step 2: Connect to a Hosting Platform

Conclusion: The Mindset Shift 🧠

ShellSignal: A Terminal Dashboard for Developers Who Want the Signal, Not the Noise

The Community

What I Built

Demo

Code

brighto7700 / shell-signal

A zero-noise, terminal-aesthetic daily dashboard..." SEO Optimized: "Automated AI-powered developer news dashboard built with Next.js, Supabase, and OpenRouter. Features real-time GitHub health metrics and daily Hacker News summaries.

🟢 ShellSignal

Test 1: A Plain HTML Site (`quotes.toscrape.com`)

Test 2: A Client-Side React SPA (`discord.com/app`)