DEV Community: Ruhid Ibadli

How to Escape Tutorial Hell and Build Something Real (A Practical Roadmap)

Ruhid Ibadli — Thu, 05 Mar 2026 13:56:11 +0000

You've finished 3 Udemy courses. You've followed along with 20 YouTube tutorials. You can build a todo app with your eyes closed — as long as someone is telling you exactly what to type.

But open a blank VS Code window and try to build something from scratch?

Nothing. Blank screen. Panic.

Welcome to Tutorial Hell. Almost every developer has been here. Most never talk about how they got out.

I'm going to.

Why Tutorial Hell Happens

It's not a motivation problem. It's a knowledge type problem.

Tutorials teach recognition knowledge — you see the solution and think "that makes sense." But building requires recall knowledge — you need to produce the solution from nothing.

These are completely different cognitive processes. Watching someone cook doesn't make you a chef. Following a tutorial doesn't make you a developer.

The gap between "I understand this code" and "I can write this code" is enormous. Tutorials never close that gap because they never force you to struggle.

And struggle is where learning actually happens.

The 5-Stage Escape Plan

Stage 1: Stop Consuming. Today.

Not tomorrow. Not "after this one last course." Today.

Close the tutorial. Close the Udemy tab. Close the YouTube playlist. You have enough knowledge to start building. You've had enough knowledge for weeks — you just didn't believe it.

Here's the uncomfortable truth: you're watching tutorials because it feels productive without the risk of failure. Following along successfully gives you a dopamine hit without the pain of debugging, being stuck, or writing bad code.

That comfort is the trap.

Action: Unsubscribe from one coding tutorial channel right now. Not because they're bad — because you need to break the habit of consuming instead of creating.

Stage 2: Pick a Laughably Small Project

Your first real project should be embarrassingly simple. Not "build a full-stack e-commerce platform." Not "create a social media clone." Something you can finish in a weekend.

Good first projects:

A personal bookmark manager (save links with tags, search them)
A daily expense logger (add amounts, see weekly total)
A weather dashboard (call one API, display the data)
A countdown timer to an event you care about
A recipe box (add recipes, search by ingredient)
A markdown note-taker (type markdown, see preview)

Why small works: Finishing a project teaches you more than starting ten projects. The lessons are in the last 20% — deployment, edge cases, error handling, making it actually usable. You only reach the last 20% if the project is small enough to finish.

Action: Pick one project from the list above or invent your own. Write it down. That's your project. No changing it later.

Stage 3: The "Stuck Protocol"

You will get stuck. Not "might" — will. Multiple times per day. This is normal. This is where learning happens. But you need a system for getting unstuck, or you'll run back to tutorials.

The 30-Minute Rule:

When you hit a wall, follow this exact sequence:

Minutes 0-10: Try it yourself.

Read the error message. Actually read it — most error messages tell you exactly what's wrong.
Add console.log or print() statements to trace the flow.
Check if it's a typo. It's almost always a typo.
Re-read your code line by line, out loud if needed.

Minutes 10-20: Search specifically.

Google the exact error message in quotes.
Search Stack Overflow with the technology name + what you're trying to do.
Read the official documentation for the function/method you're using.
Don't search "how to build X" — search "how to do this specific small thing."

Minutes 20-30: Ask for help.

Post on Stack Overflow, Reddit, or a Discord community.
Describe what you expected, what happened instead, and what you tried.
Don't ask "how do I build a bookmark manager" — ask "how do I save a JSON object to localStorage and retrieve it."

After 30 minutes: If you're still stuck, move to a different part of the project. Work on the UI. Work on a different feature. Come back to the problem later with fresh eyes.

The goal isn't to never be stuck. The goal is to be stuck productively.

