PlanB: An AI That Challenges Your Plan Before Reality Does

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I have a friend who is good at making plans.

But there is one problem: his plans usually depend on everything going right.

The train arrives on time.

The internet works.

There is enough time.

Nothing unexpected happens.

And that made me think:

What if AI didn't make Plan A for you, but instead helped you prepare for what could go wrong?

So I built PlanB.

PlanB is an AI-powered backup plan assistant built with Gemma.

You give PlanB the plan you already have. Instead of replacing it, PlanB looks at what your plan depends on and finds realistic things that could go wrong.

For every risk, it gives you:

• Impact
• Warning signs
• Prevention
• A backup action

It also creates a Prepare Now checklist, so you can take action before something goes wrong.

But I wanted PlanB to handle something else too:

What happens when the problem has already happened?

That's where Plan C comes in.

Tell PlanB what actually went wrong, and it uses your original plan, its earlier analysis, and the new situation to help you decide what to do next.

The complete flow is:

Plan A → Find what could go wrong → Plan B → Something actually goes wrong → Plan C

---

Demo

Let's take a real example.

Plan A

Tomorrow I have a job interview in Delhi at 11 AM. My train leaves at 6 AM and I expect to reach Delhi by 9 AM.

PlanB first understands the goal.

Then it identifies things this plan depends on, such as:

• the train arriving with enough time before the interview
• reaching the station on time
• local transport being available in Delhi

It then generates realistic risks, warning signs, prevention steps, and backup actions.

But then reality changes...

Suppose I tell PlanB:

My train is running two hours late.

PlanB doesn't start from zero.

It already knows my original goal and the risks around it.

It uses that context to create Plan C, including:

• Immediate actions
• A revised plan
• Additional risks to watch for

🌐 Live Demo

https://planb-five-pink.vercel.app

🎥 Video Demo

https://youtu.be/xklFTVIHJAw

---

Code

PlanB is completely open source.

GitHub

https://github.com/itsdevcode/planb

I deliberately kept the architecture small and focused:

Next.js Frontend
       ↓
FastAPI API
       ↓
PlannerService
       ↓
Gemma
       ↓
Pydantic Validation
       ↓
Structured Plan B / Plan C

There is no authentication, database, background queue, or unnecessary infrastructure in this MVP.

For a weekend challenge, I wanted every part of the application to support the main idea.

---

How I Built It

Gemma is the core of PlanB

Gemma isn't an extra chatbot added to the application.

It powers the main reasoning behind both Plan B and Plan C.

For Plan B, the backend asks Gemma to analyze the user's existing plan and return structured information.

The response looks like this:

{
  "summary": "...",
  "assumptions": ["..."],
  "risks": [
    {
      "risk": "...",
      "impact": "high",
      "warning_signs": ["..."],
      "prevention": "...",
      "backup": "..."
    }
  ],
  "prepare_now": ["..."]
}

One important decision I made while designing the prompt was to focus on realistic problems instead of extreme ones.

For example, I don't want PlanB to say:

Your train could crash.

I want it to say:

Your train could be delayed enough that you miss the interview.

PlanB should help people prepare, not make them afraid.

Building Plan C

Plan C gives Gemma three important pieces of context:

1. The original Plan A
2. The Plan B analysis
3. What actually went wrong

Gemma then generates:

• Immediate actions
• A revised plan
• Additional risks

This means Plan C isn't just a new unrelated AI response. It continues from the context PlanB already understands.

Structured AI Output with Pydantic

I didn't want the frontend to depend on unpredictable AI text.

The FastAPI backend validates Gemma's output using Pydantic models.

For example:

class Risk(BaseModel):
    risk: str
    impact: Literal["low", "medium", "high"]
    warning_signs: list[str]
    prevention: str
    backup: str

If the model response doesn't match the expected structure, the application doesn't blindly treat it as valid data.

This gives the AI layer a clear contract with the rest of the application.

Backend

The backend is built with FastAPI.

There are two main endpoints:

POST /api/v1/plans/analyze
POST /api/v1/plans/recover

/analyze takes Plan A and creates the Plan B analysis.

/recover takes the original context plus what went wrong and creates Plan C.

The backend is deployed on Render.

Frontend

The frontend is built with Next.js.

I kept the user flow intentionally simple:

Describe Plan A
      ↓
Analyze Plan
      ↓
Understand the Goal
      ↓
Find Assumptions
      ↓
Find Possible Problems
      ↓
Prepare Now
      ↓
Something Went Wrong
      ↓
Build Plan C

The frontend is deployed on Vercel.

Testing

I also added automated tests for the main API behavior.

Gemma calls are mocked in the test suite, so tests can verify the application contract without making real AI requests.

The MVP tests cover:

• Health endpoint
• Successful Plan B analysis
• Invalid Plan A validation
• Successful Plan C recovery
• Invalid recovery input

Current result:

5 passed

One Bug Taught Me an Important Lesson

During development, Gemma sometimes returned an incomplete response.

At first, it looked like the AI or JSON validation was broken.

The real problem was much simpler.

I had configured an output token limit that was too small for the structured response I was asking Gemma to generate.

Removing that unnecessary restriction fixed the problem.

It reminded me that building an AI application isn't just about writing a prompt.

The model, generation settings, validation, backend, and frontend all have to work together.

I also learned that AI responses can take longer than normal API requests.

Instead of pretending the response is instant, PlanB shows a clear loading state while the plan is being analyzed.

---

Why Does Open Innovation Matter?

PlanB uses Gemma, an open-weight model, as its reasoning engine.

That matters to me because the intelligence behind the product doesn't have to be permanently tied to one closed model.

The application has a simple boundary:

Plan
  ↓
AI Reasoning
  ↓
Structured Schema
  ↓
Application

Today, I use Gemma through an API because it allowed me to build and ship the idea quickly during the weekend challenge.

But because Gemma is open-weight, there is a path to running the model through different infrastructure or even locally with suitable hardware in the future.

That is especially interesting for PlanB.

People might use it for plans involving:

• Job interviews
• Travel
• Work
• Personal events
• Projects
• Family plans

Some of those plans can contain private information.

Having an open-weight model creates more options for where that reasoning can happen.

For me, that's one of the most exciting parts of open innovation:

It gives developers more control over how intelligence becomes part of their applications.

---

Prize Categories

Best Use of Gemma

Gemma is the core reasoning engine behind PlanB.

It analyzes Plan A, identifies what the plan depends on, finds realistic failure scenarios, creates preparation steps, and generates Plan C when something actually goes wrong.

Best Use of Render

PlanB's FastAPI backend is deployed on Render.

The Render service handles the API layer connecting the Next.js frontend with Gemma and serves both the Plan B analysis and Plan C recovery workflows.

---

Final Thought

I started this project with a simple observation about a friend.

He didn't need another tool to make plans.

He needed something that could challenge the plan he already had.

That became PlanB.

And after building it, I realized the idea applies to much more than one person.

PlanB doesn't try to predict the future.

It simply helps you stay ready when things don't go as planned.

Because when Plan A fails, you should always have a Plan B.