The starting point
A real store, not a pitch deck
SmokeOps began behind the counter at an East Texas smoke shop. The daily questions were practical: What sold? What is actually left? What needs counting? What should the owner order next?
The story behind SmokeOps
Built behind the counter, one stubborn question at a time.
SmokeOps started with a laptop, a stack of POS exports, and a simple question: how can an owner understand what is really happening in the store without replacing everything that already works?
Started in a working smoke shopBuilt around real employee workflowsDesigned to keep the existing POS
The original SmokeOps build
Before the dashboard, there was a report
Owner Operational Assessment
Generated from an ordinary sales CSV
Sales
What happened?
Inventory
What can we trust?
Actions
What happens next?
The useful problem
The report could explain sales. It could not confidently explain the shelf until product identity, counts, receiving, and daily movement became part of the same system.
First office
A store counter, a laptop, and whatever time was left after the shift.
First roadmap
Make the PDF useful enough that an owner would actually act on it.
A small beginning with a large rabbit hole
One report kept turning into another question.
The more useful the first report became, the clearer it was that store intelligence could not be separated from inventory discipline.
The first version
One PDF that asked better questions
The original build was a small script that turned a POS export into an owner-facing report. It was meant to make one store easier to understand—not to become a software company.
The realization
The report was only the doorway
The deeper problem was not a lack of charts. It was that product names drifted, UPCs were missing, physical counts were rare, receiving lived in people’s memory, and the POS could not explain every movement.
The turning point
The PDF was useful. The workflow behind it could be much more useful.
A static report could tell an owner what happened yesterday. A real operating system could help an employee count correctly today, compare a delivery to an order, resolve an unknown UPC, record damage, protect permissions, and show the owner what needs attention before tomorrow.
What SmokeOps became
An inventory-first operating layer above the POS.
The POS still handles checkout and payment. SmokeOps focuses on the operational questions that begin after the receipt prints.
Fast physical counts
Employees can scan exact products, count cases and loose units, save drafts, and submit work for review without needing to understand inventory theory.
Receiving that matches reality
Receive against an order or record an unplanned owner drop-off. Shortages, damage, substitutions, backorders, and unexpected products remain distinct.
Explainable movement
Tablet sales, POS imports, receipts, returns, damage, samples, write-offs, reversals, and corrections contribute to one auditable product history.
Inventory confidence
SmokeOps shows how trustworthy an estimate is and why—using count age, data coverage, unresolved UPCs, open receiving, and other real evidence.
Coverage-aware ordering
A low unit count is not automatically urgent. Recommendations consider demand, days of cover, lead time, open orders, case quantities, and owner settings.
Owner-controlled access
Permissions remain configurable by user and store. Owners decide who can count, receive, reverse transactions, view costs, confirm work, or manage purchasing.
How it works
Start with what is physical. Add what happened next.
SmokeOps builds its estimate from confirmed observations and auditable movement. Later POS evidence can support or challenge that story without silently rewriting it.
The simple version
Confirm what is on the shelf. Record what enters and leaves. Recount where confidence weakens. Let the owner decide what to order, fix, or review.
Identify and count
Create a trustworthy product identity and establish a confirmed physical baseline.
Record store activity
Capture receiving, tablet sales, damage, returns, samples, and corrections as they happen.
Compare the evidence
Use POS exports and later integrations to validate movement without erasing the original records.
Tell the store what matters
Prioritize recounts, exceptions, stockout risk, receiving follow-up, and owner-reviewed orders.
Why the approach may fit better
Simple enough for the counter. Serious enough for ownership.
SmokeOps is designed around the store’s existing habits and constraints instead of asking the store to become a software company.
The shelf gets the final vote
A POS record is useful evidence, but a confirmed physical count is the clearest observation of what is actually present.
Similar is not the same
Flavor, strength, size, device generation, and package count matter. SmokeOps avoids silently merging products just because their names look close.
Software should respect the employee’s time
The normal workflow must work for someone standing at a counter, serving customers, using a tablet, and trying not to make a mistake.
Uncertainty should be visible
When the evidence is incomplete, SmokeOps says so. Low confidence becomes a reason to count or review—not a number disguised as fact.
The first version answered one owner’s questions.
The goal now is to help independent stores build inventory they can explain, workflows employees can actually use, and a daily list of actions worth paying attention to.