DEV Community: Alba LM

I'm launching Fadely on Product Hunt today: an iOS vault where documents self-destruct

Alba LM — Sun, 15 Nov 2026 08:47:39 +0000

Today Fadely is live on Product Hunt 🚀 👉 https://www.producthunt.com/posts/fadely

The problem

My brother-in-law flies constantly. One day he found his passport photo buried among hundreds of old downloads on his phone. First relief, then worry: what if his phone gets stolen?

We all do this. We save a boarding pass, a ticket or an ID copy "just for a trip", and it stays on our phone for years.

What Fadely does

Fadely is a vault for documents you only need for a while:

✈️ Add boarding passes, tickets, a passport copy
📅 Pick an expiry date
🔔 Get a reminder 24 hours and 1 hour before, and extend it by 48 hours from the notification if your trip runs late
🔒 When the date comes, the vault is gone for good

How it works under the hood

Each vault is encrypted with AES-256 and its own key, stored in the iOS Keychain
When a vault expires, its key is deleted, so the files become unreadable noise
If iOS skips the background task, the vault is always destroyed before it can be opened again
The countdown widget uses a pre-built timeline, so it updates at the exact expiry without opening the app, and it only holds emoji and dates, never documents or keys
No accounts, no cloud, no backups, no analytics. Everything stays on your iPhone.

What I learned in the first two weeks

I launched on the App Store on November 1st and shared honest numbers on X: tiny, but the conversations with other indie devs were worth it. The biggest lesson: talking to developers is easy, reaching the people who actually need the app is the hard part.

I'd love your feedback

If you have a minute, take a look on Product Hunt and tell me what you think, especially about the privacy model.

👉 https://www.producthunt.com/posts/fadely

Thanks for reading! 🙏

I built an iOS app where your documents delete themselves

Alba LM — Fri, 13 Nov 2026 00:40:18 +0000

We keep too many documents forever. Scans of contracts, tickets, IDs sent for a one-time procedure, a rental agreement from three years ago. Most of them only matter for a short time, and then they just sit in your phone, your cloud and your photo library, waiting to be leaked, lost or forgotten.

So I built Fadely: an iOS app that works as a vault for temporary documents. You add a document, choose a date, and when that date arrives the document destroys itself.

Why I built it

My brother-in-law flies constantly. His passport was buried among hundreds of downloads on his phone, and he always worried: what if it gets stolen?

So in Fadely, docs get an expiry date. Then they're gone for good. 🔒

The idea

Most storage apps are built on one assumption: keep everything, forever. Fadely does the opposite. Every document has an expiry date from the moment you save it. You decide how long it should exist, and the app takes care of the rest.

It is useful for:

Documents you need for a limited period (a visa application, a rental process, a trip)
Things you must share or keep temporarily and don't want to keep around
Anyone who wants fewer sensitive files lying around on their devices

Why it's a one-time purchase

I wanted Fadely to be simple and honest: you pay once, no subscription. An app about getting rid of things shouldn't charge you a monthly fee to keep storing them.

Why I'm sharing it here

I'm a solo indie developer working in Swift and Flutter, and Fadely is my newest app. I'm building in public, so I would really like feedback from other developers:

How would you approach the expiry logic on iOS?
What would make you trust an app like this with sensitive documents?
Which feature would you expect that is not there yet?

Fadely is available now on the App Store, with a launch price for a limited time:

👉 https://apps.apple.com/app/fadely/id6820224574

You can find all my apps here: https://alorenzom.com

Thanks for reading, and I'll answer every comment. 🙌

Your photos can tell strangers where you were. Here's how to check yours

Alba LM — Thu, 12 Nov 2026 13:29:17 +0000

The test

I took a photo with my iPhone in a public place, emailed it to myself with Gmail, and opened the attachment on another device.
It still carried the exact GPS location, the date and time down to the minute, my phone model, and even the direction I was facing (east, 70°). In total, 58 pieces of hidden information travelled silently with the picture.
I'm a developer, and I still didn't expect that. Most people have no idea it happens.

