Why we flattened the tax curve: inside the September 2026 economy update

The problem: towers were paying like whole districts

Until September 2026, residential tax in BuildCity was a straight line. Every resident contributed the same amount, so a building's tax was simply its population multiplied by a base rate, happiness, and your chosen tax rate. That is a perfectly reasonable rule for a city of small houses. It stops being reasonable once density upgrades arrive, because a 2x2 plot that holds 48 people at level 1 can hold 350 to 500 people at level 3. The same footprint was suddenly paying seven to ten times as much tax, and a player who stacked a few schools and hospitals in the right place could watch income climb far faster than anything else in the game.

The result was an economy with no late game. Once a city crossed into widespread level 3 housing, money stopped being a constraint. Service upkeep, construction costs, and trade prices had all been tuned for a world where income grew roughly with the number of buildings, not with the cube of their density. We had to decide whether to raise every cost in the game or to bend the income curve. We chose to bend the curve, and this article explains exactly how.

The formula we shipped

The new rule computes a tax-effective population for each residential building from its real footprint area and its real population. Let A be the number of tiles the building actually occupies and P be the number of residents living in it.

• The first 12 residents per tile count in full, exactly as before.
• Residents 13 through 60 per tile count at 50 percent.
• Every resident beyond 60 per tile counts at 25 percent.

Three properties of this shape were non-negotiable during design. First, it is a piecewise curve applied to the marginal residents, not a blanket multiplier on the whole building, so an existing building never loses tax when it grows or upgrades; it only gains less. Second, it is expressed per tile of footprint, which means rotating a building or choosing a 1x2 over a 2x1 cannot change its tax efficiency, and the rule works unchanged for every supported private building size up to 6x6. Third, it is the same function everywhere: online tax ticks, the offline settlement when you return, and the per-building figures shown in the budget panel all call the same calculation, so the numbers you see agree with the numbers you are paid.

Commercial and industrial buildings were handled separately with simple density multipliers. Low, middle, and high density now contribute 1, 1.35, and 1.7 times the base amount respectively, replacing the previous 1, 2, and 3. The density upgrade is still clearly worth having; it just no longer triples a district's revenue on its own.

What it does to a real district

The cleanest way to see the effect is a controlled comparison. Take 100 one-tile residential buildings at 50 percent happiness and a 10 percent tax rate with no buffs, and vary only how many people live in each one. The table shows tax per real hour before upkeep.

The first row is the point of the whole exercise. A starter city of ordinary houses pays exactly what it paid before. The curve only starts to bite when a tile is carrying more than twelve people, which in practice means middle and high density housing. For a single 2x2 commercial or industrial building at the same happiness and tax rate, the figures moved from 150, 300, and 450 per hour at low, middle, and high density to 150, 202.5, and 255.

What deliberately did not change

Balance changes are easiest to trust when their scope is narrow, so the September update touched the residential curve and the commercial multipliers and nothing else. Population numbers, growth speed, the population thresholds for city rank and department unlocks, construction costs, resource production, trade prices, tourism facility income, and every player's existing cash balance were left exactly as they were. Happiness scaling, your selected tax rate, the commercial tourism buff, and the advertising buff all still apply on top of the new base in the same way they applied to the old one.

We also kept the server's accounting contract. The hourly rate the server stores for each city remains the pre-tax-rate, pre-buff base amount it always was. The new curve changed how that base is computed, not what it means, so saved cities did not need any migration. A city that had not been saved since before the update simply kept using its last stored base until its next save recomputed it.

How we tested it

The curve is implemented twice, once in the browser for live play and once on the server for settlement and validation, and the two must agree to the unit. We wrote eighteen numeric cases into a shared fixture that both the Java test suite and the JavaScript test runner load, covering the boundaries between the three segments, rotated and non-square footprints, empty buildings, buildings under construction, buffs, tax rates, zero income during commercial closing hours, and the server-side cap. The full Java suite at the time, 101 tests, passed alongside the front-end income checks and the existing regression scripts.

What we did not do, and said so in the design notes, was measure long-run net profit on real player cities before shipping. The synthetic tables above are gross tax. A high-density city with heavy service upkeep could see its net income fall by more than the gross figures suggest, and we flagged that as the main risk to watch.

What came next: the October ledger and operating costs

Flattening the curve solved the runaway income problem but exposed a second one: the accounting underneath it was inconsistent. The server was crediting the pre-tax-rate base without subtracting upkeep, the client was re-adding taxes on load, and a freight station was paying out random shipments even with an empty warehouse. In October we rebuilt that layer. The server now keeps a protected ledger per city, applies your tax rate to the actual payout, subtracts facility, add-on, and truck costs once per period, and carries fractional remainders forward. The browser predicts from the same ledger, so displayed and saved balances match. The details are in the idle income article.

On top of the corrected ledger we added a city operating cost, which is the late-game counterpart of the flattened curve. Each completed, active building contributes a weight derived from the same per-tile population curve above (for housing) or from its density-weighted occupancy (for businesses). The city's total weight is billed in tiers, and only the portion above each threshold pays that tier's rate.

The design target was that a healthy late-game city spends roughly 65 to 75 percent of its income on operations and reinvests the rest, instead of accumulating cash with nothing to spend it on. The charge phases in at 25, 50, 75, and 100 percent across the first 72 effective hours after the update so that established cities are not shocked, and no period before the update is billed retroactively.

What this means for how you play

1. Density is still worth it. Level 3 housing still earns more than level 1 on the same land; the gap is just closer to two to one than eight to one.
2. Happiness and tax rate matter more than ever, because they multiply a base that no longer grows explosively. A 10 percent rate at 70 percent happiness is the balance point the operating cost tiers were tuned around.
3. Watch the budget panel's expense lines. Facility upkeep, add-ons, trucks, and operating cost are now listed separately, and the sum tells you whether a new district will pay for itself.
4. Do not overbuild services for empty land. Under the old curve you could afford it; under the new one, upkeep on unused radius is the most common cause of a late-game deficit.

The Taxes and Budget guide covers the day-to-day decisions, and the City Planning Tool will run your current numbers through the same logic to suggest a next step.