DEV Community: doureios39

How to turn your phone into a survival tool that works without internet

doureios39 — Tue, 14 Apr 2026 10:08:51 +0000

Last year, internet blackouts hit Iran, Myanmar, Sudan, and parts of South America. Undersea cable cuts left entire regions offline. Natural disasters knocked out power grids for days.
Every time this happens, the same thing plays out. People reach for their phones and realize that without a connection, a $1000 device is just a flashlight.
But it doesn't have to be that way. Your phone has GPS, a compass, a screen, storage, and processing power. All of that works without internet. The problem is that the apps we rely on don't.
Here's how to set up your device so it actually works when the internet doesn't.

Get your maps offline before you need them

Google Maps lets you download regions for offline use, but most people never set this up. And even if you do, the downloaded area expires after a year and doesn't include business info like hospitals or pharmacies.
A better approach is having a dedicated offline map with critical locations already marked. Hospitals, police stations, gas stations, pharmacies, shelters, water sources. Information that matters in an emergency, not restaurant reviews.

This is one of the things I built into Gridless. During setup, it downloads the full location database for your country: over 113,000 locations for UK alone, including every hospital, police station, and pharmacy from OpenStreetMap and healthsites.io data. All saved to your device, all accessible without a single bar of signal.

But even if you don't use Gridless, go download your local area in Google Maps right now. Settings, Offline Maps, select your region. Takes 2 minutes. Do it today.

Save emergency information before you need to Google it

"How to stop severe bleeding." "What to do during an earthquake." "How to purify water."
These are searches you never want to make when you can't reach Google. But almost nobody saves this information ahead of time.
The basics everyone should have saved on their phone:

