You are browsing as a guest. Sign up (or log in) to start making projects!

Mohamed_Ayadi

@Mohamed_Ayadi

Joined June 10th, 2026

  • 5Devlogs
  • 3Projects
  • 3Ships
  • 30Votes
Open comments for this post

2h 41m 49s logged

Pat I ch Notes: The “I Fixed That Annoying Stuff” UpdateHey everyone! I just rolled out a new update based on the feedback you gave me.
I tackled the biggest pain points today:Security Upgrade: No more hardcoded keys!
Quality of Life:
Training Tab: Lookin’ cleaner and more organized.
Nav Hover: Fixed that weird hover glitch that followed you between tabs.Check it out and let me know if you find anything else.

Pat I ch Notes: The “I Fixed That Annoying Stuff” UpdateHey everyone! I just rolled out a new update based on the feedback you gave me.
I tackled the biggest pain points today:Security Upgrade: No more hardcoded keys!
Quality of Life:
Training Tab: Lookin’ cleaner and more organized.
Nav Hover: Fixed that weird hover glitch that followed you between tabs.Check it out and let me know if you find anything else.

Replying to @Mohamed_Ayadi

0
5
Ship Changes requested

I made a history trivia game called History Guesser. It's a single HTML file that runs in any browser.

The concept is simple. A pin drops on a world map. A year appears at the bottom of the screen. You pick the correct historical event from four options. After you answer, the game shows you a description and a fun fact about the event. You learn something even when you get it wrong.

The game has 70 events spread across nine categories. War, Science, Politics, Exploration, Culture, Disaster, Sports, Business, and a few others. There are three difficulty levels. Easy, Medium, and Hard. You can filter by category and difficulty before you start. The game tracks your score and your streak.

What I'm proud of

The map actually works. The pin lands in the right place for each event. I spent hours tweaking coordinates to get that right.

The fun facts are my favorite part. I dug through Wikipedia to find interesting details that stick with you. Little things that make history memorable.

The quit button. It took more thought than it should have. Players need a clean way to exit without refreshing the page. I added a visible button plus Escape key support. Small thing, big difference.

The design feels warm, not cold and technical. Parchment colors, a compass rose, serif fonts. It feels like an old atlas. That was intentional.

What was challenging

The map was the hardest part. I tried drawing it with canvas polygons and failed miserably. Africa looked like a blob. Europe looked like a potato. Wasted two days on that approach. Switching to a background image solved the problem but introduced new ones.

Event placement was tedious. Every pin needed exact coordinates. I manually positioned 70 events. Refresh the page, adjust by 0.005, refresh again. Over and over.

Making difficulty levels feel meaningful was tricky. I mixed obscurity with age. Ancient events are harder by default. Recent ones are easier. It's not perfect but it works.

UI responsiveness took effort. Making the game work on both desktop and mobile required careful testing. Mobile-first approach, tested on actual devices.

If you want to test it

The game is a single file called index.html. You need a map image called img.jpg in the same folder. Any world map with clear country outlines works. Open index.html in any browser. No server required. No installation. No dependencies. Just double click and play.

If the map doesn't load, check that img.jpg is in the same folder. The file name must be exactly img.jpg. Case matters on some systems. The game also has an online fallback so it should still work.

The game should load instantly. The pin should appear smoothly. Buttons respond to both mouse and touch. Everything feels snappy.

Try different category and difficulty filters. Each combination changes the event pool significantly. Easy mode has mostly famous recent events. Hard mode tests more obscure moments in history.

If you find a bug or have a suggestion for more events, let me know. I'd like to add more categories eventually. Maybe a leaderboard or timer mode. But for now, this version does what I set out to do. It makes history feel less like a textbook and more like a discovery.

  • 1 devlog
  • 12h
Try project → See source code →
Open comments for this post

12h 17m 2s logged

Dev Log

So I had this idea. I wanted to make history feel physical, like it actually happened somewhere. Drop a pin. Show the year. Make people guess. That felt more like a game than a textbook.

