Cost, Maintenance & Who Pays

Building an urban twin is not cheap, and the components are worth knowing even if the rupee figures are entirely context-dependent. You pay for the 3D city model - survey, photogrammetry, LiDAR, or licensing existing data, then processing it to usable detail (Module 2). You pay for the platform: the software that hosts, visualises and serves the model, whether bought, subscribed or built. You pay for initial data integration - connecting the first feeds, reconciling formats and coordinate systems, the genuinely hard plumbing of Module 3. And you pay for bespoke simulation and analytics if the twin is to do more than display - the mobility, flood or energy models that make it more than a viewer.

All of this is real expenditure, and on a city scale it is large. But it has three features that make it the easy part. First, it is one-off and datable: it has a clear start and a clear finish, which makes it easy to budget, approve and celebrate. Second, it is fundable: capital projects attract grants, programme money, political sponsorship and a launch event; there is an appetite to pay for things that can be cut as ribbons. Third, it is visible: you can see what the money bought - a model, a platform, a dashboard on a wall.

The trap is that the build cost is the number everyone anchors on, debates in procurement, and reports in the press - while being a fraction of the twin's true lifetime cost. A rough, deliberately illustrative way to hold it: whatever the build costs, assume the work of keeping the twin genuinely alive and trusted over its intended life will cost as much again and then more, spread across the years after the launch. Teams that budget only the spike are, in effect, buying a twin they cannot afford to keep - commissioning a living system with funding for a monument. The honest planning question is not "what does it cost to build?" but "what is the total cost of ownership over the years we intend to use it, and is that funded?" - and binding procurement and financial decisions, of course, stay with the accountable authorities and their finance and legal processes, not with a vendor's estimate or a lesson's illustration.

If the build is the spike, maintenance is the long tail - and the tail is where twins die. A twin is only a twin while its data is live and its model is trusted, and keeping both true is relentless, recurring work. Data feeds have to be maintained: sensors fail and need replacing and recalibrating, data-sharing agreements expire and must be renewed, source systems change their formats and break the integrations, and paid data subscriptions renew whether or not anyone has budgeted for them. The model has to be kept current: the city changes - new buildings, new roads, demolished blocks - and a model that is not updated drifts away from reality until it is quietly wrong (Lesson 9.2). Simulations have to be re-validated as conditions change, or their outputs stop being trustworthy. Software has to be updated and licences renewed, platforms reach end of life, and security has to be maintained for a system holding sensitive city data.

And underneath all of it, the largest and most fragile cost: people. A twin needs a standing team - data engineers, GIS and modelling specialists, someone who understands the whole system - and that payroll runs every year, competes with every other civic priority, and is the easiest line to cut when budgets tighten. The single commonest way a twin dies is not a technical failure but a human one: the person who understood it leaves, the knowledge walks out of the door, and no one remaining can keep it alive.

What makes this lethal is the asymmetry of attention. The build is exciting, funded and photographed; maintenance is invisible, unglamorous and politically unrewarding - nobody cuts a ribbon for "we kept the data feeds current for another year." So the funding and the attention both concentrate on the launch and evaporate afterward, and the twin enters a slow decay: feeds go stale, the model drifts, trust erodes, usage drops, and within a couple of years the living twin has become an expensive, out-of-date 3D model that no one opens - twin-washing arrived at not by intent but by neglect. The lesson for anyone commissioning, funding or relying on a twin is blunt: treat maintenance as the main event, fund the team and the feeds for the twin's whole intended life before you build, and design the thing to be sustainable - narrow, well-documented, not dependent on one irreplaceable person - because a twin that cannot be maintained should not be built.

How a city sources its twin shapes its costs for years, and the choice is a genuine trilemma with no free option. Building in-house - a custom stack on your own or open foundations - gives the most control and avoids being captive to a vendor, but demands scarce, expensive technical staff and carries the risk that the knowledge lives in a few heads. Buying a vendor platform gets you running fastest and shifts some maintenance to the supplier, but you pay recurring licence fees indefinitely, you are constrained by what the platform can do, and you accept lock-in: your city's data, workflows and competence become entangled with one vendor's proprietary system, and the cost and pain of ever leaving climbs every year. Assembling open components around open standards (Module 5) sits between - lower lock-in and lower licence cost, but real integration effort and the need for in-house capability to hold it together.

Lock-in deserves its own caution because it is a cost that does not appear on the first invoice and grows silently. Once a city's twin is built on a proprietary platform, the vendor holds real leverage: renewal prices can rise, essential features can sit behind upgrades, and the data and configurations may be hard to extract into anything else. Open standards and clear data-portability terms are the main defence, which is one practical reason the course keeps returning to them - they are not merely technical tidiness but a hedge against being captured. The expensive strategic mistake is to choose a route on the demo - the platform that looked best in the sales meeting - rather than on the total cost of ownership and exit: who will own, feed, staff and be able to leave the twin in year four and year eight.

There is no universally right answer; the route depends on the city's capacity, the decision the twin serves, and how much independence matters. A city with strong in-house GIS and data teams may sensibly build or assemble; one without may have no realistic option but to buy, and should then negotiate hard on data portability, exit terms and long-run licence costs rather than just the headline price. Whatever the route, the binding procurement, contractual and financial decisions stay with the accountable authorities and their legal and finance functions - a lesson can explain the trade-offs, but it cannot and does not specify what any city should sign.

The hardest economic question about a twin is not how much it costs but who keeps paying, year after year, long after the launch. A twin's value is long-term and diffuse - better decisions over a decade - while its maintenance cost is immediate, concrete and recurring, and that mismatch is politically toxic. The people who cut the ribbon are rarely the people who must fund the upkeep in year five, and a shiny launch under one administration can become an unloved budget line under the next, defunded not because it failed but because it is invisible and someone else's project.

So the durable question for any twin is: what is the funding model for its whole intended life, and is it robust to a change of government, a budget squeeze and the departure of its champions? The fragile answer is a one-off grant or a capital budget with no committed operating line - the classic recipe for a built-then-abandoned twin. Sturdier arrangements tie the twin to an ongoing operational function so that maintaining it is part of running the city rather than a discretionary extra: a drainage twin funded from the water utility's operating budget because the utility uses it every monsoon, a transit twin carried by the transit authority because planning depends on it. Others explore shared funding, where the agencies and bodies that benefit contribute, though that brings its own governance tangles. Some models lean on the private sector, which raises sharp questions - taken up in Module 8 - about who then controls a twin of a public city and in whose interest.

For India the caution is especially pointed. Programme and mission funding can pay handsomely for the build, which is exactly why the prestige-project and twin-washing risks are real: the capital arrives, the twin is launched, and then the recurring operating money - far less glamorous and competing with every urgent civic need - fails to materialise. The honest position is that a twin should not be commissioned until there is a credible, durable answer to who pays to keep it alive for its whole life; a twin funded only to be born is a twin funded to die. As a designer, student or citizen, the single sharpest economic question you can put to any proposed city twin is not "what will it cost to build?" but "who is committed to paying to keep it breathing in year five, and what happens to it when they are gone?" Everything about whether a twin survives is hiding in that answer.