Phone bookings are written on paper. LINE changes are forwarded to staff. Email inquiries are copied into a spreadsheet at the end of the day. When you search for a better way, you quickly meet three options: no-code, low-code, and custom development.
“We want to move faster, but what if an off-the-shelf tool does not fit the way our team actually works?”
This guide is for business owners, store managers, and operations staff choosing the first step. It compares the options in plain language, without treating one route as always better than the others.
Why this choice is confusing
No-code sounds fast. Low-code sounds flexible. Custom development sounds tailored. Each can be useful, but each also asks you to make operating decisions.
The real question is not “Which tool is best?” The better first question is: which part of the workflow can fit an existing shape, and which part needs a dedicated conversation?
The short answer
Use this split before your first consultation:
- Try no-code when the fields are clear and a small team owns the workflow.
- Consider low-code when the workflow should fit your current Microsoft or Google environment.
- Discuss custom development when approvals, permissions, notifications, customer-facing screens, or integrations are difficult to fit into an existing tool.
- If unsure, test one workflow before deciding the long-term route.
- In every option, decide who can see data, who can change it, and how failures are noticed.
Plain-language definitions
No-code means building screens, fields, lists, and simple actions without writing program code. It is often useful when the current data is already structured.
Low-code means using ready-made parts plus some formulas, settings, or technical configuration. It can be useful when a business app should connect with existing workplace accounts and data.
Custom development means building a dedicated system around the workflow. It is useful when the business rules, customer-facing screens, or connections do not fit an existing product well.
These are not permanent boxes. A team can start with no-code, then add custom development later. A custom project can also begin with a no-code trial to clarify the workflow.
Common options to compare
Do not treat the options as a ranking. Pricing and plan details change, so this article does not list them. Check plans directly when the choice depends on licensing.
| Option | Good fit | Main benefit | Checks before choosing |
|---|---|---|---|
| No-code tools such as AppSheet | A spreadsheet-like workflow needs intake, a list, and basic staff review | Starts quickly from existing data or templates | Confirm whether permissions, customer screens, and later changes will still fit |
| Low-code tools such as Power Apps | The workflow should connect with Microsoft 365, SharePoint, Dataverse, or internal accounts | Fits workplace data and can support browser or mobile use | Confirm licensing, admin ownership, data location, and who maintains the app |
| Business app platforms such as kintone | Cases, inquiries, approvals, progress, comments, and team records need one shared place | Lists, notifications, permissions, change history, and workflows are available as platform features | Confirm whether the workflow can fit the platform shape and which external connections are needed |
| Custom development | Customer-facing screens, special booking rules, multiple integrations, or fine permissions are central | The system can be designed around the actual workflow and future expansion | Keep the first build focused on one workflow so the project does not become too broad |
What official sources confirm
AppSheet Help describes AppSheet as a no-code application development platform and explains that apps can start from an idea, existing data, or templates.
Microsoft Learn describes Power Apps as a suite of apps, services, connectors, and a data platform for building business apps connected to sources such as Dataverse, SharePoint, Microsoft 365, Dynamics 365, and SQL Server.
kintone’s official feature page describes business apps that can store and list data, support communication, manage progress, control permissions, send notifications, and keep change history.
Digital Agency guidance and the GOV.UK Service Manual support a broader point: understand the workflow, users, surrounding systems, and risky assumptions before committing to a build path.
Five decision points
First, ask how much the workflow can change. Existing tools work best when your team can accept their structure.
Second, decide who will maintain the workflow. A no-code app still needs an owner for fields, views, and permissions.
Third, separate internal screens from customer-facing screens. Existing admin views may be enough internally, but customer-facing booking or application screens often need more care.
Fourth, list future connections early. Email, LINE, calendars, accounting tools, and payment tools can change the right first step.
Fifth, write down personal information and access rules. Customer names, phone numbers, addresses, orders, and booking details should not be scattered without ownership.
How to start small
Choose one workflow before choosing the final tool. For example:
- Collect inquiries into one list and notify the responsible person.
- Make booking changes visible before confirmation.
- Gather application details and reduce missed follow-ups.
- Keep monthly review possible without building every reporting feature.
Then look for what can fit an existing platform. If the workflow becomes distorted just to fit the tool, discuss a small custom prototype.
Common selection mistakes
Do not assume no-code has no maintenance. Someone still owns fields, views, notifications, and permissions.
Do not assume custom development should include everything at once. Start with the daily workflow that causes the most repeated work.
Do not try to automate every old step exactly as it is. Decide which paper, phone, LINE, email, or spreadsheet steps should remain and which should disappear.
Do not postpone security thinking if customer information is involved. The first version can be small, but access and responsibility should be clear.
Pre-consultation checklist
Copyable consultation note
Copy a development approach consultation note
Use this note to discuss whether the first step should be no-code, low-code, or custom development. Leave unknown items blank.
What we want to discuss: Current workflow: Example: phone booking -> paper note -> LINE confirmation with staff -> spreadsheet at closing time First workflow to improve: Example: collect requests in one list, notify the responsible person, and make status visible Tools we use now: Example: phone, LINE, email, paper forms, Google Sheets, Microsoft 365 What may fit an existing tool: Example: fields, lists, staff notes, monthly review What may need custom discussion: Example: booking confirmation rules, automatic staff assignment, external services, customer-facing screens People who use it: Example: two reception staff, four operations staff, one manager Who should be able to change settings: Example: the manager can change fields; operations staff can only view records Personal information handled: Example: name, phone number, address, booking details, order details Possible future connections: Example: LINE Official Account, Google Calendar, accounting software, email notifications Main concern: Example: starting with an existing tool and later discovering it does not fit, or making custom development too large Examples we can share: Example: paper form, current spreadsheet, LINE template, monthly review process
Your next step
Review five recent requests. For each one, write the entry channel, recording place, person who checks it, person who replies, and what you need to review later.
Then summarize the first consultation like this:
Further reading
- Google, Get started with AppSheet. Used to confirm AppSheet positioning and starting points. Publication or update date was not visible on the page. Accessed 2026-07-17.
- Microsoft, What is Power Apps?. Used to confirm Power Apps capabilities and data connections. Last updated 2025-11-18. Accessed 2026-07-17.
- Cybozu, Basic features | kintone. Used to confirm app, list, notification, permission, change history, and workflow features. Publication or update date was not visible on the page. Accessed 2026-07-17.
- Digital Agency, Digital Society Promotion Standard Guidelines. Used for the workflow-and-system planning perspective. Page last updated 2026-07-15. Accessed 2026-07-17.
- GOV.UK Service Manual, How the discovery phase works. Published 2016-08-04 / last updated 2021-06-21. Accessed 2026-07-17.
- GOV.UK Service Manual, How the alpha phase works. Published 2016-08-04 / last updated 2019-05-08. Accessed 2026-07-17.
- IPA, Information Security Guidelines for SMEs. Published 2016-11-15 / last updated 2026-07-03. Accessed 2026-07-17.