Ninja
Innovation

There is a particular kind of frustration that arrives when you discover that the data you need to do your job is sitting behind a wall you cannot climb. The wall might be a paywall. It might be a ministry. It might be a procurement clause that asks for six months of TOR writing before anyone is allowed to call anyone else. Whatever it is, the wall is there, and it is between you and the question you are trying to answer.

The traditional response is to spend money. Hire a vendor. Sign a contract. Wait. Hope the data, when it finally arrives, is still relevant to the question you originally asked.

The ninja response is different. It says: I am not going to climb this wall. I am going to find a substitute that is, for my purpose, just as good — maybe better — and is sitting in plain view.

A definition

Ninja innovation is the practice of solving real public problems by combining three things that are now, for the first time in history, abundantly available to anyone with a laptop and curiosity:

One. Public data — satellite feeds, open APIs, government records that, by treaty or by law, are obligated to be open if you read the fine print.¹

Two. Generative and agentic AI — models that can read, summarize, triangulate, and now, increasingly, take actions on your behalf. They do not replace your judgment. They extend the reach of one person's hands.

Three. A sideways question — the willingness to ask not "how do I get the data I want?" but "what would tell me almost the same thing?"

That third ingredient is the rare one. Public data has been around for a decade. AI is everywhere now. What is rare is the practitioner who, when blocked, refuses to wait, and instead goes looking for a useful proxy.

The aerosol map

I will tell you the story I told the room in Singapore. I had been asked to advise on travel routes through the Middle East during a flare-up. The honest answer was that I did not know. I am Thai. I work for a Thai agency. I have no analyst on the ground in Tehran or Tel Aviv. The honest, helpful answer required ground truth I did not have access to.

So I asked the wrong question. I asked: where in the Middle East is there a lot of combustion right now? Combustion produces aerosols. Aerosols are tracked, in near real time, by the public satellite layer that NASA and JAXA publish daily. I toggled the layer. The map lit up where the war was hot, where industry was burning, where agricultural fires were going. It was not the map I wanted. It was a map that told me, with about ninety percent fidelity, what I needed to know.

That is ninja innovation. I did not get information. I substituted it. I did not pay for it. It was already there. I did not write a TOR. I clicked a checkbox.

Why ninja

I use the word with affection and with a small amount of self-mockery. Ninjas, in the cinematic shorthand we all carry, are quiet and asymmetric. They do not announce themselves. They do not fight the dragon. They slip past it.

That is the posture I want for this practice. Not heroic. Not adversarial. Just oblique. The bureaucracy is the dragon. The vendor's price sheet is the dragon. The fact that the one person in your office who knows how to do this thing has been on leave for two months is the dragon. You are not going to slay any of them. You are going to slip past them and deliver something useful while everyone else is still arguing about the tender.

The ninja innovator's question is not why is this so hard? It is what is the smallest move I can make right now that gets us partway there?

What this book is for

This book is a record of those moves. Some are recipes — exact tools, exact stacks, exact prompts I used. Some are patterns — the shape of a problem and the shape of the workaround. Some are stories from the field, because the workaround that worked in Nakhon Si Thammarat is, by accident, also the workaround that will work in Lagos or Lima.

I have organized it in three parts. The first is the manifesto: the five principles that separate this practice from the older one. The second is field notes: five real cases, with the costs and the failures included. The third is the toolkit: the actual stack, the actual incentives, the actual things that go wrong at four in the morning when an agent has been running unsupervised for six hours.

If you only read one part, read the field notes. The principles will sound obvious there. They are not obvious until you watch them work.

There is a photograph I keep in a folder on my desktop. It shows a wide, empty boulevard in Ordos Kangbashi, the famous Chinese ghost city that Forbes has been writing updates on for ten years. The avenue is six lanes wide. The streetlights are immaculate. There are no cars. There are almost no people. There is a very large, very clean sculpture in the middle of a roundabout. The sculpture is of two horses. The horses are bigger than the cars that are not there.

I keep the photograph because every time I am asked to advise on a smart city plan and someone shows me a render, I open the folder. The render is always lush. The grass is always green. The pedestrians, drawn in by the marketing team, are always smiling and almost always white. The render shows me what the city will look like the day it opens. The Ordos photograph shows me what a city looks like seven years after it opens, when the speculation has cooled and the residents have not arrived.

A list of expensive failures

Songdo, in South Korea, was supposed to be the smartest city in Asia. Sensors in every lamppost, automated waste tubes under the sidewalks, a master plan drawn by an American architect with a master plan reputation. Le Monde, a few years in, called it a ghetto for the affluent. Foreign companies did not move their headquarters. The waste tubes filled with the wrong kind of waste.

