Inspiration
We all know the feeling: your alarm goes off, you reach for your phone, hit snooze, and tell yourself you'll get up in five minutes.
Then five minutes becomes thirty.
We wanted to build something that could interrupt that automatic behavior without simply making the alarm louder or more annoying. The idea was simple: if you're awake enough to turn off your alarm, you should be awake enough to solve a small problem.
What it does
WakeMath is an alarm and focus app built around one simple mechanic:
You have to solve something before you can continue.
For alarms, WakeMath presents a math challenge when it's time to wake up. You solve the challenge to dismiss the alarm and start your day.
For focus sessions, WakeMath can restrict access to selected apps once your allowed time has been reached. Instead of immediately returning to the app, you're presented with a math challenge.
The challenges range from simple arithmetic to more difficult problems, with multiple difficulty levels.
WakeMath also includes daily challenges and local progress tracking, giving the experience a little more continuity than simply solving a random equation every morning.
The important part is that the experience is designed around intentional friction. You're not being told that you can't use your phone. You're being asked to actively choose to continue.
How we built it
WakeMath was built natively for iOS using SwiftUI.
We separated the math system from the rest of the application so that generating puzzles, checking answers, handling difficulty, and creating daily challenges could all be tested independently.
The app is designed to work locally rather than depending on a server for its core functionality. Your alarms, challenges, and progress don't need a network connection to function.
We also had to work with several different parts of Apple's ecosystem to make the experience possible, including Apple's alarm and Screen Time-related frameworks and the extension architecture required for the focus experience.
One of our priorities throughout development was making the app predictable. Instead of building individual features in isolation, we defined how the app should behave when something unexpected happens and then built the different flows around those rules.
Challenges we ran into
The biggest challenge wasn't actually creating the math puzzles.
It was working within iOS.
An app doesn't have complete control over the operating system. Things like background execution, system audio, permissions, app termination, and Screen Time restrictions are controlled by Apple.
That meant we couldn't simply say, “The user isn't allowed to leave this screen.”
We had to design around what iOS actually allows.
We also had to deal with Apple's entitlement requirements for Screen Time functionality. Some of the focus features depend on permissions and entitlements that aren't available in the same way during normal development and simulator testing.
Another challenge was making the experience feel strict without making it hostile.
If the app makes it impossible for someone to recover from an unexpected state, that's not good friction — that's just a broken app. We therefore spent a lot of time thinking through what should happen when the app is closed, relaunched, interrupted, or loses access to something it previously had permission to use.
That led us to treat recovery as part of the product rather than an afterthought.
Accomplishments that we're proud of
We're proud that WakeMath became more than just an alarm that displays a math question.
We built a complete concept around the idea of using small amounts of intentional friction to change behavior.
We're particularly proud of the separation between the puzzle engine and the rest of the application. It means the core logic can be tested independently instead of relying on manually running through the app every time we make a change.
We're also proud of building the project with a local-first mindset. The core experience doesn't need a backend just to wake you up or give you a puzzle.
Most importantly, we have a working end-to-end prototype that lets us experience the idea as a real product rather than just describing it on paper.
What we learned
The biggest thing we learned is that friction has to feel fair.
It's easy to build something that blocks the user.
It's much harder to build something that makes the user pause without making them feel trapped.
That distinction changed how we approached WakeMath.
We also learned that the operating system is part of the product design. On iOS, you can't always implement the experience exactly the way you imagine it. Sometimes the better solution is to understand the platform's boundaries and design an experience that works with them.
Most importantly, we learned that solving a small problem can be surprisingly effective at breaking an automatic behavior.
What's next for Wake Math-MathAlarm.
There are several directions we'd like to explore next.
Earned screen time is one of the biggest ones. Instead of simply waiting for a restriction to disappear, users could earn additional time by successfully completing challenges.
We're also interested in pre-commitment — allowing users to decide their rules ahead of time, when they're thinking clearly, rather than making those decisions when they're tired or already distracted.
Another direction is making WakeMath more adaptive. If someone repeatedly dismisses an alarm and immediately returns to it, the app could adjust the challenge to create a little more friction.
And eventually, we'd like to explore an Apple Watch experience, allowing users to solve their morning challenge without even needing to pick up their phone.
The long-term idea remains the same:
WakeMath shouldn't take control away from you. It should help you take control back.
Log in or sign up for Devpost to join the conversation.