The first version was a disaster. I tried drawing the world map myself using canvas polygons. Two days of tweaking coordinates and my map still looked like a deformed potato. Africa was a blob. Europe looked like it had been through a war. I finally gave up and switched to a real image.

Getting the map to work took way longer than I expected. Online images were slow. Base64 was huge. SVG was a nightmare. Eventually I just told people to drop a jpg in the same folder. It’s not fancy, but it works and it’s fast.

The pin placement was its own headache. Every event needed exact coordinates. Battle of Hastings needed to hit England. Columbus needed the Caribbean. Hours of refreshing the page and tweaking numbers by tiny amounts. My eyes hurt.

But building the event list was actually fun. I dug through Wikipedia looking for interesting stuff. War, science, politics, exploration, culture, disaster. Each event needed a year, location, description, and a fun fact. I probably spent too much time down rabbit holes. Did you know Beethoven was completely deaf when he conducted his ninth symphony? Or that the Mona Lisa has no eyebrows? I don’t regret a single minute of that.

Difficulty levels were tricky. I mixed obscurity with age. Ancient stuff is harder. Recent stuff is easier. It’s not perfect but it works.

Design wise, I wanted the game to feel warm — like an old atlas, not a corporate dashboard. Parchment colors, a compass rose, serif fonts. I wanted people to feel like they were opening a book from their grandparent’s shelf.

The quit button was a small thing that took too much thought. I realized people need an easy way out. So I put one in the corner and added Escape key support. Small detail, big difference.

What I learned: the little stuff matters. A good map makes the game feel real. A fun fact turns a correct answer into something you actually remember. A visible quit button shows you respect the user’s time.

I also learned that AI is useful for grinding through boilerplate and generating ideas faster than I could alone. But the creative stuff, the polish, the decisions about what actually feels good — that’s still on me. The AI sketches scaffolding. I build the house.

The result is a game that loads instantly, works on any device, and teaches you something without feeling like school. It’s not perfect. I’d love to add more events, better visuals, maybe some sound effects. But it’s solid, it’s fun, and I’m happy with it.

If you play it and learn one thing you didn’t know before, I’ll consider it a win.

Dev Log

So I had this idea. I wanted to make history feel physical, like it actually happened somewhere. Drop a pin. Show the year. Make people guess. That felt more like a game than a textbook.

The first version was a disaster. I tried drawing the world map myself using canvas polygons. Two days of tweaking coordinates and my map still looked like a deformed potato. Africa was a blob. Europe looked like it had been through a war. I finally gave up and switched to a real image.

Getting the map to work took way longer than I expected. Online images were slow. Base64 was huge. SVG was a nightmare. Eventually I just told people to drop a jpg in the same folder. It’s not fancy, but it works and it’s fast.

The pin placement was its own headache. Every event needed exact coordinates. Battle of Hastings needed to hit England. Columbus needed the Caribbean. Hours of refreshing the page and tweaking numbers by tiny amounts. My eyes hurt.

But building the event list was actually fun. I dug through Wikipedia looking for interesting stuff. War, science, politics, exploration, culture, disaster. Each event needed a year, location, description, and a fun fact. I probably spent too much time down rabbit holes. Did you know Beethoven was completely deaf when he conducted his ninth symphony? Or that the Mona Lisa has no eyebrows? I don’t regret a single minute of that.

Difficulty levels were tricky. I mixed obscurity with age. Ancient stuff is harder. Recent stuff is easier. It’s not perfect but it works.

Design wise, I wanted the game to feel warm — like an old atlas, not a corporate dashboard. Parchment colors, a compass rose, serif fonts. I wanted people to feel like they were opening a book from their grandparent’s shelf.

The quit button was a small thing that took too much thought. I realized people need an easy way out. So I put one in the corner and added Escape key support. Small detail, big difference.

What I learned: the little stuff matters. A good map makes the game feel real. A fun fact turns a correct answer into something you actually remember. A visible quit button shows you respect the user’s time.