Nusantara, the new Indonesian capital being built from scratch in the jungle of East Kalimantan, has had hundreds of billions of rupiah committed to it and roughly the population of a midsize village living on site. Investors have been quietly pulling out for two years. The architects, I would bet money, do not plan to live there.

I do not bring up these projects to mock them. I have, in my career, been the urban planner whose render was on the wall. The point is not that these designers were stupid. They were not. The point is that money plus intention, the formula that built every smart-city deck of the last two decades, does not produce livability. It produces real estate. Sometimes it does not even produce that.

The procurement gauntlet

Let me describe what happens, in a normal smart-city contract in a normal Asian government, when a real problem is identified and someone tries to solve it.

Month one through six: a Terms of Reference is drafted. The TOR specifies, in exhaustive detail, what the system shall do. It cannot specify too loosely or the procurement officers will reject it. It cannot specify too tightly or only one vendor will qualify. It is rewritten an average of four times.

Month seven through twelve: procurement. Bidders are invited. Bidders pretend their off-the-shelf product matches the TOR exactly. They are awarded the contract. The actual product, when it arrives, will turn out not to match the TOR exactly.

Month thirteen through fifteen: bidding details, kickoff meetings, signature delays. Month sixteen through eighteen: planning. The vendor's architect describes the system on PowerPoint slides. Month nineteen through twenty-four: implementation. Halfway through, the technology referenced in the TOR is superseded by something better. The contract does not allow for substitution.

You have spent two years and several million dollars and you have arrived at a system whose technology is, on the day it goes live, already a generation old. The mayor who started the project may no longer be the mayor.

The flip

Here is the alternative. It works because it costs almost nothing.

You see a problem. You build the smallest working version of a solution in a weekend, on subscription tools that bill you twenty-five dollars a month. You show it to the mayor, the agency head, the operator on the ground. If they like it, you talk about scaling. If they do not, you turn it off. The cost of being wrong is twenty-five dollars and a Saturday.

The Phuket smart bus, which I will return to in chapter seven, is a system the city did not have. To convince Phuket that GPS-tracked, demand-aware buses would be a real improvement, I built a working simulation. It took me forty-five minutes on a second-hand laptop in a coffee shop. I sent the URL to the relevant person in Phuket. They saw the gap. They wanted the system.

This is the flip. The contract does not lead to the project. The project leads to the contract. The prototype is the proposal.

What dies in the flip

I want to be honest about what is lost. The procurement system, for all its inefficiency, was a discipline against corruption. It enforced documentation. The flip removes that discipline by removing the contract from the front of the process.

This is why ninja innovation is, by design, almost free. If the project costs me twenty-five dollars a month, no one will accuse me of corruption. There is nothing to embezzle. When you can no longer use money as a reward, you have to find the reward somewhere else. We will come back to that in chapter thirteen.

For now: the trap is real. Money is necessary for some things. It is not what makes a city smart. What makes a city smart is somebody, ideally not too senior, who is willing to skip the contract and ship the prototype.

A framework should earn its keep. Most of the frameworks that get put on slides do not — they are mnemonics in search of a memory. The Four Ps survive because they catch, in order, the four ways every smart-city project I have ever seen tends to fail. If a project is failing, it is failing on at least one of these. Usually two.

The Ps are: Purpose, Practical, Proof, and People. Or, if you prefer the verb forms: design, data, optimize, incentivize.

Purpose: design with a real outcome

Purpose is different from intention. Intention is a feeling. Purpose is a measurable outcome you have committed to.

Intention says: we want our students to be more engaged. Purpose says: we are going to use AR and VR to teach biology, and we will measure engagement, not grades, and the success criterion is plus forty percent on the engagement metric within one school year.

That is what we did at Nakhon Si Thammarat Metaverse School, in southern Thailand. Engagement, not grades, was the target — because grades, we believed, would follow engagement automatically, and they did. We hit the forty-percent number. We could not have hit it if we had spent a year arguing about the educational philosophy of the metaverse before turning anything on.

The trap inside Purpose is the trap of the impressive demo. A demo does not have a purpose. It has an audience. Build for real life, not demos.

Practical: better data, used promptly

Practical means digitalization that earns its complexity. It means using data to change a physical decision in a way that will be felt by a human being within forty-eight hours.

The case here is the digital twin we built for Phuket. Sensors, cameras, simulation. The output is not an animation. The output is: traffic congestion is down thirty percent, and the city now has forty-eight hours of advance warning before a flood. The animation is a side effect.

