LINE Mini App Cost Comparison — How to Choose Between SaaS, Half-Scratch, and Scratch Development

Hello. I am Kameda, in charge of business planning at the Retail App Co-Creation Department.

“I want to introduce a LINE Mini App, but I don’t know which method to choose.” Many people have this concern. There is a wide range of options, from SaaS costing a few thousand yen per month to full-scratch development costing millions of yen. You can compare them by lining up the price lists published by each company. However, there is almost no information that can answer the question, “Which method will be optimal for our company’s scale and requirements three years from now?”

In this article, I will compare four methods—SaaS (low-price range and mid-price range), half-scratch, and scratch—not only in terms of initial and monthly costs, but also from the perspectives of scalability, data ownership, and switching costs. I want to use “what we can achieve in three years” as the judgment criteria, rather than “what is cheap now.”

Conclusion first: The turning point for decision-making

Before reading the cost table, let’s organize the turning points for decision-making.

Cases where SaaS (low-price range) is suitable

• You have fewer than 10 stores and want to try it out first

• General functions such as coupon distribution and stamp cards are sufficient

• Real-time integration with proprietary CRM or POS is not required

• The budget limit is under several tens of thousands of yen per month

Cases where SaaS (mid-price range) is suitable

• Functional requirements are covered by the standard SaaS menu

• You want to postpone investment decisions for future expansion

• You need to keep initial costs within several hundred thousand yen

Cases where half-scratch is suitable

• You have 10 or more stores and want to centrally manage membership cards, reservations, and coupons

• Integration with existing systems such as Salesforce, Kintone, Smaregi, or Shopify is required

• You want to hold member data on your own AWS (there are security and personal information protection requirements)

• You plan to run a cycle of feature additions and modifications within three years

• You can secure a budget of several million yen or more

Cases where scratch development is suitable

• Complex, industry-specific logic is required that existing assets cannot handle

• Sufficient budget and a development period of 6 months or more can be secured

• The company can maintain its own engineering team

Comparison Table: Lining up the 4 methods using the same yardstick

A comparison only becomes meaningful when measured with the same yardstick. I have lined up the 4 methods along the following axes.

→ Consult about the best development method for your company

SaaS Price Ranges (Based on public information)

For reference, here are the price ranges for typical SaaS for LINE Mini Apps.

• L Message: Free plan available to several tens of thousands of yen/month

• EDWARD: Initial cost from several tens of thousands of yen, monthly fee from several thousand yen

• Kit-Curu: Initial cost from several hundred thousand yen, monthly fee from several tens of thousands of yen

Price example for Half-Scratch (Growth Pack for LINE)

Growth Pack for LINE is a service that provides base assets for LINE Mini App features such as membership cards, reservations, and coupons, offered through half-scratch development. Initial costs start from several million yen (varies depending on feature configuration). The estimated implementation period is from about 2 months. Please contact us individually for details.

Scratch Price Range

When performing everything from requirements definition to design, development, testing, and release from scratch, the market price is in the range of several million to several tens of millions of yen, with a duration of 6 to 12 months. Maintenance and operation costs are charged separately.

Thinking in terms of 3-year TCO: Cases where 'cheap now' reverses in 3 years

If you make decisions based solely on initial costs, you may end up paying high costs later. Let's compare the total cost of ownership (TCO) over 3 years, including SaaS 'switching costs' and 'opportunity losses'.

Case A: Continuing with SaaS

The 3-year total of initial costs of several tens of thousands of yen plus monthly fees stays in the range of several million yen. At first glance, it is cheap. However, the following costs are not included, are they?

• Migration costs when switching: When migrating member data managed by a SaaS vendor, costs can range from hundreds of thousands to millions of yen due to data format conversion, cleansing, and importing into the new system.

• Opportunity loss due to lack of scalability: The cost of being unable to meet requirements such as "I want real-time integration with POS" or "I want to automate segmented messaging" because the SaaS specifications do not support them.

• Risks of not owning your data: Even if you try to extract data for analysis or CRM integration, you are bound by the vendor's terms and API restrictions.

Case B: Half-Scratch Development

The total 3-year cost, combining initial expenses and monthly maintenance fees, will be higher than SaaS in absolute terms. However,

• Feature additions can be handled by combining assets (lower cost compared to scratch development).

• Data can be kept in your own AWS environment (no migration costs incurred).

• POS and CRM integrations can be added gradually later on.

When you decide after three years that you "really want POS integration," it is not uncommon for the cost of switching from a SaaS to be higher than the cost of having built it as a half-scratch solution from the beginning.

Scalability and Customization: Where SaaS Hits Its Limits

The biggest trade-off with SaaS is that the available features are predetermined from the start. Adding or changing features depends on the vendor's roadmap, and you end up using the same UI as your competitors.

On the other hand, half-scratch development follows a structure of "assets (standard features) + customization area." You can reduce development man-hours using assets while using customization to handle brand-specific UI, business workflows, and external system integrations.

The following systems have been confirmed as integration track records for Growth Pack for LINE.

• CRM integration

• Business system integration

• POS integration

• EC integration

It is important that these integrations are provided as "optional development" rather than "standard equipment." You do not need to build everything from the start; you can expand in stages, such as introducing only membership cards in Phase 1 and adding POS integration in Phase 2.

Data Ownership and Security