Stage 4: Build in Public (Even If Nobody's Watching)

This is the accelerator most people skip.

"Building in public" doesn't mean you need 10K Twitter followers. It means making your process visible — even if the audience is just you.

What to do:

Daily dev log. At the end of each coding session, write 3-5 sentences about what you built, what broke, and what you learned. Keep it in a simple text file or a markdown doc in your project.

## Day 3 - March 4

Built the "add bookmark" form. Took forever to figure out
controlled components in React. The input wasn't updating
because I forgot to use the setter from useState.
Also learned that localStorage only stores strings,
so I need JSON.stringify/parse. Obvious in hindsight.

Tomorrow: build the search/filter feature.

Why this works:

It forces reflection. Writing about what you learned solidifies it.
It shows progress. On day 12, you can look back at day 1 and see how far you've come.
It creates content. That dev log? It's a blog post draft. Those struggles? They're tweets. Your process is valuable to someone one step behind you.
It builds accountability. Even if nobody reads it, the act of writing "I didn't code today" is uncomfortable enough to keep you going.

Action: Create a devlog.md file in your project root. Write your first entry today.

Stage 5: Ship It Ugly

Your project won't be perfect. Ship it anyway.

The CSS will be weird. The error handling will be incomplete. The code structure will make you cringe in 3 months. There will be a bug on mobile that you can't figure out.

Ship. It. Anyway.

Here's why: the gap between "working locally" and "deployed on the internet" teaches you more than 5 tutorials combined:

How to set up a domain
How to configure environment variables in production
How to handle CORS
How HTTPS works
How to debug something that works locally but breaks in production
How deployment pipelines work

None of this is taught in tutorials. All of it is essential.

Free deployment options:

Frontend: Vercel, Netlify, GitHub Pages
Backend: Railway, Render, Fly.io
Database: Supabase (PostgreSQL), PlanetScale (MySQL)
Full-stack: A $5 VPS on DigitalOcean or Hetzner

Action: Deploy your project before you think it's ready. Get a URL you can share. Put it on your GitHub. The bar isn't "perfect" — the bar is "it exists on the internet."

What Happens After Your First Project

Something shifts after you ship your first project without following a tutorial.

You start seeing code differently. When you encounter a problem, your first instinct is no longer "find a tutorial." It's "I'll figure it out." That instinct is the entire difference between a tutorial consumer and a developer.

Your second project will be easier. Not because you know more — but because you trust yourself more. You've proven you can be stuck, struggle, and still ship.

Your third project will be ambitious. You'll pick something that scares you a little. And you'll build it.

The "What Should I Build?" Framework

If you're stuck on ideas, use this framework:

1. Solve Your Own Problem

What annoys you? What do you track in a spreadsheet? What do you wish existed?

The best projects come from personal frustration. You understand the problem deeply, you're the first user, and you actually care about the result.

2. Clone Something, Then Change It

Take an app you use and rebuild the core feature. Not all of it — just one feature:

Rebuild the tweet composer from Twitter (character count, preview)
Rebuild the playlist creator from Spotify (drag-and-drop reorder)
Rebuild the kanban board from Trello (columns, drag cards)

Then change one thing. Add a feature the original doesn't have. Now it's not a clone — it's your take on the idea.

3. Combine Two Things

Take a concept from one domain and apply it to another:

Tinder but for choosing what to cook (swipe recipes)
GitHub contribution graph but for any habit
Duolingo's streak system but for reading books

These often make great portfolio pieces because they're immediately understandable and slightly surprising.

The Skills You Actually Need (And The Ones You Don't)

Here's what you need to build a real project:

Must have:

HTML/CSS basics (enough to make a form and a list)
One programming language (JavaScript, Python, whatever you've been learning)
How to read error messages
How to use Git (add, commit, push — nothing fancy)
How to Google effectively

Nice to have:

A frontend framework (React, Vue, Svelte)
A backend framework (Express, FastAPI, Django)
Basic database knowledge (SQL or a simple ORM)

You don't need:

TypeScript (learn it after your first project)
Docker (learn it after your third project)
CI/CD (learn it when you have something to deploy regularly)
Testing frameworks (learn it after you've felt the pain of not having tests)
Kubernetes (you may never need this)
Microservices (you will definitely never need this for a personal project)

Stop learning tools "just in case." Learn them when a real project demands them. The demand creates the motivation, and the context makes the knowledge stick.

Common Traps (And How to Avoid Them)

Trap 1: "I need to learn X before I can start"

No you don't. Start with what you know. Learn X when you hit a wall that requires it. Just-in-time learning beats just-in-case learning every time.

Trap 2: "My code is too messy to show anyone"

Everyone's first project is messy. Ship it anyway. Nobody is going to judge your bookmark manager's code structure. And if they do, they've forgotten what it's like to be a beginner.

Trap 3: "Someone already built this"

Someone already built everything. That's not the point. You're not building it for the market — you're building it for yourself. The goal is the skill you gain, not the product you ship.

Trap 4: "I'll start after I set up the perfect dev environment"

Spending 3 days configuring ESLint, Prettier, Husky, and a custom VS Code theme is procrastination disguised as productivity. Create React App or npm init and start writing code.

Trap 5: Switching projects when it gets hard

The hardest part of every project is the middle. The beginning is exciting. The end is rewarding. The middle is where you're stuck on a bug, the UI looks terrible, and you're questioning why you started.

Push through the middle. That's where all the learning is.

A Realistic Timeline

Here's what the escape from Tutorial Hell actually looks like:

Week 1: Pick a project. Set up the repo. Build the most basic version — one screen, one feature, ugly as hell. Push to GitHub.

Week 2: Add one more feature. Hit 3-5 bugs. Solve them. Feel frustrated. Feel proud. Push updates.

Week 3: Try to deploy. Fail. Google the error. Fix it. Deploy again. Get a live URL. Send it to one person.

Week 4: Look at your code from week 1. Cringe. This is growth. Resist the urge to rewrite everything. Add one more feature instead.

Week 5+: Start your second project. This time, you won't need a roadmap. You'll know what to do.

Total time: one month from Tutorial Hell to shipped project. Not perfect. Not polished. But real.

The Truth Nobody Tells You

Here's what every senior developer knows but most beginners haven't figured out yet:

Nobody knows what they're doing at first. Every developer you admire went through the same blank-screen panic. The same "I'm not smart enough" thoughts. The same painful debugging sessions. The difference is they pushed through it early enough to build the confidence that compounds over time.

Tutorials are training wheels. They're necessary at first. But at some point, you have to take them off and wobble. You'll fall. You'll get back on. And one day you won't even remember what the training wheels felt like.

Your first project will be bad. That's the point. Ship it, learn from it, and build the next one better. The developer who has shipped 5 ugly projects has more real skill than the developer who has completed 50 polished tutorials.

Stop preparing. Start building. The blank screen is waiting, and it's not as scary as you think.

Are you currently stuck in Tutorial Hell? Or did you escape — and how? Share your story in the comments. Every journey out looks different, and yours might be the one that helps someone else take the first step.

The Overengineering Trap: You're Building a Spaceship When You Need a Bicycle

Ruhid Ibadli — Wed, 04 Mar 2026 19:01:13 +0000

You sit down to build a simple app. A to-do list, maybe. A personal dashboard. A small SaaS.

Three weeks later, you have:

A Kubernetes cluster
A microservice architecture with 6 services
An event-driven message queue
A custom authentication system with OAuth, SAML, and magic links
A CI/CD pipeline with 14 stages
Zero users

Congratulations. You've built a spaceship to go to the grocery store.

I've done this. You've done this. Let's talk about why, and how to stop.

Why We Overengineer

Before the practical stuff, let's be honest about the psychology:

1. It feels productive. Setting up infrastructure feels like building the product. You're writing code, solving problems, seeing progress. But you're solving imaginary problems for imaginary users at imaginary scale.

2. It's more fun. Configuring Kubernetes is more interesting than building a settings page. Writing a custom ORM is more exciting than handling form validation. We gravitate toward interesting problems, not important ones.

3. Resume-Driven Development. Deep down, we sometimes pick technologies because we want them on our resume, not because the project needs them. "Built a distributed event-sourcing system" looks better in an interview than "used SQLite and a cron job."

4. Fear of rebuilding. "But what if we get 100,000 users and need to scale?" You won't. And if you do, that's the best problem you'll ever have. You can rebuild then.

5. Tutorial culture. Every YouTube tutorial and Medium article shows you the "production-ready" setup. Docker, Redis, Nginx, load balancers, monitoring dashboards. For a project with one user: you.

9 Signs You're Overengineering

1. Your infrastructure is more complex than your business logic

If your Docker Compose file has more services than your app has features, something is wrong.

# This is a red flag for a side project
services:
  api-gateway:
  auth-service:
  user-service:
  notification-service:
  analytics-service:
  redis:
  rabbitmq:
  elasticsearch:
  postgres:
  pgadmin:
  prometheus:
  grafana:

12 services. Zero paying customers. Your docker-compose.yml is doing more work than your app.

2. You're solving scale problems at zero scale

"We need Redis for caching because database queries will be slow at scale."

How many users do you have? 3? Your database can handle 3 users. PostgreSQL can handle thousands of queries per second on a $5 VPS. You'll run out of motivation before you run out of database capacity.

Rule of thumb: If you can count your users on your fingers, SQLite is probably enough.

3. You're abstracting before you have two use cases

// You have ONE button in your app
// But you built this:
interface ButtonProps<T extends ButtonVariant> {
  variant: T;
  size: ButtonSize;
  colorScheme: ColorScheme;
  isLoading?: boolean;
  loadingText?: string;
  spinnerPlacement?: 'start' | 'end';
  iconSpacing?: string;
  leftIcon?: React.ReactElement;
  rightIcon?: React.ReactElement;
  onClick?: (event: ButtonClickEvent<T>) => void | Promise<void>;
  onHoverStart?: () => void;
  onHoverEnd?: () => void;
  renderAs?: React.ElementType;
  // ... 15 more props
}

You don't need a design system. You need a <button>.

The rule is simple: don't abstract until you have at least three concrete use cases. Two similar things are a coincidence. Three are a pattern.

4. You're writing "reusable" utilities for one-time operations

# You used this function exactly once
def transform_data_pipeline(
    data: List[Dict],
    transformers: List[Callable],
    validators: List[Validator],
    error_handler: ErrorHandler,
    retry_config: RetryConfig,
    batch_size: int = 100
) -> TransformResult:
    ...

If a function is called in one place, it doesn't need to be configurable. Inline it. Write the specific thing. Three lines of "duplicated" code is better than a premature abstraction.

5. Your setup instructions are longer than your README

If a new developer needs 45 minutes and a PhD in DevOps to run your project locally, you've optimized for the wrong thing.

# This is all your side project should need:
git clone repo
cp .env.example .env
docker-compose up

If it takes more than 3 commands, question every additional step.

6. You're handling errors that can't happen

def get_user_name(user: User) -> str:
    if user is None:
        raise ValueError("User cannot be None")
    if not isinstance(user, User):
        raise TypeError("Expected User instance")
    if user.name is None:
        return "Unknown"
    if not isinstance(user.name, str):
        return str(user.name)
    if len(user.name) == 0:
        return "Unknown"
    if len(user.name) > 10000:
        return user.name[:10000]
    return user.name

Your type system already guarantees most of this. Your ORM won't return a non-User from a User query. Trust your tools. Validate at boundaries (user input, external APIs), not inside your own code.

7. You picked a technology stack before understanding the problem

"I'm going to build my next project with Go, gRPC, and Kafka."

What's the project?

"I haven't decided yet."

The stack should serve the problem. If you choose the stack first, you'll bend the problem to fit the stack — and end up overcomplicating simple things because your tools expect complexity.

8. You have more config files than source files

Count your root-level config files:

.eslintrc.js
.eslintignore
.prettierrc
.prettierignore
.stylelintrc
.editorconfig
.babelrc
tsconfig.json
tsconfig.build.json
tsconfig.node.json
jest.config.ts
vitest.config.ts
postcss.config.js
tailwind.config.js
vite.config.ts
docker-compose.yml
docker-compose.dev.yml
docker-compose.prod.yml
docker-compose.test.yml
Dockerfile
Dockerfile.dev
Dockerfile.prod
.github/workflows/ci.yml
.github/workflows/cd.yml
.github/workflows/codeql.yml
.husky/pre-commit
.husky/pre-push
commitlint.config.js
lint-staged.config.js

28 config files. You haven't written the app yet. Most of these exist because a "best practices" article told you to add them.

9. You can't explain your architecture in one sentence

If your architecture requires a 15-minute presentation with a diagram, it's too complex for the problem you're solving.

Good: "A Python API with a PostgreSQL database and a React frontend."

Bad: "An event-sourced CQRS architecture with command handlers publishing to a message bus consumed by projection workers that update read models in Elasticsearch, fronted by a BFF gateway layer that aggregates responses for a micro-frontend shell application."

Both could be solving the same problem. One ships. The other gets presented at a meetup and never launches.

The Boring Stack Manifesto

Here's what actually works for 90% of web projects:

Need	Boring Solution
API	One monolithic framework (Django, FastAPI, Rails, Express)
Database	PostgreSQL. That's it.
Cache	Your database is fast enough. If it's not, add an index.
Background jobs	Cron. Literally cron.
Auth	JWT + bcrypt. Or use a library.
Deployment	A single VPS + Nginx
CI/CD	GitHub Actions with 2-3 steps
Monitoring	Logs. `grep` your logs.
State management	React Context or `useState`. Not Redux.
Styling	Tailwind or plain CSS

No microservices. No Kubernetes. No Redis. No message queues. No service mesh.

You can serve thousands of concurrent users with a $20/month VPS running a monolith. Basecamp does billions in revenue on a monolith. Stack Overflow serves millions of developers with a handful of servers.

When Complexity IS Justified

I'm not saying all complexity is bad. It's justified when:

You have evidence. Your database is actually slow (you measured it). Your monolith actually can't handle the load (you profiled it). Your deployment actually needs zero-downtime (users complained).

You have the team. Microservices require a team per service. If you're a solo developer or a team of 3, a monolith is not a compromise — it's the correct architecture.

The domain is genuinely complex. Payment processing, real-time collaboration, distributed systems — some problems require sophisticated solutions. But most CRUD apps are not these problems.

You'll maintain it. The fanciest architecture in the world is technical debt if nobody understands it in 6 months.

The Simplicity Checklist

Before adding any technology, library, or architectural pattern, ask:

Can I ship without this? If yes, don't add it.
Am I solving a current problem or a future one? If future, don't add it.
Will a junior developer understand this? If not, simplify it.
Am I adding this because I want to learn it? That's fine — just be honest about it. Call it a learning project, not a product.
Can I explain why I need this in one sentence? If not, you probably don't need it.

The Best Code I Ever Wrote

The best code I ever wrote wasn't clever. It wasn't scalable. It wasn't "production-ready" by any blog post standard.

It was simple. It worked. It shipped.

A monolithic Python API. A PostgreSQL database. A React frontend. Deployed on a single VPS with Nginx. Background jobs running on cron. Plain text emails sent with smtplib.

No one has ever complained about the architecture. Users complain about missing features, confusing UI, and slow pages. They never complain about your infrastructure choices.

Ship the bicycle. You can build the spaceship later — when you actually need to go to space.

What's the most overengineered thing you've ever built? I want to hear your confessions in the comments. No judgment — we've all been there.

How I Modeled the Forgetting Curve in 40 Lines of Python

Ruhid Ibadli — Wed, 04 Mar 2026 13:04:53 +0000

In 1885, Hermann Ebbinghaus sat in a room and memorized nonsense syllables. Then he measured how quickly he forgot them. The result — the forgetting curve — showed that memory decays exponentially. You lose the most in the first few days, then the decline slows.

140 years later, I used that same curve to build the core algorithm behind SkillFade, a skill tracking app. Here's exactly how it works, why I made the choices I did, and what I'd change.

The Problem: Quantifying "Rustiness"

Every developer knows the feeling. You spent two weeks deep in Docker, then three months pass, and suddenly docker-compose feels like a foreign language. You know the skill decayed, but by how much? When did it start? How does it compare to your Python knowledge, which you use daily?

I needed a single number — a freshness score from 0 to 100 — that answers: "How sharp is this skill right now?"

The constraints:

Must decay automatically over time without user input
Practice should reset the clock; learning should only slow the decay
Different skills should decay at different rates
The math should be simple enough to explain in a sentence

The Core: Exponential Decay

Linear decay (lose 1% per day) doesn't match reality. You don't forget at a constant rate — you forget fast at first, then slower. Exponential decay captures this:

freshness = 100 * (retention_rate ^ days_since_last_practice)

With a default retention rate of 0.98 (2% daily decay):

Days Without Practice	Freshness
0	100%
7	87%
14	75%
30	55%
60	30%
90	16%
120	9%

This feels right. After a week, you're still sharp. After a month, things are fuzzy. After three months, you're starting over.

Why Practice Resets, But Learning Doesn't

This was the most important design decision in the algorithm.

When you practice a skill (build a project, solve exercises, write code at work), you're actively retrieving knowledge from memory. Cognitive science calls this the testing effect — retrieval strengthens memory far more than re-exposure.

When you learn (read an article, watch a tutorial, go through documentation), you're consuming information. It helps, but it doesn't create the same neural pathways as active recall.

So in the algorithm:

Practice resets the decay clock. Your freshness restarts from 100%.
Learning adds a small boost. Each recent learning event adds 2% freshness, capped at 15%.

This means you can read 10 articles about Kubernetes and your freshness might go from 40% to 55%. But one afternoon actually deploying a cluster? Back to 100%.

The Implementation

Here's the actual Python function, simplified from the production code:

from datetime import date, timedelta
from typing import Optional

def calculate_freshness(
    practice_dates: list[date],
    learning_dates: list[date],
    skill_created: date,
    decay_rate: float = 0.02
) -> float:
    today = date.today()

    # Find the anchor point: last practice, or skill creation
    if practice_dates:
        last_practice = max(practice_dates)
    else:
        last_practice = skill_created

    # Days since last practice
    days_elapsed = (today - last_practice).days

    # Base decay: exponential
    retention_rate = 1.0 - decay_rate
    freshness = 100.0 * (retention_rate ** days_elapsed)

    # Learning boost: recent learning slows the fade
    thirty_days_ago = today - timedelta(days=30)
    recent_learning = sum(
        1 for d in learning_dates if d >= thirty_days_ago
    )
    learning_boost = min(recent_learning * 2, 15)

    freshness += learning_boost

    # Clamp to 0-100
    return max(0.0, min(100.0, freshness))

That's it. ~30 lines of actual logic. No machine learning. No complex statistical models. Just exponential decay with a learning modifier.

Making Decay Rates Configurable

Not all skills decay at the same speed. Spoken languages fade fast without immersion. Bicycle-riding-type motor skills barely fade at all. Programming languages sit somewhere in between.

I added per-skill decay rates with sensible presets:

DECAY_PRESETS = {
    "slow":     0.01,   # 1% per day — motor skills, deep expertise
    "default":  0.02,   # 2% per day — most technical skills
    "fast":     0.03,   # 3% per day — languages, frameworks with churn
    "very_fast": 0.05,  # 5% per day — memorization-heavy, trivia
}

The difference is dramatic over 30 days:

Decay Rate	Freshness at Day 30
1% (slow)	74%
2% (default)	55%
3% (fast)	40%
5% (very fast)	21%

Users can set custom rates per skill. Someone maintaining five programming languages might set Go (used daily) to slow decay and Rust (learning on weekends) to fast decay.

The Anchor Point Problem

One subtle decision: what happens when a skill has never been practiced?

Option A: Start at 0% freshness. But that feels wrong — you just created the skill, you presumably know something about it.

Option B: Start at 100% and decay from the creation date. This is what I chose. When you add "Python" to your tracker, you start fresh. The clock begins ticking immediately. If you don't log a practice event, your freshness will naturally decline.

This creates a useful pressure: adding a skill is a commitment. You're saying "I want to track this," and the app immediately starts showing you the decay. It's honest from day one.

# The anchor is either last practice or skill creation
if practice_dates:
    last_practice = max(practice_dates)
else:
    last_practice = skill_created  # Decay starts at creation

Why I Capped the Learning Boost at 15%

Early versions had no cap on the learning boost. The problem: a user could watch 20 YouTube tutorials in a week and see their freshness jump from 30% to 70% without ever touching a keyboard.

That defeats the entire purpose. The app is supposed to show you that consumption isn't retention.

The 15% cap means learning can slow the bleeding, but it can't substitute for practice. The numbers:

Base freshness (60 days, no practice): 30%
+ 1 learning event in last 30 days:   32%
+ 3 learning events:                  36%
+ 5 learning events:                  40%
+ 8+ learning events:                 45% (capped)

You can read your way from 30% to 45%, but to get back above 70%, you need to actually practice.

Freshness History: Tracking the Curve Over Time

A single freshness number is useful, but the trend is more interesting. I built a history endpoint that reconstructs what the freshness would have been on each day over the past N days:

def calculate_freshness_history(
    practice_dates: list[date],
    learning_dates: list[date],
    skill_created: date,
    days: int = 90,
    decay_rate: float = 0.02
) -> list[dict]:
    history = []
    today = date.today()

    for day_offset in range(days, -1, -1):
        target_date = today - timedelta(days=day_offset)

        # Only consider events before or on this date
        practices_before = [d for d in practice_dates if d <= target_date]
        learnings_before = [d for d in learning_dates if d <= target_date]

        # Calculate what freshness was on that day
        if practices_before:
            anchor = max(practices_before)
        else:
            anchor = skill_created

        days_elapsed = (target_date - anchor).days
        retention = 1.0 - decay_rate
        freshness = 100.0 * (retention ** max(0, days_elapsed))

        # Learning boost (events within 30 days of target_date)
        window_start = target_date - timedelta(days=30)
        recent = sum(1 for d in learnings_before if d >= window_start)
        freshness += min(recent * 2, 15)
        freshness = max(0.0, min(100.0, freshness))

        history.append({
            "date": target_date.isoformat(),
            "freshness": round(freshness, 1)
        })

    return history

This produces a line chart where you can see the exponential decay curves, the sharp jumps when you practice, and the small bumps when you learn. It tells a story that a single number can't.

Edge Cases I Hit in Production

1. Future-dated events

Users can log events in the past (backdating), but what about the future? A practice event dated tomorrow would make days_elapsed negative, pushing freshness above 100%.

Fix: max(0, days_elapsed) — treat future events as "today."

2. Same-day multiple events

If you practice and learn on the same day, the order shouldn't matter. Since we only look at dates (not timestamps), this works naturally.

3. Zero learning, zero practice

A skill with no events at all just decays from 100% starting at creation. No division-by-zero, no special cases needed.

4. Very old skills

A skill created 365 days ago with no practice: 100 * 0.98^365 = 0.06%. Effectively zero. The clamp handles this — it shows 0%, not a tiny decimal.

What I Considered But Didn't Build

Spaced repetition scheduling. Systems like Anki calculate optimal review intervals. I explicitly avoided this because SkillFade is a mirror, not a coach. It shows decay; it doesn't prescribe when to practice.

Weighted event types. Should a 3-hour project count more than a 15-minute exercise? Probably. But adding weights adds complexity and subjective tuning. I kept it simple: one practice event = one clock reset, regardless of duration.

Collaborative decay. In teams, you could model shared skill decay — if nobody on the team has touched Terraform in 60 days, flag it. Interesting, but it would require social features, which violates the design principles.

ML-based personal decay curves. With enough data, you could learn each user's actual forgetting rate per skill. But this violates the "no AI/ML" constraint, and honestly, the exponential model works well enough.

The Takeaway for Your Own Projects

If you need to model something that degrades over time — cache staleness, content freshness, user engagement risk — exponential decay is almost always the right starting point:

value = initial * (retention_rate ** time_elapsed)

Three parameters. One line of math. Adjust the retention rate to match your domain.

The hard part isn't the algorithm. It's deciding what resets the clock, what slows the decay, and what you refuse to let cheat the system. Those are product decisions disguised as math.

You can see this algorithm in action at skillfade.website. Create an account, add a skill, and watch the decay begin.

Because the first step to retaining knowledge is measuring how fast it disappears.

Built with Python, FastAPI, React, and PostgreSQL. The algorithm runs on every page load — no caching, no background jobs, just real-time math.

You're Consuming Too Much and Creating Too Little

Ruhid Ibadli — Sat, 31 Jan 2026 18:35:30 +0000

Last year I tracked my "learning" hours:

120+ hours of YouTube tutorials
40+ hours of online courses
Countless articles, blog posts, documentation pages

Sounds productive, right?

Then I tracked my "building" hours:

3 side projects started, 0 finished
Maybe 30 hours of actual coding outside work

The ratio was embarrassing: 4:1 consumption to creation.

I was a learning addict who never actually learned anything.

The Input/Output Trap

Developers fall into this trap constantly. We:

Watch tutorial after tutorial
Save hundreds of "read later" articles
Bookmark GitHub repos we'll "explore someday"
Buy courses on sale "for when I have time"

It feels like progress. Our brains reward us with dopamine for "discovering" new information. But discovery isn't learning. Consumption isn't skill.

The uncomfortable truth: if you're not building, you're not learning.

Why We Prefer Input

Input is easy. Output is hard.

Watching a video is passive. Your brain can half-engage while you feel productive. Building something requires focus, problem-solving, failure, frustration.

Input has no failure state. You can't "fail" at watching a tutorial. But you can absolutely fail at implementing what it taught. That failure feels bad, so we avoid it.

Input is infinite. There's always another video, another article, another course. Output has an end point—you have to ship something eventually.

So we keep consuming. And keep not-learning.

The Ratio That Matters

I started tracking my input/output ratio:

Input: Tutorials, courses, articles, videos, documentation
Output: Projects, code, writing, teaching, contributing

A healthy ratio for actual skill building? At least 1:1.

For every hour you consume, spend an hour creating. Watch a React video? Build a component. Read about Docker? Deploy something. Learn a new pattern? Refactor old code to use it.

Better yet: lead with output.

Don't watch a tutorial on authentication. Try to build it first. Get stuck. Then watch the tutorial. Now you have context. Now you'll remember.

The Tutorial Purgatory

You know the pattern:

Want to learn X
Search "X tutorial for beginners"
Watch 4-hour video series
Feel accomplished
Never use X
Forget everything
Months later, repeat from step 1

This is tutorial purgatory. Infinite consumption, zero retention.

The way out is simple but painful: build something before you feel ready.

You'll fail. You'll get stuck. You'll write bad code. That struggle is the learning. The tutorial was just entertainment.

What I Changed

I set rules for myself:

The 1:1 rule - Match consumption time with creation time. Watched a 2-hour course? Spend 2 hours building with it.

The 24-hour rule - If I learn something, I must use it within 24 hours or it doesn't count as learning.

The teach rule - If I can't explain it simply, I didn't learn it. Writing a blog post or explaining to a colleague forces real understanding.

The project-first rule - Start the project before the tutorial. Use tutorials as reference, not curriculum.

Tracking the Balance

This input/output problem is why I built balance tracking into SkillFade.

Every skill shows two numbers:

Learning events (input)
Practice events (output)

The ratio is visible. When it skews too far toward input, you see it. No judgment—just data showing you've been consuming more than creating.

It's a mirror. And sometimes the reflection is uncomfortable.

The Question

Look at your last month:

How many tutorials did you watch?
How many projects did you ship?
How many articles did you read?
How many articles did you write?
How many courses did you complete?
How many things did you build with that knowledge?

If the first number is always bigger than the second, you're not learning. You're just watching.

What's your input/output ratio? And what are you going to build this week?

Why You've Already Forgotten Half of What You Learned Last Month

Ruhid Ibadli — Fri, 30 Jan 2026 12:37:21 +0000

In 1885, German psychologist Hermann Ebbinghaus memorized nonsense syllables and tracked how quickly he forgot them.

His discovery is now called the Ebbinghaus Forgetting Curve, and it's brutal:

After 1 day: ~70% forgotten
After 1 week: ~90% forgotten
After 1 month: almost everything gone

This was 140 years ago. The finding has been replicated countless times since. And yet we still act surprised when we can't remember that tutorial we watched last month.

The Uncomfortable Math

Let's say you completed a Docker course last month. You were excited. You understood containers, images, volumes, networking. You felt competent.

Today? Without practice, you've retained maybe 10-20% of that knowledge. The rest is gone. Not "rusty"—gone. Your brain literally pruned those neural connections because you didn't use them.

This isn't a personal failing. It's biology.

Why Practice Beats Learning

Ebbinghaus also discovered something else: active recall dramatically slows forgetting.

When you passively watch a video, information enters short-term memory and mostly disappears. When you actively use that information—write code, solve problems, build projects—it moves to long-term memory.

The difference is massive:

Activity	Retention after 1 month
Watched a video	~10%
Took notes	~20%
Did exercises	~50%
Built a project	~70%+

This is why tutorials feel productive but rarely stick. You're not learning—you're spectating.

The Learning Trap

Modern learning platforms accidentally exploit this gap.

You watch 10 hours of Python tutorials. The platform shows you a completion bar at 100%. You get a certificate. You feel accomplished.

But completion ≠ competence. You consumed content. You didn't build skills.

The platform doesn't care. Their metric is "courses completed," not "skills retained." They're optimized for your feeling of progress, not actual progress.

What Actually Works

Spaced repetition - Review material at increasing intervals (1 day, 3 days, 1 week, 2 weeks). Each review resets the forgetting curve.

Active recall - Don't re-read notes. Close them and try to remember. The struggle of retrieval strengthens memory.

Project-based learning - Build something real. Applied knowledge sticks. Tutorial knowledge evaporates.

Interleaving - Mix different skills in practice sessions. Harder in the moment, better for retention.

None of this is new. Cognitive scientists have known it for decades. We just keep ignoring it because passive learning feels easier.

Tracking Decay

I built SkillFade to make this forgetting visible.

Every skill you track has a freshness percentage that decays over time:

Practice something → freshness resets to 100%
Learn something (video, article) → small boost, but decay continues
Do nothing → freshness drops ~2% per day

After a month of no practice, a skill shows ~55% freshness. After two months, ~30%. The red warning color makes the decay impossible to ignore.

It's not gamification. There's no streak to maintain, no badge to earn. Just honest data: here's what you're forgetting.

The Point

Your skills are decaying right now. The Python you learned six months ago. The SQL from that online course. The framework from your last job.

Most of it is already gone. Not because you're bad at learning—because that's how human memory works.

The question isn't whether you're forgetting. You are. The question is: which skills are worth maintaining?

Pick the ones that matter. Practice them regularly. Let the rest go.

At least now you're making that choice consciously.

What skills have you let decay? And which ones are you actively maintaining?

I Built a Skill Tracker Because I Was Tired of Lying to Myself

Ruhid Ibadli — Thu, 29 Jan 2026 15:40:35 +0000

Six months ago I listed "Kubernetes" on my resume.

The truth? I watched a tutorial series, deployed one pod, and never touched it again. Could I debug a failing cluster in an interview? Absolutely not.

But it felt good to write "Kubernetes" on that skills list. It felt like progress. I was "learning."

Sound familiar?

The Problem

We all do this. We consume courses, watch tutorials, read documentation—and call it learning. Our skill lists grow. Our actual abilities don't.

I call it skill inflation: the gap between what we claim to know and what we can actually do.

The existing tools didn't help. Duolingo gave me streaks that made me feel accomplished while I forgot basic vocabulary. LinkedIn Learning gave me certificates for videos I half-watched. Every app was designed to make me feel good, not to show me the truth.

What I Wanted

A tool that would answer one honest question: What am I actually forgetting?

Not what courses I completed. Not how many days in a row I logged in. Not how I compare to other users.

Just: here are your skills, here's how fresh they are, here's what's decaying.

So I Built It

SkillFade tracks your skills and shows their freshness—a percentage that decays over time without practice.

Finished a React course? Freshness starts at 50% (learning boost only).
Built a React project? Now you're at 100%.
Haven't touched React in 60 days? You're at 30% and dropping.

That's it. No badges. No streaks. No leaderboards. No AI telling you what to learn next.

Just data about what you're forgetting.

How It Works

Add skills you want to track (Python, Docker, Spanish, whatever)
Log events when you learn (watched a video) or practice (built something)
Check freshness to see what's decaying

The dashboard shows everything at a glance:

🟢 Green = Fresh (>70%)
🟡 Yellow = Aging (40-70%)
🔴 Red = Decayed (<40%)

Optional email alerts (max 1/week) tell you when skills drop below your threshold.

What Makes It Different

Practice > Learning

Most apps treat all activity equally. SkillFade doesn't. Practice resets your freshness. Learning only slows decay.

This reflects reality: watching a Kubernetes video isn't the same as deploying a cluster.

No Gamification

No streaks to maintain. No badges to collect. No points to accumulate. Miss a week? Your freshness drops a bit. That's information, not punishment.

Privacy First

No tracking. No analytics. No data sharing. Full export and delete anytime. Your skill decay is nobody's business.

Calm Design

The app doesn't fight for your attention. No push notifications. No "come back!" emails. Log your stuff, check your freshness, leave.

Who It's For

Developers maintaining multiple languages and frameworks
Career switchers tracking new field knowledge
Self-learners who want honest feedback
Anyone tired of apps that manipulate instead of inform

Try It

If you've ever felt that gap between what you "know" and what you can actually do—give it a try.

👉 skillfade.website

It's free. No credit card. Takes 30 seconds to add your first skill.

I'd love feedback from this community. What would make this more useful for you? What's missing?

And honestly—what skills are you pretending you still have?

The Features I Refused to Build in SkillFade

Ruhid Ibadli — Tue, 27 Jan 2026 18:03:46 +0000

Every product is defined as much by what it doesn't do as by what it does.

When I built SkillFade, a skill tracking app, I kept a list. Not a backlog of features to add—a list of features I actively refused to build.

Here's that list, and why each "no" made the product better.

1. No Streaks

Streaks are the most requested feature I'll never add.

"Just add a streak counter! It motivates people!"

Does it? Or does it create anxiety? Miss one day and your 47-day streak resets. Now you feel like a failure. The app that was supposed to help you learn just made you feel worse.

Streaks optimize for daily opens, not actual learning. They punish life happening—vacations, sick days, busy weeks. They turn a tool into an obligation.

SkillFade shows freshness decay instead. Miss a week? Your skills dropped a bit. That's just information, not judgment. No streak to "break." No guilt. Just data.

2. No Badges or Achievements

"You earned the 'Python Pioneer' badge!"

Who cares?

Badges are fake accomplishments that distract from real ones. You didn't become a better developer because an app gave you a virtual medal. You became better by building things.

Every badge system I've seen eventually becomes the goal itself. People optimize for unlocking achievements instead of actual skill development. The map becomes the territory.

SkillFade has no badges. The only achievement is the skill you built. The only reward is the work itself.

3. No Leaderboards

"See how you rank against other learners!"

Why would I want that?

Learning isn't a competition. Someone else's Python freshness has nothing to do with mine. Leaderboards create winners and losers in a game that shouldn't exist.

Worse, they encourage gaming the system. Log fake practice sessions to climb the ranks. Optimize for points instead of learning. The metric becomes the target, and once a metric becomes a target, it ceases to be a good metric.

SkillFade is single-player only. Your data is yours. No comparisons. No rankings. No "you're in the top 10%!" notifications.

4. No Push Notifications

My phone buzzes enough.

Push notifications are an attention tax. Every app fights for your focus. "Come back!" "You haven't logged in today!" "Your streak is at risk!"

This is hostile design. The app prioritizes its own engagement metrics over your mental peace.

SkillFade sends email—maximum once per week, plain text, one-click unsubscribe. No push notifications. No red badges. No "you have 3 unread alerts!"

If you forget the app exists for a month, that's fine. Your data will be there when you return.

5. No AI Recommendations

"AI suggests you should learn Kubernetes next!"

Why? Because it's trending? Because other users learned it? Because an algorithm thinks it knows my career better than I do?

AI recommendations optimize for engagement, not usefulness. They're based on aggregate patterns that may not apply to you. They create FOMO about skills you don't need.

SkillFade doesn't tell you what to learn. It shows you what you already decided to learn and how fresh those skills are. You're the expert on your own goals. The app just holds up a mirror.

6. No Social Features

"Share your progress with friends!"
"Follow other learners!"
"Join study groups!"

No.

Social features turn personal tools into performance spaces. Suddenly you're not tracking skills for yourself—you're curating an image for others. The private becomes public. The honest becomes performative.

Some people thrive on social accountability. Great—use a different app. SkillFade is deliberately antisocial. Your skill decay is nobody's business but yours.

7. No "Gamification"

Let's be honest about what gamification usually means: psychological manipulation dressed up as fun.

Variable rewards. Progress bars that never quite fill. Artificial scarcity. Dark patterns that exploit human psychology to drive engagement.

Games are fun because they're games. Turning learning into a game doesn't make learning fun—it makes it a worse game. You're not playing because it's enjoyable; you're playing because the app engineered you to.

SkillFade has no game mechanics. It's a spreadsheet with a nice UI. Boring? Maybe. Honest? Yes.

8. No Onboarding Tutorial

"Let me show you around!"
Click
"This is your dashboard!"
Click
"Here's how to add a skill!"
Click click click

If your app needs a tutorial, your app is too complicated.

SkillFade drops you on a dashboard with one button: "Add Skill." Click it. Fill in the name. Done. You now understand the entire app.

The interface should teach itself. If users need a guided tour, that's a design failure, not a feature opportunity.

9. No Premium Tier (For Now)

"Free users get 5 skills, premium gets unlimited!"

Artificial limitations designed to frustrate you into paying. The feature already exists—the code just checks if you've paid before letting you use it.

SkillFade is currently free with all features. When I add paid tiers, they'll be for genuinely new capabilities—not for removing arbitrary restrictions I invented.

10. No "Insights" Dashboard

"You learned 47% more this month!"
"Your most productive day is Tuesday!"
"You're a visual learner!"

Meaningless metrics presented as wisdom.

These insights sound smart but rarely change behavior. They exist to make the app feel sophisticated, to give you something to screenshot and share.

SkillFade shows one insight: your skills are decaying. That's it. One number per skill. No charts about your "learning style." No personality quizzes. No "insights" that are really just flattery.

The Pattern

Look at the list again. Every refused feature has something in common:

They optimize for the app, not the user.

Streaks keep you opening the app. Badges keep you engaged. Leaderboards drive competition. Push notifications interrupt your day. Social features create network effects. Gamification increases time-in-app.

All of these are great for metrics. MAU, DAU, retention, engagement—every startup's favorite dashboard.

But I don't have investors to impress. I don't need hockey-stick growth charts. I built SkillFade for myself first, and I wanted a tool that respects my time and attention.

The Alternative

What SkillFade does instead:

Shows you the truth - Your skills decay. Here's how much.
Gets out of your way - Log events in 10 seconds, then leave.
Respects your attention - No notifications unless you want them, and even then, rarely.
Trusts you - You know what you need to learn. The app doesn't.

It's less "product" and more "tool." Boring, perhaps. But boring tools get used for years. Exciting apps get deleted after the dopamine fades.

Building What You'd Actually Use

My filter for every feature request: "Would I want this in a tool I use daily?"

Streaks? No, they stress me out.
Badges? No, they feel patronizing.
Push notifications? God no.
AI recommendations? I'll decide what to learn, thanks.

This isn't for everyone. If you love gamification, SkillFade will feel empty. That's fine—there are dozens of apps that do that well.

But if you've ever felt exhausted by apps that demand your attention, manipulate your psychology, and treat you like a metric to optimize—maybe you want something quieter.

SkillFade is that quiet tool. No dopamine hits. No manipulation. Just a simple question: what are you forgetting?

What features have you refused to build? I'd love to hear what others have cut from their products.

Technical Deep Dive: Building SkillFade with FastAPI and React

Ruhid Ibadli — Mon, 26 Jan 2026 14:35:41 +0000

Last week I shared SkillFade, a skill tracking app that prioritizes honesty over gamification. Today I want to walk through the architectural decisions and technical choices that shaped it.

The Stack

Backend:  FastAPI + SQLAlchemy 2.0 + PostgreSQL
Frontend: React 18 + TypeScript + TailwindCSS
Auth:     JWT + bcrypt
Deploy:   Docker + Nginx

Boring? Yes. That's the point. Every piece is battle-tested, well-documented, and easy to hire for.

Why FastAPI?

I'm primarily a backend engineer with Python experience. When choosing a framework, I wanted something that would let me move fast without fighting the tooling.

FastAPI checked every box:

Familiar language - Python is my comfort zone, so I could focus on product logic instead of learning new syntax
Type hints as documentation - Pydantic schemas generate OpenAPI docs automatically, no extra work
Async when needed - But sync works perfectly fine for database-bound operations
Great ecosystem - Need anything? There's probably a Python library for it
Developer experience - Hot reload, clear error messages, intuitive routing

Could I have used Django? Sure. Flask? Also fine. But FastAPI hit the sweet spot between simplicity and features. For a solo developer shipping a product, that matters more than benchmarks.

The honest truth: I picked the tool I knew best so I could ship faster. No regrets.

Architecture: Monolith by Choice

No microservices. No message queues. No Kubernetes. A single FastAPI process handles everything.

This wasn't a compromise—it was a deliberate decision.

Why monolith?

Simpler debugging - One log stream, one deployment, one place to look when things break
Faster development - No service orchestration, no network calls between components, no distributed tracing
Cheaper hosting - Everything runs on a modest VPS, no complex infrastructure costs
Easier mental model - The entire application fits in my head

What about scale?

SkillFade is a personal productivity tool. Even with thousands of users, a single well-optimized server handles the load easily. PostgreSQL can manage millions of rows without breaking a sweat.

The microservices question I ask myself: "Do I have a team of 50 engineers who need to deploy independently?" No. So monolith it is.

I'll split it when I have the problem. Not before.

The Core Algorithm: Freshness Decay

The heart of SkillFade is the freshness calculation. Here's the thinking behind it.

The concept:

Every skill starts at 100% freshness after you practice it
Each day without practice, freshness decays exponentially
Recent learning activity adds a small boost (max 15%)
Result is clamped between 0-100%

The math (simplified):

Default decay rate is 2% per day, compounding. This means:

Days since practice	Freshness
0	100%
7	~87%
14	~75%
30	~54%
60	~30%
90	~16%

Why exponential decay?

Linear decay (lose 1% per day) doesn't match how memory works. In reality, forgetting is steep at first, then levels off. The exponential curve better models the Ebbinghaus forgetting curve that psychologists have studied for over a century.

Why does learning only "boost" and not reset?

This is the key philosophical choice. Watching a tutorial about React doesn't mean you can build a React app. Reading about Kubernetes doesn't mean you can debug a cluster.

Learning slows decay. Only practice resets the clock.

This forces users to confront an uncomfortable truth: passive consumption isn't the same as skill building.

Custom decay rates

Not all skills fade equally:

Motor skills (cycling, typing) - slow decay, muscle memory persists
Conceptual knowledge (design patterns, architecture) - medium decay
Syntax and tooling (specific APIs, CLI flags) - fast decay, details fade quickly

Users can adjust decay rate per skill to match reality.

Database Design Decisions

The Schema Philosophy

Six core tables. No more than necessary, no fewer than useful.

users
categories
skills
learning_events
practice_events
skill_dependencies

Every table has clear ownership. Users own categories. Categories organize skills. Skills have events. Simple hierarchy, predictable queries.

Separate Tables for Learning vs Practice Events

I debated this one. A single events table with a type column would be simpler, right?

I went with separate tables because:

Query patterns differ - Dashboard shows practice frequency, detail pages show both. Separate tables = simpler queries for common operations
Different subtypes - Learning events have types like "video, article, course, book". Practice events have "project, exercise, teaching, code-review". One enum would be confusing
Future flexibility - Practice events might get "difficulty" or "output_url" fields that don't make sense for learning
Schema as documentation - Two tables makes the learning/practice distinction explicit in the data model itself

The tradeoff is some duplication in the codebase. Worth it for clarity.

Hard Deletes Over Soft Deletes

When a user clicks "Delete my account," everything goes. CASCADE deletes across all tables. No deleted_at columns, no recovery period, no "we keep your data for 30 days."

This aligns with the privacy philosophy. If someone wants out, they're out. Fully.

It also simplifies queries—no WHERE deleted_at IS NULL everywhere.

Categories as First-Class Entities

Early version had category as just a string field on skills. Worked fine until I wanted:

Category-level analytics ("How fresh are my Frontend skills overall?")
Rename a category everywhere at once
Ensure no duplicate category names per user

Refactored to proper categories table with foreign keys. More work upfront, cleaner long-term.

Frontend Architecture

Why React + Vite (Not Next.js)

Next.js is great. I considered it. Went with plain React SPA instead.

Reasons:

No SEO needed - It's a dashboard behind login. Google doesn't need to crawl it
Simpler mental model - No SSR vs CSR decisions, no hydration bugs, no server components confusion
Clear separation - API is API (FastAPI), frontend is frontend (React). Clean boundary
Deployment flexibility - Static files served by Nginx, API proxied separately

For a marketing site or blog, I'd pick Next.js. For an authenticated dashboard app, SPA is simpler.

State Management: Context Over Redux

SkillFade uses React Context for global state. No Redux, no Zustand, no MobX.

What's in global state?

Current user (authentication)
Theme preference (dark/light)
That's it

Everything else?

Fetched fresh per page. Server is the source of truth. When you navigate to the dashboard, it fetches current data. No stale cache problems, no sync issues.

Why not Redux?

Redux solves problems I don't have:

Complex state interactions across many components? Nope, state is simple
Time-travel debugging? Never needed it
Middleware for side effects? fetch() works fine

For this app, Redux would add complexity without adding value. Context + useState + useEffect covers everything.

Component Structure

src/
  components/     # Reusable UI pieces (Button, Card, Modal)
  pages/          # Route-level components (Dashboard, SkillDetail)
  context/        # Global state (AuthContext, ThemeContext)
  services/       # API calls (skills.ts, events.ts)
  hooks/          # Custom hooks (useSkills, useFreshness)
  types/          # TypeScript interfaces

Nothing fancy. Pages fetch data on mount, pass to components via props. Components are mostly presentational.

Real-time Updates Without WebSockets

When you log a practice event on the skill detail page, the dashboard freshness should update.

Options considered:

WebSockets - Real-time push from server
Polling - Fetch every N seconds
Browser events - Signal between components in same tab

Went with option 3. It's a SPA—dashboard and detail page components exist in the same JavaScript context. When detail page logs an event, it dispatches a custom event. Dashboard listens and refetches.

No socket server to maintain. No unnecessary network requests. Works perfectly for single-tab usage.

For multi-device sync (phone updates, desktop sees it), you'd need WebSockets or polling. Not implemented yet. Manual refresh works for now.

The Alert System: Calm by Design

Philosophy

Most apps optimize for engagement. More notifications = more opens = better metrics.

SkillFade optimizes for calm. Alerts should be:

Infrequent - Maximum 1 email per week, total
Actionable - Only alert if user can do something about it
Respectful - Plain text, no tracking pixels, instant unsubscribe

Three Alert Types

1. Decay Alert
Triggers when a skill drops below 40% freshness. But not immediately—waits for 14 days since last alert for that skill. Prevents nagging about the same thing repeatedly.

2. Practice Gap Alert
Triggers when a skill has learning events but no practice events for 30+ days. The message: "You've been learning X but not practicing. Theory without application fades fast."

3. Imbalance Alert
Triggers when overall learning/practice ratio stays below 0.2 for two consecutive months. The message: "You're consuming a lot but producing little. Consider more hands-on work."

Implementation Notes

Alerts run via scheduled job (cron), not real-time triggers. Once daily, batch process checks all users who have alerts enabled.

Each alert type has independent cooldowns. You might get a decay alert and an imbalance alert in the same week, but never two decay alerts for the same skill within 14 days.

API Design Principles

RESTful, But Practical

Pure REST says everything should be a resource. I follow that mostly, but bend it when convenient:

GET /analytics/balance - Not really a "resource," but makes sense as an endpoint
POST /auth/login - "login" isn't a noun, don't care

Pragmatism over purity.

Flat URL Structure

GET  /skills
GET  /skills/:id
POST /skills
PUT  /skills/:id

GET  /learning-events
POST /learning-events
PUT  /learning-events/:id
DELETE /learning-events/:id

Not nested like /skills/:id/learning-events/:eventId. Flat is simpler to route, simpler to reason about, simpler to document.

Events reference skills via skill_id in the body/params, not URL hierarchy.

Consistent Response Patterns

Success: Return the data directly (object or array)

Error: Always { "detail": "Human readable message" }

Pagination: Offset-based with ?skip=0&limit=20, returns { items: [], total: number }

Frontend code stays simple when API is predictable.

Authentication: Keep It Simple

JWT Tokens

Access token in Authorization header
Stored in localStorage (yes, I know about XSS concerns—acceptable for this use case)
30-minute expiration
No refresh tokens—expired means re-login

For a personal productivity tool used by one person at a time, this is plenty secure. No need for refresh token rotation, token families, or OAuth complexity.

Password Handling

bcrypt with default work factor
72-byte input limit (bcrypt truncates silently, so I handle it explicitly)
No password rules beyond minimum length—let users choose their own passwords

Deployment

Docker Compose

Three containers:

PostgreSQL - Database
FastAPI - Backend API
Nginx - Serves frontend static files + proxies API requests

Single docker-compose up brings everything online. Environment variables for secrets, volumes for data persistence.

Why Not Serverless?

Lambda/Vercel functions would work for the API. Didn't go that route because:

Cold starts matter for dashboard responsiveness
PostgreSQL connection pooling is annoying in serverless
I wanted full control over the environment
Monthly cost is predictable with a VPS

For a side project, a $10-20/month VPS beats managing serverless complexity.

Lessons Learned

1. Start Without Auth

First two weeks, I built with a hardcoded user ID. No login, no registration, no password reset flow. Just the core features.

This prevented the classic trap: spending weeks on auth while the actual product stays unbuilt.

Added auth last, once everything else worked.

2. Migrations From Day One

Even solo, even on a side project: use database migrations (Alembic for Python).

Schema will change. "I'll just modify the table directly" becomes a nightmare when you have production data. Migrations saved me multiple times.

3. TypeScript Everywhere

Frontend and backend types should match. I define Pydantic schemas in Python, then manually keep TypeScript interfaces in sync.

Not ideal (would love auto-generation), but catching type mismatches at compile time is worth the maintenance.

4. Boring Tech Compounds

Every time I picked the "boring" option (PostgreSQL over MongoDB, REST over GraphQL, React over Svelte), I benefited from:

Better documentation
More Stack Overflow answers
Easier debugging
Smoother hiring (if I ever need help)

Novel tech is fun. Shipped products need boring tech.

5. Design for Deletion

GDPR requires "right to deletion." Even if you're not in the EU, it's good practice.

Plan for cascade deletes from day one. No orphaned data, no "soft delete" flags that accumulate forever.

What I'd Do Differently

E2E Tests Earlier

I relied on manual testing too long. Click through the app, check if it works. Tedious and error-prone.

Should have set up Playwright or Cypress from week two.

Design Alert System First

Retrofitting notifications into an existing schema was messy. Alert cooldowns, user preferences, email templates—all added later, all awkward.

If I started over, I'd design the alert data model upfront.

Use a Component Library

Built every button, input, modal, and dropdown from scratch with Tailwind. Educational, but slow.

Next time: Radix UI or Headless UI for primitives, custom styling on top.

The Anti-Complexity Manifesto

Every feature request, every "nice to have," every shiny technology gets filtered through one question:

"Does the added complexity justify the value?"

Microservices? No. One process is fine until it isn't.
GraphQL? No. REST handles every use case here.
Redis caching? No. PostgreSQL is fast enough.
Real-time sync? No. Manual refresh works.
Mobile app? No. PWA covers it.
AI recommendations? No. That's not what this product is.

The best code is code you don't write. The best infrastructure is infrastructure you don't maintain. The best feature is the one that solves the problem without adding moving parts.

That's the technical foundation of SkillFade. The theme throughout: simple, boring, maintainable. Complexity is easy to add. Simplicity is hard to maintain.

If you're building a side project, my advice: pick boring tech, ship fast, add complexity only when forced.

Questions about specific decisions? Drop them in the comments.

The uncomfortable truth: that course you finished 6 months ago? Almost gone.

Ruhid Ibadli — Sun, 25 Jan 2026 17:11:03 +0000

SkillFade: A Skill Tracking App That Tells You the Truth (Not What You Want to Hear)

Ruhid Ibadli ・ Jan 25

#webdev #react #python #productivity

[Boost]

Ruhid Ibadli — Sun, 25 Jan 2026 17:08:22 +0000

SkillFade: A Skill Tracking App That Tells You the Truth (Not What You Want to Hear)

Ruhid Ibadli ・ Jan 25

#webdev #react #python #productivity

SkillFade: A Skill Tracking App That Tells You the Truth (Not What You Want to Hear)

Ruhid Ibadli — Sun, 25 Jan 2026 14:46:54 +0000

The Problem with Learning Apps

Most skill tracking and learning apps follow the same playbook: gamification,

streaks, badges, and dopamine hits. They're designed to make you feel good, not to
show you reality.

But here's the uncomfortable truth: skills decay without practice. That Python

course you finished 6 months ago? It's fading. That framework you learned but

never used in a project? Almost gone.

I built SkillFade to be different—a mirror, not a coach.

What is SkillFade?

SkillFade is a web application that tracks your skills and exposes three
uncomfortable realities:

Learning Decay

Skills degrade over time without reinforcement. SkillFade calculates "freshness"

(0-100%) based on when you last practiced, not just when you last read about

something.

Practice Scarcity

Reading tutorials and watching videos isn't the same as doing. SkillFade flags

skills where you've been learning but not applying.

Input/Output Imbalance

Too much consumption, too little production. The app tracks your
learning-to-practice ratio and gently reminds you when you're all input and no

output.

The Anti-Gamification Approach

What SkillFade deliberately doesn't have:

❌ No points or badges
❌ No streaks (they cause anxiety, not learning)
❌ No leaderboards
❌ No "motivational" push notifications
❌ No AI recommendations
❌ No social features

Instead, it offers:

✅ Honest freshness percentages
✅ Calm, infrequent email alerts (max 1/week)
✅ Simple charts showing your actual patterns
✅ Full data export and deletion
✅ Zero third-party tracking

How Freshness Works

The core algorithm is simple but honest:

freshness = 100% × (0.98 ^ days_since_practice) + learning_boost

Practice keeps skills fresh. Learning only slows decay—it doesn't reverse it.

Visual indicators make it clear at a glance:

🟢 >70% - Fresh
🟡 40-70% - Aging
🔴 <40% - Decayed

Key Features

Skill Categories & Dependencies
Organize skills by category. Mark prerequisites between skills and get alerts when
your foundations are decaying.

Activity Calendar
See your learning and practice patterns at a glance. Track what you're actually

doing, not what you planned to do.

Balance Ratio
Visual representation of your input (learning) vs output (practice). Spot
imbalances before they become problems.

Custom Decay Rates
Some skills fade faster than others. Set custom decay rates per skill based on

complexity.

Freshness Targets
Set personal freshness thresholds and get notified when skills drop below your

standards.

PWA Support
Install on mobile or desktop. Works offline.

Dark Mode
Because we respect your eyes.

Privacy First

This isn't another app harvesting your data:

No Google Analytics or third-party tracking
No tracking pixels
No data sharing with anyone
Full JSON export of all your data
Permanent account deletion (we actually delete everything)
Email only used for optional alerts

Who Is This For?

Self-directed learners tired of gamification
Developers maintaining multiple tech skills
Career switchers tracking new field knowledge
Anyone who values long-term insight over short-term dopamine

The Philosophy

"This product is a mirror, not a coach. It does not push, judge, or optimize the

user. It simply tells the truth, kindly and clearly."

Sometimes what we need isn't another app cheering us on. Sometimes we just need

honest data about where we actually stand.

Try SkillFade

Ready to see where your skills actually stand?

👉 https://skillfade.website

It's free to get started. You can support using Support button.

What do you think? Would you use a skill tracker that prioritizes honesty over

engagement metrics? I'd love to hear your thoughts on the anti-gamification

approach in the comments.