The test for Practical is brutal: name the decision this data changes. If you cannot name it, the data is decoration.

Proof: optimize, do not assume

Proof is the discipline of treating every belief as a hypothesis until the system tells you it is true.

In Rayong, we built a remote-care system for non-communicable disease. The hypothesis was that local governments needed a way to classify residents into four risk tiers — Normal, At-Risk, Disabled, Bedridden — so that benefits could be targeted by tier. We did not optimize the distribution before we ran the system. We ran the system, watched what happened, and only then did we optimize. The result was a fifteen to twenty percent reduction in cost.

The order matters: ship, measure, then improve.

People: incentives over instructions

The fourth P is the one I wish more leaders thought about first.

You can mandate a system. People will use it for as long as someone is looking. Then they will go around it. Or you can make using the system the path of least resistance, plus a small reward. The reward does not have to be money.

In Nakhon Si Thammarat, citizens report problems to a LINE app. They give the staff who fix the problems a one-to-five star rating. Staff stars accumulate. Stars feed into promotion decisions, automatically, with no committee.

What used to be the kiss-the-boss promotion model became the kiss-the-citizen promotion model. And the response time? It went from one hundred and eighty-four hours to forty-two.

The Ps in order

The order is the order of failure. A project without Purpose fails first, at conception. A project with Purpose but no Practical data fails second, at implementation. A project with both but no Proof fails third, at scaling. A project with all three but no People dies fourth, the slow death by quiet non-adoption.

If you are diagnosing a project that is in trouble, walk down the list and stop at the first one that breaks. That is the one to fix.

For most of my career, I worked on the assumption that policy comes first. You convene the working group. You produce the white paper. You consult the stakeholders. You publish the strategy. And then, after about eighteen months, you build the thing the strategy describes.

The problem with this order is not that policy is bad. The problem is that policy, written in the absence of a working system, is a guess. Sometimes the guess is correct. More often it is correct in the abstract and wrong in the specific. The system, when finally built, has to be retrofitted around a policy that was written before anyone knew what the system would actually do.

The inversion is simple. Build a small working version of the system first. Watch what people do with it. Codify what works.

Why this is now possible

This inversion was not available to anyone five years ago. Building anything required vendors, time, and money. Today the cost of a working prototype is, in the cases I will describe, between zero and twenty-five dollars a month. The cost of being wrong is the cost of a coffee. That changes the math of policy.

It changes who is qualified to propose policy, too. Until recently, only the people with the budget could propose anything. Today, the person with curiosity and a laptop can propose by demonstration. The mayor sees a working dashboard. The dashboard makes a case the white paper could not have made.

An example

The civic-issue reporting system in Nakhon Si Thammarat was not policy first. There was no smart-city ordinance that mandated it. There was a flood-prone city, a mayor who needed re-election, an annual cycle of damage, and one civil servant who built a small thing.

The small thing was a LINE bot that took a photograph, extracted its geolocation, ran it through a quick AI check for plausibility, opened a ticket, dispatched a team, and waited for the citizen to rate the outcome. It cost almost nothing to build and almost nothing to run.

The first month, a few hundred citizens used it. The first year, tens of thousands. By the time we were tracking the system at scale, it had handled forty-thousand-plus problems. Then the policy got written. The regulation was not a guess. It was a description.

The fail-fast clause

The other half of solve-first is also kill-first. If a system does not work, you turn it off. There is no political capital invested in it. There is no five-year plan that has to be saved. There is, in my case, a server bill that you stop paying.

I have killed many systems. I have built a Bangkok-wide air-quality alerting tool that nobody used and turned it off after six weeks. I have built a tourism-recommendation prototype that was technically correct and culturally useless and turned it off after a month. The freedom to kill a system is structurally identical to the freedom to build one. Both freedoms come from the cost being low.

What policy is for, when you no longer write it first

Policy is now a description of what is already working, formalized so it can be funded, scaled, and protected from political turnover. It is a ratchet, not a blueprint. It is what you write after you have stopped guessing.

This is, perhaps not coincidentally, what I trained for. I am an anthropologist by doctorate. I spent four years in Shanghai's alleyway houses watching what residents actually did, as opposed to what they said they did. The lesson of that fieldwork has, two decades later, become the lesson of this practice. Policy by ethnography. Build first. Watch hard. Codify the truth.

For a long time, the smart-city industry treated data as a commodity to be purchased. Vendors would arrive with their proprietary sensors and their proprietary analytics platforms and their proprietary licensing terms. Cities would pay. Cities would notice that the data was not all that useful. Cities would pay anyway.