I also learned that AI is useful for grinding through boilerplate and generating ideas faster than I could alone. But the creative stuff, the polish, the decisions about what actually feels good — that’s still on me. The AI sketches scaffolding. I build the house.

The result is a game that loads instantly, works on any device, and teaches you something without feeling like school. It’s not perfect. I’d love to add more events, better visuals, maybe some sound effects. But it’s solid, it’s fun, and I’m happy with it.

If you play it and learn one thing you didn’t know before, I’ll consider it a win.

Replying to @Mohamed_Ayadi

0
1
Ship

# AquaRead — Irrigation Need Predictor

**Know before you water. Save what the soil already has.**

---

## What did I make?

I built AquaRead — a tiny, browser-based tool that helps farmers decide how much water their field actually needs.

It's not another dashboard with charts for the sake of charts. It's a practical decision helper. You enter a handful of things you already know about your field — soil type, current moisture, crop, growth stage, recent rainfall, temperature — and the tool gives you back a clear prediction (Low, Medium, or High), a confidence breakdown, a plain-language explanation, and one practical thing you can do right now.

No login. No installation. No data sent anywhere. Just open the page, adjust the sliders, click predict, and get an answer. It's built to feel like a conversation with an agronomist friend — not a machine.

---

## What was challenging?

The hardest part was resisting the urge to overcomplicate things.

I had a full dataset with 14 columns — Electrical Conductivity, Organic Carbon, Wind Speed, Field Area, Mulching Used, Water Source, Region, Irrigation Type — all begging to be used. But irrigation need doesn't come from 14 things. It comes from a handful of core drivers: soil moisture, rainfall, temperature, crop stage, and soil type.

So I chose essentials over impressiveness. That meant leaving out data that didn't move the needle, trusting that farmers know their fields better than any dashboard ever could.

Another challenge: the dataset is unbalanced. About 59% show Low irrigation need, 38% show Medium, and only 3% show High. High need is genuinely rare — it only happens when moisture is low AND rainfall is low AND temperatures are high simultaneously. Getting the model to recognize that rarity without over-predicting High was a delicate balance.

---

## What am I proud of?

The explanation layer.

It would have been easy to just show "Low" and move on. But that's not useful. What's useful is telling someone WHY the model said Low — so they can trust it, disagree with it, or learn something about their field.

The explanation reads like: *"Based on adequate soil moisture, good recent rainfall, and moderate temperatures, the model suggests Low irrigation need."*

That's just connecting the dots in a way that makes sense to a human who's been watching the sky and feeling the soil.

I'm also proud of the confidence bars. They're simple — three horizontal bars — but they tell a story. When you see "Low: 72%, Medium: 22%, High: 6%" you know the model isn't guessing. It's weighing evidence. And when you see a tight spread — say, 45% / 40% / 15% — you know the conditions are borderline, and maybe you should trust your own judgment more.

---

## What should people know to test my project?

Here's how to kick the tires:

1. Open the page in any modern browser (Chrome, Firefox, Safari, Edge — they all work).
2. Play with the sliders and dropdowns. Try extreme conditions:
- Dry scenario: Moisture = 10%, Rainfall = 0mm, Temperature = 40°C → should return High.
- Wet scenario: Moisture = 55%, Rainfall = 1200mm, Temperature = 18°C → should return Low.
- Borderline: Moisture = 30%, Rainfall = 200mm, Temperature = 28°C, Crop = Rice, Stage = Flowering → often returns Medium with narrow confidence.
3. Read the explanation. Does it match what you'd expect? Does it feel like a real agronomist talking?
4. Look at the confidence bars. Are they wide or narrow? That tells you how clear-cut the conditions are.

The tool is trained on 10,000 records across four soil types, six crops, and three seasons. The model logic is rule-based — not a neural network, but a carefully weighted decision system that mimics how an agronomist thinks. It's transparent, predictable, and easy to tweak.

---

