Lock In

Follow through on a goal by pairing a focus-blocker with a real financial stake you place on yourself.

You set a goal, a daily quota, a time window, and how long you're committing for. You stake your own money and pick a charity. During the window, apps and sites you chose stay blocked until the day's quota is met. Complete the commitment and nothing is ever charged — your card is never touched. Miss days and your stake is forfeited.

No device lockout. No pay-to-unlock. The teeth are the money you staked, never a held-hostage phone. A blocked app is a nudge, and you can always get past it.

Status: in development. The mobile app is Phase 1 and not yet shippable. The Chrome extension in extension/ is the previous iteration — it still works and becomes the desktop verifier for job applications in Phase 2.

The terms

The rule you're charged on, in full:

Missed days	Outcome
0	Nothing charged. Your card is never touched.
1	20% of your stake forfeited. 80% never taken.
2+	Full stake forfeited.

A day is missed when its window closes with the quota unmet, on a day the goal was scheduled. Unscheduled days can't be missed. A partial quota — 3 of 5 — is a miss, recorded honestly as a partial and never rounded up. There are no grace days.

A commitment always runs its full length. Misses never cut it short: losing the stake doesn't mean losing the tool.

Forfeits split 60% to your chosen charity, 40% to Lock In. The 40% is company revenue that funds the platform. Minimum stake £20. Processing fees come out of our share, so the charity receives its full 60%.

Layout

mobile/          Expo app — iOS first (Phase 1, in progress)
  src/lib/time.ts         day boundary, windows, DST
  src/lib/commitment.ts   goals, day resolution, settlement
extension/       Chrome extension — previous iteration, Phase 2 verifier
docs/            Family Controls entitlement request
PROJECT.md       decisions, why they were made, and what they superseded

Running it

cd mobile
npm install
npm test          # 104 assertions across time and commitment logic
npx tsc --noEmit  # typecheck
npx expo start    # requires a dev client, not Expo Go

The Chrome extension loads unpacked from extension/ at chrome://extensions with Developer mode on.

Two rules worth knowing before reading the code

A day starts at 04:00 local, not midnight. A window opening 23:50 and closing 00:10 belongs entirely to its opening date. Windows may not cross the 04:00 boundary — that would split one window across two days, leaving no honest answer to "did it close?", and resolving a window means taking someone's money.

Windows are compared as local wall-clock minutes, never as resolved instants. On a spring-forward day the skipped hour simply never matches, instead of producing a negative deadline. This also maps directly onto iOS: DeviceActivitySchedule is built from DateComponents, which is inherently wall-clock.

Both rules are carried over from the extension, where they were worked out and tested. The tests came with them.

Known limits

• iOS blocking needs Apple's Family Controls distribution entitlement, which is granted selectively and slowly. Development works without it; shipping does not.
• You can't see which apps a user blocked. FamilyActivitySelection returns opaque tokens by design. No analytics on which apps correlate with failure.
• Web blocking is partial — Safari and WKWebView only; other browsers may not honour it.
• Verification is mostly self-report, deliberately. No API can verify "practise guitar", and the stake does the work that policing otherwise would. health (HealthKit) is the one automatic verifier in v1.
• Daily quotas only. "Gym 4× a week" isn't supported yet.
• No Android.

Decisions

PROJECT.md records what was decided, why, what it superseded, and what's still open — including the ones that were argued against and overruled. Read it before changing anything load-bearing.