This still happens. It is a smaller industry than it used to be, because most of the data that mattered turns out to be free if you know where to look.

The five kinds of free data

Satellite layers. NASA, JAXA, ISRO, ESA, the Chinese space agencies, and Roscosmos all operate under public-data obligations of varying strictness. The fine print is rarely cited because almost nobody reads it. I have read it. Aerosol concentration, vegetation health, surface temperature, nighttime lights, precipitation, water vapor — all queryable, daily, in near real time.²

Open government data. Almost every national statistics office publishes a feed. The World Bank, the Asian Development Bank, the OECD, and the UN all publish economic and demographic feeds. The data is messy and sometimes years out of date. AI cleans it faster than a research assistant.

Social listening. Citizens broadcast their problems publicly all the time. They do it on TikTok, on X, on local Facebook groups. Tools that sample and classify these signals exist. A flooded street in Bangkok shows up on social media within minutes; the official report shows up days later, if at all.

Webcams and traffic feeds. Cities have already paid for cameras at intersections, in transit hubs, at construction sites. Most of these cameras stream publicly or semi-publicly. AI can watch them at a fraction of a cent per analysis.

Radio. This one I love. In Bangkok, traffic-accident information is still distributed by analog radio. So I have a radio at home, with a microphone in front of it, listening twenty-four hours a day. Every time the radio reports an accident, an AI model transcribes it and writes a pin to a map. Analog data, made digital, with no input from any human. Total cost: the price of a radio.

The discipline of the proxy

Public data is rarely the data you originally wanted. It is almost always the data that, with a little ingenuity, gives you ninety percent of what you wanted.

You wanted ground truth in the Middle East. You got aerosol concentration. You wanted in-bus passenger counts. You used flight-arrival schedules as a demand proxy. The skill is not access. The skill is the proxy. What is almost-the-same-thing, free?

The expiry problem

One caveat. Free data tends to become not-quite-free over time, especially when it becomes economically valuable. The defense against this is to use it while it is open, and to publish your work in such a way that the open data community has a stake in keeping it open. I publish my pipelines. I share the GitHub repos. I do this in part because I believe in the public-good case, and in part because if my pipelines are widely depended on, the satellites that feed them are slightly more likely to remain open. Mutual interest is the cheapest insurance.

If you have a project you are thinking about, do not wait. The data is free today.

Nakhon Si Thammarat is a province most people outside Thailand have never heard of. It sits on the eastern coast of the southern peninsula, between the Gulf of Thailand and a chain of low mountains. The mountains catch the monsoon. The monsoon falls on the city. The city floods, every year, in patterns that have been documented since the seventeenth century and that no infrastructure budget has ever fully addressed.

The mayor at the time was a man named Kanesh, and the problem he came to me with was not the floods themselves. The floods were unsolvable on his timeline. The problem was the response time on the ten thousand small things that broke after a flood — and between floods. The streetlight that had been out for a month. The drain clogged with leaves. These were, in aggregate, why people were unhappy with the municipality.

The baseline

The baseline response time, when we measured it, was one hundred and eighty-four hours. Just under eight days. That was the median time between a citizen reporting a problem and the problem being marked resolved. The reporting channels were a phone line that was rarely answered, a walk-in counter at city hall, and a Facebook page that was monitored erratically.

The build

What we built was a LINE app. LINE is the messaging app that everyone in Thailand uses, the way Brazilians use WhatsApp. The friction of installing a new app would have killed the project in a week. So we did not install a new app. We added a chatbot to the messenger people were already in.

The bot took a photo. It pulled the geolocation from the photo's metadata. It asked the citizen, in casual Thai, to pick a category. It opened a ticket. It dispatched the ticket to the relevant department. When the work was complete, it pinged the citizen and asked for a one-to-five star rating.

The clever part was the rating. Stars accumulated, by staff member. The staff who got the most five-star ratings on the most tickets resolved fastest got promoted. The committee had no role. The mayor had almost no role. The citizens decided who advanced.

What went wrong

Three things went wrong. One: the AI categorization was wrong about ten percent of the time. A photograph of a dead snake on a sidewalk got categorized as "stray animal" and dispatched to animal control, who arrived expecting a live one. We added a triage layer.

Two: a few staff members figured out that they could resolve tickets quickly by marking them resolved without doing the work. Citizens caught this immediately, gave one stars, and the leaderboard self-corrected.

Three: the system was so much faster than the rest of the municipality's processes that it created internal jealousy. We resolved it by making the system mandatory for the relevant departments.

What it cost

Roughly nothing. The LINE bot was built on a free tier. The classification ran on a model API at fractions of a cent per ticket. The dominant cost was the salary of one civil servant, half-time, for six months — and that civil servant was already on payroll.

