Status: Proof of Concept in Active Development
A Ruby on Rails task management application designed for freelancers to organize projects, track deadlines, and receive automated notifications. Built as a comprehensive portfolio project demonstrating full-stack Rails development, background job processing, production deployment, and systematic problem-solving.
Test Credentials:
- Email:
test@testemail.com - Password:
password123
Note: Hosted on Render's free tier - first visit may take 30-60 seconds to wake up.
- User Authentication - Secure signup/login via Devise with proper authorization
- Project & Task Management - Full CRUD operations with nested routing (projects contain tasks)
- Status Tracking - Tasks support pending, in_progress, and completed states
- Responsive Dashboard - Card-based layout showing all projects and their tasks at a glance
- Automated Deadline Notifications - Email alerts for tasks due tomorrow or in two days
- Background Job Processing - Synchrononous email delivery
- Scheduled Jobs - Render Cron Job checks deadlines every hour
- Notification Preferences - Users can enable/disable email and in-app notifications
- In-App Notification UI - Bell icon dropdown showing recent notifications with read/unread tracking
- Framework: Ruby on Rails 8.1.1
- Database: PostgreSQL (production), SQLite (development)
- Authentication: Devise
- Background Jobs: Sidekiq with Redis (local dev only)
- Email: Mailtrap SMTP (for testing notifications without spamming real inboxes)
- Deployment: Render (web service + cron job + PostgreSQL)
- Frontend: ERB templates, Turbo, Bootstrap 5
- Job Scheduling: Render Cron Jobs (runs
CheckDeadlinesJobevery 2 hours at minute 12)
Why Synchronous Email Delivery for POC?
For this proof-of-concept, emails are sent synchronously (using deliver_now) directly from the scheduled cron job. With low volume (typically 0-5 notifications per hour), sending emails takes only 2-3 seconds total per job run. This eliminates the need for Redis ($10/month) and a persistent background worker ($7/month), keeping infrastructure costs minimal for demonstration purposes. For production scale with hundreds of users, I would implement Sidekiq with Redis to handle email delivery asynchronously, preventing SMTP latency from blocking the application and providing automatic retry logic for failed deliveries.
Why Render Cron Jobs?
Rails has several scheduling options (whenever, Solid Queue, sidekiq-scheduler), but they all require a persistent process running 24/7. Render's free tier spins down after inactivity, so a separate cron job service ($7/month) reliably triggers deadline checks every hour without keeping the main app awake.
Why PostgreSQL?
The data model (Users → Projects → Tasks → Notifications) is inherently relational. Foreign keys enforce referential integrity, and cascade deletes (dependent: :destroy) keep the database clean when tasks are deleted.
Next Up:
- ActionCable Integration - Real-time dashboard updates via WebSockets (notifications appear without refresh)
- RSpec Test Suite - Comprehensive tests for models, jobs, and controllers
Future Iterations:
- Priority Levels - High/medium/low priority tasks with adjusted notification timing
- Task Archiving - Soft delete with archive/restore functionality
- Modal Forms - Replace separate form pages with inline modals
- Recurring Tasks - Support for daily/weekly/monthly repeating tasks
- Analytics Dashboard - Completion rates, deadline patterns, project timelines
- Ruby 3.4.7
- Rails 8.1.1
- PostgreSQL
- Redis (for Sidekiq)
# Clone repository
git clone https://github.com/n4ika/cadence-app
cd cadence-app
# Install dependencies
bundle install
yarn install
# Setup database
rails db:create db:migrate db:seed
# Start Redis (separate terminal)
redis-server
# Start Sidekiq (separate terminal)
bundle exec sidekiq
# Start Rails server
rails serverVisit http://localhost:3000 and use the test account credentials above.
Challenge: Project edit route randomly returned 404 errors in production
Root Cause: Rails 8.1.1 had a bug where method names (set_project, authorize_project!) collided between ProjectsController and TasksController. After visiting a task route, subsequent project routes would erroneously trigger TasksController methods.
Solution: Renamed TasksController methods to set_task_project and authorize_task_project! to avoid namespace collision. Also consolidated duplicate resources :projects definitions in routes.rb that were causing routing ambiguity.
Challenge: Delete task button showed 404 instead of confirmation dialog
Root Cause: Rails 7+ deprecated method: :delete syntax in favor of Turbo-specific data: { turbo_method: :delete }.
Solution: Updated link helper syntax and added dependent: :destroy to Task model's has_many :notifications association to handle cascade deletes properly.
Challenge: Notifications triggered for completed tasks
Root Cause: CheckDeadlinesJob queried all tasks by due date without filtering status.
Solution: Added .where(status: ['pending', 'in_progress']) to queries to exclude completed tasks from notification logic.
Challenge: Production emails failing silently
Root Cause: Missing SMTP environment variables (SMTP_USERNAME, SMTP_PASSWORD, etc.) in Render production environment.
Solution: Configured Mailtrap credentials as environment variables and updated production.rb to use ENV[] lookups instead of hardcoded values.
Challenge: Production deployment requiring $17/month for background job infrastructure
Root Cause: Sidekiq requires Redis and a persistent worker process, adding significant cost to free-tier POC deployment.
Solution: Switched to synchronous email delivery via deliver_now for POC scale. Evaluated trade-offs: acceptable 2-3 second delay during low-volume cron runs vs. $17/month infrastructure cost. Documented scalability path to Sidekiq for production deployment.
- Full-stack Rails MVC architecture with proper separation of concerns
- Background job processing and asynchronous task handling
- Production deployment with environment-specific configuration
- RESTful routing with nested resources
- ActiveRecord associations and database modeling
- User authentication and authorization patterns
- Debugging complex issues in production environments
- Modern Rails 8 conventions (Turbo, Solid Queue, Propshaft)
- Stimulus controllers for interactive JavaScript features
- Read/unread state management
- Notification timing is date-based only (no time-of-day support yet)
- Cron job cost: ~$7/month on Render (free tier doesn't support persistent background workers)
- Mailtrap's free sandbox limits email sending speed. Tested successfully - emails deliver correctly when within rate limits. Production deployment would use SendGrid, Postmark, or similar service with appropriate rate limits for scale.
Built by Naïka | GitHub | LinkedIn | naika.c.estriplet@gmail.com