What a photo can carry

Every time you take a photo, your phone can save extra information inside the file. It's called metadata, and you never see it when you look at the picture. It can include:
• The exact location where you took it, often accurate to a few metres
• The date and time, to the minute
• Your phone's make and model
• Camera and lens settings
• The direction you were facing, altitude, and sometimes the app you used to edit it
None of this is a bug. It's useful when you browse your own photos on a map. The problem starts when the photo leaves your phone.

Why it matters

Many social apps remove this data when you upload a photo. WhatsApp and Instagram usually do. But photos sent by email, AirDrop, as a file or through a cloud link can keep everything.
Think about the photos you send without a second thought: a picture of something you're selling, taken in your living room. A photo of your kids at the park near home. A "harmless" picture sent to someone you've only just met online.
Anyone who receives the file can open its details and see where it was taken. You don't need to be a hacker to do it, and the person who sent it never knows.

Privacy is about choice

Privacy isn't about having something to hide. It's about deciding what you share, with whom, and when.
We've got used to giving away information without noticing: location permissions, cookies, accounts for everything. Photo metadata is one more layer of that, and one of the least known. The good news is that it's also one of the easiest to fix, once you know it's there.

How to check your own photos

I built foto.alorenzom.com to make this visible to anyone, without technical knowledge.

Open the site and choose a photo.
See everything it carries, with the location on a map.
Download a clean copy without the hidden data. The tool practises what it preaches: your photo never leaves your device. Everything happens in your browser. Nothing is uploaded, there are no accounts, no ads and no analytics. It's free. One tip for iPhone: when you pick the photo, tap "Options" and turn on Location. Otherwise iOS hides it from the site, which is a good privacy default, but it means you won't see what the photo really carries.

How to protect yourself

On iPhone:
• When sharing a photo, tap "Options" at the top and turn off "Location".
• For a photo you already took: open it in Photos, tap (i), then Adjust, then No Location.
• To stop saving it in future photos: Settings → Privacy & Security → Location Services → Camera → Never.
On Android: open your camera settings and turn off location tags. The exact name changes from one phone to another.

Try it

Check one of your own photos at foto.alorenzom.com/en. It takes ten seconds, and you might be surprised.
If it helped, share it with someone who sends photos by email. And if you find metadata it misses, I'd love to hear about it.
I'm an indie iOS developer. I build small apps at alorenzom.com.

I checked what 31 big websites tell AI crawlers in robots.txt, and found a bug in my own tool

Alba LM — Thu, 05 Nov 2026 22:59:19 +0000

Can ChatGPT, Claude or Perplexity read your website? The first place to look is a small text file: robots.txt.

I wanted to see what big websites actually say in it, so I picked 40 well-known sites and audited their home pages for 12 AI crawlers. The results split much more cleanly by industry than I expected.

The study also found a bug in my own tool. More on that below, because it's a mistake you could easily make too.

What I measured

On 5 November 2026 I ran PageSignal, the AI visibility API I built, against the home pages of 40 sites: news, e-commerce, SaaS and developer tools, and reference sites.

31 sites gave usable results.
9 sites could not be audited. Most answered with an anti-bot wall, two timed out, and one page was over my 2 MB limit.

I split the crawlers into two groups, because they do different jobs:

AI search and assistant bots (OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User): they fetch pages to answer people.
AI training bots (GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, meta-externalagent): they collect content for training models.

The results

Group	Sites audited	Block at least one AI search or assistant bot	Publish llms.txt
News	6	6	0
E-commerce	8	2	2
SaaS and dev tools	10	0	9
Reference	7	2	1
Total	31	10	12

Across all 31 sites:

10 block at least one AI search or assistant bot on their home page.
13 block at least one AI bot of any kind. Three of them (AliExpress, Figma and Notion) only block training bots.
18 block none of the 12 crawlers.