**Know before you water. Save what the soil already has.**

— AquaRead

  • 1 devlog
  • 5h
Try project → See source code →
Open comments for this post

5h 19m 19s logged

🌱 AquaRead — Devlog

aka “I built a plant hydration therapist”


The Origin Story

My mom kept drowning her garden. Every. Single. Day. Even after rain. I was like “Mom, you’re watering the tomatoes to death” and she hit me with “Well how am I supposed to know??”

So I built this instead of doing my math homework. Priorities, right?


What It Does

You punch in some numbers about your field — soil type, moisture, what you’re growing, weather stuff — and it spits out:

  • Low/Medium/High irrigation need
  • How confident it is (with a fancy bar chart)
  • Why it thinks that
  • One actually useful thing to do right now

No PhD required. No manual. Just sliders and dropdowns.


The Data

10,000 real farm records. Messy. Unbalanced. Perfect.

  • 59% Low irrigation
  • 38% Medium
  • 3% High (because emergencies are rare IRL)

The model had to learn that “High” actually matters, not just predict “Low” every time and call it a day.


What I Kept (and What I Threw Out)

Used:

  • Soil_Type, Soil_Moisture, Temperature, Humidity, Rainfall
  • Crop_Type, Growth_Stage, Season

Trashed:

  • Electrical_Conductivity, Organic_Carbon, Wind_Speed
  • Field_Area, Mulching, Water_Source, Region, Irrigation_Type

Why? Because irrigation need comes down to like 5 things. The rest is noise. Fight me.


