I remember when I was in Class 12, I wanted to build two things that probably made very little sense as “projects.”
One was a faster AI suggestion tool for the desktop — something that could understand what I was typing and suggest what I might want to write next.
The other was a PDF n-gram counter — a tool that could take a PDF, analyze the text, and tell me which words or sequences of words appeared most frequently.
I didn't have a startup idea.
I wasn't solving a business problem.
I didn't have a detailed roadmap.
I just had two questions:
“Can I actually make this?”
And that was enough.
Looking back, I think that's where experimentation really starts.
Most people think building with technology starts with a big idea.
You need a startup idea.
You need a business problem.
You need a detailed roadmap.
You need to know exactly what the final product will look like.
I think that mindset is backwards.
Some of the most interesting things you can build start with a much simpler thought:
“I wonder if I can make this.”
That is experimentation.
Imagine waking up and wondering:
“What if I had a bot that watched a few websites I care about and told me only the interesting changes?”
You don't need to turn that into a SaaS product.
Build it.
Maybe the bot checks websites, RSS feeds, GitHub repositories, research papers, product launches, or even a few obscure forums. It collects what changed, sends the information through an LLM, and produces a small daily summary.
A few hours later, you have something that didn't exist that morning.
Maybe it is useful.
Maybe it is completely pointless.
Both outcomes are valuable.
The interesting part is that you learned something.
Another day, you might wonder:
None of these need to become products.
They're technical playgrounds.
And playgrounds are where you learn surprisingly quickly.
One experiment I find particularly interesting is creating a personal AI information system.
Instead of asking:
“What happened in the news today?”
you define:
“What changed in the things I care about?”
For example, suppose you're interested in AI infrastructure.
Your system could monitor:
GitHub
↓
Research papers
↓
Company blogs
↓
Product changelogs
↓
Developer discussions
↓
Technical forums
↓
News
↓
AI summarizer
↓
Interesting changes
↓
Personal daily briefing
The output doesn't have to be another generic news summary.
It could say:
3 things worth investigating today
- A new open-source inference framework appeared.
- A major model provider changed its API pricing.
- A GitHub project you've been watching suddenly gained 2,000 stars.
Now the AI isn't replacing your curiosity.
It is amplifying it.
Try building things that sound unnecessary.
A bot that argues with your ideas.
A program that finds the most interesting commits in your favorite repositories.
An AI that reads your bookmarks and groups them into topics.
A script that checks whether websites you follow have changed.
A personal "what did I miss?" machine.
A bot that watches a dataset and messages you when something unusual happens.
A system that takes a random question every morning and researches it automatically.
A tiny AI that summarizes your own notes every evening.
A dashboard showing what technologies you've been researching over the last six months.
These aren't necessarily businesses.
They're questions turned into software.
Tutorials usually give you the destination.
Experimentation gives you the problem.
That changes everything.
Instead of:
"Today I'm going to learn FastAPI."
you might think:
"I want a bot that receives a URL, analyzes it, stores the result, and lets me query my collection."
Suddenly you have a reason to learn:
The technology becomes a tool for answering your question.
That's much closer to how real engineering works.
The biggest mistake is turning an experiment into a six-month project.
Don't.
Give yourself constraints.
One evening.
One weekend.
One API.
One dataset.
One weird question.
Build the smallest version that can answer:
“Does this idea actually work?”
If it works, extend it.
If it doesn't, throw it away.
Then start another experiment.
That ability to throw things away is important.
You don't need every experiment to become a portfolio project.
Some experiments exist purely to teach you something.
You can even maintain a simple list:
| Experiment | Question | Result |
|---|---|---|
| Desktop AI suggestions | Can I make typing suggestions faster? | Learned from the attempt |
| PDF n-gram counter | Can I extract useful patterns from documents? | Learned from the attempt |
| GitHub bot | Can I detect interesting projects automatically? | Works |
| Paper summarizer | Can AI identify papers worth reading? | Partially |
| Personal search | Can I search all my notes semantically? | Works |
| Web monitor | Can I detect meaningful website changes? | Surprisingly useful |
| AI researcher | Can an agent investigate a topic autonomously? | Needs improvement |
After a year, you might have built 50 strange little systems.
Most will be abandoned.
A few will be useful.
One or two might become something much bigger.
But even the failed experiments leave you with something valuable:
technical intuition.
There is an enormous amount of technology to consume today.
News.
Launches.
Benchmarks.
Tutorials.
Tweets.
Videos.
Podcasts.
Reddit threads.
Documentation.
It's easy to spend an entire day learning about what other people built.
Experimentation changes the relationship.
“What is everyone building?”
start asking:
“What can I build in the next two hours?”
That question is more interesting.
You don't need permission.
You don't need a startup.
You don't even need a particularly good idea.
Find something that makes you curious.
Build the smallest possible version.
Break it.
Fix it.
Learn something.
Then find another question.
And in a world where technology is becoming easier to build with, the ability to turn random curiosity into working software might become one of the most useful technical skills you can develop.