The 10 sites that block at least one search or assistant bot were The Guardian, BBC, Reuters, The Verge, TechCrunch, Wired, Amazon, eBay, Reddit and IMDb.

Reuters, Reddit and IMDb are a special case. Their general User-agent: * rules close the home page to any bot without its own rules, so this isn't always AI-specific. Reddit's file ends like this:

User-agent: *
Disallow: /

The pattern: publishers close, software companies open

All 6 news sites block at least one bot that fetches pages to answer people. None of the 10 SaaS and developer tool companies do, and 9 of those 10 publish an llms.txt file, while no news site does.

My guess, and it's only a guess, is that this comes down to the business model. A publisher sells its content, so an AI answer can replace the visit. A software company sells a product, so being mentioned in an AI answer works like free marketing.

Neither choice is automatically right. Blocking is often deliberate. The thing to avoid is blocking by accident, for example with a security rule or a template nobody remembers adding.

The bug in my own tool

My first run said Figma was blocking AI search bots. I double-checked before writing that here, and it was wrong.

PageSignal was using Python's built-in urllib.robotparser. It's convenient, but I found two behaviours that don't match the robots.txt standard, RFC 9309:

1. It doesn't understand $, the end-of-URL marker.

from urllib.robotparser import RobotFileParser

parser = RobotFileParser()
parser.parse("""User-agent: OAI-SearchBot
Allow: /$
Disallow: /""".splitlines())

print(parser.can_fetch("OAI-SearchBot", "https://example.com/"))  # False, should be True

Under the standard, the most specific matching rule wins, so Allow: /$ opens the home page. That's how Figma's file is written.

2. It can apply the wrong group when one bot name is contained in another.

parser = RobotFileParser()
parser.parse("""User-agent: Applebot
Allow: /

User-agent: Applebot-Extended
Disallow: /""".splitlines())

print(parser.can_fetch("Applebot-Extended", "https://example.com/"))  # True, should be False

The rule for Applebot gets applied to Applebot-Extended. This made my tool miss a real block on The Verge, Reuters and IMDb.

In total, 4 of the 32 sites audited in that first run had wrong crawler results. I replaced the parser with a small RFC 9309 matcher and checked the numbers in this post against a separate implementation. They match.

If you read robots.txt with urllib.robotparser (tested on Python 3.12), it's worth testing these two cases.

What this study doesn't prove

It's a small, hand-picked sample. It shows a pattern in these sites, not the whole web.
It only looks at home pages. This matters: Figma opens its home page to AI search bots but closes /pricing to them. A page-level answer can differ from the rest of the site.
It's one day's snapshot. These files change.
robots.txt is a request, not a lock. It shows what a site asks for, not what each company's crawler really does.
Being readable doesn't mean being cited. Passing these checks gives an AI bot access. It can't guarantee a mention.
A file doesn't show the whole relationship. A publisher may also have a licensing deal that robots.txt doesn't reveal.

Check your own site

Look at yoursite.com/robots.txt and search for the bot names above, then look at the User-agent: * block. Check the pages you care about, not only the home page.

Also look at your page without JavaScript. Many AI crawlers don't run it, so a page built entirely in the browser can look almost empty to them.

If you'd rather not do it by hand, there's a free live demo with no signup. For automated checks, the API is on RapidAPI and API.market.

Did you decide on purpose what your robots.txt says about AI crawlers, or is it just whatever your template shipped with? I'd love to hear what you found.

How to audit a website's SEO and AI visibility with a single API call

Alba LM — Mon, 19 Oct 2026 13:33:05 +0000

Checking a page's SEO usually means opening five different tools: one for the title and meta description, another for Open Graph tags, another for canonicals and indexability, another for the sitemap, and yet another to validate JSON-LD.

And now there's a new question: can AI assistants and AI search engines actually read your page? A site can look perfect in a browser and still be blocked in robots.txt, or be almost empty for crawlers that don't run JavaScript.

