a clear answer to what I am doing here, what I have done so far, and how it should be judged.

Forge Residency: objective, progress, and accountability.

This stay is not meant to be vague startup talk. It is a fixed build sprint. The goal is to make Soar iOS and Astrail more real, get sharper feedback, and leave July with proof that can be judged clearly.

End date

July 31, 2026. This is the review date, not an open-ended stay.

Checkpoint

By July 20, I should be able to show visible demo progress and serious feedback.

Proof

Demos, commits, screenshots, recordings, feedback notes, and a clear August decision.

Fair rule

If I cannot show progress by the checkpoint, I should come back or change the plan.

01 · objective

The objective is simple: build, show, learn, decide.

The residency is useful only if it produces visible work. By the end of the month, I should be able to show what I built, what changed because of feedback, and what decision I am making for August.

  • Make Soar iOS feel closer to a real product: cleaner flows, tighter UI, fewer obvious mobile bugs, and a demo path that can be shown on a phone.
  • Move Astrail forward with a visible product milestone instead of only keeping it as an idea.
  • Work on real coding problems: iOS UI, product flows, app architecture, builds, polish, bug fixing, and AI/product direction.
  • Use the people here for direct technical feedback, product judgment, and pressure to ship.
  • Leave with proof: demos, commits, screenshots, screen recordings, feedback notes, and a clear August plan.

02 · accomplishments

What I have accomplished so far.

Build sprint

I converted the stay into a focused build sprint instead of treating it like a vague hacker-house experience.

Soar iOS

I worked inside the real iOS codebase, fixed visible UI and product polish issues, pushed code, tested builds, and coordinated around flight detail and navigation issues.

Product quality

I focused on things that make an app feel real: broken layout, oversized UI, weird mobile presentation, animation polish, passenger flows, and user-facing bugs.

Astrail

I continued product direction and execution work so Astrail does not stay as a vague idea.

Clarity

I have a clearer milestone list for what needs to be demoable by July 31 and what should be cut if it is not working.

Accountability

The stay is now structured around proof, not just effort: commits, demos, recordings, feedback, and checkpoints.

Important: I am not claiming the final result is already done. I am saying there has been real work, and the next step is to turn it into visible proof by the checkpoint.

03 · remaining work

What still needs to be done.

  • Make Soar iOS fully demoable on a phone, with the core path clean enough to show without explaining around broken parts.
  • Polish the main Soar flows: results, passenger details, flight detail, booking path, navigation, and mobile presentation.
  • Fix remaining visible bugs and record before/after proof for the changes that matter.
  • Create one clear Astrail milestone that can be opened, shown, or walked through with evidence.
  • Collect serious feedback from builders/users and write down what changed because of that feedback.
  • Prepare a July 20 checkpoint update and a July 31 final packet: demos, commits, recordings, feedback, and an August decision.

04 · environment

The environment is the part I cannot fully recreate at home.

At home, I can still write code. Here, I am around people whose default day is building, shipping, debating products, debugging, and comparing output. That changes my speed and standard.

Forge describes the Bengaluru July cohort as a 31-day residency with 16 fellows, and frames it as a place for builders going full-time on what they love. The practical value is simple: faster feedback, higher pressure, and less room to hide behind vague plans.

  • If I am stuck, I can get feedback faster.
  • If the product is confusing, someone can tell me directly.
  • If my output is weak, it becomes obvious because other people are shipping too.
  • The people here include serious engineers, founders, dropouts, and builders working across AI, apps, infra, product, and startups.

05 · checkpoint

The fair way to judge this is a checkpoint, not a panic decision.

By July 20, I should be able to show visible demo progress and serious feedback. If I cannot, then staying here is not justified and I should come back or change the plan.

Going home immediately cuts the experiment before the proof is ready. The first stretch gave me setup and momentum. The useful part now is turning that into visible output before July 31.

Judge the stay by what exists: demos, commits, recordings, feedback, and the August decision.

06 · evidence by july 31

What should exist by the end of the month.

Soar iOS demo

A phone demo of the core flows and visible UI/product fixes.

Astrail progress

A concrete product milestone that can be opened, shown, or explained with evidence.

GitHub commits

Proof that I actually shipped code, not just thought about it.

Feedback notes

Who I spoke to, what they said, and what changed because of it.

August plan

A direct decision: continue, narrow, pause one project, or switch to a more practical path.