A CRUD API That Stays Boring

Smart Task Manager is a plain task manager: FastAPI, SQLAlchemy, SQLite, Pydantic v2 and a Streamlit front end. POST, GET, PUT and DELETE on /tasks, a completion toggle, title search and status filters. No model anywhere in it — on purpose.

Boring is a feature

Every choice is defensible on its own terms: SQLite because the data is one person's tasks, SQLAlchemy because it maps cleanly onto Pydantic models, Streamlit because I needed a UI in an afternoon. Nothing in the stack has to be clever. That's the point — every component is doing exactly the job it was built for, which is rarer than it sounds.

The parts that aren't boring

Even at this size the real work was contracts. Validation errors that say what is actually wrong — not just 422 with a stack of internals. A status field that can't hold nonsense, enforced by the schema, not by a hopeful comment. A search that doesn't silently return nothing because of a typo.

The completion toggle deserves its own mention: it's a partial update, which means PATCH semantics, which means deciding what happens when a field is absent versus null. That decision, made carelessly, is where most "simple" CRUD APIs develop their first bug.

The habits are the deliverable

Same habits a large ML system needs — just cheaper to practise here. Pydantic models at the boundary, errors that carry enough context for a client to recover, status codes chosen rather than defaulted, and a README where the contract is written down before the code.

When the stack is this small, there's nowhere to hide. If the API is bad, it's bad because of your decisions, not your framework. That feedback loop is exactly why I keep a project like this in rotation.

Why it stays in the portfolio

It's the clearest example I have of a complete, honest API surface. When someone asks how I design endpoints, this is faster to point at than any of my RAG systems. Big systems prove you can handle complexity. A small clean one proves you know what to leave out.