How Can a Mobile Developer Show App Store and Google Play Projects in One Portfolio?

What information does each mobile app entry need?

Each entry needs the app name, platform, user problem, your contribution, availability status, and a direct destination that works for the visitor.

Use the project description to supply the context a store card cannot: whether you built the whole product, owned a specific feature, or created a prototype. Link the correct regional listing when possible and avoid QR codes or redirect chains inside the portfolio.

If the same app exists on iOS and Android, one entry can explain both and use the most useful product destination. If the versions differ substantially, create separate entries and name the platform in each title or tag.

• Platform and availability: iOS, Android, web, live, beta, or retired.
• Scope: the part of the app you actually built.
• Proof: official store, product page, demo, or public documentation.

What is the quickest way to organise mobile apps with IndieShow?

The quickest way is to claim an IndieShow page and add each app as a project with its logo, tag, description, URL, optional metric, and status.

The dashboard lets you upload app logos, reorder entries, choose status sections, edit profile details, add social links, and preview the page. Use Shipped or Built for available apps, Building or Working on for active development, and Archived for work no longer distributed.

A single indie-show.com/yourname URL can then sit in a CV, developer profile, or email signature while each card routes to the appropriate store or product source.

Claim your IndieShow pageStart by claiming a handle; after that, the dashboard shows the $15 one-year pass and $30 lifetime option See the editor and publishing options.

How should you handle an app that has been removed from a store?

Keep a removed app only when it still proves relevant work, label it as archived, and replace the dead store link with a legitimate surviving source.

A product page, public case study, documentation page, or repository can preserve context. If no public evidence remains, describe the project conservatively and do not offer a destination that fails. Never imply that an archived app is currently available.

Explain what you built and why the app is included; avoid inventing a reason for removal or publishing private analytics. Honest status makes old work useful without misleading users.

Which mobile app should appear first?

The first app should be the strongest match for the viewer’s purpose, not automatically the newest release or the app with the most visual polish.

For a mobile role, prioritise the app that best demonstrates the requested platform and responsibility. For potential users, prioritise the app they can install now. For collaborators, an active build may deserve the first position if the page clearly marks it as unfinished.

Review every destination on both desktop and mobile. Store links can behave differently across devices, so the descriptive card must still make sense if the visitor cannot install that platform’s app.

For the wider portfolio pattern, read: show multiple projects on one page · the indie hacker portfolio guide

Why use IndieShow as the index instead of only store profiles?

IndieShow works as the index because it keeps apps from different platforms, statuses, and publisher accounts under one maintained maker identity.

The official stores remain the source for downloads; IndieShow supplies the missing portfolio context and lets you reorder or archive entries from one dashboard. That distinction keeps the page factual and useful.

As your next app moves from Building to Shipped, update its section and destination without replacing the URL you already shared. IndieShow becomes the stable front door to a changing mobile catalogue.