Designing Around Expensive Traffic Data

When I first envisioned RutaRoo, I thought I could make it so that the data would be super fresh and update every minute. But after seeing the price tag, I knew nobody would use it if it were updating every minute. It would over $300 a month at that rate!

Smarter Updates

I realized that really, most of us are interested in traffic data in a small portion of the day. After all I can't imagine too many people worrying about the traffic at 2am (where there probably wouldn't be traffic anyways).

Next, instead of updating really fast, I realized that traffic doesn't really change THAT much minute by minute. So instead I would default to hourly updates and give the option for any users who wanted to get high frequency updates.

Also for the regular commuters there wasn't a need to look up traffic on Saturdays and Sundays.

All this made sense on paper, and giving users as much control while allowing fine tuned cost controls seemed like a really good idea. But now we've just created two new problems.

UI Complexity

What if someone has weird night shift schedules? And needs to monitor traffic in two unconnected chunks of the day? What if they worked weekends and had middle of the week free? I had to come up with a whole bunch of new UI elements to let people freely choose the days of the week and hours that they were interested in.

It works, but it's still a lot to take in. So I made sure to hide it behind the "custom" button and default to a commuter schedule which I hope works for the vast majority of people.

Price Structure

But the bigger issue was that I couldn't figure out a right way to actually charge for RutaRoo. I originally was just going to charge for usage. After all, the more often someone monitors a route, the more expensive it was since it costs money for each lookup.

There's lots of businesses that have this type of cost structure. For most large companies that use computing resources in the cloud, they are billed exactly on their usage. The more you use, the more you pay. In fact with the rise of AI tools, this has become more and more the norm.

It honestly would've been so much easier for me because then the user's incentives would be totally aligned with RutaRoo's. Since we would both feel the "cost" of wasteful usage, the user would be motivated to go through some clunky menus to set it up and fine tune it the way they wanted.

Nobody Likes the Taxi Meter

After some thinking, I realized despite the explosion of AI use by everyday users, not a single one of them charges by usage. They all had settled on the $20/month plan. No matter how much we use a tool, the big AI companies charged us the same flat rate.

If they did charge by usage, we would automatically start using it less and thinking about how to ration our usage. Instead, they want us to use the product more and discover new uses, and not have the ticking meter looming over our heads.

To prevent people from going way over board and abusing the "buffet", companies have started to work in creative limits.

For example, all AI agents now have a rolling window of usage. If you use too much, they can degrade the service or prevent you from using it for a while.

Adapting Pricing for RutaRoo

The problem with RutaRoo however is that none of the cost controlling ideas work since people aren't actively using the app the same way. All of the "usage" comes from us passively updating your routes for you in the background. The concept of rolling windows or degraded performance just doesn't translate.

I had to spend several days thinking about this problem. I'm just a lowly programmer, not a suit! I eventually plagiarized took inspiration from a totally different industry.

The Security Camera Model

I honestly have no idea how I came across this. But it turned out to have so many similarities to RutaRoo. First, you had configurable number of "units". Someone with two cameras would generate footage (cost) at double the rate of those with just one.

Two, there were levers that would drastically change the price of the footage stored. Footage at 4k is four times as large as 1080p. Storing footage 24/7 also would obviously cost more than just storing those with movement detected.

The way they solved it was to charge a base subscription that allows for a few cameras and additional cameras would be an extra, with high resolution costing more.

Copy and Paste

I honestly thought this was the best balance of not having to do a taxi meter while also allowing for enough wiggle room so a user who wanted to keep track of 8 routes didn't just bankrupt me.

But I also spent so long thinking things over that it gave me a headache. I figured I would start with how it is and let people give me feedback. If you have a suggestion please feel free to reach out!