#developer-productivity — Public Fediverse posts

Run multiple GitHub accounts on one Mac using folder-based Git identities, HTTPS credentials and the GitHub CLI—without SSH keys or manual switching. https://hackernoon.com/a-three-layer-setup-for-multiple-github-accounts-on-one-machine #developerproductivity

So now we've entered the era of "HATCHA" - a delightful tool that somehow proves you're an alien 👽 rather than a human. #GitHub has decided to test your humanity with a #CAPTCHA, and then swiftly revoke it with #HATCHA. 🤖 Because, clearly, nothing says "developer productivity" like existential identity crises in the login process! 🙃
https://github.com/mondaycom/HATCHA #developerproductivity #identitycrisis #HackerNews #ngated

Migrating from Lovable: Steps to Self-Host Your App

Lovable is a remarkable product.
You describe what you want. It builds it. You ship in hours instead of weeks.
That’s genuinely impressive, and I’ve used it to launch things I would have otherwise shelved for “when I have more time.”

But “when I have more time” eventually arrives.

And when it does, you start asking different questions:

“What happens if they change pricing?”
“Can I run this on my own infrastructure?”
“Where exactly does my data live?”

Those aren’t paranoid questions. They’re the right questions.
This post is about answering them — practically, with actual steps you can follow.

Why Leave Lovable?

Before anything else: you might not need to.

Lovable is a solid platform. If your app is a side project, an internal tool, or an early-stage product with low traffic, staying there is probably the right call. The cost of self-hosting is real — you own the ops now.

But there are situations where moving makes clear sense:

Cost at scale
Lovable’s pricing is per-project and per-usage.
Once you’re past early stage, running your own stack on a VPS or cloud provider is often ~3–5x (or more) cheaper.

Data residency
Some industries (healthcare, finance, defense) require you to control where data lives.
“It’s on Lovable’s servers” isn’t an acceptable answer in those conversations.

Customization ceiling
Lovable generates clean React/Supabase apps, but it has opinions. When you need a specific architecture, edge functions, a custom auth flow, or native mobile builds outside their defaults — you hit the wall.

Ownership
At some point, the code is yours.
You should be able to run it. Anywhere.

What You’re Actually Working With

Lovable generates a specific stack.
Understanding it before you touch anything is important.

A typical Lovable export looks like this:

• Frontend: React (Vite), TypeScript, Tailwind CSS, shadcn/ui components
• Backend/DB: Supabase (Postgres, Auth, Storage, Edge Functions)
• Routing: React Router
• State/Fetching: TanStack Query, sometimes Zustand
• Deployment: Previously Lovable’s own hosting; they now push to GitHub and can connect to Netlify/Vercel

The code is real – It’s readable. There’s no magic proprietary runtime you need to reverse-engineer.
That’s the good news.

The less-good news:
Supabase is tightly integrated.
The app talks to a Supabase project by project URL and anon key. If you want to move away from Supabase (or self-host Supabase), that’s a bigger migration than just moving the frontend.

For most people: keep Supabase, move the frontend.
That’s the path of least resistance.

Step 1: Export Your Code

First things first.

Go to your Lovable project → click the GitHub button → connect your GitHub account → push the project.

You now have a real repository with real code. Clone it locally:

 git clone https://github.com/your-username/your-lovable-project.git  cd your-lovable-project  npm install 

Before you do anything else, make sure it runs locally:

 npm run dev 

If it opens in your browser and works: great. If it doesn’t: check your .env file (more on that in a moment).

Step 2: Understand Your Environment Variables

This is where most people get stuck.
Lovable injects environment variables automatically. When you run this yourself, you’re responsible for them.

Create a .env file in your project root:

 VITE_SUPABASE_URL=https://your-project-ref.supabase.co  VITE_SUPABASE_ANON_KEY=your-anon-key-here 

Find these in your Supabase dashboard → Project Settings → API.

One important thing: never commit your .env to git. Add it to .gitignore immediately if it isn’t already there.

 echo ".env" >> .gitignore 

For production deployments, you’ll set these as environment variables in your hosting provider’s dashboard — not as files checked into the repo.

Step 3: Build for Production

 npm run build 

This generates a dist/ folder. Everything in there is static — HTML, CSS, JavaScript bundles. No Node.js server required to serve it.

You can host this on:

• Vercel (easiest, free tier is generous)
• Netlify (similar to Vercel, excellent DX)
• Cloudflare Pages (fastest globally, very generous free tier)
• A plain VPS with Nginx (most control, most work)

My default recommendation:
1. Cloudflare Pages for public-facing apps
2. VPS + Nginx if you want full control and have ops comfort.

Step 4: Deploy to Cloudflare Pages (Recommended)

If you just want it running fast with zero infrastructure overhead:

1. Push your repo to GitHub (done in Step 1)
2. Go to Cloudflare Pages → Create Project → Connect GitHub
3. Select your repo
4. Set build settings:

• Build command: npm run build
• Build output directory: dist

1. Add your environment variables (VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY)
2. Deploy

Done.

