I Built a Tool to Solve a Problem That Didn’t Exist
By My Code Diary
I spent three weekends building a Python tool that automatically renamed my project folders based on their last modified date. Color-coded. Sorted. With a CLI interface and everything.
Nobody asked for it. Not even me.
I never once thought, “Man, I really wish my folders had timestamps in the names.” But there I was, 11 PM on a Sunday, proudly running my script on a test directory like I had just launched a startup.
That was the moment I realized I had a problem. Not with my folders. With how I was choosing what to build.
The Trap Most Programmers Fall Into
Here is how it usually goes. You learn a cool library. You think, “What can I build with this?” And then you build something technically impressive that solves absolutely nothing for anyone on earth.
I have done this more times than I am willing to admit. A sentiment analyzer for my own tweets (I have 47 followers). A weather CLI tool when I already have a phone. A script that auto-generates motivational quotes every morning and emails them to myself (I unsubscribed from my own emails within a week).
The problem is not the code. The code is fine. The problem is the question you start with.
“What can I build with this?” is the wrong question.
“What problem am I annoyed by every single day?” is the right one.
The Day I Actually Solved Something Real
A few months ago, I was reviewing a batch of research PDFs for a side project. About 60 files. All named things like download(1).pdf, final_FINAL_v3.pdf, and my personal favorite, untitled.pdf.
Instead of manually opening each one, I wrote a script that read the first 500 characters of each PDF, sent them to an LLM with a one-line prompt, and renamed the file based on what the model returned.
import fitz
import anthropic
import os
def get_suggested_name(pdf_path):
doc = fitz.open(pdf_path)
text = doc[0].get_text()[:500]
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-opus-4-6",
max_tokens=64,
messages=[
{"role": "user", "content": f"Give a short file name (no extension) for this document:\n\n{text}"}
]
)
return message.content[0].text.strip().replace(" ", "_")
for filename in os.listdir("./pdfs"):
if filename.endswith(".pdf"):
path = f"./pdfs/{filename}"
new_name = get_suggested_name(path)
os.rename(path, f"./pdfs/{new_name}.pdf")
print(f"{filename} -> {new_name}.pdf")
That is it. Forty lines including the loop. Renamed 60 PDFs in under two minutes.
No UI. No config file. No CLI flags. Just a script that did one thing and saved me about an hour of boring work.
That was the first tool I built that I actually kept using.
What I Learned From Building Useless Things
Do not get me wrong. The folder renaming tool taught me a lot. I learned os.walk(), datetime formatting, and how to structure a small CLI with argparse. That knowledge was not wasted.
But there is a difference between building to learn a tool and building to solve a problem. Both are valid. You just need to know which one you are doing before you start.
If you are building to learn, timebox it. Give yourself a weekend. Make something small and dumb and fun. Nobody needs to use it. The learning is the point.
If you are building to solve a problem, start by writing one sentence: “Every week, I waste time doing _______ manually.” Fill in that blank first. Then write the code.
Pro tip: The best project ideas are embarrassingly simple. If you feel like the problem is too small to be worth solving, that usually means it is exactly the right size to actually finish.
The Follow-Up Tool I Never Planned to Build
Once I had the PDF renamer working, I noticed something. Half the PDFs were on similar topics. Machine learning papers, system design notes, some random tutorials I had saved and forgotten about.
So I extended the script. Instead of just renaming, it now also reads the abstract, generates an embedding, clusters the documents by similarity, and moves them into topic folders automatically.
from sentence_transformers import SentenceTransformer
from sklearn.cluster import KMeans
import shutil
model = SentenceTransformer("all-MiniLM-L6-v2")
abstracts = [get_abstract(f) for f in pdf_files]
embeddings = model.encode(abstracts)
kmeans = KMeans(n_clusters=5, random_state=42)
labels = kmeans.fit_predict(embeddings)
for i, file in enumerate(pdf_files):
folder = f"./organized/cluster_{labels[i]}"
os.makedirs(folder, exist_ok=True)
shutil.move(file, folder)
This is the thing nobody tells you about real projects. They grow naturally when you are actually using them. You do not need a grand vision upfront. You just need a real problem and one working script.
The folder renamer I built for no reason? Still sitting in a repo I have not opened since March. The PDF organizer? I use it every month.
Why Automation Is the Best Teacher
There is something about automation projects specifically that makes you a better programmer faster than almost anything else.
When you automate a task you actually do, you immediately know if it works. There is no ambiguity. Either you saved time or you did not. Either the output is correct or you have to debug it. The feedback loop is tight and honest.
Compare that to building a portfolio project nobody uses. You can convince yourself it works, ship it to GitHub, and never think about it again. But when you automate something in your real workflow, you will hit edge cases within days. Files with weird characters in the names. PDFs that are scanned images with no text layer. API rate limits you never accounted for.
Those edge cases are where the real learning happens.
One Framework That Actually Helps
Before I start any project now, I ask myself three questions.
First: do I personally face this problem, or am I just imagining that someone might? If I cannot answer yes to the first half, I move on.
Second: can I describe the solution in one sentence without using the words “platform,” “ecosystem,” or “AI-powered”? If the answer sounds like a pitch deck, it is probably too big to finish in a weekend.
Third: what does “done” look like? Not version two. Not the polished version. The version I could use tomorrow morning. That is the version I build first.
The folder renaming tool failed question one. The PDF organizer passed all three.
My Thought
The most useful tools I have ever built looked embarrassing on paper.
A script that checks if my meeting notes folder has grown past a certain size and sends me a reminder to clean it up. A one-liner that pulls my most-edited files from the last week and lists them in the terminal. A tiny function that formats raw JSON from an API response into a readable table so I stop squinting at curly braces.
None of these would impress anyone at a job fair. But every single one of them has saved me real time.
Meanwhile, the tools I built to impress people, the ones with nice READMEs and feature lists and architecture diagrams, most of those have never run on a machine other than my own.
The best code you can write is code that solves your own problem so well you forget it exists.
Start there.
What is something you do manually every week that you wish a script would handle? That is your next project.
