Inspiration

A lot of productivity tools are designed around finishing tasks: complete the checklist, hit the deadline, maintain the streak, close the loop.

But for many people, the hardest part is not finishing. It is starting.

The moment before action is often where avoidance, anxiety, perfectionism, low energy, and uncertainty show up. A task can be important and still feel impossible to begin.

That insight led me to create Startam, built around one simple idea:

Don’t finish. Begin.

Instead of pressuring users to complete an entire task, Startam helps them make a commitment to start, reduces the task when they feel stuck, and records proof that they began.

What it does

Startam is an AI accountability app focused on helping people move from hesitation to action.

A user creates a commitment, chooses when they want to begin, and decides what proof of starting will look like.

When the commitment becomes due, the user can:

  • start immediately
  • say they are stuck
  • reschedule the commitment
  • release it when circumstances genuinely change

When a user selects I’m stuck, Startam asks what is blocking them and uses AI to generate one short, specific action that is easier to begin.

For example, instead of saying “work on your presentation,” Startam may suggest:

Open the presentation and write one heading.

If that still feels difficult, the user can ask Startam to make the action even smaller.

After starting, the user can submit text or image proof. The commitment is then recorded in History as Started. Released commitments are also preserved in History without being treated as failures.

Startam also supports multiple independent commitments, scheduling, in-app due states, rescheduling, persistent local data, and responsive mobile and desktop layouts.

How I built it

I built Startam as a responsive web application using Codex and GPT-5.6 throughout the development process.

The app uses the OpenAI Responses API to generate smaller, commitment-specific actions. The API integration runs server-side so the OpenAI API key is not exposed in the browser.

I used Codex across the development workflow, including:

  • application structure
  • interface implementation
  • state management
  • local persistence
  • multiple commitment support
  • scheduling and reminder states
  • AI-generated task reduction
  • proof submission
  • History records
  • responsive design
  • debugging and regression testing
  • GitHub preparation
  • Vercel deployment

I gradually moved from broad implementation prompts to narrower, testable instructions. Before making changes, I asked Codex to verify whether an issue still existed, preserve working behavior, make the smallest safe correction, and test the exact flow afterward.

The project is stored in a public GitHub repository and deployed as a live application on Vercel.

Challenges I ran into

One challenge was keeping every AI response tied to the correct commitment. Earlier versions could accidentally carry context from one commitment into another. I had to ensure that each request used only the current commitment, the current blocker, and the current reduction level.

Supporting multiple commitments was another major challenge. The first implementation behaved more like it had one global commitment, meaning a new commitment could overwrite the previous one. I changed the state structure so every commitment retained its own ID, schedule, AI state, proof, status, and History record.

I also had to make Released a truly terminal state. Released commitments initially remained active in parts of the app, but they now disappear from Today, cannot become due again, and remain available only in History.

The most difficult bugs involved proof and History persistence. At one point, proof submission displayed Success but reverted after refresh. After I fixed that, saving a Started record could remove an unrelated Released record. Resolving these issues required tracing the full flow across UI state, commitment state, History records, local storage, and refresh hydration.

Another challenge was balancing polish with hackathon scope. I focused on honest in-app reminder states rather than claiming to support background notifications when the browser is closed.

Accomplishments that I’m proud of

I am proud that Startam became a complete working product rather than only a visual prototype.

A user can now:

  1. Create a commitment.
  2. Choose when to begin.
  3. Receive an in-app due state.
  4. Ask for help when stuck.
  5. Reduce the suggested action further.
  6. Submit proof of starting.
  7. View the result in History.
  8. Preserve commitments and records across refreshes.

I am also proud of the app’s focus. Startam did not become another large task-management platform. It remained centered on one specific moment: when someone knows what they need to do but cannot make themselves begin.

The AI is intentionally constrained to produce one useful action rather than long motivational advice or an overwhelming productivity plan.

What I learned

I learned that productivity tools do not always need to push people harder. Sometimes the most effective intervention is to reduce the size of the action.

I also learned that AI can become more useful when its role is narrow and clearly defined. Startam does not ask AI to manage a user’s entire life. It asks a smaller question:

What is the smallest useful action this person can take right now?

From a technical perspective, I learned how important state boundaries are. When an application supports multiple commitments, every schedule, AI response, proof submission, status change, and History record must be connected to the correct commitment ID.

I also learned that effective AI-assisted development depends on verification. Codex produced better and safer results when I asked it to inspect, reproduce, repair, and test instead of immediately rewriting large parts of the application.

What’s next for Startam

Future versions of Startam could include:

  • authenticated user accounts
  • cloud synchronization across devices
  • browser and mobile push notifications
  • recurring commitments
  • calendar integration
  • optional accountability partners
  • richer proof verification
  • personalized suggestions based on previous blockers
  • native mobile applications
  • deeper accessibility support

I would also like to explore how Startam can learn which kinds of smaller actions work best for each user while keeping the experience private, simple, and non-invasive.

My long-term vision is to make Startam a trusted tool for the space between intention and action.

Not a tool that demands completion.

A tool that helps people begin.

Built With

  • chatgpt
  • codex
  • gpt5.6
  • gpt5.6sol
Share this project:

Updates