Your app is live on a Cloudflare CDN edge network in ~2 minutes, with automatic deployments on every push to main.

Step 5: Deploy to a VPS (The “Real Self-Hosting” Path)

For maximum control, run it on your own server.
I recommend fly.io (so you don’t need to install/maintain anything – just build your webapp in docker) or Hetzner — the value is absurd compared to AWS or GCP for basic hosting needs.

Provision your server, then SSH in:

 ssh root@your-server-ip 

Install Nginx:

 apt update && apt install nginx -y 

Create your site directory and copy the build:

 mkdir -p /var/www/myapp  # From your local machine:  scp -r dist/* root@your-server-ip:/var/www/myapp/ 

Or better: set up a CI/CD pipeline that does this automatically on push.

Configure Nginx:

 server {      listen 80;      server_name yourdomain.com;      root /var/www/myapp;      index index.html;       # This is critical for React Router — all paths serve index.html      location / {          try_files $uri $uri/ /index.html;      }       # Cache static assets aggressively      location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {          expires 1y;          add_header Cache-Control "public, immutable";      }  } 

Save to /etc/nginx/sites-available/myapp, symlink it:

 ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/  nginx -t && systemctl reload nginx 

Add HTTPS with Let’s Encrypt:

 apt install certbot python3-certbot-nginx -y  certbot --nginx -d yourdomain.com 

Certbot auto-renews.
You’re done.

Step 6: The Native App Situation

If your Lovable app has a native mobile wrapper — this is where things get interesting.

Lovable has been expanding into native capabilities using Capacitor under the hood. If your project has native bindings, you’ll find a capacitor.config.ts in the project root.

The good news:
Capacitor is open-source and you own the workflow entirely.

For iOS:

 npm run build  npx cap sync ios  npx cap open ios 

This opens Xcode with your project. From there, you archive and submit to the App Store exactly like any other iOS app. You need an Apple Developer account ($99/year).

For Android:

 npm run build  npx cap sync android  npx cap open android 

This opens Android Studio. Build → Generate Signed Bundle/APK → distribute via Play Store or sideload directly.

The webview URL matters.

In development, Capacitor talks to localhost. In production, you need to point it at your live web app. Edit capacitor.config.ts:

 import { CapacitorConfig } from '@capacitor/cli';   const config: CapacitorConfig = {    appId: 'com.yourcompany.yourapp',    appName: 'Your App',    webDir: 'dist',    server: {      // Remove this for production — use bundled assets instead      // url: 'http://localhost:5173',      androidScheme: 'https'    }  };   export default config; 

For most native apps, you want the webDir approach — the built assets are bundled directly into the native app binary. This means offline support works and you don’t depend on your web server being up for the app to function.

Run npx cap sync after every build to keep the native project in sync with your web build.

Step 7: Handling Supabase at Scale

You moved the frontend. Supabase is still doing the backend work.

For most apps: that’s fine. Supabase is genuinely good infrastructure.

But if you want to self-host Supabase too (for compliance, cost, or curiosity), they publish an official Docker Compose setup:

 git clone --depth 1 https://github.com/supabase/supabase  cd supabase/docker  cp .env.example .env  # Edit .env with your secrets  docker compose up -d 

This runs the full Supabase stack — Postgres, GoTrue (auth), PostgREST, Realtime, Storage, and Studio — on your own hardware.

It’s more maintenance burden. But it’s also complete ownership.

My honest take: use Supabase managed unless you have a specific reason not to.
Their managed infrastructure is well-run and the pricing is reasonable until you’re at serious scale.

Step 8: Setting Up CI/CD So You Don’t Do This Manually Again

Manually copying files to a server is how you get paged at 2am because you forgot a step.

Here’s a minimal GitHub Actions workflow that builds and deploys on every push to main:

 # .github/workflows/deploy.yml  name: Deploy   on:    push:      branches: [main]   jobs:    deploy:      runs-on: ubuntu-latest      steps:        - uses: actions/checkout@v6         - name: Setup Node          uses: actions/setup-node@v6          with:            node-version: '24'            cache: 'npm'         - name: Install & Build          run: |            npm ci            npm run build          env:            VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}            VITE_SUPABASE_ANON_KEY: ${{ secrets.VITE_SUPABASE_ANON_KEY }}         - name: Deploy to Server          uses: appleboy/[email protected]          with:            host: ${{ secrets.SERVER_HOST }}            username: ${{ secrets.SERVER_USER }}            key: ${{ secrets.SSH_PRIVATE_KEY }}            source: "dist/*"            target: "/var/www/myapp"            strip_components: 1 

Add your secrets in GitHub → Settings → Secrets and variables → Actions.

Push to main. It deploys automatically.
That’s the whole loop.

The Checklist Before You Pull the Plug on Lovable

Don’t cancel your Lovable plan until you’ve verified all of this:

• [ ] App runs locally with npm run dev
• [ ] Production build succeeds with npm run build
• [ ] All environment variables are set correctly in production
• [ ] Supabase Row Level Security policies are configured (don’t rely on Lovable having set these correctly)
• [ ] Auth flows work end-to-end (sign up, sign in, sign out, password reset)
• [ ] Any storage/file uploads work against your Supabase bucket policies
• [ ] Edge functions (if any) are deployed to Supabase
• [ ] Custom domain is pointing to your new hosting
• [ ] HTTPS is working
• [ ] Native builds open and run correctly (iOS Simulator + Android Emulator at minimum)
• [ ] CI/CD pipeline deploys successfully from a test push

Run through this list twice.
Yep… On the second time you’ll catch something you missed.

What I’ve Learned From Doing This

Lovable is excellent for getting to a working product quickly.
Self-hosting is excellent for owning what you built.

These aren’t in conflict — they’re a sequence.

Build fast on Lovable.
Validate the idea.
Get real users.
Then, when the infrastructure costs start mattering or the compliance questions start arriving, migrate.

The migration is maybe 4–6 hours of focused work for a typical app.
That’s worth doing on a quiet Sunday, not during a crisis.

Do it before you need to.

Questions? Find me on GitHub

Rate this:

Coding agents improve fast once they stop guessing how your repo works.

I wrote about why a small https://AGENTS.md matters more than most prompt tricks: scope, defaults, uncertainty, memory, and a template you can actually use. https://www.the-main-thread.com/p/coding-agent-operating-manual #AIAgents #SoftwareEngineering #DeveloperProductivity

The Engineering Leadership Crisis Nobody Talks About 🚨 #EngineeringLeadership #SoftwareEngineering #PlatformEngineering #TechLeadership #Microservices #SRE

https://atozofsoftwareengineering.blog/2026/05/19/the-engineering-leadership-crisis-nobody-talks-about-%f0%9f%9a%a8-engineeringleadership-softwareengineering-platformengineering-techleadership-microservices-sre/

⏰✨ Ah yes, because tracking how much time you waste in a terminal is the true pinnacle of developer productivity! Now you can finally ship that invoice without ever having to face the terrifying world outside the command line. Surely, a "closed ring" will magically fix your procrastination... or not. 🙈🔧
https://closedrings.sh/en #developerproductivity #timewasting #terminaltools #procrastinationcommandline #invoicetracking #HackerNews #ngated

The new 10x Engineer with AI

https://codeaholicguy.com/2026/05/13/the-new-10x-engineer-with-ai/

Google Cloud Next 2026: 75% of Code Is Now AI-Generated — The Developer's Guide

At Google Cloud Next 2026, Sundar Pichai revealed that 75% of all new code at Google is now AI-generated and reviewed by engineers — up from 50% just six months ago. Here is wha...

https://wowhow.cloud/blogs/google-cloud-next-2026-75-percent-ai-generated-code-developer-guide

#wowhow #google #aicoding #developerproductivity

I use AI tools every day. They help. But I also feel the other side of it more now: more review, more supervision, more mental carry-over after the laptop is closed.

This piece is about that cost for senior Java developers and enterprise teams.

https://www.the-main-thread.com/p/ai-senior-java-developers-fatigue-productivity

#Java #EnterpriseJava #SoftwareEngineering #AI #DeveloperProductivity

This is possibly my favourite talk I've given in the last couple of years. It's about how to apply the stuff you've learnt at a conference (or through research) and how to convince your bosses that you need time to play.

#DeveloperProductivity

https://youtu.be/kSNwB5xilgQ?si=DFkZUttW4SltSN_o

#DeveloperProductivity isn’t just about faster builds or better tools - it’s about creating an environment where developers can do their best work.

In this #InfoQ video, Nicole Forsgren shares a practical blueprint to:
• Identify & remove the hidden friction slowing your team down
• Uncover obstacles
• Win stakeholder buy-in
• Scale DevEx improvements across your organization

🎬 Watch now | 📄 #transcript included: https://bit.ly/4tivSAP

#DevEx #BestPractices #Agile

🖥️ Ah, the thrilling world of font selection 🎮! Because why not turn the paralyzing indecision of choosing a coding font into a game 🙄? Try not to get too distracted by the riveting "LazyMono Industrial" and "Vibrant Ink," because clearly, this is the pinnacle of developer productivity tools. 🕹️🤦‍♂️
https://www.codingfont.com/ #fontselection #codingfonts #developerproductivity #gamification #LazyMonoVibrantInk #HackerNews #ngated

A Senior Engineer's Guide to Prompting AI for Real Code

https://techlife.blog/posts/a-senior-engineers-guide-to-prompting-ai-for-real-code/

#OpenAICodex #AICoding #PromptEngineering #SoftwareDevelopment #GPT5 #GitHubCopilot #AITools #DeveloperProductivity #CodeReview #AIAgents

What would your team do with 30% more time? By consolidating 12+ language ecosystems into one repository, the ActiveState Catalog helps DevSecOps teams reclaim engineering hours.
See how: https://www.activestate.com/resources/press-releases/activestate-unifies-79m-components-to-launch-worlds-largest-secure-open-source-catalog/?utm_source=twitter/x&utm_medium=organic_social&utm_campaign=fy26_q1_organic_social #DeveloperProductivity #SoftwareEngineering