I think about this often when I am told that smart cities are expensive. The most-used smart-city application I have ever helped build was, in cash terms, almost free. Its cost was paid in attention.

Phuket is a small island with a very large tourism economy. Two airports' worth of arrivals, a few hundred thousand permanent residents, traffic that has been quietly worsening for fifteen years, and a public transit system that, on the day I was asked to consult, did not really exist.

The provincial government wanted a digital twin. The phrase "digital twin," at that moment, meant whatever the most recent vendor pitch had told them it meant. It usually meant a 3D rendering of the island on a wall. I was asked to scope a procurement. I declined to scope a procurement. I built a working prototype instead.

Forty-five minutes

I was in a coffee shop. I had a second-hand laptop. I pulled the public flight-arrival data for Phuket International. I pulled the GPS feed for the existing minibus operators. I wrote a small simulation that showed, on the left, planes landing at the airport, and on the right, buses leaving the airport. The gap between the two — passengers landing, buses available — was the metric I was after.

It took about forty-five minutes. It was not pretty. It was clearly a prototype. I sent a screen recording to the relevant person in Phuket's transit department. Within a day, three things happened. First, the prototype was forwarded to the deputy governor. Second, a meeting was scheduled. Third, the meeting was not about whether to build the system. It was about how fast.

What demand-aware means

The buses do not run on a fixed schedule. They run on a demand schedule. When flights are landing, more buses are dispatched to the airport. When the airport is quiet, the buses are repositioned to wherever the social-media chatter and the cellular data show concentrations of foot traffic.

Phuket has reported a thirty-percent reduction in airport-area congestion since the system went live. I cannot independently verify the thirty percent. I can verify that the buses, when I have ridden them, are full.

The flood module

The other thing the digital twin became was a flood-warning system. We layered satellite precipitation forecasts on top of the road-network model, and we now produce, for the city's emergency operations center, a forty-eight-hour advance warning of which roads are likely to flood and how deep.

Forty-eight hours is enough time to move equipment, warn residents, and pre-position the pumps. The forty-eight-hour warning, by itself, has prevented several million baht of equipment damage that would have been lost in the previous reactive system.

I have stopped writing procurement scopes. I now write prototypes that, if they work, become the scope.

Rayong is an industrial province on the eastern seaboard of Thailand, the petrochemical heart of the country. The deputy chief executive at the time was a former engineer. He came to me with a specific frustration: his social-welfare budget was being sprayed across the population with very little intelligence about who actually needed which benefit.

Free eyeglasses for senior citizens, distributed by ward without regard to whether the senior citizen could already see. Free adult diapers, distributed by ward without regard to whether the recipient was bedridden or running marathons. The problem was not budget. The problem was targeting.

Four tiers

We classified residents into four tiers: Normal, At-Risk, Disabled, and Bedridden. The classification was done partly by the existing public-health volunteer network, which had been visiting households for decades and had a working knowledge of who was who. AI was the tool that made their data legible.

The volunteers had been writing in notebooks. We gave them a simple form, on a tablet, that mirrored the notebook. The structured data fed a classifier. The classifier suggested a tier. The volunteer could override. The override rate in year one was fifteen percent. By year two it was under five percent.

What the tier unlocked

The savings, in misdirected procurement, were between fifteen and twenty percent of the social-welfare line.

The harder problem

The harder problem in Rayong was not the classifier. It was the connectivity. Many of the bedridden tier lived in households where the smartphone belonged to a working-age adult who took it to work each day. Telemedicine on a phone that is not in the house is not telemedicine.

The fix was a small dedicated device, basically a tablet locked to two apps, given to the bedridden tier and connected to the local hospital's nursing station. It cost about a hundred dollars per household. Telemedicine adoption in the bedridden tier went from near zero to about sixty percent within six months.

Over the first two years, the system ran at a net savings to the province. The province now uses the system as the standard intake for any new social-welfare program.

In late 2024 my agency, depa, was asked to produce a national livability dashboard. The brief was modest in tone and absurd in scope. Cover every district, every municipality, every sub-district in Thailand. Score each on a livability index. Make the score actionable. Do it on a budget that, in any previous decade, would not have funded the data collection for one province.

Thailand has roughly seven thousand local administrative units. Until recently, producing a livability index for seven thousand of anything would have required a survey infrastructure that does not exist in this country, or any other country, in 2026.

What the index actually measures

The index has six axes. Mobility, environment, public services, economic vitality, social cohesion, and digital readiness. Each axis aggregates between four and twelve underlying indicators, drawn almost entirely from public data — satellite layers, telecom records anonymized at the ward level, government statistics, social listening, weather.

