QIAOPANG.COM · SELECTED ESSAYS (2013–2026) · 260 ESSAYSBrowse Chronologically (2013 → 2026) ↗
QiaoPang · Programmers LifeSelected Essays · Systems, Craft & Agentic Era
Timeline ↗

Pay As You Go: When Programmers Set Their Sights on Car Insurance

Pay As You Go: When Programmers Set Their Sights on Car Insurance

Car insurance may be one of the most irrational products in the world. If you take the bus to work every day, only drive out occasionally on weekends, log fewer than two hundred kilometers a week, and get behind the wheel only a few dozen times a year, you still have to pay almost exactly the same premium as someone who drives every single day and racks up tens of thousands of kilometers annually. This is deeply unreasonable — under any sane risk assessment, if other factors hold roughly constant (driving skill, say), you are a very low-risk customer: the fewer miles you drive and the fewer trips you take, the lower your odds of an accident. So your premium should be lower.

Is it possible to tie premiums to miles driven, so that customers who drive less benefit?

A good idea. The trouble is that it’s hard to operationalize — it means the insurer has to precisely monitor each user’s driving behavior. Without a way to capture a user’s mileage every day and every month, pay-per-mile premiums are a nonstarter. That’s why traditional insurers rarely price premiums by mileage, and when they do, it’s crude: have the customer estimate a usage band, then require them to upload a maintenance report at every service visit to recover the actual mileage from the past few months.

The inability to measure precisely is what keeps premiums from being tied to mileage.

Another reason traditional insurers are reluctant to link premiums to mileage is that it would hurt their revenue. By the insurance industry’s usual definition, the customer who drives sparingly is a golden customer — they pay high premiums, use little, complain less, and stay loyal. (Does that sound like the ideal partner, the programmer — earns a lot, spends little, good-tempered too?) Customers who drive constantly threaten to switch insurers at every renewal to extract the most favorable terms and rates; customers who rarely drive can’t be bothered to shop around at renewal — whatever you say goes.

Let me digress for a moment. For highly loyal customers, the standard practice in the insurance business (and some other businesses too) is: skin as much as you can without causing a significant dip in loyalty. So they hand out extra discounts, deals, and gifts to other customers, while the loyal ones get nothing — in fact, they pay more.

So pay as you go cannot come from the traditional insurance industry revolutionizing itself. They lack both the stomach and the capability.

Fortunately, this world has programmers — a tribe that keeps challenging the unreasonable old order. They’re willing to think, to turn one “why not?” after another into possibilities.

How do you precisely measure a user’s mileage? We know cars have an OBD system (OnBoard Diagnostics). So could we read information from the car’s OBD system to achieve this?

Yes. Devices that read OBD data and send it to a phone have existed for a long time; it’s nothing new, so the approach works. Give each user a free device, pair it with their phone over Bluetooth, and send data over the phone’s network — problem solved, seemingly.

But what if the user has no smartphone (unlikely these days)? What if they can’t install the app? What if they uninstall it? What if their phone’s OS gets hacked (corrupting the data)? What if they can’t manage the Bluetooth pairing? What if their phone dies? What if they switch phones? What if the phone is lost or broken? What if a family member or friend drives the car?

If you want to transmit mileage data safely, reliably, and in real time, this is not the best solution.

Then how about providing a device that reads OBD data and transmits it directly over its own cellular connection?

Compared with the previous approach, this dissolves all the problems above. We still have to think about hardware reliability and transmission security, but the earlier approach had those concerns too. Of course, there’s no free lunch: the new approach adds hardware cost (at minimum a 4G LTE chip) and operating cost (a monthly carrier data fee). But if this can be built into a business, those added costs can be amortized into each customer’s monthly premium.

That clears the technical obstacle to tying premiums to mileage. So how do we do risk assessment for customers? After all, premiums can’t hinge on mileage alone; other factors matter too. Traditional auto insurers collect this information to set prices:

  • Whether the customer is a good driver: judged from age, how long they’ve held a license, claim history over the past three years, occupation, and so on.
  • Whether the parking environment is safe: judged from crime and accident rates in the areas where they live and work, and whether the residence has a garage or private parking.
  • Whether the main commuting route is safe: judged from accident rates in the areas where the user primarily drives.

