Why we’re building our own internal business system

Start with the questions the business needs to answer

A sales total is useful, but it rarely tells the whole story. Which period does it cover? Which channel supplied the figures? Have returns or adjustments been included? When several tools describe the same business in different ways, a tidy screen can still leave those questions unanswered.

Our starting point is the work around the numbers: where a record comes from, what it means, and who needs it next. We want the system to make that context easier to follow. The aim is not to replace every existing tool, but to choose where a shared view or a small internal application would help.

Sales tracking and dashboards need agreed definitions

Sales tracking and executive dashboards are part of the intended scope. A useful dashboard should answer a particular question, such as how sales compare across periods or which figures need checking. We want to keep the route back to the source visible, so a surprising number can be investigated.

Before choosing a chart, we need to agree the calculation, the reporting period and the update frequency. A number from yesterday should not look like a live count. Comparing channels also means checking whether the figures describe the same thing. Those choices matter more than filling a screen with indicators.

Inventory and social media belong in the business context

Inventory management is another intended area. The design needs to distinguish recorded stock from an estimate or a planned movement. An exception worth reviewing might be a mismatch between two records, rather than a simple low-stock warning. What matters is that someone can understand the issue and decide what to check.

Social media integration is also in scope, but that does not mean every action should be automatic. A useful first step could be a shared view of content plans and relevant records. Publishing, changing an offer or making a customer commitment should have clear permissions and an appropriate review step.

How we want the information to flow

The proposed flow brings records together, checks their meaning and puts useful information in front of the person who needs it. We will refine the details around the available sources and access permissions.

Build a small part that can be checked

We want each addition to have a clear purpose and a way to test it. For a reporting view, that means comparing the result with source records. For an internal task, it means checking the ordinary path as well as missing information, duplicate records and unavailable services.

Access, backups and documentation belong in that work from the beginning. A system is not ready simply because a screen displays data. The people using it need to know when it was updated, what it cannot tell them and how to correct a mistake.

What we will share as the work develops

This is the beginning of a build diary. As the system develops, we want to share the decisions behind it: a problem found during testing, a feature we changed or a simpler approach that worked better. Those details should make the development process useful to follow.

For another business considering an internal system, the same starting questions are useful: which decision is difficult today, which records support it, and who needs to act? Answering those questions gives a first version a purpose before a technology stack is chosen.