How I Built an App That Forces You to Remember Your Goals — and Finally Finished It

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built Goal OS — an Android app designed to make your goals absolutely impossible to ignore.

I’m a Mechanical Engineering student and a self-taught developer, and I suffer from a problem most of us share: I set ambitious goals, feel incredibly motivated for about twenty-four hours, and then completely forget them. Every goal-tracking app I tried had the exact same structural flaw: you have to open it for it to work. The moment life gets busy, the app disappears into an app drawer, and your goals disappear with it.

Goal OS flips that dynamic entirely. Instead of forcing you to visit your goals, it embeds them directly into your daily rhythm:

Personalized Morning Alarms: Greets you by name and briefs you on your specific focus areas for the day.

Context-Aware Reminders: Notifications don't just say "open the app"; they route directly to the specific goal they are about.

Progress Logs: A continuous history of your effort, keeping you accountable over time.

Weekly Review System: A built-in mechanism that forces you to pause and reflect on your wins, challenges, and overall direction.

This isn’t just a tracker. It’s a comprehensive system for people who are serious about what they are building toward.

Demo

This is a link to a demo for the app https://youtube.com/shorts/KcS3G5t_3mg?si=dGZ6sOyAtfbFNxPv.
And here is the link to the github repository

The Comeback Story

I started Goal OS in the first week of April. The base was there — goal creation, SQLite storage, Supabase sync, clean UI. But the features that made it actually different from every other goal app were either broken or missing entirely.
Notifications were firing at midnight instead of scheduled times. Reminder notifications had no goal context — just a generic ping. Vision rotation notifications showed as blank cards in the notification shade. There was no progress logging, no weekly reflection, no history. A newArchEnabled conflict between app.json and gradle.properties was silently breaking the build. The SQLite path in the native helper was wrong so it loaded empty data without a single error thrown.
The app looked finished. It wasn't.
What I fixed and finished:

Progress logging — every check-in creates a timestamped log, visible as a full history on the goal detail screen
Weekly Review screen — mood selector, wins, challenges, reflection, and a scrollable list of past reviews
Notification deep linking — tapping any notification navigates directly to the relevant goal, not the home screen
Personalized morning alarm — greets you by name, feels like a brief not a ping
Midday and evening notifications — reference your actual top goal title, not generic copy
Streak warning — fires at 8:30pm if your streak is at risk
Background fetch task — streak checks run even when the app is fully closed
Build fixed — resolved newArchEnabled conflict, removed duplicate expo-build-properties entry, corrected SQLite path

My Experience with GitHub Copilot

Copilot changed how I work on complex features — not by writing code for me, but by letting me work at the level of intent rather than implementation detail.
The most valuable thing I learned was how to write prompts that actually work. Vague prompts get vague code. Specific prompts — ones that reference exact file names, existing function patterns, and the precise behavior you want — get code that slots directly into your project without introducing new conventions or breaking what's already there.
Here's a concrete example. I needed to build a full Weekly Review screen — mood selector, multiple text inputs, a save function that writes to SQLite and syncs to Supabase, and a past reviews list. Instead of asking Copilot to "build a weekly review screen," I gave it this:

"Create components/weekly-review.tsx. Use useColorScheme, Colors, ThemedText, ThemedView from existing imports. Load reviews on mount using getWeeklyReviews(). Show a mood selector with 5 emoji buttons stored as values 1–5, active one highlighted with c.accent. Three multiline TextInputs for wins, challenges, and reflection. A save button that calls addWeeklyReview, clears the form, and calls syncLocalDataToSupabase if a user_id exists. Below the form, a past reviews list showing week_start, mood emoji, and truncated wins. Follow the exact same StyleSheet pattern as components/morning-brief-settig.tsx."

The output needed minimal adjustment. Because I told it exactly which existing components to use, which DB functions to call, and which file to match for styling — it worked within my codebase instead of inventing its own patterns.
I used the same approach across every feature I finished during this sprint. For progress logging, I told Copilot exactly which table columns existed and which existing function to use as a style reference. For notification fixes, I described the exact bug — "goal reminder trigger time is always midnight because new Date('YYYY-MM-DD').getHours() returns 0" — and told it to default to 9am without changing anything else. For the background fetch task, I gave it exact import paths, the task name constant, and which useEffect to register it from. Each time: one precise prompt, one clean result.
That's a different way of building — and it's faster.

Takeaways
This sprint taught me a fundamental truth about AI-assisted development: Copilot is not a replacement for understanding your own codebase. It is a force multiplier for developers who already do.

The more context and architectural precision you feed it, the more effective it becomes. By the end of this sprint, I wasn't spending my mental energy on syntax or repetitive boilerplate. I was thinking purely about the product logic and the engineering requirements, translating that high-level intent into instructions precise enough for Copilot to execute cleanly.

That is an entirely different, incredibly fast way of building software.