Here’s a small client story with a lesson I keep relearning: the most valuable line in a scope document is the one that says what we’re not building.
NOVOSIC — a UAE medical equipment supplier we’d already built the export-desk site for — came back with a warehouse problem. Their products carry GS1-128 barcodes: the compound codes that pack several pieces of information into a single scan. One string, several facts:
Zoho Inventory’s native scanner reads these barcodes fine — but it reads them as one opaque string. It doesn’t know that (01) starts a product identifier, (10) starts a batch number, and (17) starts an expiry date. For a medical supplier, that’s not pedantry: batch traceability and expiry tracking are the difference between an audit that takes an hour and one that takes a week.
The build
A focused Zoho Creator workflow that takes the scanned GS1-128 string, walks the application identifiers, and writes each element into its own clean field — product identifier, batch number, expiry date — ready for use everywhere else in their existing Zoho environment. Scan once in the warehouse; three structured fields appear in the system.
That’s it. That’s the whole project.
The part I’m actually proud of
It would have been easy — and honestly, more billable — to propose more. A custom scanning app. A new inventory module. A dashboard. Clients rarely push back on scope, because they can’t always see where the platform ends and the genuine gap begins.
Zoho already does scanning, inventory, batch management, and everything downstream. Rebuilding any of that in Creator would have meant NOVOSIC paying twice: once to build it, then forever to maintain a custom copy of features their subscription already includes — a copy that breaks every time Zoho updates and theirs doesn’t.
So we scoped the solution to the one place that genuinely needed custom logic, and nothing else. The client’s system stays lean. The custom surface area — the part that can break, the part only we understand, the part that needs maintaining — is one workflow, not one platform.
My rule of thumb after enough of these projects: when a client asks for custom development, the first deliverable is finding out how little of it they need. The cheapest, most reliable code is the code you never write — and the trust you earn by not overselling a build is what brings the client back with the next real problem.
(It’s how this engagement happened, too — the site project came first, the barcode problem followed. Solve one thing properly and the next one finds you.)
Got a “the platform almost does it” gap in your Zoho setup — or anywhere else? That’s Forzateks’ favorite kind of problem. Talk to me.