Build in public advice is written by and for people making developer tools. Those have a natural audience: other developers, on platforms full of developers, who find the subject interesting on its own.
If you are building inventory software for tyre distributors, none of that applies. There is no community of enthusiasts. Nobody is going to follow you for updates about stock movements.
What works instead is different, and it has one large advantage.
The audience is not the product's audience
The mistake is assuming you need to reach buyers directly. You probably cannot, at least not this way. Warehouse managers are not on X reading build in public threads.
But the problem is interesting to a much broader group, and the reason is that boring domains are full of things that surprise outsiders.
The client identified sites by a code that turned out not to be unique. Two warehouses had shared one for four years and nobody had noticed because the reports were aggregated.
That is interesting to anyone who has worked with real data, regardless of whether they care about warehouses. It is a story about how systems drift from reality, which happens to be set in a warehouse.
Boring domains have better stories
This is the advantage, and it is real.
Developer tools are built by people who understand the domain perfectly, for users who are basically themselves. There are fewer surprises, because there is less distance between builder and problem.
Boring domains are full of distance. The way the business actually works never matches the way it is documented. The edge cases are absurd and true. The requirement that sounds trivial takes three weeks because of something nobody mentioned.
Every one of those is a story, and they are stories nobody else is telling, because most people writing about software are writing about software.
What to actually post
The domain surprise. The thing about this industry you did not know and now do. This is your best material and you have an endless supply.
The requirement that was not what it seemed. "They asked for a report. What they needed was for two people to stop arguing about whose number was right."
The technical decision, framed by the constraint. Constraints in unglamorous domains are more interesting than in green field ones, because they are real.
What the software replaced. Usually a spreadsheet, and usually a spreadsheet that worked better than anyone admits. That is a good post.
What to leave out
Client specifics. Obviously, but worth saying, because the interesting details are often the identifying ones.
The rule that works: describe the shape of the problem, never the party. "A distributor with two warehouses" carries the story. The name adds nothing except risk.
Expect a different shape of result
This will not build a large following, and that is not the goal.
What it builds is evidence that you understand a domain. When someone in that industry eventually finds you, through a search, a referral, a conference, they find a body of writing that demonstrates you know how their business actually works.
That converts at a rate developer tool content does not, because the audience is tiny and every member of it is qualified.
Ten readers who run warehouses is a better outcome than a thousand who found your post interesting and will never buy anything.