Day 0: Launching #OneTimeShare30 - A 30-Day Public Build Challenge
Photo by Lukas Blazek on Unsplash
Date: December 24, 2025
Status: Planning Phase
Repository: github.com/Aayushbankar/onetimeshare
Hashtag: #OneTimeShare30
Twitter: @enthusiadev
Linkedin: @aayushbankar
🎄 Christmas Eve Announcement
It's December 24th, 10:00 PM, and I'm sitting here on Christmas Eve with an idea that won't wait. Starting tomorrow, I'm embarking on a 30-day public build challenge to create something I genuinely need: a secure, one-time file sharing application.
Why today? Why not wait until after the holidays? Because good ideas don't follow calendars, and the problem I'm solving doesn't take time off.
🧐 The Problem That Keeps Me Up at Night
As a developer and student, I constantly face this dilemma:
"How do I share this API key/config file/password securely right now?"
My current options all suck:
- Email attachments - They live forever on multiple servers
- Discord/WhatsApp - University projects with sensitive keys exposed in group chats
- Pastebin - Public by default, retention unclear
- Google Drive/WeTransfer - Third-party servers storing my data
- Self-built solutions - Time-consuming, over-engineered
Just last week, I needed to share a Google Gemini API key with a batchmate for our machine learning project. I spent 15 minutes debating the "least bad" option before settling on splitting the key across multiple messages. There has to be a better way.
Think about it: API keys, configuration files with database credentials, project secrets, authentication tokens - we're sharing these daily through completely insecure channels.
💡 The Vision: OneTimeShare
Imagine this workflow:
- You upload a file or paste text (like that Gemini API key)
- You get a unique, unguessable link
- You share that link with one person
- They view/download the content once
- The data is permanently deleted from the server
- The link becomes invalid forever
No accounts. No tracking. No permanent storage. Just secure, ephemeral sharing.
Perfect for:
- Sharing API keys with teammates
- Sending configuration files for projects
- Temporary password sharing
- Code snippets with sensitive data
- Project credentials for group assignments
🗓️ The 30-Day Challenge Timeline
Start Date: December 26, 2025
End Date: January 24, 2026
Duration: 30 days of daily progress
Weekly Breakdown:
Week 1: Foundation & Planning (Dec 26 - Jan 1)
- Flask application setup
- File upload system
- Text snippet handling
- Unique URL generation
Week 2: Core Features (Jan 2 - Jan 8)
- One-time view implementation
- Timer-based expiration
- Password protection
- API development
Week 3: Security & Polish (Jan 9 - Jan 15)
- Advanced security measures
- Rate limiting and abuse prevention
- Docker optimization
- Testing suite
Week 4: Advanced Features & Launch (Jan 16 - Jan 24)
- Performance optimization
- CI/CD pipeline
- Documentation
- Public launch
🛠️ Technology Stack Decisions
After much deliberation (and several cups of coffee), here's what I'm going with:
| Component | Choice | Why |
|---|---|---|
| Backend Framework | Flask | Lightweight, easy to prototype, Python ecosystem |
| Containerization | Docker | Reproducible environments, easy deployment |
| Ephemeral Storage | Redis | Built-in TTL, fast in-memory operations |
| Frontend | Bootstrap 5 | Responsive, minimal CSS, rapid UI development |
| Database | SQLite (for metadata) | Simple, file-based, no setup required |
| Hosting | DigitalOcean/Railway | Affordable, developer-friendly |
| CI/CD | GitHub Actions | Free, integrated with repository |
📁 Day 0: What I've Built Today
1. GitHub Repository Setup
The foundation is live: github.com/Aayushbankar/onetimeshare
What's included:
- Detailed README with 30-day roadmap
- MIT License for open source distribution
- Project structure skeleton
- Issue templates for community feedback
- Workflow diagram of the planned architecture
2. Initial Workflow Design
I've mapped out the core user journey:
Student/Developer Uploads API Key/Config
↓
Generate Unique ID (UUID + timestamp)
↓
Encrypt Data (AES-256)
↓
Store in Redis with TTL (5 min - 24 hr)
↓
Return Unique URL to User
↓
Teammate Accesses URL
↓
Decrypt & Serve Data
↓
DELETE from Redis Immediately
↓
Invalidate URL Forever
3. 30-Day Daily Breakdown
Each day has specific, achievable goals. No vague "work on backend" tasks. For example:
Day 1 (Tomorrow):
- Flask "Hello World" application
- Basic file upload endpoint
- Docker container setup
- HTML template with Bootstrap
Day 8:
- One-time view implementation
- Database flags for "viewed" status
- Atomic operations to prevent race conditions
🤔 Why Build in Public?
This isn't my first project, but it's my first public build challenge. Here's why I'm doing it:
1. Accountability
When you tell the internet you're going to do something, you're more likely to actually do it. No more abandoned side projects.
2. Community Wisdom
I don't know everything. By sharing my process, I'll get feedback from people who've solved similar problems.
3. Learning Acceleration
Mistakes made in public are lessons learned faster. If I architect something poorly, someone will (hopefully kindly) point it out.
4. Portfolio Building
A 30-day public build with documented challenges and solutions is better than any resume bullet point.
5. Helping Others
If one person looks at this and thinks "I could do that too," it's worth it.
📊 Success Metrics
By Day 30, I aim to have:
- ✅ Working MVP with all core features
- ✅ 100+ GitHub stars (showing community interest)
- ✅ Security audit completed (or at least started)
- ✅ Production deployment live and working
- ✅ Comprehensive documentation for users and developers
- ✅ 10+ community contributions (issues, PRs, feedback)
👥 How You Can Participate
Level 1: The Observer
- Follow #OneTimeShare30 on Twitter
- Read these weekly Dev.to updates
- Watch the GitHub repository
Level 2: The Supporter
- Star the GitHub repository
- Share updates with batchmates or colleagues who might find it useful
- Give thumbs up on social media posts
Level 3: The Contributor
- Open issues for feature requests or bugs
- Test early versions and provide feedback
- Share your expertise in the comments
- Submit PRs for improvements
Level 4: The Co-Builder
- Build your own version alongside me
- Create complementary tools (CLI, browser extension)
- Document your learnings from following along
🚀 What's Next?
Tomorrow (December 26, Day 1):
- Flask application skeleton
- Basic file upload endpoint (even if it just prints to console)
- Docker container that runs the app
- First commit to the repository
I'll be posting:
- Twitter: Daily progress threads with code snippets
- GitHub: Commit-by-commit development
- Dev.to: Weekly retrospective articles like this one
- LinkedIn: Technical deep-dives on specific challenges
❓ Questions for You
- As a student/developer, how do you currently share API keys or config files with teammates?
- Which security feature should I prioritize first? (Encryption, rate limiting, file validation, etc.)
- Have you ever accidentally committed an API key to GitHub? (I have! 🫣)
- What would make this tool genuinely useful for your projects or assignments?
🔗 Quick Links
🎄 Final Thoughts on Christmas Eve
It's almost midnight on Christmas Eve. My family is asleep, the house is quiet, and I'm excited.
Excited to build something useful.
Excited to learn in public.
Excited to see where this 30-day journey takes me.
If you're reading this, thank you. Whether you're a fellow student working on group projects, a developer tired of insecure file sharing, or just someone curious about building in public - you're part of this journey.
Here's to 30 days of building, learning, and sharing.
See you tomorrow for Day 1.
Merry Christmas, and happy building! 🎄👨💻
Top comments (0)