Experimenting With Tech: Build Something Just Because You’re Curious

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.

Build First, Figure Out the Point Later

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.

Curiosity Is a Better Starting Point Than Requirements

Another day, you might wonder:

• Can I make a bot that talks to my own documents?
• Can I build an AI that explains everything happening in a particular field?
• Can I automatically detect interesting GitHub projects?
• Can I analyze my browser history and discover what I spend time researching?
• Can I turn thousands of saved articles into a searchable knowledge base?
• Can I build a personal dashboard that tells me what changed since yesterday?
• Can I make an agent that investigates a question and gives me sources?
• Can I predict something purely as an experiment?
• Can I scrape a public dataset and discover something nobody asked me to discover?

None of these need to become products.

They're technical playgrounds.

And playgrounds are where you learn surprisingly quickly.

Build Your Own Information Radar

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

1. A new open-source inference framework appeared.
2. A major model provider changed its API pricing.
3. A GitHub project you've been watching suddenly gained 2,000 stars.

Now the AI isn't replacing your curiosity.

It is amplifying it.

The Best Experiments Are Slightly Ridiculous

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.

Why This Is Different From Following Tutorials

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:

• FastAPI
• databases
• APIs
• authentication
• background jobs
• embeddings
• web scraping
• LLMs
• deployment

The technology becomes a tool for answering your question.

That's much closer to how real engineering works.

Keep Experiments Tiny

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.

Your Personal Tech Laboratory

You can even maintain a simple list:

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.

Don't Only Consume Technology. Play With It.

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.

Instead of asking:

“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.

That is experimentation.

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.