Let’s start with how to tell whether someone is a good driver. Claim history over the past three years is important and precise information — after all, insurance risk assessment predicts the future from the past. But age, time since licensure, occupation — these are fuzzy, merely statistical parameters that don’t attach directly to the individual. As a group, programmers tend to be easygoing and to drive well; they’re good drivers. But taken individually, there are programmers with road rage or a habit of driving while exhausted; they are not good drivers. Only by capturing a customer’s actual driving habits can we precisely measure how close they come to being a good driver.

In an era when machine learning can infer your gender, age bracket, and preferences from your browsing habits, precisely judging whether a customer is a good driver is no mission impossible. We just need the relevant data, and some model will get us very good results.

Veteran drivers tell us: smooth starts, gentle acceleration, few lane changes, steady speed, matching the flow of traffic, keeping enough distance from the car ahead — these are the marks of a good driver. So how do we capture them?

The answer is OBD + GPS. OBD gives us a lot of real-time data — speed, fuel consumption, engine RPM, brake status, and more. Combined with the continuous coordinates from GPS, we should be able to build a model that analyzes how well the person currently driving is driving. With enough accumulated data, we can even tell which driver is currently behind the wheel, based on differences in behavioral habits (a household usually has several drivers, who become the registered drivers on the policy).

Moreover, with OBD + GPS plus precise map services (Mapbox, say), we can accurately determine the user’s parking environment, their main commuting route, and the property type where they park (residential? office building? hotel? hospital? mall? and so on). Combined with other data (crime rates for an area, accident rates for a stretch of road), we can build a complete, continuously updated model of each driver’s risk state.

And that’s just the data from a single car. With enough users, forming a network like Waze (or partnering with a company like Waze), we could — beyond assessing individual driver risk — provide more precise, more real-time risk assessment for the roads themselves. After all, any single driver’s quality is only one link in the overall risk assessment; current road conditions and the driving habits of surrounding drivers are more important data — an accident up ahead, a sudden surge in traffic, speeds that keep surging and stalling all dramatically affect the risk of driving right now. If we can feed that analysis back to users and help them avoid high-risk roads, we can further reduce driving risk and thus lower their premiums.

So far, the pay-as-you-go model for car insurance seems quite feasible, both technically and commercially. But don’t forget: insurance is an industry still heavily shaped by policy. Governments lay down a whole set of regulations to keep the system running (though those rules aren’t always correct or in step with the times). Pay as you go, for instance, plainly conflicts with the requirement that a vehicle carry continuous insurance while registered. If I only drive two days a week and only pay for those two days, how do I guarantee continuity of coverage (to comply with policy)? And don’t forget, governments typically also mandate that certain basic coverage be included; that part, as things stand, can’t be fully pay as you go.

So we need a compromise: a base premium (fixed fee) + premium per mile driven × miles driven × risk factor. That way we comply with regulations while saving the customer money.

This is the business model Metromile adopted.

The San Francisco–headquartered company was founded in 2012, and after four years of grinding it began to shine this year; in September it raised $190 million in venture funding (including an investment from China’s CPIC). When a friend introduced me to the company a couple of days ago, I immediately signed up for its insurance and terminated the Farmers policy I’d had for two years. Previously I counted as a good driver, and my two cars together cost $179 a month in premiums. With Metromile, the base premium for both cars comes to $65, plus 3–4 cents per mile per car. At my current mileage, my premium lands under $100. That’s a very substantial saving — nearly half of what I was paying! What’s more, I dropped my deductible from $1,000 to $250. Were it not for a claim my wife filed in early 2015, my two cars could have come in under $90. And by our earlier analysis, if the insurer can keep learning and keep lowering customers’ driving risk, there’s enormous room for premiums to fall further.

