"Our order management Excel file has ballooned to over 20 sheets with convoluted formulas. Since the creator left, everyone is terrified to touch it. Yet our company's entire order workflow runs through this file." A manufacturing client brought us this problem. Management sheets, spreadsheets, and GAS (Google Apps Script) automations cultivated by frontline teams are undeniable assets up to a point. But once data volume and user headcount cross a threshold, they shift from productivity boosters into ticking time bombs that will halt operations if broken.
Even so, that doesn't mean you should develop a dedicated system for everything. Development demands substantial time and budget, followed by ongoing maintenance. Should you push current tools further, build with no-code, or invest in full development? Making the wrong call leads either to overinvestment or neglected risks waiting to explode. Establish clear criteria to identify where your company stands before commissioning work.
"Signs of reaching the limit" appear in symptoms, not costs
The timing to consider custom systems rarely presents itself as vague inconvenience; it shows up as tangible symptoms. If several of the following describe your situation, your current tools are nearing their limits.
First, individual dependency: only one specific person understands the file's overall architecture, stalling operations whenever they take leave. Second, breakdowns in concurrent editing: multiple users work in the same file, making overwrites and version conflicts daily occurrences. Third, manual transcription and duplicate entry: staff routinely copy and paste data by hand between tables. Fourth, late detection of errors: broken formulas are only discovered during end-of-month reporting. Finally, "fear of touching it": staff want to make improvements but hold back because nobody knows what downstream formulas will break.
These symptoms inevitably arise when data volume expands and user counts grow. Conversely, if a task is self-contained by one person, involves low volume, and runs infrequently, there is no need to force custom development. You can manage effectively with spreadsheets and GAS using techniques like those in Google Sheets Best Practices. Building custom systems without evident symptoms is overinvestment.
Custom development is not the only option
Moving beyond spreadsheets doesn't automatically mean developing custom software from scratch. Multiple tiers exist, each with different cost and risk profiles. The key is determining which level of intervention suits your symptoms.
| Option | Best suited for | Primary cost |
|---|---|---|
| Refining existing tools | Mild symptoms; main goal is removing individual dependency | Low (establishing operational rules) |
| No-code / low-code | Standard workflows/data tracking with relatively clear requirements | Medium (configuring settings and integrations) |
| Custom scratch development | Proprietary business logic drives competitive advantage and off-the-shelf tools cannot support it | High (development + ongoing maintenance) |
In recent years, no-code options that convert Excel or Google Sheets data directly into apps have become highly practical, offering an accessible middle ground before jumping into full scratch development. Specific approaches to converting operational Excel sheets into apps are covered in Client Essentials for Building Business Apps with AppSheet. However, no-code also has boundaries, including difficulty handling complex processing and constraints imposed by platform specifications. We explored this distinction in Is Low-Code Obsolete in the Age of AI Agents?. The dividing line for building custom versus adopting existing mechanisms is: "Is proprietary logic a source of competitive advantage, or is this standard administrative management?"
"Rebuilding everything from scratch" is usually the worst move
When organizations hit limits, they often fall into the mindset of "let's rebuild everything from the ground up." However, workflows used for years contain immense amounts of tacit operational rules invisible in file layouts. Attempting to lift and shift all of them into a new system blows up requirements, balloons budgets and timelines, and often leads to user backlash that "the old way was easier to use"—a failure pattern we have witnessed repeatedly.
A pragmatic approach is to treat symptoms incrementally, starting with the most painful one. If dependency is the issue, isolate centralized data management first. If duplicate entry is the problem, automate only that transcription. Preserving existing usability while resolving pain points aligns with the philosophy in Improving Legacy Business Systems Without "Rebuilding" Them. Proceeding "incrementally by impact" rather than "all at once" is the cardinal rule of successful systems implementation.
Three things to decide before commissioning development
Articulating the following three points internally before consulting external vendors will significantly improve the accuracy of proposals and quotes.
First is prioritizing the symptoms you want to resolve: define concrete targets like "we want to eliminate this duplicate entry first" rather than vague desires to "make things more convenient." Second is separating what to keep from what to change: what works well in your current process, and where are the pain points? Third is who will operate and maintain the system after launch. No system is complete upon deployment. Will you outsource maintenance and future enhancements, or handle them in-house? Many companies struggle after inheriting GAS or macros from predecessors; neglecting post-launch planning simply recreates the same dependency. Considerations for reviving inherited automations are detailed in Reviving Inherited GAS Automations Through Client Development.
Where to begin
Start by identifying three files or automations that would halt operations if broken, and verify whether anyone besides the creator understands how they work. If the answer is "no," that is your highest-priority target. Pinpointing the single most acute pain point before envisioning an elaborate system provides the foundation for protecting your investment.
Whether to stick with existing tools, build with no-code, or invest in custom development—the ideal approach depends on company scale, team structure, and task characteristics. We work with you from setting priorities to designing a phased implementation roadmap.
