This project started with a small but annoying observation. A daily business workflow depended on someone manually opening a website every morning just to check updated prices.
It was repetitive. Easy to forget. And clearly automatable.
So I automated it.
The Problem
Every day, the same steps:
- Open a website
- Find today’s price
- Read the numbers
- Share them with others
Nothing complex. Just fragile human effort.
I didn’t want dashboards. I didn’t want alerts, logins, or subscriptions.
I wanted the system to:
- Run every day
- Fail safely
- Never need babysitting
The Solution
I built a small Python automation that runs on its own.
The script:
- Sends an HTTP request to a public website
- Parses the returned HTML
- Locates the table containing the Pune egg rates
- Extracts only today’s row
- Reads values for piece, tray, 100 eggs, and peti
Because websites change, the script is defensive by design.
If:
- Today’s data isn’t present, or
- The page structure changes
It does not guess. It fails cleanly and sends a clear “data unavailable” message instead of incorrect numbers.
Wrong data is worse than no data.
Delivery, Not Just Extraction
Once the data is extracted, it’s formatted into a simple, readable message.
That message is sent automatically using the Telegram Bot API.
The same message is broadcast to multiple recipients:
- No duplicated logic
- No separate flows
- No per-user handling
Simple input. Simple output.
Full Automation with GitHub Actions
I didn’t want this tied to my laptop.
The entire workflow runs via GitHub Actions on a scheduled cron job.
Every day, the workflow:
- Spins up
- Installs dependencies
- Runs the script
- Exits
All sensitive values — bot token and recipient IDs — are handled through environment variables and GitHub Secrets. No secrets in code. No shortcuts.
Intentional Simplicity
This project was deliberately minimal.
No:
- Database
- Backend server
- Frameworks
- Paid services
Just:
- Python
- HTTP
- HTML parsing
- A scheduler
- A messaging API
Total runtime: seconds. Total maintenance: near zero.
Once deployed, the system requires zero manual intervention, zero maintenance, and zero daily thought.
It just works.
What I Learned
This project reinforced a simple but important idea: small systems that solve real problems teach you more than large systems built for demos.
I improved my understanding of:
- Web scraping
- Defensive programming
- Automation
- Designing systems that expect failure instead of ignoring it
No buzzwords. No overengineering. Just removing friction from real life.
And that’s usually the best place to start.