What should a small business’s technology actually look like? The answer is not a list of recommended tools. Specific tools change, and the right choice depends on circumstances this book cannot know. What does not change are the principles that distinguish a well-designed technology stack from a poorly-designed one. The most important of these principles is simple: a good stack reduces tools rather than adding them.
Consolidation Over Proliferation
Small businesses accumulate tools over time, each one added to solve a specific problem, until the collection becomes its own source of complexity. You become the integration layer, manually connecting systems that do not talk to each other. Information scatters across tools, and finding what you need requires knowing where to look.
A well-designed stack moves in the opposite direction. Instead of adding a new tool for each new problem, it asks whether existing tools can be extended or whether multiple tools can be consolidated. The goal is not to have the fewest possible tools, but to avoid the fragmentation that creates integration burden and information scatter.
This principle changes how tool decisions should be made. Before adding a new tool, ask what it will connect to and who will maintain that connection. Ask whether the problem it solves is significant enough to justify another system to learn, another place where data lives, another potential point of failure. Sometimes the answer is yes. Often, the answer is that the problem can be solved within existing systems, or that solving it is not worth the complexity a new tool would add.
Where Data Should Live
One of the most important decisions in any technology stack is where data lives. Customer information, job details, financial records, operational history—this information is the memory of the business. Where it is stored determines who can access it, how easily it can be found, and what happens when systems change.
The principle is straightforward: for any important category of information, there should be one authoritative place where it lives. This does not mean every piece of data must be in a single system. It means that when someone asks a question about a customer, or a job, or a transaction, there is a known place to find the answer. That place should be accessible to the people who need the information and should not depend on a specific person’s memory or inbox.
In practice, this often means choosing one system to be the primary record for each type of information and treating other systems as secondary. Customer information might live primarily in one place, even if it is referenced in others. Job status might be tracked in one system, even if related communication happens elsewhere. The choice of which system is primary matters less than the clarity of having made a choice.
When Spreadsheets Are Fine
Spreadsheets have a poor reputation in discussions of business systems, and earlier chapters described how they can become symptoms of missing structure. But spreadsheets are not inherently problematic. They are problematic when they are used for purposes they cannot serve well.
Spreadsheets are fine for analysis, one-time calculations, and problems that do not need permanent solutions. They work well when one person uses the data without needing to share it, or when flexibility matters more than consistency.
Spreadsheets become dangerous when they are the authoritative record for information that multiple people need to access, when they grow to the point where their structure is difficult to understand, or when the business depends on them but only one person knows how they work. The test is not whether a spreadsheet is being used, but whether it is being used for something it can handle reliably.
When a spreadsheet has become essential to operations, is accessed by multiple people, and breaks when its creator is unavailable, it has outgrown its appropriate use. At that point, the information it contains should move to a system designed for shared, reliable access.
What Should Be Automated
Automation is appealing because it promises to eliminate repetitive work. Defaults and guardrails can reduce decision volume, as described earlier. But not everything that can be automated should be.
Good candidates for automation are tasks that are repetitive, rule-based, and well-understood. If the same action is performed the same way every time, and the criteria for performing it are clear, automation can save time and reduce errors. Moving data between systems, sending routine notifications, applying standard calculations: these fit the criteria.
The risk increases for tasks that are not yet well-understood. Automating a process that is still being figured out encodes the current understanding, including any errors or inefficiencies, into a system that will repeat them at scale. It is better to run a process manually until it is stable, then automate once the right approach is clear.
A related risk is loss of visibility. A manual process, however tedious, keeps humans aware of what is happening. An automated process can run in the background, unnoticed, until something goes wrong. Before automating, consider whether you will know when the automation fails and whether you will understand what it is doing well enough to fix it.
When Off-the-Shelf Tools Are Not Enough
Most small businesses can operate effectively with standard, commercially available tools. Accounting software, scheduling tools, email, and a place to store documents cover the majority of needs. The previous chapters’ advice about consolidation and simplicity applies primarily to choosing among and configuring these standard tools.
Occasionally, a business has needs that standard tools cannot meet. The signs are recognizable: extensive workarounds required to make a tool do something it was not designed for, multiple tools being used together in ways that create constant hassle, or processes that are central to the business but poorly served by any available option.
When these signs appear, custom systems become worth considering. A custom system is built specifically for the business’s needs, rather than adapted from a general-purpose tool. This allows it to match how the business actually works, rather than forcing the business to adapt to the tool’s assumptions.
Custom systems have costs: they require investment to build, expertise to design well, and ongoing maintenance. They are not appropriate for problems that standard tools can solve adequately. But for businesses whose core operations are genuinely distinctive, a well-designed custom system can eliminate the inefficiency that accumulates when standard tools are forced into roles they were not designed for.
A Right-Sized Stack
A right-sized technology stack is not the most sophisticated or the most minimal. It is the stack that fits the business’s actual needs while respecting the constraints the previous chapters described.
It consolidates where possible, avoiding the proliferation that creates integration burden, and it has clear answers to the question of where important information lives. It uses spreadsheets appropriately and recognizes when they have been outgrown. It automates what is well-understood and repetitive while maintaining visibility, and it considers custom solutions only when standard tools genuinely cannot meet the need.
The technology stack is a means to an end. The end is a business where information is accessible, decisions can be made without delays, and work flows without unnecessary friction. The next chapter addresses what can go wrong when systems are implemented without sufficient care, and how to avoid the most common failures.
