Table of Contents
Do not index
Hide CTA
Hide cover
Every shared spreadsheet breaks down, eventually. It’s only a question of how badly. Someone will put the wrong data in a column, accidentally overwrite a formula, or clutter the sheet with quick something in blank columns. It could be fine. Or work could grind to a halt as small issues in the spreadsheet add up over time.
JPMorgan lost over $6 billion in 2012 largely from spreadsheet processes that relied on copying and pasting data, and a broken Excel formula. Similar disasters struck Fidelity (leaving a $1.3 billion loss) and the London Olympics (accidentally selling 10,000 phantom tickets), and could strike a critical spreadsheet in your business, too.
We’re humans, bound to make the occasional mistake. No software can fully prevent that. Yet spreadsheets, with their anything-goes flexibility, are particularly susceptible to human failings. They’re malleable to a fault because they put flexibility at the wrong layer. While most teams won’t accidentally vaporize billions, the same freedom spreadsheets give you to build a report or sort data into a pivot table also lets you enter the wrong data, move columns, and break formulas, accidentally or maliciously.
There’s an adage in software development that every shared spreadsheet is a startup idea. But that idea originated a decade ago, when building even reasonably simple software required a team of developers, months of development time, and often dedicated infrastructure for hosting.
Today, you can build a scalable app that codifies business workflows and systemizes operations, in minutes. It’s possible today, and likely better, to turn every shared internal spreadsheet from free-form cells into explicit workflows in a custom, in-house app.
A double-edged spreadsheet sword
“It’s not a coincidence that about 95% of the real work of business is done inside Excel,” says Alan Cooper, the programmer behind the original Visual Basic drag-and-drop software development environment. “[Excel is] powerful, flexible, and it allows its user to work fudgably, adaptably, in real time, while seeing most of what is happening right there on the screen.”
Spreadsheets are the first tool teams reach for when organizing and analyzing data. They’re also the tool people use to patch gaps in their software-backed workflows. When your eCommerce store or email platform doesn’t include the reports you need, spreadsheets, very often, are the easiest way to build them. They’re an escape valve when software limitations hinder your work, putting flexibility at the data-entry level.
Things tend to start out well. A single person can easily keep a spreadsheet tidy. Then you share the sheet, and the lack of structure and validation turns from an asset into a liability.
An eventual mistake will push you to look for software to handle the task, only to find that it, too, misses a critical feature you need, or buries it under layers of bloat after fulfilling every customer’s feature requests. Quickly enough, someone will patch workflow holes with an ad hoc spreadsheet, and the cycle restarts.
Why shared spreadsheets break down
Spreadsheets let you put anything in any cell, without validating data. They let you reorder anything and move any row or column around. They let you leave stuff out, or add it without notifying anyone else. And they let anyone save a copy of the file, share it via email, or import it into any other spreadsheet app.
Each is a boon in the moment. Over time, that flexibility becomes a liability, as business practices break down with missing critical data and data security risks pile up as various copies of the spreadsheet take on a life of their own.
Thus the idea, as Patrick McKenzie originally worded it, that “every spreadsheet shared in a business is an angel announcing another SaaS app still needs to be built.”
Developers answered the call, codifying the most popular HR, project management, accounting, inventory management, CRM, and other spreadsheet systems into apps. Yet they each break down when the software isn’t flexible enough to cover a company’s unique use cases, when they’re too complicated for everyone on the team to start using, and when edge cases start piling up and being solved ad hoc with data exports and spreadsheets.
I’ve lived through the cycle, planning work first in Google Sheets, migrating to Trello when we outgrew the spreadsheet and needed more structure, then building a custom Airtable database to track every data point about the tasks. Each step required a bit more setup time and onboarding, for a system that more closely fit our needs—but still never exactly solved all of the problems.
Today, the better option would be to custom build an app for our team’s needs from the start.
The case for homemade, single-team software
For the majority of computing history, the choice was binary: Simple, fragile spreadsheets, or constricting software built around someone else’s workflows. Building custom software was reserved for the largest of software firms.
That’s changing. Today, you have a third option: AI-powered tools, like Zite, that create custom business applications for you, complete with databases, forms, automations, reports, authentication, and hosting. They translate your business requirements into databases with automated workflows and interfaces built around the way your team works.
The first wave of AI developer tools were either technical-focused software like Cursor and Claude Code, or AI prototyping tools, like Bolt or v0, designed for building prototypes and consumer-facing websites. They help developer teams ship faster, with many of the same development, scaling, and hosting challenges that prevented most teams from building their own software in the first place. Zite and other AI app builder tools are, instead, built for non-technical teams to turn business workflows into structured apps that solve internal needs without any additional development work. They’re how you can build a CRM for your sales process, an inventory tracker built for your products, or any other data-powered software you need.
Take an employee directory that tracks shirt sizes for company swag. In a spreadsheet, some could leave the shirt size blank, while others might write “Medium tall” or “L/XL,” leaving the ops team scrambling to confirm everyone's data days before a company retreat.
In a custom-built app, you’d make shirt size a required field with pre-set options like small, medium, and large. Everyone would pick their preferred size the first time, and the ops team would have the data in a clean report without followups, data cleanups, or export. Instead of relying on everyone to enter data correctly, the system enforces the rules you set.
The key difference is where the flexibility lies. Spreadsheets leave the flexibility at the data-entry level; easy to use, and to break. Off-the-shelf software allows for flexibility in the choice of software and perhaps in custom fields, but is difficult to fit into more unique workflows. In Zite, the flexibility is at the design and workflow level, building tools that look and work the way you want that then enforce the data rules needed to keep processes consistently running into the future.
From freeform cells to structured data
Those rules and structure make all the difference. Instead of a spreadsheet where every cell is a blank canvas, your app’s fields enforce rules consistently. This data goes here, this field can’t be blank, this person is the only one allowed to edit data, and so on. A JPMorgan-style error wouldn’t happen in a properly structured app, where carefully audited formulas are clearly defined, not hidden away in Excel cells, and where workflows enforce data guardrails.
The same focus on structure lets custom apps prevent the other common spreadsheet disasters. No more phantom inventory because the system enforces that you can't sell what you don't have. No more missing data because required fields must be filled before submission. No more versioning chaos because there's one source of truth, not multiple copied files floating around in email attachments.
Structured applications aren't new, of course. Microsoft Access provided an early way for non-developer teams to build personal CRMs, inventory management systems, and basic point of sales systems with databases, forms, and views. But Access was limited to a single computer, required learning Visual Basic for anything complex, and had no integrations to other business software.
Today's AI-powered internal app builders like Zite start with a hosted database, built for collaboration from the start instead of being locked down to a single computer. They're built around integrations, making the new software you build a hub at the center of your existing tools instead of an island unto itself. They run on the web, making them accessible from any computer or phone, with authentication and user management baked in. And they're designed around generative AI, to build the app and tie everything together for you, paired with tools to manually edit the app's design and workflows when needed.
In Zite, for example, you start with an AI chat prompt where you describe your business needs and workflow (employee directory) and your team’s unique requirements (every team member’s shirt size). Armed with that knowledge, it builds a custom database schema that translates the ideas into specifics of which type of data is needed (name, address, and more along with shirt size) and what’s required or optional. It creates workflows that save the data and restrict access controls around who is allowed to enter or view that data. It then builds the application interface around the database, with editable dashboards, forms, and reports complete with any branding you added to the initial chat prompt, and email or Google authentication to keep data secure.
Software that protects you from yourself
With a custom-built app designed for your team, you’ll have exactly what your team needs, and nothing else. When a new requirement comes up, you can add it as needed, without submitting a feature request and hoping the development team decides to add it. And when loose ends crop up from incomplete or misformatted data, you can tighten your app’s requirements to avoid similar issues in the future.
There’s more setup time in building an app than creating a spreadsheet, but not all that much more than you’d spend customizing a CRM like Salesforce into a tool for your team. The difference is, once you’ve defined the structure, your custom-built software enforces it forever. You don’t need eternal vigilance to prevent someone from accidentally breaking a formula or entering the wrong data type. Your software will enforce the guardrails to keep your workflows working, automatically.
"People who are really serious about software should make their own hardware,” quipped Xerox PARC computer scientist Alan Kay, and it’s easy to point at everything from Apple to Nintendo and see the self-apparent truth in the statement. Perhaps, now that the cost of building is literally not much more than the time it’d otherwise take to set up more complicated software, the idea should be broadened to businesses in general.
Tomorrow, you’re going to open up a shared spreadsheet again. You could continue to delay the inevitable, hoping the spreadsheet will keep humming along. Instead, it’s time to rebuild it into a structured application, defining the rules once and letting the software enforce them forever, with flexibility at the design instead of the data-entry level.
Written by
Matthew Guay is a writer and co-founder of Pith and Pip. He previously was founding editor of Capiche and Zapier’s senior writer and editor.
