It Started with My Own Design Mistake

Recently, I wrote about a fundamental design error in my LINE Messaging API cost forecasting logic, where actual costs ended up being over 9 times higher than predicted.

/en/tech/line-cost-forecast-design-mistake

/en/tech/line-cost-forecast-validation

The cause was simple: I was forecasting "cost" on a daily basis. Since LINE Messaging API uses tiered pricing, extending the amount through daily calculations breaks the numbers. The correct approach is to forecast "message volume" first, then pass it through the pricing function. It's just that simple, but surprisingly easy to miss.

I validated the corrected logic manually and confirmed it was working correctly.

That's when I thought:

"There might be others struggling with the same thing."

Tiered Pricing Calculations Are Tedious by Hand

LINE Messaging API's pricing structure is simple: a free tier, with tiered pricing for overage.

However, calculating "how much will it cost by month-end at this pace?" manually is genuinely tedious:

I did this calculation repeatedly myself and initially got the logic wrong. If there were a tool to automate this calculation, it could help others facing the same problem. That was the trigger.

Just hoping it might be useful to someone.

Starting with "Build and Release"

When deciding to build this tool, the first thing I established was the stance:

This isn't a passive attitude—it's an active constraint: design with the premise of releasing it.

"Don't maintain" sharpens the design. Minimal inputs, simple logic, no state, no dependencies. The result is a structure that remains robust over time.

Conversely, adding "future features" inflates maintenance costs and eventually becomes technical debt. I didn't want that this time.

Technology Choice: Why Lovable

I used Lovable for this project. The reasoning is simple.

The requirements for this tool perfectly aligned with Lovable's strengths.

Requirements:
├── Single-screen completion
├── No login required
├── No state persistence
├── Form input → Immediate results
├── No API integration
└── No data storage

Honestly, I got stuck here—just kidding, there was barely any room for deliberation in technology selection. Simple inputs, clear outputs, no state. With these conditions met, there's no reason to write from scratch.

If you want to build compact applications quickly, there's hardly a better tool currently available. Depending on usage, you can also fine-tune UI details and logic implementation, so it supports both "just get something working" and "polish it properly."

What Mattered Most in Design

The design approach for the calculation logic came directly from my own mistake:

❌ Don't do this:
   Forecast "cost" on a daily basis

✅ Correct approach:
   1. Forecast message volume
   2. Pass forecasted volume into pricing function

graph LR
    A[Current cumulative messages] --> B[Calculate daily average]
    B --> C[Forecast month-end messages]
    C --> D[Calculate cost via tiered pricing table]
    D --> E[Display forecasted cost]

The key is to separate the pricing calculation as a function. If the pricing structure changes in the future, you only need to replace the function's internals. Tightly coupling forecast logic with cost calculation recreates exactly the mistake I made initially.

The "Order" I Focused on in UI

I limited input fields to just three:

  1. Target month (e.g., February 2026)
  2. Current day (e.g., day 5)
  3. Cumulative messages to date (e.g., around 30,000)

This order is meaningful. "When is this?" → "How far into the month are we?" → "How many sent?" Matching the user's thought process with the input order. Subtle, but misalignment here creates "hard to use."

Result display also follows an order:

  1. Month-end forecasted cost (the number people want most, first)
  2. Free tier status (reassurance or warning)
  3. Calculation breakdown (elapsed days, daily average, forecasted month-end volume)

Showing the breakdown isn't for explanation—it's to leave room for verification. Engineers can glance at it and know "nothing weird is happening." Trust comes from logic transparency.

Positioning as "Unofficial"

This tool is not official LINE. It doesn't guarantee accuracy. The final billing amount should be checked in LINE's official dashboard.

This isn't a disclaimer—it's positioning design.

Official information is naturally accurate, and the dashboard provides solid confirmation. This tool does something different: a quick helper tool to grasp "roughly how much at this pace." Nothing more.

Just three notes:

Monetization Decision: Don't Sell, But Leave Recovery Pathways

Free release was the premise, but not placing any recovery pathways at all felt unnatural.

I placed just two:

1. Affiliate links for LINE Messaging API-related books (up to 2)

This doesn't contradict the tool's philosophy. Since the tool's essence is "understanding how to think," books that deepen thinking are natural as reference information. I limited the number and kept it within the scope of appearing as an extension of reference material.

2. Tips (¥300 / ¥500 / ¥1,000)

After results display, before the footer. Small.

If this tool helped even a little, I'd appreciate a coffee's worth of support ☕

Both are positioned not to push sales. Just for those who notice, with that level of distance.

Multilingual Support Decision

I hesitated on multilingual support.

LINE Messaging API is widely used not only in Japan but also in Taiwan, Thailand, Indonesia, etc. Should I support multiple languages?

The conclusion: I added only English. Not for English-speaking regions, but as a common language for non-Japanese developers. Developers in Taiwan or Thailand can often read English UI.

However, I didn't do full translation. Just input labels, result cards, and notes. Minimal English support for maximum reach.

Traditional Chinese or Thai can wait until access analytics show demand. If demand doesn't appear, I won't do it. I won't add work that contradicts the "build and release" policy.

For those reading this far and thinking "I'm doing the same calculation repeatedly," here's the simple pricing simulator I built.

What I Built

🔗 LINE Cost Simulator (Unofficial)

graph TB
    A[Blog Article] -->|Problem Statement| B[Simulator]
    B -->|Reference Info| C[Official Books]
    B -->|Optional| D[Tips]
    A -.->|Only Readers| B
    style B fill:#f0f4ff,stroke:#4a6fa5

The flow is simple. Blog readers who think "calculation is tedious" have the tool. Tool users who want "deeper understanding" have books. There's no "sell" anywhere.

Reflection: Why "Releasing" Is Hard

Honestly, while building, "I want to add this" came up many times. Add graphs, save history, create an API.

But those are all "maintenance" direction ideas. Maintaining creates maintenance. Maintenance makes it impossible to abandon. Inability to abandon turns assets into liabilities.

The most important decision in this design wasn't "what to build" but "what not to build":

The more you cut, the less it breaks. What doesn't break lasts long. What lasts long occasionally helps someone.

This tool was born from my own experience struggling, so I'd be happy if it reaches someone stuck in a similar place. If using it gives you that "ah, this is enough" feeling that settles in your gut, it was worth making.

Reference: Learning About LINE API

If you want to deeply understand LINE Messaging API pricing structure and specifications, practical guides like the following can be helpful.

[📦 商品リンク: moshimo-card-TUBHo]

By cross-referencing actual implementation with official documentation, you can accurately understand detailed specifications like the pricing calculations in this case.