The Design (aka “I care about colors”)

  • Forest green (#2d5a3d) — the serious backbone
  • Straw gold (#c9a84c) — warmth so it’s not a hospital
  • Sage for chill, terracotta for “OMG WATER YOUR CROPS”

Fonts: Literata for headings (book vibes), Plus Jakarta Sans for UI (clean but friendly), DM Mono for numbers (because monospaced numbers make my brain happy).

No charts-for-the-sake-of-charts. Just the confidence bar because “Low: 72%” is way more useful than just “Low.”


The Proud Moment

Mom tested it. Punched in her garden. Model said:

“Medium irrigation need. Soil moisture is adequate but temperature is rising. Consider watering in the evening to reduce evaporation.”

She looked at me like I hacked the Matrix. I was just like “yeah, JavaScript, whatever” but inside I was doing backflips.


What’s Next (v2.0)

  1. GPS weather lookup — auto-fill temperature and rainfall from a weather API
  2. History log — track predictions over time, see patterns

The Honest Part (AI helped)

Yeah I used AI. For the boilerplate. For the JavaScript I always forget. For debugging that one stupid bug where the bars wouldn’t render.

Not for the creative decisions. Not for the colors or the flow or the “vibe.” That’s all me.

Think of it as a coding intern who knows everything but has zero taste. I tell it what to build, it spits out code, I fix it, break it, fix it again, and make it actually good.


🌱 AquaRead — Devlog

aka “I built a plant hydration therapist”


The Origin Story

My mom kept drowning her garden. Every. Single. Day. Even after rain. I was like “Mom, you’re watering the tomatoes to death” and she hit me with “Well how am I supposed to know??”

So I built this instead of doing my math homework. Priorities, right?


What It Does

You punch in some numbers about your field — soil type, moisture, what you’re growing, weather stuff — and it spits out:

  • Low/Medium/High irrigation need
  • How confident it is (with a fancy bar chart)
  • Why it thinks that
  • One actually useful thing to do right now

No PhD required. No manual. Just sliders and dropdowns.


The Data

10,000 real farm records. Messy. Unbalanced. Perfect.

  • 59% Low irrigation
  • 38% Medium
  • 3% High (because emergencies are rare IRL)

The model had to learn that “High” actually matters, not just predict “Low” every time and call it a day.


What I Kept (and What I Threw Out)

Used:

  • Soil_Type, Soil_Moisture, Temperature, Humidity, Rainfall
  • Crop_Type, Growth_Stage, Season

Trashed:

  • Electrical_Conductivity, Organic_Carbon, Wind_Speed
  • Field_Area, Mulching, Water_Source, Region, Irrigation_Type

Why? Because irrigation need comes down to like 5 things. The rest is noise. Fight me.


The Design (aka “I care about colors”)

  • Forest green (#2d5a3d) — the serious backbone
  • Straw gold (#c9a84c) — warmth so it’s not a hospital
  • Sage for chill, terracotta for “OMG WATER YOUR CROPS”

Fonts: Literata for headings (book vibes), Plus Jakarta Sans for UI (clean but friendly), DM Mono for numbers (because monospaced numbers make my brain happy).

No charts-for-the-sake-of-charts. Just the confidence bar because “Low: 72%” is way more useful than just “Low.”


The Proud Moment

Mom tested it. Punched in her garden. Model said:

“Medium irrigation need. Soil moisture is adequate but temperature is rising. Consider watering in the evening to reduce evaporation.”

She looked at me like I hacked the Matrix. I was just like “yeah, JavaScript, whatever” but inside I was doing backflips.


What’s Next (v2.0)

  1. GPS weather lookup — auto-fill temperature and rainfall from a weather API
  2. History log — track predictions over time, see patterns

The Honest Part (AI helped)

Yeah I used AI. For the boilerplate. For the JavaScript I always forget. For debugging that one stupid bug where the bars wouldn’t render.

Not for the creative decisions. Not for the colors or the flow or the “vibe.” That’s all me.

Think of it as a coding intern who knows everything but has zero taste. I tell it what to build, it spits out code, I fix it, break it, fix it again, and make it actually good.


Replying to @Mohamed_Ayadi

0
0
Open comments for this post

1h 0m 52s logged

Recovery Quest — Devlog #1: the night this started making sense

Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up.

The thought that wouldn’t leave me alone

I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI?

In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time.

That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan.

The first version was straight up homework

What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter.

Nothing different from the five other apps I’d already downloaded and quit on.

Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night.

The dumb little rename that fixed everything

I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words.

But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me.

That tiny change became the seed for everything else.

Once that clicked, I couldn’t stop

After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat.

None of it was planned, it just kept clicking into place.

I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about.

And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?”

The feature that hit harder than expected

Memory Map started as a throwaway idea — one photo per day on a timeline.

But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it.

Claude was in the room for basically all of this

I didn’t build this alone.

That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?”

It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled.

I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of.

Why I kept going

Every time I added something, I’d get that “wait… this is actually a system now” feeling.

Rare enough that I kept chasing it.

Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics.

Hard to go back once you see it that way.

Devlog #1, done. More soon.

Recovery Quest — Devlog #1: the night this started making sense

Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up.

The thought that wouldn’t leave me alone

I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI?

In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time.

That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan.

The first version was straight up homework

What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter.

Nothing different from the five other apps I’d already downloaded and quit on.

Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night.

The dumb little rename that fixed everything

I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words.

But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me.

That tiny change became the seed for everything else.

Once that clicked, I couldn’t stop

After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat.

None of it was planned, it just kept clicking into place.

I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about.

And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?”

The feature that hit harder than expected

Memory Map started as a throwaway idea — one photo per day on a timeline.

But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it.

Claude was in the room for basically all of this

I didn’t build this alone.

That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?”

It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled.

I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of.

Why I kept going

Every time I added something, I’d get that “wait… this is actually a system now” feeling.

Rare enough that I kept chasing it.

Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics.

Hard to go back once you see it that way.

Devlog #1, done. More soon.

Replying to @Mohamed_Ayadi

0
1
Ship

What did you make?

I built Recovery Quest, a web application that transforms recovery and healthy habits into an RPG-style experience.

The idea started with a simple observation: taking care of ourselves often feels invisible. You sleep well, eat better, stay active, and make healthier choices, yet it's hard to see the impact of those small decisions from day to day. Without visible progress, motivation fades.

Recovery Quest changes that.

Users log information related to their sleep, nutrition, and exercise, and the system evaluates their overall recovery state. Instead of just displaying numbers, the app presents meaningful feedback through game-inspired progression systems. Healthy choices contribute to a sense of growth, turning recovery from an abstract concept into a journey users can actively follow.

The goal is simple: make taking care of yourself feel rewarding instead of repetitive.

What was challenging?

The biggest challenge was designing a system that felt encouraging without oversimplifying recovery.

Recovery isn't determined by a single factor. Sleep, nutrition, and physical activity all influence how someone feels, and I had to think carefully about how these elements should work together to generate useful feedback.

Another challenge was balancing the RPG elements. I didn't want Recovery Quest to become just another game with health-themed decorations. The progression systems had to support the main purpose of the app: helping users understand and improve their recovery habits.

Finding that balance between engagement and meaningful feedback required a lot of experimentation and refinement.

What are you proud of?

I'm proud that Recovery Quest makes something invisible feel visible.

Recovery is difficult to measure in everyday life. Most people don't notice the cumulative effect of sleeping better, eating more consistently, or exercising regularly until weeks later.

Recovery Quest highlights those small victories. Users can see how their habits influence their recovery state and receive feedback that encourages them to continue building healthier routines.

I'm also proud that I built the entire experience as a fully functional front-end application using HTML, CSS, and JavaScript, combining recovery tracking with engaging progression mechanics into one cohesive experience.

Most of all, I'm proud of creating something that encourages people to take care of themselves through positive reinforcement rather than guilt or pressure.

What should people know so they can test your project?

To test Recovery Quest, simply explore the app by entering information related to your sleep, nutrition, and exercise habits. The system will evaluate your recovery state and provide feedback based on the choices you make.

One important thing to note is that this version does not include a backend. If you log out, your data will be lost.

Despite this limitation, the complete recovery experience can still be explored, allowing users to understand the core idea behind Recovery Quest: turning the journey toward better well-being into an adventure worth returning to.

Try project → See source code →
Open comments for this post

10h 8m 51s logged

Recovery Quest — Devlog #1: the night this started making sense

Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up.

The thought that wouldn’t leave me alone

I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI?

In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time.

That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan.

The first version was straight up homework

What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter.

Nothing different from the five other apps I’d already downloaded and quit on.

Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night.

The dumb little rename that fixed everything

I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words.

But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me.

That tiny change became the seed for everything else.

Once that clicked, I couldn’t stop

After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat.

None of it was planned, it just kept clicking into place.

I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about.

And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?”

The feature that hit harder than expected

Memory Map started as a throwaway idea — one photo per day on a timeline.

But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it.

Claude was in the room for basically all of this

I didn’t build this alone.

That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?”

It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled.

I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of.

Why I kept going

Every time I added something, I’d get that “wait… this is actually a system now” feeling.

Rare enough that I kept chasing it.

Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics.

Hard to go back once you see it that way.

Devlog #1, done. More soon.

Recovery Quest — Devlog #1: the night this started making sense

Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up.

The thought that wouldn’t leave me alone

I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI?

In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time.

That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan.

The first version was straight up homework

What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter.

Nothing different from the five other apps I’d already downloaded and quit on.

Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night.

The dumb little rename that fixed everything

I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words.

But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me.

That tiny change became the seed for everything else.

Once that clicked, I couldn’t stop

After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat.

None of it was planned, it just kept clicking into place.

I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about.

And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?”

The feature that hit harder than expected

Memory Map started as a throwaway idea — one photo per day on a timeline.

But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it.

Claude was in the room for basically all of this

I didn’t build this alone.

That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?”

It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled.

I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of.

Why I kept going

Every time I added something, I’d get that “wait… this is actually a system now” feeling.

Rare enough that I kept chasing it.

Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics.

Hard to go back once you see it that way.

Devlog #1, done. More soon.

Replying to @Mohamed_Ayadi

0
1

Followers

Loading…