I will not pretend the indicators are perfect. The social cohesion axis leans on social-media sentiment as a proxy and is almost certainly wrong in interesting ways. The mobility axis, by contrast, leans on telecom-derived movement patterns and is very nearly ground truth.

The shape of the work

The shape of the work that produced this index would have been, in 2018, something like a hundred research assistants for two years. The shape of the work in 2026 is six full-time staff for ten months, with AI as the unsleeping intern.

The intern's job was data ingestion and harmonization. Different agencies use different geographic codes. One ministry uses 1990-era sub-district names. Another uses the 2017 redistricting. A third uses postal codes. In our pipeline, the reconciliation is automated. The AI reads the source documentation, infers the mapping, flags ambiguity, and asks a human only when it is uncertain.

Where it gets political

An honest book has to admit this part. A national index that ranks seven thousand cities is, immediately and unavoidably, political. We managed this in two ways. First, by being aggressively transparent about methodology — every indicator is documented, every calculation reproducible. Second, by separating the ranking from the action. The dashboard does not lead with "you are 4,237th." It leads with "here are the three things that, given your peers, you could do next."

This is not a complete solution to the politics. It does, however, change the conversation from "this index is unfair" to "the index says I should fix my drainage, and you know what, I should fix my drainage."

I want to close Part Two with the case study that, more than any of the others, taught me what this practice actually is. It is a small case study. The deliverable was a single afternoon's work. But it is the case I tell first when I am asked what ninja innovation means in three minutes or less, because it contains the whole pattern in miniature.

The setting was the Israel-Iran flare-up of mid 2025. I was being asked, by colleagues who were planning travel through the region, what the ground situation actually looked like. I did not know. I had no analyst on the ground. I had a laptop and a Claude subscription.

The wrong question

The right question — where is the violence concentrated? — was unanswerable to me. So I asked a wrong question that I could answer: where in the Middle East is there a lot of combustion right now?

Combustion produces aerosols. Aerosols are tracked by NASA's MODIS satellites, by JAXA's Himawari, by ESA's Sentinel program. The aerosol layers are public. They are updated multiple times per day. Anyone can query them.

I queried. The map lit up. Tehran, dim. The corridor between Israel and southern Lebanon, bright. Gaza, very bright. Industrial corridors near Bandar Abbas, bright in a different pattern, indicating ordinary heavy industry rather than war. Agricultural fires in Egypt, bright but dispersed.

What the map said

The map did not tell me where the violence was. It told me where things were burning, which is a different question. But the overlap, in the case of an active military conflict, is high enough that the map was, for travel-routing purposes, almost as good as the question I had originally wanted to ask. I overlaid flight paths. My colleagues took those routes. They came home.

Total time invested: about one afternoon. Total cost: my Claude subscription. Total information value: enough to make a real travel-routing decision affecting several human beings.

It is not a substitute for real intelligence. It is, however, a real answer where I had none. And in the gap between no information and professional intelligence, where most of us actually live, the proxy is the practice.

People ask me, with some regularity, what I actually use. The question is sometimes framed as curiosity and sometimes framed as challenge — as if the answer, if sufficiently cheap, would disprove something. The answer is cheap. That is not a challenge to anyone. It is the point.

Here is the actual list. I have not rounded up the costs to make them look more serious. I have not rounded them down to make myself look more frugal. These are the receipts, approximately, as of early 2026.

• Claude (Anthropic)Primary AI — coding, research, agents, analysis. The engine for most of the builds in this book.
  $20/mo
• Claude CodeAutonomous coding agent in my terminal. Replaces a junior developer for 90% of tasks.
  Usage
• SupabaseDatabase, auth, storage, edge functions. The backend I use for almost every project.
  $25/mo
• GitHub + Cloudflare PagesVersion control and deployment. Every project gets a live URL in under two minutes.
  Free
• Mapbox / MapLibreMaps and geospatial rendering. The spatial layer on most dashboards.
  $0–50/mo
• RenderBackend hosting for bots, cron jobs, PostGIS databases.
  $25/mo
• NASA / JAXA / ESA APIsSatellite data. Aerosol, vegetation, surface temperature, nighttime lights. Completely free.
  Free
• LINE Messaging APIBot interface for Thai citizen-facing applications. Goes where the users already are.
  Free tier

The total for a month in which I am building something serious: between ninety and a hundred and fifty dollars. The total for a quiet month: under fifty.

What this stack replaces

