Wattage

A planner built around scheduled power cuts.

Inspiration

If you've lived somewhere with load-shedding, you know the routine: you plan your evening, and then the power just leaves — on a schedule someone else set. So you replan, in your head, every day, and you get it wrong half the time because you're not actually tracking which of your tasks need a wall outlet and which just need a charged device.

Most planner apps assume electricity and internet are constants. Where I live, they aren't. I wanted to build something that treats an unreliable grid as a real constraint to plan around, not an edge case to ignore — and I hadn't seen anything that does this, which made it a good problem to spend a hackathon on.

What it does

Wattage is an Android app where you enter your area's outage schedule once — the windows when mains power is off — and it automatically slots your tasks into the hours you'll actually have power.

• It understands power requirements per task. A task can need mains power (ironing, desktop work) or just a charged battery (reading, writing, anything on a laptop or phone). Battery-friendly tasks get scheduled into outage windows first, so powered hours stay free for the work that genuinely needs them.
• It tells you what won't fit, instead of silently dropping it or pretending everything's scheduled.
• It's fully offline. No backend, no network calls in the data layer at all — every task, every outage window, lives in local SQLite. The premise is "this has to work when the power and the router are both down," so a server dependency would defeat the point.
• Free tier: one area, manual schedule entry — enough for most individual users.
• Pro tier (RevenueCat): multiple areas, cross-device sync, a home-screen widget, battery-budget planning — aimed at anyone managing more than one property, or a family split across locations.

How I built it

React Native + Expo, Expo Router for navigation, local SQLite for storage, RevenueCat for monetization. This is my first React Native project — I came in from a React (web) + Oracle PL/SQL background, so a good chunk of the build was learning what doesn't carry over from web React: no DOM, no localStorage, Metro instead of webpack, native builds instead of just shipping a JS bundle.

The core of the app is core/scheduler.ts — a pure TypeScript function with no framework code in it at all. It takes your tasks and your outage windows, builds a timeline of powered vs. unpowered minutes, and greedily places each task into the earliest slot that satisfies its power requirement, preferring outage time for battery-capable work. It's independently testable, and it's the one piece of logic I wanted to actually trust, so it has 40+ unit tests covering merging overlapping outages, priority ordering, midnight-spanning windows, and tasks that don't fit anywhere.

RevenueCat is wired to a live offering — the paywall fetches the current offering and its packages directly from the RevenueCat dashboard at runtime, so changing a price or product doesn't require an app update. Nothing about pricing is hardcoded. Purchases are entitlement-gated: a pro entitlement controls whether the free-tier task limit applies, checked through RevenueCat's SDK, not a local flag I could accidentally fake.

Challenges I ran into

Almost all of them were "first React Native project" problems, not product problems. Getting Expo Go, a real EAS build, and a browser preview all working consistently meant hitting SDK-version mismatches, a dependency resolution mess where a stale @react-native/codegen version got hoisted to the root and broke Metro's parser, expo-notifications throwing on import inside Expo Go since SDK 53, and local environment variables not carrying over into EAS's cloud build (RevenueCat's API key has to be set through eas.json, not just a local .env, or the paywall silently fails in the built APK). Every one of these was a real, fixable configuration issue rather than a flaw in the app's logic — and now that they're diagnosed, they won't recur on the next build.

Accomplishments I'm proud of

Getting a genuinely complete RevenueCat purchase flow working end to end — SDK init, live offering fetch, a real completed purchase, and the app correctly reading the resulting entitlement to unlock Pro features — not a mockup, not a hardcoded "isPro" flag. And the scheduler's battery-vs-mains logic actually working the way I designed it on paper: watching a task drop into a dark outage band instead of eating into powered hours was the moment the idea felt real instead of theoretical.

What's next

Notifications (pre-outage warnings) and on-device SQLite persistence need another pass specifically in the release build — they work in development but surfaced build-specific issues I ran out of time to fully chase down before the deadline. Multiple areas, the home-screen widget, and battery-budget planning are designed into the Pro tier but not yet built. And I'd like to explore optional integration with published utility outage schedules where they exist, while keeping manual entry as the reliable fallback.

Built with

React Native, Expo, Expo Router, TypeScript, expo-sqlite, expo-notifications, RevenueCat (react-native-purchases), Jest

Built With

• android
• eas-build
• expo-router
• expo-sqlite
• expo.io
• jest
• react-native
• react-native-purchases
• revenuecat
• sqlite
• typescript