Where Are the Limits of kintone Customization? What It Can Do, Where It Struggles, and What Comes Next

kintone is a business-improvement platform from Cybozu that lets people build work apps — deal tracking, daily reports, inquiry management — without any programming knowledge. Because it can be started for a few thousand yen a month, it has become a common entry point for digital transformation at small and medium-sized businesses. At the same time, as a company grows and its operations become more complex, many run into a wall where customization alone can no longer keep up. This article separates the areas where kintone's standard features remain strong from the areas where repeated customization struggles, and lays out the realistic options once you hit that limit.

Managing operations in Excel or spreadsheets has real limits — simultaneous editing by multiple people, version history, and access permissions all become difficult. Building a custom system from scratch through an outside vendor, on the other hand, requires a meaningful budget and lead time. Platforms like kintone filled the gap between these two options, offering relatively low cost and short setup time. For fairly standardized workflows such as deal tracking, daily reports, or simple approval flows, the complexity rarely justifies hiring a development company, so standard features and the app marketplace are often enough on their own.

The starting premise worth keeping in mind is that most internal operations at small and mid-sized companies can run at a high level of completeness using kintone's standard features alone. Unless there is a specific reason not to, trying the standard features and plugins first is the reasonable approach.

- Deal and progress management: listing status, owner, and due dates to prevent items from falling through the cracks
- Daily and weekly reports: input forms combined with list and aggregation features for routine reporting
- Simple approval workflows: requests and approvals with one to three approval steps
- Inquiry and complaint management: accumulating response history chronologically and sharing it across staff
- Asset and equipment ledgers: digitizing ledgers and improving searchability

It helps to think of kintone customization in four stages, defined by the skill required to implement them. This makes it easier to see where your organization currently stands. As you move through the stages, you gradually move beyond no-code territory and start needing engineering skill.

- Standard features: field settings, lookups between apps, automatic calculations, notification settings — everything achievable through the admin screen alone
- Plugins: adding official Cybozu or third-party plugins for things like report output or Gantt charts, extending functionality while staying no-code
- JavaScript/CSS customization: using kintone's customization API to change screen behavior and display. This is where real programming becomes necessary
- External integration development: connecting to other systems via the kintone REST API or integration services, which requires a team to handle design, development, and maintenance

No matter how much customization is layered on, there are areas that are structurally a poor fit and tend to hit limits. If any of the following becomes central to your operations, it is worth paying attention.

- Complex reports and bulk processing of large data volumes: kintone has certain limits on the number of records per app and API call volume, which can make it unsuited to large batch-processing jobs
- Multi-step, complex business logic: conditional branching and calculations that span multiple apps tend to become harder to maintain the more JavaScript customization is layered on
- Screens for external customers: kintone is fundamentally designed for internal use, so using it as a service screen for an unspecified number of end users comes with many constraints
- Tight integration with core systems: for use cases that exchange large volumes of data in real time with accounting, production management, or POS systems, integration complexity and cost tend to grow quickly

To judge which stage your company is in, it is better to rely on concrete indicators than on a general feeling. If several of the following apply, considering integration development or a scratch migration earlier — rather than extending the life of the system with more plugins — often ends up being the more cost-effective path.

- Are monthly record additions and updates exceeding tens of thousands?
- Do approval flows or calculation logic change frequently enough that customization costs recur each time?
- Do you need screens that customers or business partners outside the company will use directly?
- Is real-time integration with core systems (accounting, inventory, production management, etc.) becoming essential to operations?
- Do you have staff or a vendor who can maintain the customization on an ongoing basis?

When considering a migration, the starting point is organizing your actual business requirements and comparing the pros and cons of integration development versus scratch development. For how to choose a development approach, see Scratch Development vs. Package Solutions; for a sense of budget, see A Guide to System Development Cost. The overall process for ordering system development is covered in A Guide to Ordering System Development for Small and Mid-Sized Businesses.

kintone remains a strong option for improving internal operations at small and mid-sized businesses. Having limits is not a flaw in itself — it is simply a matter of scope, and standardized work such as deal tracking or daily reports can be fully handled with standard features alone. What matters is objectively assessing which stage your operations are currently in and considering integration development or scratch development once it becomes necessary. Having decision criteria for each stage, rather than layering on customization reactively, is what leads to long-term cost optimization.