It replaces the infrastructure that, five years ago, would have required: a data engineering team, a cloud architect, a GIS specialist, a backend developer, a database administrator, a DevOps engineer, and a project manager to coordinate them. The combined salary bill for that team, in Bangkok, would be in the range of three hundred thousand dollars a year. My stack costs under two thousand.

I am not claiming I produce the same output as that team. I am claiming I produce, on a solo budget, output that a year ago would have required that team. The gap is real and it is closing, not from the team's direction.

The agent layer

The part of the stack that most changed what I could do in the last year is the agent layer — specifically, Claude Code, which runs in my terminal and executes tasks autonomously. I describe a system. I walk away. An hour later there is a working prototype that I did not type.

This is not magic. The agent makes mistakes. The mistakes are usually findable. Fixing them is faster than writing from scratch. I now think of my role less as a coder and more as a QA engineer reviewing an agent's output.

What I still do myself

Judgment. Every system in this book required a human to decide what the system was for, what the success criterion was, and when to kill it. AI is very good at executing within a goal and very poor at setting the goal. The goal is still mine.

Relationships. No system in this book was adopted without a human conversation. The deputy governor in Phuket, the mayor in Nakhon, the engineer in Rayong — these were real meetings with real people who needed to trust the person behind the prototype, not just the prototype. That trust does not transfer to a bot.

And sleep. I am forty-two years old. I sleep eight hours. The agents run while I do.

My mother owns a television remote control with thirty-six buttons. She uses four of them. The other thirty-two exist because, at some point in the product development process, someone decided that having thirty-two additional features would make the remote more impressive in a store. It has made the remote unusable in a living room.

I think about this remote control every time I am asked to present a smart-city dashboard to a government delegation. The delegation wants the thirty-two buttons. They want the drone integration, the augmented reality layer, the machine learning forecast, the citizen-engagement leaderboard. They want to see the future. I want to show them the four buttons that will actually save them time next Tuesday.

Who the demo optimizes for

A demo is designed for a person who is paying attention, who has been primed to be impressed, and who will not actually use the product. It is designed for the delegation visit, the board meeting, the pitch deck. It is designed for the moment of acquisition, not the moment of use.

Real life is different. Real life is the civil servant at nine in the morning who has seventeen browser tabs open, a phone ringing, and a chief who just walked in with an urgent question. Real life is the village health volunteer who is semi-literate and has a phone with forty percent battery. Real life is the bus dispatcher who trained on the old system and has strong opinions about the new one.

The system that works for the demo almost never works for real life. The system that works for real life almost never wins the demo. The ninja innovator has to choose.

The design rules I use

One action per screen. If someone can only do one thing on this screen, what should that one thing be? Every additional option is a friction multiplier.

Zero training assumption. The system should be discoverable without a manual, a training session, or a designated champion. If it requires explanation, it will be explained once and then forgotten.

Show the number, not the chart. A chart is beautiful and almost always requires interpretation. A number requires none. The Phuket transit dashboard has one number at the top: the gap between airport arrivals and available buses, in minutes. That number changes. People check it.

Mobile first, always. Every system I have built that has been actually adopted was adopted on a phone. Not a laptop. Not a kiosk. A phone in a pocket, often with intermittent signal, often with hands that are doing something else.

The forty-five-minute rule

There is a version of the Phuket prototype I could have spent six months building. It would have been beautiful. It would have had satellite imagery, animated route overlays, a machine-learning demand forecast, a user management system, role-based access control, and a mobile app for the dispatchers. I spent forty-five minutes building the version that got the deputy governor to call a meeting.

The forty-five-minute version had two columns, one number, and a gap. That was it. The gap did the convincing. Everything else was not needed for the conversation, and some of it turned out not to be needed at all.

The discipline of the forty-five-minute version is not laziness. It is the refusal to build things before you know they will be used. The features you omit now you can always add later. The features you add now that nobody uses you cannot easily remove — they are owned by someone's expectations.

There is a standard story about digital transformation in government that goes like this: the system is built, the training is delivered, the manual is written, and then the staff use the old system anyway because the old system is what they know, what they are used to, and what nobody is going to penalize them for.

I have watched this story play out, in whole or in part, in almost every government project I have ever been involved in. The system adoption problem is not a technology problem. It is a human problem. You can solve technology problems by improving technology. You cannot solve human problems by improving technology.

Why instructions fail

An instruction tells a person what to do. An incentive tells a person what they will get for doing it. The instruction assumes the person is listening and willing. The incentive assumes the person is rational and self-interested. Of these two assumptions, the second is reliably more accurate.

