What a building materials business should digitise first

Digitise the catalogue first. Not sales, not the dealer portal, not reporting — the product data underneath all of them. Every other system you build will read from it, and if it is wrong, everything downstream inherits the error. Businesses that start with a dealer app and fix the catalogue later usually rebuild the app.

This is rarely what anyone wants to hear, because the catalogue is not the thing causing pain today.

Why the catalogue before anything else?

Because it is the shared dependency. Consider what needs it:

A dealer portal needs products, prices and availability
A quotation tool needs the same, plus configuration rules
A website needs products with images and specifications
Reporting needs a stable structure to group by
A visualiser or calculator needs accurate dimensions and packaging data

Build any of those on a catalogue held in three spreadsheets with inconsistent naming, and you inherit that inconsistency permanently. Worse, each new system tends to bring its own copy of the product data, and within two years you have four versions that disagree and no authoritative one.

One catalogue, one place, everything else reads from it. That single decision determines how much everything after it costs.

What does “digitising the catalogue” actually mean?

Not scanning a brochure. Six things:

Element	What good looks like
Hierarchy	Category, collection, product, variant — with a rule for where new products go
Attributes	Structured fields, not free text. Filterable and reportable
Identifiers	One code per item, used consistently across every system
Packaging data	Pieces per box, coverage per box, weight — the numbers orders depend on
Images	Consistent naming, linked to the item, at usable resolution
Ownership	One person or team responsible for keeping it correct

The last row matters as much as the rest. A catalogue with no owner drifts within months, and a drifted catalogue is how you end up back with spreadsheets.

What comes second?

Order capture — whichever channel carries the most orders, whether that is dealers, counter sales or projects.

Two reasons. It produces immediate operational value: fewer transcription errors, faster processing, and a record of what was actually ordered rather than what someone remembers. And it generates the transaction data every later system needs — you cannot report on sales patterns you never captured.

Start with the channel with the highest volume, not the one with the loudest complaints.

What about compliance — where does that sit?

Alongside, and not optional if it applies to you.

Under GST, e-invoicing is mandatory above a turnover threshold, and businesses above a higher threshold must also report invoices to the Invoice Registration Portal within a fixed window of issue. Confirm both against CBIC notifications or with your chartered accountant. The figures have been lowered repeatedly since e-invoicing was introduced, and proposed reductions circulate as though already in force long before any notification exists.

Three things about it are worth knowing whatever the current numbers are, because they are what catch businesses out.

Turnover is assessed across your PAN, not per registration — so several GSTINs under one PAN are added together, and a business can be in scope without any single registration looking large.
Crossing the threshold is permanent. It is tested against past financial years, so a business that qualified once stays in scope even if turnover later falls.
Late reporting can invalidate the invoice. Where a reporting window applies, an invoice that misses it cannot obtain a valid reference number — and your customer cannot claim input tax credit on it.

That last point is why this belongs in the build order rather than in a finance conversation. Retrofitting invoice reference generation into an order flow that was not designed for it is considerably more work than allowing for it at the start — and the consequence of getting it wrong lands on your customer, which makes it a commercial problem as well as a compliance one.

If you are anywhere near the threshold, build as though it applies. The direction of travel has been one way since it was introduced.

What should wait?

Three things that are usually attempted too early.

Dashboards and analytics. Reporting on data you have only just begun collecting tells you about your adoption curve, not your market. Give it six months of transactions first.

Anything AI. Models need data. If your product data is inconsistent and your transaction history is thin, an AI project will produce confident nonsense. Fix the foundations and the same investment works far better a year later.

A customer-facing app. Expensive, hard to get installed, and usually solving a problem a well-built mobile website solves for a fraction of the cost. Justify the app specifically, rather than assuming it.

A reasonable order

Catalogue — structured, owned, single source
Order capture — highest-volume channel first
Compliance — e-invoicing and statutory reporting, where applicable
Channel visibility — dealer portal, order status, stock
Field and sales tools — once there is data worth carrying
Reporting — when six months of transactions exist
Customer-facing tools — visualisers, calculators, apps

Most businesses want to start at six or seven, because that is where the visible frustration is. Starting there means building on data that is not ready, and rebuilding later.

Common questions

How long does catalogue work take?

It depends entirely on how many products you have and how consistent they currently are. The structural design is quick; the cleaning is not, and it is the part that gets underestimated because nobody knows how inconsistent the data is until they look.

Can we do catalogue and order capture together?

Often yes, and it can be sensible — order capture gives the catalogue an immediate use, which keeps it accurate. Just make sure the catalogue structure is agreed before order capture is built on top of it.

What if our ERP already holds the catalogue?

Then check whether it holds it well. Many ERPs hold enough for accounting — a code, a description, a rate — and nothing usable for sales: no images, no coverage data, no structured attributes. That is the gap to fill.

We are a dealer, not a manufacturer. Does this order change?

The principle holds but the catalogue problem is harder, because you carry several principals with different structures. Merging them into one usable view is the first job, and no manufacturer’s system will do it for you.

More on this: build, buy or neither and why generic ERP breaks. For how we work with this trade, see building materials.