I got tired of checking all of this by hand, so I built PageSignal: an API that audits any public URL in a single request and returns two explainable scores, one for SEO and one for AI visibility, so you know not just what failed but why.

What it checks

SEO

Title and meta description: length, and duplicate tags on the same page
Open Graph and Twitter Card tags: and which recommended ones are missing
Indexability: meta robots, googlebot and the X-Robots-Tag header combined into one verdict
Canonical URL: missing, empty, duplicated, self-referencing or pointing elsewhere
robots.txt and XML sitemap discovery
JSON-LD: every block parsed and validated, with its schema types
Headings, image ALT coverage, internal and external links
A 0–100 SEO score where every rule shows its points, severity and the reason

AI visibility

robots.txt rules for 12 AI crawlers: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, CCBot and meta-externalagent
Search bots vs training bots: blocking search and assistant bots can hide you from AI answers, while blocking training bots is a policy choice, so they are reported separately
Content visible without JavaScript: pages built in the browser can look almost empty to crawlers that don't run JS
JSON-LD presence and llms.txt detection
A 0–100 AI visibility score with findings and plain-English fixes

Try it without signing up

There's a live demo where you paste a URL and get both scores and the top issues to fix:

👉 https://pagesignal.alorenzom.com/demo

Or straight from your terminal, no key needed (3 checks per day):

curl -s https://pagesignal.alorenzom.com/demo/api/audit \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com/"}'

The demo returns a summary. The full API returns the complete report — here's a real, unedited one for python.org.

Call the full API

With a free RapidAPI key:

curl --get 'https://pagesignal-seo-audit-metadata-json-ld-validator.p.rapidapi.com/v1/audit' \
  --data-urlencode 'url=https://www.python.org/' \
  -H 'X-RapidAPI-Host: pagesignal-seo-audit-metadata-json-ld-validator.p.rapidapi.com' \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY"

Only want the AI visibility report? Use the dedicated endpoint:

curl --get 'https://pagesignal-seo-audit-metadata-json-ld-validator.p.rapidapi.com/v1/ai-visibility' \
  --data-urlencode 'url=https://www.python.org/' \
  -H 'X-RapidAPI-Host: pagesignal-seo-audit-metadata-json-ld-validator.p.rapidapi.com' \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY"

Example output

This is a trimmed, real response for https://www.python.org/:

{
  "success": true,
  "network": {
    "final_url": "https://www.python.org/",
    "status_code": 200,
    "response_time_ms": 113,
    "redirect_count": 0
  },
  "quality_score": {
    "score": 68,
    "grade": "C",
    "errors_count": 1,
    "warnings_count": 4,
    "breakdown": [
      {
        "rule_id": "title_check",
        "severity": "warning",
        "max_points": 15,
        "points_impact": -6,
        "message": "Your title is shorter than recommended (30–60 characters). Consider adding primary keywords or brand context."
      },
      {
        "rule_id": "xml_sitemap_check",
        "severity": "error",
        "max_points": 10,
        "points_impact": -10,
        "message": "No XML sitemap was detected at common locations."
      }
    ]
  },
  "diagnostics": { "http_ok": true, "likely_client_rendered": false, "notes": [] },
  "title": { "status": "warning", "value": "Welcome to Python.org", "length": 21 },
  "indexability": { "status": "healthy", "is_indexable": true, "raw_directives": "index, follow" },
  "canonical": { "status": "warning", "is_present": false, "badge": "Missing" },
  "structured_data": {
    "status": "healthy",
    "blocks_detected": 1,
    "valid_blocks": 1,
    "invalid_blocks": 0,
    "blocks": [{ "schema_types": ["WebSite"], "errors": [] }]
  },
  "ai_visibility": {
    "status": "healthy",
    "score": 95,
    "grade": "A",
    "badge": "Readable by AI",
    "content_visible_without_js": true,
    "robots_txt_checked": true,
    "crawlers": [
      { "name": "GPTBot", "operator": "OpenAI", "purpose": "training", "allowed": true },
      { "name": "OAI-SearchBot", "operator": "OpenAI", "purpose": "search", "allowed": true }
    ],
    "blocked_search_crawlers": [],
    "blocked_training_crawlers": [],
    "llms_txt": { "checked": true, "found": false, "status_code": 404 }
  }
}

