Zoho is a large platform with a lot of dials, and that is mostly good news: there is usually more than one way to build what you need. It also means the shape of a project is decided early, by a handful of choices that are easy to make well at the start and expensive to revisit later. These are the eight we work through in every discovery.
1. Size your API usage
Each plan comes with a daily allowance of API calls. For a standard rollout you will never come near it. For a high-volume integration or a two-way sync running every few minutes, it is worth doing the arithmetic. Estimate the steady state rather than the pilot, batch where batching is natural, and pick the plan that fits the volume you will actually run.
2. Match the plan to the requirement
Zoho's tiers differ by capability as well as price, and some modules and user types live further up the range. This is straightforward to handle when it is checked in week one and awkward when it surfaces in week six. We confirm tier-dependent features against the licence you hold before anything is scoped, so the plan is a decision rather than a surprise.
3. Plan for document volume
If your process attaches scanned documents, drawings or photographs to records, storage becomes an architectural question rather than an administrative one. Work out roughly what you will accumulate over three years, and decide up front where long-term documents should live. An archival approach designed in at the start costs almost nothing; one retrofitted later is a project of its own.
4. Design the automation, do not accumulate it
Workflows, scheduled functions and blueprints are easy to add one at a time, which is exactly how systems end up with forty rules nobody fully understands. Consolidating several narrow rules into one well-built process is usually cheaper to run, far easier to maintain, and keeps you comfortably inside what your plan allows. Good automation design is mostly restraint.
5. Know who supports each extension
Marketplace extensions can save real build time. Before one becomes load-bearing in your architecture, settle three questions: who supports it, what it costs at your volume, and what your process does if it stops being maintained. Often the answer is to use it. Sometimes it is to build the piece yourself so you own it.
6. Model permissions early
Roles, profiles and visibility rules are among the hardest things to change once real data and real habits exist. Organisations with layered approvals or separated visibility between teams should map that structure during discovery, not after go-live. Getting it right first time is quick; unpicking it later touches everything.
7. Pace high-volume operations
Bulk imports, migrations and chatty integrations can move faster than a platform wants to accept, and the resulting failures look like bugs without being bugs. Retry logic, queuing and deliberate pacing are part of building an integration properly rather than optional extras, and they cost very little when they are designed in from the start.
8. Confirm region and residency
If you operate across borders, or your sector requires data to stay inside one, confirm feature availability and data residency before implementation begins. This shapes architecture, and that is fine as long as it is known early. We have delivered on-premise Zoho Creator, including for a Government of India engagement, precisely because the residency answer came first.
How we work through it
All eight are covered during discovery and written into the feasibility document you receive before any build begins, alongside a recommended plan and a design that fits it. That is the point of starting discovery while you are still deciding: these choices are knowable up front, and knowing them is what makes a timeline worth quoting.
Scoping something now and want a second opinion on any of these? Describe it and we will come back within a working day.