DEV Community: Arun Yadav

PlanB: An AI That Challenges Your Plan Before Reality Does

Arun Yadav — Sun, 04 Oct 2026 17:20:52 +0000

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:

The original Plan A
The Plan B analysis
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.

Mastering Routing in FastAPI: From Flat Files to Clean Architecture

Arun Yadav — Wed, 09 Sep 2026 17:37:32 +0000

When building an API with FastAPI, it’s deceptively easy to dump every endpoint into main.py. A few @app.get() decorators here, a couple of @app.post() decorators there, and everything works.

Then your project grows. Suddenly, main.py is an 800-line monolith, team members are constantly hitting Git merge conflicts, and nobody knows where the user authentication logic ends and the billing logic begins.

FastAPI solves this with APIRouter. Here is how to structure your routing cleanly from day one.

1. The Core Tool: `APIRouter`

Think of APIRouter as a mini FastAPI app that doesn’t run on its own. It groups related path operations together, which you then mount onto your main application.

A typical modular directory structure looks like this:

my_project/
├── app/
│   ├── routers/
│   │   ├── users.py
│   │   └── items.py
│   ├── dependencies.py
│   └── main.py
└── requirements.txt

In your module (app/routers/users.py), define your router:

from fastapi import APIRouter, HTTPException

router = APIRouter()

@router.get("/")
async def list_users():
    return [{"id": 1, "username": "alice"}]

@router.get("/{user_id}")
async def get_user(user_id: int):
    return {"id": user_id, "username": "alice"}

Then, register it in app/main.py:

from fastapi import FastAPI
from app.routers import users

app = FastAPI()

app.include_router(users.router, prefix="/users", tags=["Users"])

Two key parameters to notice:

prefix: Prepend /users to every endpoint in the router. Notice how users.py uses / and /{user_id} instead of repeating /users everywhere.
tags: Groups these endpoints together in FastAPI's auto-generated Swagger UI (/docs).

2. Cleaner Endpoints with Shared Dependencies

One of the biggest advantages of APIRouter is attaching security checks or common dependencies to an entire group of routes at once.

Instead of writing Depends(verify_token) on 15 separate endpoints, apply it to the router level:

# app/routers/admin.py
from fastapi import APIRouter, Depends
from app.dependencies import require_admin_role

# Every route attached to this router will now require admin access
router = APIRouter(
    prefix="/admin",
    tags=["Admin"],
    dependencies=[Depends(require_admin_role)]
)

@router.delete("/purge-cache")
async def purge_cache():
    return {"status": "cache cleared"}

3. Nesting Routers for Sub-Resources

Real-world APIs often have hierarchical relationships—such as comments belonging to a specific post (/posts/{post_id}/comments).

Rather than hardcoding long prefix strings, routers can be nested inside other routers:

# app/routers/comments.py
from fastapi import APIRouter

comments_router = APIRouter()

@comments_router.get("/")
async def get_comments(post_id: int):
    return {"post_id": post_id, "comments": []}

# app/routers/posts.py
from fastapi import APIRouter
from app.routers.comments import comments_router

posts_router = APIRouter(prefix="/posts", tags=["Posts"])

# Mount comments directly under a specific post
posts_router.include_router(
    comments_router,
    prefix="/{post_id}/comments",
    tags=["Comments"]
)

Now, mounting posts_router inside your main.py automatically exposes both /posts and /posts/{post_id}/comments cleanly.

4. API Versioning Without Headaches

Versioning is simple when your routing is modular. You can bundle whole sets of routers under a version prefix:

# app/main.py
from fastapi import FastAPI, APIRouter
from app.routers import users, items

app = FastAPI()

# Create a v1 router
api_v1 = APIRouter(prefix="/api/v1")
api_v1.include_router(users.router, prefix="/users", tags=["Users"])
api_v1.include_router(items.router, prefix="/items", tags=["Items"])

# Include the full v1 bundle into the main app
app.include_router(api_v1)

When it's time for v2, you can spin up an api_v2 router alongside it without touching older client integrations.