How to control severe bleeding (apply direct pressure, don't remove the cloth, elevate if possible)
Earthquake protocol (drop, cover, hold on, stay away from windows)
Water purification methods (boiling for 1 minute, or 8 drops of household bleach per gallon)
CPR steps and ratios (30 compressions, 2 breaths)
Your country's emergency numbers (not just 911, which only works in the US)

Gridless includes 9 interactive emergency guides based on US Army FM 3-05.70, Red Cross, and WHO protocols. They walk you through each situation step by step, with branching decisions based on what's happening. They include text-to-speech so you can listen hands-free while treating someone.

At minimum, take screenshots of basic first aid guides and save them to your camera roll. It's not elegant, but it works offline.

Know how to communicate without internet

Your phone's radio still works without internet. You can still make calls if cell towers are up. But what if you're in a foreign country and don't speak the language?

A few things worth having on your device:

Emergency numbers for the country you're in (police, ambulance, fire are different numbers in most countries)
Basic phrases in the local language ("I need help," "Where is the hospital," "I'm injured")
Knowledge of international distress signals (SOS in morse code: three short, three long, three short)
Emergency radio frequencies if you have a radio receiver

Gridless has a phrase book covering 11 languages with phonetic pronunciation, one-tap emergency calling for 38 countries, a morse code encoder with SOS flashlight, and a radio frequency guide. But even a screenshot of the local emergency number saved to your phone is better than nothing.

AI doesn't need the cloud

This surprises most people. You can run a full AI assistant on your laptop without any internet connection.
It's not as powerful as ChatGPT, but it can answer medical questions, help you draft messages, translate text, explain survival techniques, and generally serve as a knowledge base when you can't reach the internet.
Gridless has this built into the desktop app (Windows and Mac). You install it once, download a model (1.6 GB for the fast version), and you have an AI that works forever without internet. Nothing is ever sent to the cloud. It's yours.

The tools you forget you need

Your phone has a magnetometer (compass), a flashlight, a screen that can display morse code, and a speaker that can emit a loud alarm tone. These are basic survival tools hiding in a device most people only use for Instagram.
Having them organized in one place, accessible offline, with clear purpose, is the difference between fumbling through settings during a crisis and having a tool ready to go.

The bottom line
The internet is a single point of failure in our daily lives. Most of us have zero backup plan for when it goes down.
You just need 10 minutes of preparation while you still have a connection.
I built Gridless because I wanted all of this in one place. One app, one setup, works forever without internet. Offline maps with hospitals and emergency services for 38 countries. Emergency guides. AI assistant. Survival tools. All on your device.
It's $19 during launch (regular $39).
Gridless: https://gridless.gumroad.com/l/gridless

The security gap between "it works locally" and "it's live"

doureios39 — Thu, 05 Mar 2026 12:52:48 +0000

Most developers treat deployment as the finish line. Code works, tests pass, push to production, done. But there's a gap between "it works locally" and "it's live on the internet" where security quietly falls apart.

I built a pre-deployment scanner and over 100 developers have used it in the past few weeks. The same mistakes show up everywhere. Not sophisticated vulnerabilities - just things that got forgotten in the rush to ship.

Here are the six most common ones.

1. .env files served publicly**

This is the big one. Your .env file has database passwords, API keys, and secrets. Locally, it sits safely in your project root. In production, if your web server isn't configured to block it, anyone can visit yoursite.com/.env and read everything.

It happens more than you think. A recent study of hackathon repos found that 17% had leaked credentials. And those are just the ones committed to git - the deployed versions are often worse.

Fix: Make sure your server or hosting platform blocks requests to dotfiles. In Nginx, add:

location ~ /\. {
    deny all;
}

Most frameworks handle this by default, but custom setups and VPS deploys often miss it.

2. Database files at non-standard paths

Static security scanners check for /backup.sql or /db.sqlite3. But real apps don't name their files that way. They use names like myapp.db, production_data.sqlite3, or the app name itself as the filename.

I recently caught a deployed app serving its entire database file at a URL that no static scanner would ever guess - because the filename was based on the project name, not a common default. The scan detected it in about 1.3 seconds using directory listing detection and dynamic filename checks.

This is the kind of thing that only gets caught if you actually probe the live deployment instead of checking a list of known paths.

Fix: Never store database files inside your web root. Keep them outside the directory your web server serves, or configure your server to block access to common database extensions:

location ~* \.(db|sqlite3|sqlite|sql|mdb)$ {
    deny all;
}

3. Open database ports

Locally, your Postgres runs on port 5432 and nobody can reach it. On a VPS, that same port might be open to the internet. Same with Redis (6379), MongoDB (27017), and MySQL (3306).

An open database port with weak or default credentials is an invitation. Bots scan for these constantly - within minutes of spinning up a new server, you'll see connection attempts on common database ports.

Fix: Configure your firewall to only allow database connections from your application server, not from the public internet:

sudo ufw allow from your_app_ip to any port 5432

Or bind the database to localhost only in its configuration file.

4. Missing security headers

Your app works fine without them. Nobody notices they're missing. But security headers like HSTS, Content-Security-Policy, and X-Frame-Options protect your users from real attacks - clickjacking, protocol downgrade attacks, XSS.

Most frameworks don't add these by default. You have to configure them yourself, and in the rush to ship, they're the first thing that gets skipped.

Fix: At minimum, add these headers:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Referrer-Policy: strict-origin-when-cross-origin

Where you add them depends on your stack - Nginx config, middleware, or your framework's response headers.

5. .git directory exposed

If you deploy by cloning or pulling your git repo on the server, the .git directory might be accessible from the web. That means anyone can reconstruct your entire source code, see your commit history, and find secrets that were committed and later removed.

Fix: Either deploy without the .git directory (build artifacts only), or block access to it in your web server config:

location ~ /\.git {
    deny all;
}

6. Debug endpoints and admin panels left open

Django's debug mode shows full stack traces with variable values. Express error handlers dump internal details. Admin panels at /admin sit behind nothing but a login form - or sometimes not even that.

I've seen deployed apps with /api/admin/users endpoints returning full user records with no authentication. Not because the developer forgot to add auth - because the AI-generated code never included it in the first place.

Locally, these are useful. In production, they're attack surfaces.

Fix: Always set DEBUG=False (Django), NODE_ENV=production (Express), or equivalent for your framework before deploying. Put admin panels behind VPN or IP restrictions, not just authentication.

The pattern

None of these are hard to fix. Each one takes five minutes. The problem is nobody checks. There's no step between "deploy" and "move on to the next feature" where someone looks at the live deployment from the outside and asks: is anything exposed that shouldn't be?

Code scanners check your source. Dependency scanners check your packages. But the live deployment - the thing your users actually interact with - gets deployed and forgotten.

What I built

This is why I built Preflyt. Paste a URL or run it from your terminal:

npx preflyt-check https://your-site.com

30 seconds, no signup. Checks for exposed files, open ports, missing headers, and common misconfigurations. If you use AI coding agents, drop a skill file in your project and scans run automatically after every deploy.

Free for 3 scans at preflyt.dev.

What deployment mistakes have you run into? Drop them in the comments.