Let’s do a simple projection. According to Wikipedia (https://en.wikipedia.org/wiki/Passenger_vehicles_in_the_United_States), there were 255 million private passenger vehicles in the US in 2013. By rough DMV counts, a traffic accident occurs every 60 seconds — over 5 million accidents a year. Suppose technology cuts the annual accident rate in half, to 2.5 million. Not every accident goes through insurance (filing a claim means higher premiums, so if the repair cost is near the deductible, customers usually don’t file). Assume 80% of accidents are claimed, at an average handling cost of $10,000 — that’s $20 billion a year in claims cost. Sell through internet channels and you eliminate the insurance broker, a middleman with little added value, saving a large chunk of personnel and sales cost. On that basis, if we set gross margin at 60%, we’d need $50 billion in annual revenue — meaning a premium of $17 per car per month could sustain a new kind of insurance company.

That price is far below any car insurer on the market! Even far below Metromile’s prices!

Yet even with a crushing technical advantage over traditional insurers, Metromile and its peers cannot instantly devour the traditional market. In the way stand laws and regulations that may well be obsolete. In the US alone, state laws differ wildly and must be cracked one by one — to say nothing of the global market. This is fundamentally different from other consumer products, the iPhone say. Which is why, in the Chinese market, local entrepreneurs still have plenty of opportunity in this space.

Metromile is dead simple to use: enter your name and address, and it automatically pulls your personal and vehicle information from the DMV; a few steps later, you’re enrolled:

Pay As You Go: When Programmers Set Their Sights on Car Insurance

Pay As You Go: When Programmers Set Their Sights on Car Insurance

Pay As You Go: When Programmers Set Their Sights on Car Insurance

After that you just cancel your previous car insurance. Metromile mails you the device that plugs into the OBD port — the Pulse. In the meantime, you pay only the base premium. Once the Pulse arrives and is installed, everything about every drive can be monitored on its website and app.

Finally, let me talk about my concerns with Metromile and its peers. Concerns only — they won’t change my behavior. I remain a Metromile loyalist.

The biggest concern is privacy. All your travel data ends up in a third party’s hands. Combined with detailed map information, they could even infer your intentions: when you go to work, when you visit the hospital, how often you work out each week, the home addresses of friends you meet often, the places you take the kids on weekends — all laid bare. If enough households in a region use such insurance, they could even tease out the relationships between people. The thought is terrifying.

This is a chronic ailment of the internet industry. Think about the ride-hailing app you use every day — it can easily learn your home and work addresses, know the areas you frequent, even your favorite restaurants, hotels, and shopping spots. Honestly, these apps may know you better than your family does — better, even, than you know yourself.

See, in A Chinese Odyssey, Bodhi says to Joker: in your delirium you called out for Jingjing ninety-eight times, and the name Zixia, you called seven hundred and eighty-four times. A muddled ledger even Joker himself couldn’t sort out — and Bodhi cracked it with “big data.”

MORE IN Systems & Architecture

Further Reading in This Column

View all essays in “Systems & Architecture” →

The Future of Logs: Rectifying Names

For a decade we built observability into a beautiful tower on a foundation of drifting strings—field names by convention, cardinality by luck, bills by endurance. This essay proposes a radical fix: use protobuf to give every observed event a proper name, unify logs, metrics, and audit into one versioned, owner-tagged, retention-aware event catalog, and keep an escape hatch called ForensicEvent for the unknown unknowns.

New Hope (2025–2026)10,772 chars · 24 min read

Abandoning Multi-Environment Entirely: Reshaping the Next-Generation Serverless Architecture with Rust and Pingora

When we return to first principles and reconsider what "compute" really is, we find that multi-environment setups are an illusion, Kubernetes is an over-abstraction, and Serverless cold starts and connection-pool storms are self-inflicted. This essay dissects an environment-less architecture built on Baggage Header routing, a Pingora smart gateway, Firecracker microVMs, and a Rust Data Bus — an attempt to answer: what should compute look like in the post-Kubernetes era?

New Hope (2025–2026)23,788 chars · 53 min read