This is not a cynical observation. Self-interest is not the enemy of good government. Self-interest properly channeled is one of the most powerful forces available to a public administrator. The challenge is to align self-interest with the public good, not to suppress it.

The Nakhon Si Thammarat system did exactly this. The civil servant who resolved tickets fastest got the most five-star ratings. The civil servant with the most five-star ratings got promoted. The civil servant who wanted to get promoted therefore wanted to resolve tickets fast. Their self-interest was, in this system, identical to the citizen's interest. Nobody had to write a policy about urgency. Urgency was the rational choice.

Designing the incentive

The incentive that works is specific, observable, and timely. Specific: not "be a good civil servant" but "resolve this ticket before someone else does and get the five-star rating." Observable: the leaderboard is visible to everyone, in real time. Timely: the star goes to the resolver within hours of the citizen's rating, not at the annual performance review.

The incentive that fails is vague, delayed, and private. "We value your contribution to the department" is an instruction wearing an incentive's clothes. Nobody has ever resolved a pothole faster because of a generic thank-you email.

Non-monetary incentives

The most powerful incentives in government contexts are usually not money. Money is complicated — it requires HR processes, budget approvals, equity considerations. Non-monetary incentives are simpler and, in many cases, more motivating.

Recognition is an incentive. Public, visible recognition — a leaderboard, a badge, a name called out in a meeting — costs nothing and activates something deep in human psychology about status and belonging.

Autonomy is an incentive. The staff member who earns the right to handle her own ticket queue without supervisor approval values that autonomy more than a salary increment. The autonomy was earned by the stars. The stars are provided by the citizens. The citizens, quietly, now run the promotion committee.

Avoidance is an incentive. Nobody wants to be last on the leaderboard. The fear of the bottom is as motivating as the ambition for the top. In Nakhon, the lowest-ranked staff member in the first quarter had a direct conversation with her supervisor about why. The conversation was not about the leaderboard. It was about whether her caseload was manageable. She was overloaded. The system had surfaced a management problem that nobody had known existed.

That is what a well-designed incentive structure does. It does not just change behavior. It reveals the system's actual state.

I want to end with the sentence that got me into trouble on stage in Singapore, because I think it is true and I think it has to come with a caveat that I did not give it that day.

The sentence is: if you can imagine it, you can build it.

I said this in the context of a workshop on public-sector innovation. I meant it as encouragement. I meant it as a description of what has changed in the last two years. The engineering constraint — you need a team, you need a budget, you need a contract — has not disappeared but it has shrunk so dramatically that for most of what a public servant in a middle-income country needs to build, it is no longer the binding constraint. The imagination is the binding constraint. If you can hold a clear enough picture of what you want, the tools to build it are available to you.

The caveat I owe you

After the talk, a young woman from the audience — she was, I learned, a data scientist at a public health ministry — came and said: "You said if we can imagine it we can build it. But my ministry can imagine a system that tracks the movement of citizens who have not consented to being tracked. Can we build that?"

The answer is yes. You can build that. The tools are the same tools. The satellite data is the same satellite data. The AI is the same AI. The fact that it is now cheap and fast to build a civic surveillance tool is exactly as true as the fact that it is now cheap and fast to build a pothole-repair tracker.

I told her: the question that used to be "can we build this?" has become "should we?" The engineering question has been largely settled. The ethics question is wide open.

What I trust

I trust the practice I have described in this book because it is cheap enough to fail and cheap enough to stop. The systems I have built have been small enough that no government has had a meaningful interest in capturing them. The LINE bot in Nakhon was built by a civil servant on a government salary. It belongs to the city. If the city turns it off, it turns off. If the city uses it to harass rather than serve citizens, the citizens will give it one star and the leaderboard will tell the story.

The incentive structure, if you design it right, is also the accountability structure. Citizens who rate the service become a form of distributed oversight. This is not perfect oversight. But in the countries where this practice is most needed — middle-income governments with overstretched audit capacity and under-resourced civil society — distributed oversight beats no oversight.

The practitioner I am trying to describe

She works in government, or adjacent to it. She has a specific problem she cannot solve through the normal channels because the normal channels are too slow, too expensive, or simply not available. She has a laptop and curiosity and now, after reading this book, a small collection of techniques.

She is not a technologist. She is a public servant who is willing to be a little oblique. She does not fight the dragon. She slips past it.

She builds something small. She shows it to the mayor. If it works, she makes it bigger. If it does not, she turns it off.

She does this quietly, without announcements, without press releases, without waiting for permission. She is the person who, while everyone else was still arguing about the tender, already shipped the prototype.

If you can imagine being that person, you can build what she builds.

Start Tuesday.