Skill-tracker: The Small Python App That Behaves Like a Real Product

A flat FastAPI codebase packs JWT auth, password resets, role-based access, and cloud-ready database switching into a surprisingly complete student skills system.

7 min read • View on GitHub • More from Kaameshwar-K

A wide editorial scene of a compact workbench with a locked filing cabinet labeled for auth, skills, and reset email, plus a small control panel that switches between SQLite and Postgres. It explains how a small repo can still contain the machinery of a real web product. — The surprise is not the domain. It is the density of product infrastructure packed into a tiny codebase.

Key Takeaways

Skill-tracker matters because it turns a tiny FastAPI repo into a production-shaped application, not just a CRUD demo.
Its real strength is the trust layer, where JWT auth, password resets, and admin bootstrapping make the system feel operational.
The flat file structure is a feature, because it keeps the codebase readable while still supporting deployable configuration.
This repo is a useful template for solo builders who want security and portability without framework sprawl.

Most starter apps are easy to recognize. They collect a few forms, save a row or two, and stop just before the hard parts. Skill-tracker does something more interesting: it keeps the codebase small while still shipping the machinery you need for a real product.

A tiny repo with product-grade ambitions

The repository is framed as a website for tracking skills, but the actual story is broader. It is a compact FastAPI app that already knows about identity, authorization, recovery, and deployment posture. That combination makes it feel less like a class project and more like a template for how a solo builder gets to something shippable.

That matters because the difficult part of small apps is rarely the UI. It is the trust system around the UI. Once a project can sign users in, recover passwords, distinguish roles, and move between local and hosted databases, it has crossed the line from demo to infrastructure.

The whole app fits into a handful of files

A flat structure does not mean a thin app. Here, the few top-level files tell you almost everything about the system.

File	What it does	Why it matters
main.py	Backend routes, models, auth, and database logic	It concentrates the core application surface in one readable place
index.html	Single-page UI with view switching	It keeps the frontend lightweight without losing product feel
create_admin.py	Bootstraps the first admin account	It shows the project expects real operations, not just sign-up
skill_tracker.db	Local SQLite database	It makes the app easy to inspect and run locally

The flat layout is the point. It lowers cognitive overhead while still leaving room for the app to behave like a system. You can read the repo in one sitting and still come away with a clear picture of how it authenticates users, stores data, and initializes privileged access.

Authentication is the real product

This repo earns its credibility in the trust layer. The backend uses OAuth2 password flow, JWTs, password hashing, and protected routes, which is already more serious than most tutorial apps. Add password recovery through email, and you have a system that assumes users will lose access and need a clean way back in.

A close-up editorial scene of a passport checkpoint where a user card passes through password hashing, JWT token, and reset token gates. A side door marked for admin bootstrap opens once with a single key. It explains how the app turns identity and recovery into a sequence of enforced trust checks. — The most interesting mechanism is not skill entry. It is the chain of checks that lets the app trust a person in the first place.

The password reset flow is the strongest evidence that this is more than a toy. A reset request creates a token, stores it with expiry, sends it through email, validates the new password on the frontend, and finally checks the token again before updating the credential. That is a complete lifecycle, not a placeholder.

The admin script matters because it reveals intent. A system that needs create_admin.py is not just waiting for casual signups. It assumes someone will initialize the product, assign authority, and then use the normal app flow after that.

from database import SessionLocal
from security import get_password_hash
from models import User, RoleEnum


def create_admin():
    db = SessionLocal()
    admin = User(
        email="admin@example.com",
        hashed_password=get_password_hash("strong-password"),
        role=RoleEnum.admin,
    )
    db.add(admin)
    db.commit()

A frontend that swaps views instead of routes

The UI avoids framework sprawl by switching views inside a single page. Login, registration, and dashboard states appear and disappear without a client-side router carrying the complexity. That keeps the app lightweight, but it also preserves the feeling of a cohesive product.

This is a good trade-off for a small system. A single-page shell can still feel polished if the states are clean and the handoffs are obvious. Here, the simplicity is not a compromise so much as a discipline.

The database switch is the quietest smart decision

The environment-driven database setup is one of the most teachable parts of the repo. SQLite is practical for local development and inspection. A production database can be swapped in through configuration without changing the app’s shape.

Mode	What it gives you	What it avoids
SQLite	Fast local setup and easy inspection	Infrastructure overhead during development
Production database	Deployment portability and better scale posture	Locking the app to a laptop-only workflow

That choice is small but telling. Many starter apps are built as if they will never leave the desktop. This one is already thinking about deployment, which changes how you read the rest of the repository.

Compared with most starter apps, this one assumes continuity

Capability	Typical starter app	Skill-tracker
Authentication	Basic login form	JWT-based auth with protected routes
Password recovery	Usually missing	Token-based reset flow with email delivery
Roles	Often ignored	Student and admin paths are distinct
Deployment	Local-only assumptions	SQLite locally, production database via environment
Frontend structure	Routing-heavy or overbuilt	Single-page view switching
Operations	Minimal or absent	Admin bootstrapping and persistent state

The contrast is simple. A tutorial app teaches isolated features. Skill-tracker shows how those features connect when you expect people to actually use the system. That shift from feature list to continuity is what makes the repo feel unusually complete.

What this repo really teaches

The lesson here is not that every project needs this exact stack. It is that a small codebase can still respect the hard edges of product development: identity, recovery, roles, persistence, and deployable configuration. If you want a compact example of how to ship with discipline, this is a strong one.

Skill-tracker is most interesting not because it tracks skills, but because it shows how a solo developer can assemble a secure, deployable, product-shaped app without framework sprawl.