Every point lost comes with a message, so you can show your users exactly what to fix instead of a bare number.

Fail your CI build when SEO or AI visibility breaks

Here's a small script that audits a list of URLs and exits with code 1 if any page breaks a rule you care about. Save it as seo-check.mjs (Node 18+, no dependencies):

// seo-check.mjs: audits a list of URLs and exits with code 1 if any of them
// breaks a rule you care about, so it can stop a CI pipeline.
const HOST = 'pagesignal-seo-audit-metadata-json-ld-validator.p.rapidapi.com';
const KEY = process.env.RAPIDAPI_KEY;
const MIN_SCORE = 60;

const urls = process.argv.slice(2);
if (!KEY || urls.length === 0) {
  console.error('Usage: RAPIDAPI_KEY=your_key node seo-check.mjs <url> [more urls...]');
  process.exit(2);
}

let failed = false;

for (const url of urls) {
  const res = await fetch(`https://${HOST}/v1/audit?url=${encodeURIComponent(url)}`, {
    headers: { 'X-RapidAPI-Host': HOST, 'X-RapidAPI-Key': KEY },
  });
  const report = await res.json();

  if (!res.ok) {
    console.log(`✖ ${url}: ${report.error?.code ?? `HTTP ${res.status}`}`);
    failed = true;
    continue;
  }

  const { quality_score, indexability, canonical, structured_data, ai_visibility } = report;
  const problems = [];
  if (quality_score.score < MIN_SCORE) problems.push(`score ${quality_score.score} is below ${MIN_SCORE}`);
  if (!indexability.is_indexable) problems.push('page is not indexable');
  if (!canonical.is_present) problems.push('canonical tag is missing');
  if (structured_data.invalid_blocks > 0) problems.push('invalid JSON-LD found');
  if (ai_visibility.blocked_search_crawlers.length > 0) {
    problems.push(`AI search crawlers blocked: ${ai_visibility.blocked_search_crawlers.join(', ')}`);
  }
  if (!ai_visibility.content_visible_without_js) problems.push('content is not visible without JavaScript');

  if (problems.length > 0) {
    console.log(`✖ ${url}: ${problems.join('; ')}`);
    failed = true;
  } else {
    console.log(`✔ ${url}: SEO ${quality_score.score}, AI visibility ${ai_visibility.score}`);
  }
}

process.exit(failed ? 1 : 0);

Run it like this:

RAPIDAPI_KEY=your_key node seo-check.mjs https://example.com/ https://example.com/pricing

Limitations

JavaScript is not executed, so single-page apps can return partial data. The response flags this in diagnostics.likely_client_rendered.
Sites behind anti-bot walls can't be analyzed.
Only public http/https URLs are supported.
The AI checks show whether a page can be read. They can't guarantee that any AI product will cite it.

Try it

Live demo: https://pagesignal.alorenzom.com/demo
RapidAPI: https://rapidapi.com/AlbaLM/api/pagesignal-seo-audit-metadata-json-ld-validator
API.market: https://api.market/store/alorenzom/pagesignal-seo-ai-audit

What would you add to a check like this? I'd love to hear what you'd want it to catch.

Hi DEV! I'm Alba, an indie dev building iOS/Flutter apps and PageSignal, an API that audits SEO, metadata & JSON-LD of any URL in one call. Happy to hear what checks you'd want in a tool like this 👋

Alba LM — Sun, 18 Oct 2026 14:35:24 +0000