Why most Kintone plugins live outside Kintone

Looking at the Kintone plugin market, something's strange: most products called "Kintone plugins" don't actually configure inside Kintone. You have to log in to a separate vendor portal with names like "kintone___app.com" or "___customize.io" to set anything up. Why?

This isn't laziness from the vendors. It's structural. This post lays out the business-model reason vendors chose external portals — and what happens when you deliberately don't.

What's actually happening

Fact check first. Survey the Kintone plugin market broadly and you see three patterns:

Native plugin type

Uses Kintone's own plugin system, runs entirely inside Kintone, configuration happens in Kintone's admin UI. Classic examples include the Cybozu Developer Network's conditional formatting plugin. Usually built by independent developers or small vendors, with relatively simple scope.

External portal type (integration services)

A thin plugin gets installed in Kintone, but the actual processing and configuration happen on an external website. Users log into both Kintone and the vendor portal, and manage settings in both. the major external-portal services on the market — these follow this pattern. The majority of Kintone plugin market revenue comes from this category.

JavaScript type (custom-build)

Per-project JavaScript injected into Kintone. Usually delivered by SIers or consulting firms. More custom-development than product.

The revenue concentration is in category 2: external portal type. And many of the most recognized plugin brands in that category don't live inside Kintone.

Why external portals dominate

"Why don't vendors just build it inside Kintone?" The answer isn't technical. It's the business model.

Reason 1 — To make SaaS metrics work

An external portal lets the vendor:

• Per-user pricing. Separate from the Kintone license, the vendor manages its own user accounts. Per-user pricing, access control, feature gating — all implementable.
• Usage visibility. Who used what, how many times, which APIs they called, how much data they processed — all visible in the vendor's own dashboard. Without this, tiered plans and metered pricing are hard.
• Retention metrics. DAU, MAU, feature-level usage rates, upsell signals. The telemetry a SaaS business needs to measure its own health.
• Upsell funnel. Making users log into the vendor portal makes it natural to prompt "try the new features" / "upgrade to Professional" messaging inline.

A native-inside-Kintone architecture breaks all of these. The vendor genuinely cannot see what users are configuring or how much they're using the product. That kills the core SaaS measurement playbook.

Reason 2 — Avoid Kintone API rate limits

Kintone rate-limits APIs per subdomain. Heavy workloads (bulk operations, PDF generation, mail sending) routed through Kintone API affect every other app on the subdomain. External portal architectures do the heavy lifting on the vendor's servers, avoiding this constraint.

Reason 3 — Complex logic is easier on a real server

Kintone plugin JavaScript runs in a constrained environment (CORS, CSP, execution time limits). Complex PDF rendering, image processing, external API calls, long-running tasks — all hard inside Kintone. On a server you control, easy.

The cost of external-portal architecture

The vendor-side benefits are understandable. But the moment a vendor chooses that model, users pay real costs:

Duplicated admin surface

Users need to learn Kintone's admin UI and the vendor portal. User management, permission management, configuration changes — done in both systems. When an employee leaves, they need to be removed from both. Forgetting the second system means the ex-employee retains access to sensitive data on the vendor portal.

Duplicated authentication

Most external-portal plugins ask users to create a separate account. Kintone might have SAML SSO via Cybozu, but the vendor portal has its own auth. Password management gets fragmented. SSO consistency breaks.

Data boundary crossing

Some portion of your Kintone data flows to the vendor's servers for processing. Usually justified in terms of service as "for processing purposes." In financial, healthcare, and public-sector environments, data boundary flows must be documented for security audit. This slows procurement approval and makes evaluation committees uncomfortable.

Vendor dependency

If the vendor portal goes down, the plugin stops working. Kintone itself might be running fine, but your workflows break because the vendor's infrastructure had an outage. Your business continuity is now coupled to the vendor's operational reliability.

IP-restricted environments become difficult

Financial, insurance, healthcare, public-sector Kintone environments often have IP restrictions. Allowing communication to the vendor portal means whitelisting their IP ranges, which creates operational complexity when vendors change infrastructure (or during DR events).

So why do users still choose external portals?

The costs above are real. So why is the market still dominated by this model?

There weren't alternatives

From around 2015-2020, when the Kintone plugin market took shape, every major vendor was pursuing SaaS business models. Few vendors seriously pursued the native-plugin approach, so for a long time users had no option.

Feature comparison favors external portals

Server-side architecture can implement complex features more easily. In feature-comparison tables, external-portal products look more capable than native-plugin alternatives. When users compare on features first, they miss the architectural costs that emerge later.

The problems don't show up during evaluation

External portal logins, duplicated user management, data boundary crossings — these are problems that manifest after live operation, not during trial or procurement. At contract time, only the "new features" are visible. The costs come later.

What happens when you actually commit to native

kinplug's architecture is native plugin. Choosing this forces constraints on the vendor side:

• No per-user pricing → flat-rate by subdomain becomes the only viable model
• No direct usage metering → plans must be designed as "all you can use"
• No upsell funnel → sales-led growth must be abandoned
• No retention metrics → instead, judge health from renewal rates and support ticket content

In effect, you walk away from the standard SaaS playbook. Revenue structure changes, which changes how the company grows. Specifically: you end up with a "charge a lot of customers a little each" model. Unlike traditional user-scaled SaaS, subdomain-flat-rate pricing doesn't compound account value. But user-side friction is dramatically lower, so growth depends on churn rates and referrals.

We chose this deliberately because, as Kintone consultants since 2019, we saw too many clients paying the cost of external-portal plugins and regretting it. We believe this isn't a path other vendors can't take — it's one they can't take while preserving their revenue model.

How to evaluate plugins on architecture

Before comparing features, ask:

• Is configuration really entirely inside Kintone? (Are you ever asked to log into a separate vendor portal?)
• Does user management stay within Kintone's permission system? (Is a separate vendor account needed?)
• Does data transit through vendor servers? (If so, is the scope and reason documented?)
• What happens if the vendor shuts down? (Does the plugin keep working? Any contractual commitments to open-source or migration?)
• IP-restricted environment support? (Are the domains to whitelist documented?)

Asking these upfront surfaces architectural decisions that don't show on feature-comparison tables but will affect your operational burden later.

Bottom line

The external-portal dominance in Kintone plugins is a consequence of vendor business models, not technical necessity. For users, this architecture carries operational, security-audit, and vendor-dependency costs.

Choosing native plugin architecture changes the vendor's growth strategy and revenue ceiling. The fact that a vendor deliberately chose this path is the small structural shift currently visible in the Kintone plugin market.

More about kinplug at the plugin catalog or comparison page.