How to choose a Kintone plugin — 5 axes that matter

Kintone has over 400 plugins in the ecosystem. "Which one should I pick?" is the question every buyer faces. Rather than listing plugins by category, this post gives you 5 decision axes to evaluate any plugin — the axes that separate a purchase you're happy with in 3 years from one you regret.

Common failure patterns

When plugin selections go wrong, it's usually one of three patterns:

Picking by feature comparison table alone

"Vendor A does X, Vendor B does Y" tables favor whichever product looks more capable on paper. The problem: features are additions that can be built later. Architecture and vendor continuity can't be changed after the fact. Choosing on features and regretting on operations is the most common failure mode.

Looking at introduction cost only

"$50/month, cheap" or "free for year 1" shows you entry cost, not 3- or 5-year cost. Per-user pricing plugins scale with your headcount. Flat-rate per-subdomain pricing doesn't. Without projecting long-term cost, you end up with "how did we get here?" in year 3.

Being sold instead of buying

"The sales rep was helpful, so we trust them." Common pattern in Japanese enterprise. But products picked via sales are usually priced and structured such that they can't be purchased without the sales conversation. That's a structural signal the product doesn't stand on its own.

The 5 axes

Here's the framework we use in the field:

Axis 1 — Architecture

The most important axis. Does configuration and operation live inside Kintone, or in an external vendor portal?

Native plugin type: Configuration entirely within Kintone's admin UI. No external portal login. User management uses Kintone's permission system. Minimal data boundary crossing.

External portal type: Requires logging into a separate site with names like "kintone___app.com" or "___customize.io" to configure. User accounts managed separately in the vendor system. Data transits vendor servers for processing.

Neither is universally better. For financial, healthcare, or public-sector environments with heavy procurement approval processes — or IP-restricted Kintone — native is dramatically lower friction. For small SMB with "we just want features" priorities, external portal is also viable.

Practical test: during trial, check "does configuration require logging into any site other than kintone.com?" If yes, it's external portal type.

Axis 2 — Vendor continuity

How confident can you be that the vendor exists in 5 or 10 years?

Checkpoints:

• Company size and funding: Public company > funded startup > bootstrapped > individual developer. Smaller isn't necessarily worse, but the continuity risk should be explicit in your decision.
• Operating years: 3+ years with growing customer base. Plugins at "6 months since launch" are for early adopters.
• Shutdown contract terms: If the vendor ceases operation, what happens to your plugin? Does the contract include source-code open-sourcing, self-hosting migration support, or notice period? Japanese enterprise procurement processes always ask this.

Axis 3 — Cost structure

Always project 3- and 5-year total cost.

Two main models:

Per-user pricing: Scales with headcount. Example: $10/user/month × 100 users = $1,000/month × 5 years = $60,000. Bad for growing organizations.

Flat-rate per-subdomain: Doesn't scale with user count. Example: $65/month flat × 5 years = $3,900. Predictable ceiling makes procurement approval easier.

Additional cost categories to check:

• Setup or onboarding fees
• Per-plugin add-on pricing
• Per-feature add-on pricing (e.g., CC/BCC only in top tier)
• Usage-based billing (data volume, API call count)
• Support fees (basic support free, priority support paid)

"Cheap monthly" products sometimes end up 3× when you add up the extras.

Axis 4 — Security and audit readiness

In financial, insurance, healthcare, and public-sector environments, check:

• Data residency: Does data sit on vendor servers, or only in Kintone? If vendor, which region (Japan domestic or overseas)?
• Encryption: TLS in transit and AES-256 at rest are baseline expectations.
• Authentication: OAuth 2.0 or basic-auth dependency? Products dependent on basic auth stop working after April 2026.
• IP-restricted environment support: Are whitelist domains and IP ranges documented? Does proxy use work?
• DPA (Data Processing Agreement): Included in Enterprise plans?
• SOC2, ISO 27001, or similar certifications: Large enterprise procurement may require these.

Axis 5 — Operational burden

After go-live, what daily work does the plugin create for IT admins and users?

• User add/remove effort: Does Kintone's user management cover it, or do you need to remember to also update the vendor portal? How does offboarding work?
• Incident response: When the vendor has an outage, what's your IT team's role?
• Update handling: Plugin updates require reconfiguration and user notification, or do they apply transparently?
• Support response time: How many hours until first response? Who responds — a technical person or a ticket-routing agent?

The actual selection process

When comparing plugins against these 5 axes, this sequence works well:

1. Articulate the requirement (what business problem are you solving?)
2. Shortlist to 3-5 candidates (features that satisfy the requirement)
3. Evaluate candidates on the 5 axes (architecture, continuity, cost, security, ops)
4. Run trial with 2-3 finalists (14 or 30-day free trial)
5. Test with real data and real users (not just a sales demo)
6. Pick one, contract, migrate in parallel operation

Rushing this process usually means regret in 2 months. Taking time usually means no regret in 3 years. That's a big gap.

Self-check questions

Run each plugin candidate through these:

• Does configuration happen entirely inside Kintone? (No external portal login required, ever?)
• Has the vendor been operating 3+ years?
• Are shutdown-commitment terms in the contract?
• Have you projected 5-year cost?
• Does the vendor provide procurement attachment materials (company profile, security docs)?
• During trial, did real users test with real data?
• Does first-line support have technical depth, or just triage?
• OAuth 2.0 support? (For mail plugins)
• Is offboarding a single-system operation?

A plugin that answers "yes" to all 9 isn't the type you choose on feature comparison and regret later.

Where kinplug fits

Disclosure: kinplug is designed to score well on all 5 axes as native plugin type. Architecture is Kintone-native, contractual shutdown commitment (open-source + migration support), subdomain-flat-rate pricing (¥9,800/mo), OAuth 2.0 native, subdomain-scoped authentication, engineer-level support.

kinplug isn't universal though. On feature depth, external-portal architectures that process on the server side will have advantages for specific use cases. AI-driven automation, gigabyte-scale data processing, complex multi-cloud orchestration — external portal types are genuinely stronger there. If your use case is "we need complex processing that really needs server-side execution," kinplug may not be the best fit.

On the other hand, if your priority is any of: "make daily operations smoother with a Kintone-native addition," "meet financial/healthcare/public-sector security requirements," or "minimize long-term operational burden" — kinplug is a strong candidate.

Related reading

• Why most Kintone plugins live outside Kintone
• Microsoft 365 basic auth shutdown — Kintone mail after April 2026
• Head-to-head comparison with other vendors

Selection consultations welcome at support@kinplug.com. If kinplug isn't the right fit for you, we'll tell you so plainly.