When using SaaS, member data is stored in the vendor's cloud environment. Because you can only access data within the scope of the APIs and export functions provided by the vendor, there are limitations on deep integration with your own analysis infrastructure or CRM.

Growth Pack for LINE uses a configuration where data is held in your own AWS environment. The following non-functional requirements are defined.

For companies with strict requirements for handling personal information, such as major retailers, drugstore chains, and financial groups, the fact that 'data is in your own AWS' is often a key factor in obtaining approval for implementation.

Case study of switching from SaaS: Gooday

Gooday Co., Ltd. (a home center chain with 63 stores, mainly in Kyushu) is a company that replaced a LINE Mini App built with a combination of SaaS with Growth Pack for LINE.

Regarding the challenges before implementation, Gooday stated the following:

Gooday lists the following three points as priorities for system reconstruction:

1. To own the data that was previously held on the SaaS side

2. A system where data can be extracted and freely processed

3. Ensuring the continuity of existing functions

Results after the replacement (Source: https://classmethod.jp/cases/gooday/).

• Membership card presentation rate: Increased by more than 5 times per month

• Operational stability has improved. The errors and bugs that were a concern have disappeared.

• They are quick to propose solutions to problems, and modifications were carried out immediately.

The Gooday case shows that the limitations of SaaS often become apparent in terms of 'data ownership' and 'system complexity' before they do in terms of 'cost'.

→ Download the detailed case study document

4 timings when the limitations of SaaS become apparent

It is not that every company should start away from SaaS. However, it is certain that many companies face the limitations of SaaS at the following four timings.

1. When the number of stores exceeds 100
Operational requirements that cannot be handled by SaaS management screens, such as setting management for each store, segregation of duties, and sales promotion settings by area, are likely to emerge.

2. When real-time integration with POS or CRM becomes necessary
Requirements such as "I want to reflect points immediately at the time of payment" or "I want to sync member purchase history to Salesforce" are often not supported by many SaaS providers, or their specifications are fixed.

3. When you want to fully commit to in-house data analysis
SaaS export functions are constrained by the formats, fields, and frequency defined by the vendor. If you want to utilize BI integration or machine learning for segment analysis, a configuration that allows you to own the data in real-time is a prerequisite.

4. When security and compliance requirements become stricter
This occurs when you encounter audits that cannot be passed in a vendor-managed cloud environment, such as group company security reviews, compliance with ISO 27001, or responses to amendments in the Personal Information Protection Act.

Decision Checklist

When choosing SaaS (Appropriate if you meet all 5 conditions)

▢ You have 10 or fewer stores, or want to start on a small scale
▢ Integration with external systems (POS, CRM, EC) is currently unnecessary
▢ You have little concern for brand-specific UI design
▢ You have no issues with entrusting the ownership and management of member data to a vendor
▢ Your business is viable with monthly operating costs of within several tens of thousands of yen

When choosing Half-Scratch (Worth considering if 2 or more of the following apply)

▢ You have 10 or more stores, or plan to expand in the future
▢ You want to integrate the LINE Mini App with systems like Salesforce, Kintone, Smaregi, or Shopify
▢ You want to hold member data in your own environment and utilize it for analysis
▢ There are business workflows or UI requirements that existing SaaS cannot handle
▢ You need to pass security and compliance audits
▢ You can secure an initial budget of several million yen or more

Summary

When considering the cost of a LINE Mini App, I believe it is important to work backward from "what you want to achieve in 3 years" rather than "how much it costs now."

SaaS excels in initial speed and low cost. However, the moment even one of the three requirements—data ownership, external integration, or scalability—arises, it often falls out of consideration.

Half-scratch is a third option that secures the scalability, integration, and data sovereignty that SaaS cannot achieve, while keeping initial costs lower than scratch development. As the Gooday case shows, rather than "trying SaaS first and switching after feeling its limitations," choosing half-scratch at the stage when requirements are clear often saves total cost and time.

When in doubt, start by specifically articulating "what you want to achieve with this system in 3 years." The answer to that question should be the most reliable guide for choosing your approach.

Next Step: Narrowing Down the Implementation Method

Selecting an implementation method that considers 3-year TCO and scalability is a decision that is difficult to change once made. I would like you to re-evaluate and compare methods from the perspective of "how much you can pay for future system operation and growth" rather than "what is cheap now."

First, please check the product overview to see what kind of functions and integrations Growth Pack for LINE is implemented with.

Growth Pack for LINE Product Site
Learn about Growth Pack for LINE

Next, I recommend reading three white papers on industry-specific case studies implemented with half-scratch. You will be able to see why companies that faced the limitations of SaaS chose half-scratch and what functions they added incrementally after implementation.

Half-Scratch Implementation Case Studies (by Industry)

• How to centrally manage member initiatives for apparel chains

• Designing the next step for department store customer experiences

• Systems to streamline store operations for grocery supermarkets

Once you have narrowed down your implementation method, we will provide a customized quote based on your company's requirements. Please feel free to contact us from the link below.

Individual Quote & Implementation Consultation
Request a quote tailored to your company's requirements

Well then, see you later!

The cost data in this article is sourced from the following:

• L Message Pricing Plans: https://lmessage.jp/ (Public information)

• Kit-Curu Pricing Plans: (Public information)

• Growth Pack for LINE Budget Estimates by Feature: Classmethod Official Information (As of April 2026)

• Gooday Implementation Case Study: https://classmethod.jp/cases/gooday/