Skip to main content

​
December 22nd, 2025

The Day We Built Intent, Pressure, and Structure Today didn’t start like a normal dev day. Before touching any code, we made a conscious decision: finish one thing properly. That choice shaped everything that followed.

​
The Conscious Pause

Q: What was different about today’s approach? Normally, development starts with opening the editor and building the next feature. Today, we stopped first. The realization: “If we keep building randomly, CommitT will slowly become just another productivity app.” That was concerning because CommitT is not supposed to feel like a habit tracker or an app blocker. Q: What did we do before coding? We listed everything the app eventually needs:
  • Verification
  • Alarms that work after restart
  • Maps
  • Strict mode
  • Penalties
  • Waivers
  • Payments
But instead of trying to do everything, we made a decision: today, we will finish just one thing properly — Start Verification. That choice shaped the entire day.

​
The Initial Problem

Q: What was wrong with the initial verification UI? Initially, the verification UI looked very similar to app blockers. There were buttons like Timer and Manual Check, and even though it worked, something felt off. Q: Why did it feel wrong? It felt like we were giving the user options at the moment when there should be no negotiation. The UI was treating verification as a setting, when it should be something else entirely.

​
The Realization: Verification as Commitment Checkpoint

Q: What is verification, really? Verification is not a setting. It is a commitment checkpoint. Q: What should the user see right before they are held accountable? Not controls. Not explanations. They should see the terms they already agreed to. This was the key insight: at the moment of verification, the user should not be making new decisions. They should be reminded of the decision they already made.

​
Redesigning the Verification Card

Q: How did we redesign the Verification Card? We redesigned it to show facts, not explanations:
  • Gym
  • 6:00–7:00
  • ₹500
  • CAPTCHAS
No sentences. No “this means if you fail then…”. Just facts. Like a contract summary. Q: Why does this matter? At a glance, the user knows: I agreed to go to the gym between 6 and 7, I have ₹500 at stake, and the only waiver is CAPTCHAS. At that moment, CommitT stopped feeling like an app that helps you, and started feeling like an app that expects something from you. This is the difference between a productivity tool and a commitment system.

​
The Entire Card as Decision

Q: How did we simplify the interaction? Instead of making the user click a specific button like “Start Verification”, we realized something simpler and stronger: the entire card itself should be the decision. Q: What does this mean in practice? If you tap anywhere on that card, you are saying: “I am entering verification mode.” The button inside becomes just a visual cue, not the real action. Q: Why is this better? We made the entire Verification Card pressable. The inner buttons were made non-interactive — just indicators. One tap anywhere means there is no confusion and no half-commitment. This removes ambiguity. There is no “maybe I will start verification” — there is only “I am entering verification” or “I am not.”

​
The Architectural Decision: Route Separation

Q: Where does verification belong in the app structure? This was a significant architectural moment. Verification does not belong in creation. It does not belong in settings. Those are places where you tweak things. Verification is execution. Q: What did we create? We created a separate route group:
Q: Why does this matter? That single decision quietly enforced a rule:
  • Before this route → you can edit, adjust, rethink
  • Inside this route → you only do
No renegotiation. No editing penalties mid-way. That separation is subtle, but it is the backbone of the product. This architectural choice enforces the psychological boundary between planning and execution.

​
The Classic Dev Moment

Q: What went wrong initially? Everything looked correct, but tapping the card did nothing. At first glance it felt broken, but it was not a logic issue. Q: What were the actual problems? Two small mistakes caused it:
  1. Routing to /index instead of the group path
  2. Placing a pressable card inside a header component that was swallowing touch events
Q: How did we fix it? Once we fixed those — moved the card out of the header and routed correctly — the flow worked as intended. Tap the card, verification page opens. Q: Why did this moment matter? That moment mattered more than it looked, because that is when the flow became real. The architecture was correct, but the implementation details were blocking the user experience. Fixing those details made the entire concept functional.

​
What We Actually Built

Q: What did we actually build today? By the end of the day, we did not build alarms, or camera verification, or backend logic. But we built something more fundamental: the line between planning and execution. Q: What does this mean for CommitT? CommitT now has a clear moment where the user crosses over:
  • Before that moment, the app is flexible
  • After that moment, the app is strict
Q: What did we actually build? Not just UI. Not just navigation. We built intent, pressure, and structure. Q: Why does this make CommitT different? This is why CommitT now genuinely feels different from an app blocker. An app blocker is a tool you use. CommitT is a system you enter into. The difference lies in the architecture of commitment, not only in the features.

​
The Verdict

Q: What was the real achievement today? Today we built the psychological and architectural foundation for verification. We did not just add a feature — we created a boundary. A moment of transition. A point of no return. Before verification: planning, adjustment, flexibility. After verification: execution, accountability, structure. That boundary is what makes CommitT feel like a commitment system, not just another productivity app.