Template preview — Draft structure. Links, metrics, certificates, and LeetCode stats are placeholders — nothing here is claimed as real.

MD IrfanFull-stack developer
Résumé
All work

Case study 03 — Draft

Mobile Weather

A draft case study for the mobile weather app. The phone mockup is illustrative; the visitor-weather demo is real. Add the app's stack and links.

Role
Add role
Timeline
Add timeline
Stack
Add stack
Links
Add live URLAdd repo

Illustrative mockup — replace with a real screenshot. Tap the phone, or press W, for your real weather.

The short version

  • What it is — add one sentence.
  • What you built — add the framework, the API, and the offline behaviour.
  • What was hard — add the permission, cache, or release problem.
—Add one outcomea number you can defend

The finished story. Switch to Process for the sketches, dead ends, and the bug that ate a week.

Live demo: tap the phone below, or press W, to fetch your real local weather with your permission. The mockup itself is illustrative; the demo is not.

Who it was for

To add

Add the real user and the moment they open the app: the commute, the school run, the walk to the station. One hand, three seconds.

The problem

To add

Add what the web version could not do and why a phone app was the right answer. If it was a learning project, say that instead.

How it works

To add

Add the framework, the weather API, the proxy, and the cache. Name what is stored on the device and what is fetched every time.

01Clientadd the framework and the screen
02Serveradd the API, auth, and cache
03Dataadd the database or the external API
Draft illustrative architecture — replace the nodes with the real stack
This diagram is a placeholder. It shows the shape of the explanation, not the stack.

The hard part

To add

Add the permission, the API key, or the offline state. The best version of this section explains a trade-off: accuracy versus speed, freshness versus a usable screen.

The outcome

To add

Add one number you can defend: cold start, APK size, or a real user's feedback. Do not invent a store rating.

What I would change

To add

Add one honest thing: a background refresh, a widget, or the component tests you skipped.

Draft case study. The structure is real; the details are placeholders. The live demo below is the only part that uses real data.

The process

Three moments from the build. Add real dates and commits when they exist; until then, this is the shape of the story.

  1. Step 01

    The screen

    Add the one screen you designed first and what you cut to keep it to three seconds.

  2. Step 02

    The key cannot live here

    Add how the app talks to the weather API without shipping a secret. A proxy, a serverless function, or a signed request.

  3. Step 03

    Offline is a state

    Add how the app behaves without a network. Does it show the last forecast, a timestamp, and an offline badge — or a spinner?