BTLR

A Butler that actively optimizes a student’s day and opportunities, not just reminds them.

Comment

Student-Centric Flutter Butler (BTLR)

About the Project

As students, we constantly struggled with planning tools that assumed discipline instead of adapting to reality. Most productivity apps expect students to perfectly follow schedules, but real life is messy — classes run late, energy fluctuates, and plans often fail. We wanted to build something that responds to how students actually behave, not just what they intend to do.

This project was inspired by that gap.

BTLR is a personal assistant built for students that plans daily and monthly schedules, tracks real task completion behavior, adapts future plans automatically, and surfaces relevant opportunities like internships and hackathons — all while respecting academic constraints.

Instead of reminding users endlessly, the Butler learns from missed tasks and adjusts accordingly.

What the Butler Does

The Butler operates as a continuous loop:

  1. Collects student constraints (academic schedule, preferences, goals)
  2. Generates a time-blocked daily and monthly plan
  3. Observes what tasks are actually completed or missed
  4. Adapts future plans based on real behavior
  5. Injects relevant student opportunities directly into available time slots

This creates a system that improves over time rather than enforcing rigid schedules.

Opportunity Discovery

In addition to planning, the Butler actively helps students stay aware of opportunities that matter to them.

The Opportunity & Discovery page aggregates student-relevant opportunities such as:

  • Hackathons
  • Internships
  • Scholarships and competitions

These opportunities are fetched from public sources on the web and filtered based on the student’s profile, interests, and availability. Instead of acting as a passive feed, the Butler connects opportunities to the student’s schedule by suggesting when students can realistically apply or participate.

Progress Tracking & Activity Insights

The Butler also provides a Progress Tracking view that helps students reflect on their growth across platforms they already use.

From a single dashboard, students can view and track activity from:

  • Codeforces
  • LeetCode
  • GitHub
  • LinkedIn

This page focuses on visibility and reflection rather than raw metrics. It allows students to see trends in learning and activity over time and connect that progress back to planned goals and daily effort.

Together, these features ensure the Butler is not just a planner, but a system that helps students plan, discover, and reflect in one place.

How We Built It

The project is built entirely using the Flutter + Serverpod stack.

Backend

  • Serverpod (Dart) powers the backend
  • PostgreSQL stores all user data
  • Background jobs handle:
    • Daily plan regeneration
    • Monthly roadmap updates
    • Opportunity fetching

All planning, adaptation, and decision-making logic runs server-side using deterministic, rule-based services rather than opaque AI models.

Frontend

  • Flutter is used for the mobile UI
  • The app acts as a thin client:
    • Displays plans
    • Collects feedback
    • Sends completion events
  • Only minimal UI state is cached locally

Core Design Principle

  • The backend is the source of truth
  • The frontend reflects decisions, not logic

Adaptive Logic (Without AI Hype)

Instead of using a large language model, the Butler relies on observable behavior:

  • Tasks completed vs missed
  • Miss reasons (too long, bad timing, too hard)
  • Average session duration
  • Time-of-day success patterns

These signals are aggregated into behavioral statistics and used to adjust:

  • Session lengths
  • Time slots
  • Task density per day

This makes the system transparent, explainable, and reliable — especially in a hackathon setting.

Challenges Faced

Scope Control

The biggest challenge we faced was resisting feature creep. It was tempting to add chatbots, complex psychology models, or generic AI coaching features. Instead, we focused on building a small number of features that worked end-to-end and interacted meaningfully.

Designing Adaptation Logic

Creating adaptive behavior without overcomplicating the system required careful separation between:

  • Data collection
  • Behavior analysis
  • Plan regeneration

Keeping these steps independent made the system easier to reason about and debug.

Backend-First Thinking

Most student apps are frontend-heavy. Designing this project as a backend-driven system — where background jobs and services do the real work — required a shift in mindset but ultimately led to a cleaner architecture.

What We Learned

  • How to design a behavior-driven system instead of a static planner
  • How to use Serverpod background jobs effectively
  • How to structure a backend so it remains explainable and hackathon-friendly
  • How to balance ambition with execution under time constraints

Most importantly, we learned that adaptation doesn’t require complex AI — it requires good data, clear rules, and thoughtful design.

What’s Next

With more time, this project could be extended to:

  • Smarter opportunity relevance scoring
  • Long-term burnout detection
  • Offline plan viewing and sync
  • Deployment on Serverpod Cloud

For this hackathon, our focus was on building a solid, adaptive core that demonstrates the power of Flutter and Serverpod working together.

Built With

Share this project:

Updates