Budget a Weekend AI App Before the 2027 Price Hike

Your weekend app on Gemini 3.7 Flash has a cheap rate with a deadline. The introductory API cost is $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026. On January 1, 2027, the standard API cost becomes $1.50 per million input tokens and $7.50 per million output tokens. For a small side project, that dated rate is the constraint.

Gemini 3.7 Flash launched on August 13, 2026. The introductory tier is half the original cost of Gemini 3.6 Flash. The scheduled change doubles both input and output rates after December 31, 2026. The doubling is pre-announced, effective January 1, 2027, from the introductory rates.

The dated rate is the real budget

For a small app, the token bill can stay small if traffic is modest. The risk appears in the month after the rate changes: a side project can survive a low bill, but it can also quietly outgrow the rate that made the bill low.

Choosing a model also means choosing a time frame. A few more weekends to finish can make the dated rate the right choice. Months of running before launch can force a different choice.

Build the budget around the date

To estimate the current bill, multiply expected monthly input tokens in millions by the introductory input rate. Multiply expected monthly output tokens in millions by the introductory output rate, then add the two amounts. Keep the estimate rough, not perfect. The test is whether the bill stays small before the date changes.

• Write down the rate you will actually pay. Record the input rate, the output rate, and the end date in a project note. A short note that survives a busy weekend is enough.
• Mark the date the rate changes. Put the scheduled change in a calendar reminder, not in your memory. The reminder should say the rate changes.
• Estimate tokens from real usage. Count the prompts, replies, retries, and background jobs your app will run. A rough monthly token range is enough.
• Choose the exit before the clock runs out. Decide whether to ship before the hike or switch to a model without a scheduled clock. A dated decision beats a vague hope.

The usual mistake is treating the introductory price as the permanent baseline. The entry price has a date, and the date belongs in the plan.

Choose the exit before the clock runs out

Shipping before the hike is the cleanest path when the app is already useful. When the main feature works, the users are real, and the cost is still small, launch while the introductory rate applies. A small app needs a live version that can answer whether people will use it, not a perfect feature set.

Choosing a model without a scheduled clock is the safer path when the project needs more time. When you are still testing prompts, changing the interface, or waiting for a feature to feel right, a stable rate can keep the weekend work calm. The tradeoff is that the model may be less attractive on paper, but the absence of a dated hike can be worth more than a temporary discount.

Most side projects stay side projects, and that is fine. The decision should fit the hours you actually have. Keep the scope small enough that the token bill stays boring. Cut the background jobs early. Shorten the prompts. Cache repeated answers. Limit the number of automatic retries. A weekend app needs to be cheap enough to keep running while you learn, not clever about everything.

Check the bill after a real week of use. Lower usage leaves the dated rate as a possible path. Higher usage makes the scheduled change a real decision. Either ship the app, move to a model without a scheduled clock, or narrow the feature set until the cost fits the weekend budget.