I don't sell traffic.
I build things
you use.

A spreadsheet is not automatically the problem

A spreadsheet can be the right tool for a focused calculation, a controlled planning model, a temporary analysis, or a modest process with one clear owner. Replacing it simply because it is a spreadsheet can add cost and complexity without improving the work.

The real concern is the operating process that has accumulated around the file. A useful workbook can gradually become a shared database, approval queue, reporting system, and institutional memory at the same time. Those responsibilities place very different demands on access, validation, history, permissions, and reliability.

Start by separating the file itself from the workflow it supports. If the workflow is still understandable, bounded, and resilient, improvement may be enough. If the workflow has become difficult to control, it is reasonable to evaluate a system.

Look for evidence that the workflow has outgrown the file

No single inconvenience proves that custom software is required. A pattern of recurring workarounds is more useful evidence. Pay attention to where people spend time reconstructing context, correcting preventable errors, or waiting for information that technically already exists.

The strongest signals usually sit at the handoffs between people and systems. That is where version confusion, informal approvals, missing ownership, and duplicate entry tend to appear.

• The same information is entered into several files or systems.
• People maintain competing copies and must determine which one is current.
• Approvals happen in email or chat and are difficult to connect to the underlying record.
• Leadership reporting requires recurring copy-and-paste work before anyone can review it.
• Important steps depend on one person remembering how the process works.
• Permissions, change history, or traceability matter more than the current setup can support.
• Exceptions are common, but the file cannot make responsibility or the next action clear.

Define the work before defining the software

A request to replace a spreadsheet often arrives as a list of fields and screens. That is useful detail, but it is not yet a product definition. A dependable system begins with the decisions people make, the events that move work forward, and the exceptions that need a deliberate response.

Map one real cycle from beginning to end. Identify who starts it, what information they need, where that information originates, who reviews it, what can block it, and what counts as complete. Include the unofficial steps, because the workaround often reveals a requirement that the formal process has missed.

• What event starts the workflow?
• Who owns each stage and who needs visibility without edit access?
• Which information is authoritative, and how current must it be?
• What exceptions occur, and who decides what happens next?
• What history, evidence, or approval record must remain available?

Compare the responsible options

Once the workflow is understood, compare solutions at the right scale. A carefully designed workbook may remain the best answer. A small automation may remove duplicate entry. An existing platform may cover the process after configuration. A focused custom application may be justified when the workflow is distinctive, the handoffs matter, and the organization needs control that available products do not provide.

A hybrid approach is also common in principle: retain a source system that already works, then add a purpose-built workflow or reporting layer around a specific gap. The feasibility of that option depends on access, integration methods, data quality, permissions, and support responsibilities; it should be verified rather than assumed.

Compare not only the initial build or licence. Consider configuration, migration, training, administration, vendor dependence, maintenance, security, and the cost of continuing the current manual process.

Start with a bounded first step

If the evidence supports change, the first release does not need to reproduce every tab, exception, and historical workaround. Choose one valuable workflow boundary: one group of users, one decision, and one dependable source of information.

Prototype the critical path before committing to the complete build. That creates something concrete for the people who do the work to review. It also exposes missing rules and source-data problems while the cost of changing direction is still lower.

The goal is not to turn every spreadsheet into software. It is to give the right process an appropriately dependable home.

Begin with the decision, not the dashboard category

A reporting project can become a product comparison too early. Teams start evaluating chart libraries, vendor feature lists, or interface examples before agreeing on who needs to decide what. That makes it difficult to distinguish a real requirement from an attractive option.

Describe the recurring decision first. Name the person or role making it, the information they require, how current it must be, and what action should follow. Then test each possible solution against that operating need.

If a standard product supports the decision with acceptable configuration and process change, that is meaningful evidence in its favour. If the product leaves the organization rebuilding context outside the tool, the apparent fit may be incomplete.

When off-the-shelf reporting is the stronger choice

An existing reporting or business-intelligence product is often the responsible starting point when the need is well understood across many organizations and the product already supports the required sources, permissions, distribution, and administration.

Packaged software also brings an established product roadmap and vendor support model. Those advantages matter when the organization is comfortable adapting parts of its process to the product and has people who can own configuration and governance.

• The reporting workflow is common and does not depend on distinctive operational rules.
• Required data sources and authentication methods are supported and have been verified.
• Available permissions, refresh behaviour, and audit features match the actual requirement.
• Users can work effectively within the product's navigation and reporting model.
• The organization accepts the vendor's pricing, roadmap, support boundaries, and degree of control.

When a custom dashboard deserves investigation

Custom does not mean adding a branded surface to standard charts. It becomes relevant when the organization needs an interface organized around a particular decision, workflow, or combination of information that available products do not support cleanly.

The case is stronger when users must move from seeing an exception to assigning, approving, documenting, or resolving it in the same flow. At that point, the need may be operational software with dashboard views rather than a reporting page alone.

• Several existing systems need to be understood together, and their access methods can support responsible integration.
• Roles require meaningfully different views or actions that packaged permissions cannot express well.
• Definitions and workflows are specific enough that repeated configuration workarounds undermine clarity.
• The organization needs direct control over the product experience, roadmap, or deployment responsibilities.
• A bounded first release can deliver a useful decision or workflow without attempting to replace every system.

Do not overlook the hybrid option

The choice is not always a complete packaged platform or a completely custom system. An organization may keep an established source of record, use a vendor product for general analysis, and introduce a focused custom workspace for one workflow or executive view.

That approach can reduce replacement scope, but it still depends on verified integration access, data definitions, identity, permissions, and clear ownership. A custom layer cannot correct unclear source information by itself.

Prototype the connection and the highest-risk workflow early. If the source cannot provide dependable information, discovering that constraint is more valuable than polishing the surrounding interface.

Compare the total responsibility, not just the starting price

A useful comparison includes every responsibility needed to keep the reporting dependable. Packaged software may include core hosting and upgrades while still requiring configuration, data preparation, licences, training, administration, and vendor management. Custom software may provide closer workflow fit while requiring explicit ownership of hosting, maintenance, security, support, and future changes.

Neither model removes organizational work. Someone must own definitions, access, source quality, and the process for changing a report. Include those responsibilities in the decision so the chosen option remains supportable after launch.

• Initial discovery, configuration, or development
• Data access, cleanup, integration, and migration
• Identity, permissions, privacy, and security review
• Training, adoption, and operating-process changes
• Ongoing administration, support, upgrades, and enhancement
• Exit options and the organization's ability to retrieve or move its information

1. What decision should become easier?

A dashboard is a means of supporting a decision, not an outcome by itself. If the brief begins with a list of charts, it is easy to produce an attractive surface that still leaves its audience wondering what to do next.

Start with a recurring decision in plain language. A leader may need to decide where an exception requires attention. A coordinator may need to decide which work item should move next. A reviewer may need to decide whether the available information is complete enough to approve. Each of those decisions requires a different interface, level of detail, and update cadence.

Name the primary person or role responsible for that decision. Other audiences may need visibility, but designing one screen to satisfy every level of the organization often removes the context each group needs. A clear primary audience gives the dashboard a useful centre of gravity.

• Which recurring decision is currently slow, unclear, or dependent on manual preparation?
• Who is accountable for making it?
• How frequently does the decision occur?
• What is the consequence of deciding late or with incomplete information?
• What action should become possible once the answer is visible?

2. What information is needed, and where does it live?

Once the decision is clear, work backwards to the minimum information required to support it. Separate information that changes the decision from information that is merely interesting. This protects the first version from becoming a catalogue of every field the organization can access.

For each required item, identify its source and condition. It may live in a business system, a database, a spreadsheet, a form, a shared document, or an informal exchange between people. Determine whether it can be accessed, how it is structured, how often it changes, and whether the same term means the same thing across departments.

Data availability should be verified before an interface is treated as feasible. An existing system may not expose the necessary information in a supported way. A source may be technically accessible but too incomplete or inconsistent for the intended decision. Those are discovery findings, not interface problems that a chart can conceal.

• Which source is authoritative for each required value?
• How current must the information be for the decision?
• Can the source be accessed through a supported export, API, database connection, or other approved method?
• Which definitions or calculations need agreement before they are displayed?
• What should the interface show when information is missing, delayed, or disputed?

3. Who owns the information and the definitions?

A dashboard can make a definition visible, but it cannot decide who has the authority to define it. Terms such as complete, overdue, available, at risk, or on track may have different meanings across teams. If those meanings remain unresolved, the interface can make disagreement look more precise without making it more useful.

Assign ownership at several levels. Someone must be accountable for each source, someone must approve shared definitions and calculations, and someone must decide who can view or change information. The organization also needs an owner for the product itself: the person who can prioritize corrections and future changes after launch.

Permissions belong in this conversation early. Executive visibility, operational editing, approval authority, and administrative access are not interchangeable. The design should expose the right detail to each role without relying on everyone to ignore information or controls they should not use.

• Who owns the source and addresses quality problems?
• Who approves definitions, thresholds, and calculations?
• Which roles can view, comment, edit, approve, or administer?
• Who decides when the dashboard itself should change?
• What history or audit evidence must remain available?

4. What should happen when something needs attention?

Visibility matters only if it connects to an appropriate response. If a dashboard identifies an overdue approval, an asset requiring attention, or a report with missing information, define what should happen next. Otherwise the dashboard may become another place people check before returning to email and spreadsheets to do the work.

The answer does not always require a complex workflow engine. It may be enough to identify an owner, expose the supporting record, and provide a clear route to the existing system where action occurs. In other cases, the value of the product may depend on assignment, acknowledgement, comments, approval, or escalation within the same experience.

Notification also needs restraint. Decide which events justify an alert, who receives it, through which channel, and what happens if nobody responds. More notifications do not create more accountability; a clear response path does.

• What condition requires action rather than observation?
• Who becomes responsible when that condition occurs?
• Can the action happen in the dashboard, or should the user move to a source system?
• What context must travel with an assignment, approval, or escalation?
• How is the item resolved, and what record of that resolution is required?

5. How will you know the dashboard remains useful?

A dashboard can match its original brief and still lose relevance as definitions, source systems, responsibilities, and operating priorities change. Plan for review rather than assuming the first release will remain correct indefinitely.

Usefulness should be evaluated against the decision named at the beginning. Ask whether the intended people can find the information, understand its condition, and take the required next step. Feedback from actual use is more informative than counting available charts or fields.

Agree who will receive feedback, how corrections are prioritized, and how source or definition changes are communicated. Also define the support boundary: who monitors the system, who manages access, who responds when data is delayed, and who is responsible for technical maintenance.

• Is the intended decision clearer and appropriately timed?
• Do users understand the source, freshness, and meaning of the information?
• Are exceptions reaching a responsible owner with enough context to act?
• Which unused or confusing elements should be revised or removed?
• Who owns review, support, access, and future enhancement?