None of these predict the thing that actually determines the outcome — how the partner behaves when the project becomes difficult. And it will. Data will be messier than expected, a requirement will turn out to be wrong, and a deadline will collide with a discovery nobody anticipated.

This article is a set of questions that reveal that behaviour in advance. We are a software partner, so read this with that in mind — though several of these questions are ones we would rather be asked, because they make bad-fit engagements visible early.

Ask what they will do before they build

The single most predictive question: what happens in the first two weeks?

If the answer is "we gather requirements and produce a specification", that is a partner who will build what you describe. If what you describe is complete and accurate, fine. In our experience it never is — operations run on workarounds and undocumented exceptions that do not appear in any requirements meeting, which is why we document how the work is actually performed rather than collecting a specification.

Better answers involve spending time in the operation, watching the work, and coming back with observations you did not tell them.

A partner who is willing to disagree with your brief before starting is worth more than one who agrees with all of it.

Ask what they would not build

"What in our request would you push back on?"

A partner with no answer either has not thought about it or is unwilling to say. Every substantial brief contains something that should be scoped differently, deferred, or solved without software.

The related question: "What would you recommend we buy instead of build?" A partner who can identify nothing reusable in your requirements is either not looking or is billing by the hour. There are mature products that solve real problems, and a good partner knows where theirs is not the answer — a judgement covered in off-the-shelf or custom.

Ask about deployment, not just delivery

Most failures are rollout failures, not engineering failures. So ask how the system reaches the business.

How is it deployed? A single cutover on a planned date, or gradually with the old system running in parallel? Parallel running costs duplicated effort briefly and is far cheaper than an outage in a live operation.

What is the migration plan? If migration is a line near the end of the timeline, it has been underestimated. It is usually the largest source of risk, as covered in moving years of records without losing them.

Who trains the staff, and for how long? Training measured in weeks suggests a system too complex for the people who must use it under pressure.

What happens if it goes wrong on day one? There should be a rollback answer.

Ask about after

Software projects are sold as builds and lived as relationships.

Who maintains it, and at what cost? Get the ongoing figure before signing, not at renewal.

What happens when we need a change in a year? Rate, lead time, and whether there is a queue.

What if the people who built it leave? This applies to their team and to yours. Systems that only one person understands are a risk regardless of which side that person is on.

Can we take it elsewhere? Ask directly about code ownership, documentation, and whether another firm could reasonably pick it up.

Ask the data question early

Can we export everything, in standard formats, whenever we want?

The answer should be immediate and unqualified. Hesitation, or an answer about proprietary formats and export tooling, is telling you that your switching cost will rise over time — and that cost becomes a negotiating position against you at every renewal.

A partner confident in the work does not need lock-in to retain clients.

What a portfolio does and does not tell you

A portfolio proves capability existed on some project, once, possibly with a different team.

More useful:

Ask about a project that went badly. What happened, what they would do differently. A partner with no such example is either inexperienced or not being straight with you. The quality of this answer is the most diagnostic thing in most evaluations.

Ask to speak to a client from two years ago, not a recent one. Recent clients are still in the honeymoon. Two years in, someone knows what maintenance actually costs and how change requests are handled.

Ask who specifically will work on it. Firms sell with senior people and staff with junior ones. Ask who, and whether that is contractual.

Warning signs

• Agreement with everything. A brief with no pushback is a brief nobody examined.
• A fixed price before understanding the data. Either padded heavily or about to become a change-order argument.
• Vagueness about maintenance cost. It exists. Someone is planning to tell you later.
• No questions about your operation. A partner who does not ask how the work happens will build against assumptions.
• Guaranteed timelines before seeing the data. Migration timelines depend on data quality, which nobody has looked at yet.
• Reluctance on export. The clearest signal available.

What we would say about ourselves

We start by documenting the operation rather than collecting requirements, because the process as described and the process as performed reliably differ. We deploy gradually alongside existing systems. Your data stays exportable in standard formats.

We also say no. If a business is single-location with simple stock and one person holding the whole picture, we say the existing arrangement is doing its job. If a mature vertical product already encodes a genuinely unusual regulatory structure, we say buy that instead. Ten deployments have not changed that position — a partner who concludes every enquiry needs them is selling, not advising.

Frequently asked questions

Should we run a formal tender?

For larger commitments it imposes useful discipline. The risk is that tenders reward proposal-writing, which is a different skill from delivery. Balance it with the behavioural questions above.

How much should this cost?

Wide enough range that any figure here would mislead. More useful: ask each partner to break down build, migration, training and first-year maintenance separately. The shape of that breakdown is more informative than the total.

Is a bigger firm safer?

Bigger reduces the risk of the firm disappearing and increases the risk of your project being staffed by whoever is available. Ask who specifically, either way.

Should we ask for a fixed price?

For a well-defined scope, reasonable. For anything involving migration of data nobody has profiled, a fixed price is either padded or a dispute in waiting. A fixed price for the first phase, with the rest scoped after, is usually the honest structure.

What if we have no technical person internally?

Then the behavioural questions matter more, because you cannot evaluate the technical answers. Ask about deployment, migration, maintenance, ownership and export — all answerable without technical knowledge, and all predictive.

Where to start

Before contacting anyone, write down how your operation actually works, including the workarounds and the parts that live in people's heads. That document is your real brief.

Then ask every partner the same five questions: what happens in the first two weeks, what would you push back on, how do you deploy, what does maintenance cost, and can we export everything.

For what you would be asking them to build, what a business operating system actually is sets out the components.

The answers will differentiate them more than any portfolio. And if you want a straight read on whether your operation needs a system at all, get in touch — including if the answer is no.

Originally published at truffaire.in.

Counting more often measures the problem more frequently. It does not reduce it, and it consumes the time of people who could be doing something else. Variance is not a single failure with a single fix — it is at least six distinct causes that happen to produce the same symptom, and each one responds to something different.

If you cannot tell which cause produced a given discrepancy, you cannot fix any of them. That is the actual problem, and it is a records problem before it is a stock problem.

The six causes, and what each responds to

Receiving errors

Stock arrives and is recorded as the quantity on the invoice rather than the quantity in the box. Short deliveries, substitutions and damaged units enter the record as though they were correct.

Everything downstream inherits this. The count will be wrong for weeks, and when it surfaces it looks like shrinkage.

Responds to: recording what was physically received, at receipt, against the order — not transcribing the paperwork.

Sales not recorded against stock

An item leaves without the transaction decrementing inventory. Manual bills during a system outage, staff purchases, samples, replacements given to a customer.

Each is individually legitimate and individually invisible.

Responds to: one record, so a sale cannot be recorded without moving stock. This is structural, not procedural — if the two are separate systems, this gap always exists. It is the argument in what a business operating system actually is.

Wastage and damage nobody logs

Breakage, expiry, spoilage, returns that cannot be resold. Real cost, frequently unrecorded because logging it takes effort at the moment someone is busy and slightly embarrassed.

Unlogged wastage is indistinguishable from theft in the numbers, which means neither can be addressed.

Responds to: making the write-off faster than not doing it, and treating it as normal rather than as an accusation.

Transfers between locations

Stock leaves one outlet and arrives at another. Two entries, made by two people, at two times. Anything less than both being recorded produces a discrepancy in two places at once.

Responds to: transfers as a single transaction with a dispatch and a receipt, where an unreceived dispatch stays visible as in-transit rather than vanishing.

Unit and conversion errors

Bought in cases, sold in units. Bought by weight, sold by count. Every conversion is a place for a factor to be applied twice or not at all.

Responds to: defining the conversion once in the system rather than performing it mentally at each transaction.

Actual shrinkage

Theft — internal or external. Real, and generally a smaller share of total variance than businesses assume, because the five causes above are quietly inflating the figure.

Responds to: the other five being controlled first, so the residual is visible and attributable.

Why counting more does not help

A count tells you the size of the gap on the day you counted. It tells you nothing about which of the six causes produced it, or when.

Worse, counting is itself error-prone. Full physical counts are conducted under time pressure, often after hours, by people who are tired. A count that introduces its own errors produces a new baseline that is wrong in a different way — and the next variance is measured against it.

The useful shift is from counting more to capturing better: recording each stock movement as it happens, so variance is attributable rather than merely detectable.

Cycle counting is different

Counting a small subset continuously — high-value or fast-moving items weekly, everything else on rotation — is more useful than an annual full count, for a specific reason. Discrepancies are found close to when they occurred, while the cause is still knowable.

A variance found in March that arose in January is a number. A variance found within a week is an investigation someone can actually complete.

What a system has to do to prevent, not just record

Most inventory software records stock. Preventing variance requires more specific behaviour.

Receiving against the order, with discrepancies captured. If the system cannot easily record "ordered 100, received 96, 2 damaged", the difference disappears into the count.

No path to move stock without a record. Every legitimate reason for stock to leave — sale, transfer, wastage, sample — needs a fast route. If the fast route does not exist, staff will use the manual one and the record will drift.

Transfers with two ends. Dispatch and receipt as one linked transaction, with in-transit stock visible.

Conversions defined once. Purchase and sales units, with the factor held in the system.

Same-day visibility. Variance surfaced when it appears, not at the next count. This is the single highest-leverage property, because it collapses the distance between a cause and its discovery.

Variance attributable. The record should indicate what kind of movement produced the gap. That is what makes the number actionable instead of just alarming.

What we have seen

Inventory sits in most of the ten systems we have delivered — retail, warehouse, distribution, clinic and factory operations among them. The largest is a retail chain of more than thirty outlets, where every one of the six causes above appears simultaneously and in different proportions per location.

Two findings hold consistently.

Wastage logging is the fastest improvement available. It is almost always under-recorded, it is quick to fix, and fixing it immediately shrinks apparent shrinkage — which changes what the business believes about its own staff.

Staff are not the problem. They are usually being asked to record the same movement in more than one place while serving customers. When the record is a by-product of the work rather than an additional task, accuracy improves without anyone being asked to try harder. That principle — the counter comes first — is in how Truffaire builds software, and the failure mode is in why most business software breaks at the counter.

Frequently asked questions

What level of variance is normal?

It varies too much by sector for a single figure to be meaningful, and chasing a benchmark is less useful than chasing attribution. A business that knows its variance is largely logged wastage is in a better position than one with a lower unexplained number.

Should we do a full count or cycle counts?

Cycle counting for operational control, because it finds problems while the cause is still traceable. A periodic full count may still be needed for audit, but it is a poor instrument for actually reducing variance.

Will barcodes fix this?

They remove transcription and identification errors, which is genuinely valuable. They do not address unlogged wastage, missing transfer receipts or conversion errors. Scanning the wrong movement quickly is still the wrong movement.

How do we tell theft from process failure?

Only by controlling the other five causes first. Until receiving, unrecorded sales, wastage, transfers and conversions are captured, every discrepancy is ambiguous — and treating ambiguous variance as theft damages trust for no benefit.

Do we need this if we only have one location?

Less urgently. Single-site operations can often hold stock in view. The threshold is usually multiple locations, or enough SKUs that nobody can eyeball it. Where multi-outlet businesses lose money covers what changes with a second site.

Where to start

Before buying anything, categorise your last few discrepancies against the six causes. Most businesses find they cannot — which is itself the finding, and it identifies capture as the constraint rather than counting.

If you can categorise them, fix the largest category first. It is usually receiving accuracy or unlogged wastage, and both are cheap relative to the loss they hide.

What a business operating system actually is covers why a shared record removes the unrecorded-sale case structurally, and SPEXA is our implementation. If you want a read on which cause dominates in your operation, get in touch.

Originally published at truffaire.in.

The gap between those two conditions is where almost every real complaint about point-of-sale software originates. It is rarely about features. It is about what the system does when conditions are worse than the demo assumed — and the specific ways it slows down, blocks, or forces a workaround that quietly corrupts the record.

Speed is a feature, and it is measured in keystrokes

The number that matters is not how fast the software runs. It is how many actions a staff member performs to complete a normal sale.

Count them for your busiest transaction type. Every additional step is multiplied by the number of transactions per day and by the pressure of the queue. A billing flow requiring nine interactions instead of five does not cost four keystrokes — it costs four keystrokes several hundred times a day, performed by someone being watched by waiting customers.

This is also why systems get bypassed. When the official route is slow, staff find a faster one — a manual bill, a note to enter later, a "same as last time" shortcut. Every bypass produces a record that is incomplete, and the stock variance that follows is attributed to counting rather than to the interface.

Where the keystrokes actually go

Common and avoidable:

• Searching for items by scrolling rather than by code, barcode or short name
• Mandatory fields nobody needs on a routine sale — customer details on a cash purchase
• Confirmation dialogs on actions that are never accidental
• Re-entering the customer for a regular who buys weekly
• Switching screens to check stock or price mid-transaction

Each is defensible in isolation. Together they decide whether the system is used as designed.

Offline behaviour is not an edge case

Connectivity fails. Not rarely — routinely, and usually at the worst moment, because peak trading and network congestion often coincide.

What the system does then is a first-order requirement, not a footnote:

Does billing continue? If the answer is no, the business stops or reverts to manual bills. Manual bills are the single largest source of unrecorded sales.

Does it reconcile automatically? Transactions made offline must sync when connectivity returns, without someone re-keying them. Re-keying is where the errors enter.

Is the operator told which state they are in? Staff need to know whether they are online. A system that fails silently produces confident behaviour on stale data — a price or stock figure that is no longer current.

Ask about offline behaviour before anything else. It is the question that most reliably distinguishes software built for real counters from software built for demos.

The transactions nobody demonstrates

Demos show a clean sale. Operations are full of the other kind, and these are what generate the workarounds.

Partial returns. Three items bought, one returned, against a bill that had a discount applied to the total. How is the discount apportioned? If the system cannot do this, staff will improvise, and the numbers will not reconcile.

Split payment. Part cash, part card, part credit against an account. Common in almost every sector and frequently handled badly.

Price override. A manager authorises a reduction. Is it recorded as an override with a reason, or does it silently alter the line? This is exactly the price and discount drift that erodes margin invisibly.

Held and resumed sales. A customer steps away mid-transaction while others are served.

Items sold by weight or measure, where the quantity is not an integer and conversions apply.

Exchange rather than return. Two transactions or one, and what the record shows.

Ask a vendor to demonstrate these, not the clean sale. The answers are more diagnostic than any feature list.

What billing has to be connected to

A till that only records money is a cash register with a screen.

The transaction is the moment nearly everything else in the operation should update: stock decrements, the customer's history and balance change, the ledger moves, and the day's position shifts. If those are separate systems, someone performs the connection manually — which is the reconciliation burden described in what a business operating system actually is.

The practical test: after a sale, how many other things need updating by a person? If the answer is more than zero, the counter is generating work for someone else in the business.

Closing the day

The daily close is the most underrated part of billing software.

A good close reconciles expected cash against counted cash, surfaces the variance immediately, accounts for every non-cash tender, and produces a figure the business can act on before tomorrow begins.

A bad close is a report someone prints and files. The difference is whether a discrepancy gets investigated while anyone still remembers the day.

Our position is that every day must close clean — that operational health is measured by how quickly the day settles and how fast a problem becomes visible. It is one of three principles that shape what we ship, described in how Truffaire builds software.

What we have seen

Billing sits in most of the ten systems we have delivered, including a retail chain of more than thirty outlets and a billing and operations management system built specifically around this.

The consistent lesson is that counter software is judged by its worst moment, not its average one. A system that is pleasant at 11am and obstructive at 7pm will be worked around by 7pm, and the workaround becomes permanent because it was invented under pressure and never revisited.

This is why we test with the staff who will actually use it before launch rather than after, and redesign whatever is awkward while it is still cheap to change. The most common redesign is not adding a feature — it is removing a step.

Frequently asked questions

How important is hardware?

Less than most vendors imply, with one exception: input speed. A reliable scanner and a responsive screen matter more than the terminal's specification. Where hardware genuinely decides things is offline capability and whether the device keeps working on poor connectivity.

Can we use a tablet app instead of a proper POS?

Often yes, particularly at lower volumes. The questions are the same regardless of form factor: keystrokes per sale, offline behaviour, and whether the awkward transactions are handled.

What about GST and compliance requirements?

Non-negotiable and worth verifying directly rather than trusting a feature list. Confirm the specific formats and filing requirements your business faces, and ask to see them produced from real data.

Should billing and accounting be the same system?

They should share a record. Whether that is one application or two connected ones matters less than whether a sale reaches the ledger without anybody re-entering it.

How do we evaluate this properly?

Do not accept a scripted demo. Ask to complete your five most common transactions and your five most awkward ones, ideally on your own data, with someone from the counter operating rather than the salesperson.

Where to start

Before comparing products, document your actual transaction mix — including the awkward ones. Partial returns, split payments, overrides, weight-based items. That list is your real requirements document, and it is far more useful than a feature matrix.

Then ask three questions of any vendor: how many actions for our commonest sale, what happens when the internet drops, and show us these five awkward transactions.

A system that answers those well will survive peak hour. One that cannot will be bypassed, and the bypass will become the process.

SPEXA handles billing as one of six modules sharing a single record. If you want a read on what is actually slowing your counter, get in touch.

Originally published at truffaire.in.

This is not a business without software. It is a business running on a dozen tools that were never designed to talk to each other. And the failure is never in any single tool. The billing app works. The spreadsheet works. The failure lives in the gaps between them — every place where a number has to be copied from one system into another, every handoff where a sale is rung up but the stock count is not touched, every reconciliation that happens too late to change anything.

Those gaps are where the money leaks. Not dramatically. Quietly. A little shrinkage here, a discount that was never recorded there, a customer who was overcharged, a supplier who was paid twice. By the time the month-end numbers reveal the leak, the month is already gone.

More software is not the answer

The instinct — and the pitch of most business software — is to add another tool to the pile. A better POS. A dedicated inventory app. A CRM. Each one is genuinely good at its one job. And each one adds another seam, another export, another place for the numbers to drift out of agreement.

The result is a strange kind of progress: a business that has bought more software every year and is no more certain of its own numbers than it was before. It has more dashboards and less clarity. More features and more reconciliation.

The reframe is simple to state and hard to build. A business at this scale does not need more software. It needs one operating layer — a single live record where a sale at the counter updates the stock, the customer's history, and the ledger in the same moment. No export. No re-entry. No end-of-month reconciliation, because there is nothing to reconcile: the books were never separate from the counter in the first place.

The hard part is not the features

Anyone can list the modules. Billing. Inventory. CRM. Accounting. Dashboards. A little AI over the top. The hard part — the part that decides whether the system is used or quietly abandoned three weeks after launch — is fitting the software to how the business already works.

Every business has its own language. Its own product names, its own workflows, its own idea of what a "counter" is and how a day is supposed to close. Generic software asks the business to adapt to it: to rename its products, restructure its process, and retrain its people around the tool's assumptions. That works in a demo. It does not survive the seven-o'clock rush, when a staff member has ten seconds and a customer waiting, and the screen in front of them is asking for information the way the software wants it, not the way the business thinks.

So the real work happens before a line of code. It happens at the counter — documenting how the business actually runs, in its own terminology, and finding the bottlenecks that live in people's heads rather than in any system. The software is then configured to that reality: only the modules the business needs, arranged the way the team already thinks. It goes live outlet by outlet, alongside the existing tools, with the old data carried over, so nothing breaks on day one.

This is the principle we hold above every feature: the counter comes first. A system that is not usable by ordinary staff during the busiest hour of the day is not a good system, no matter how complete its feature list. Usability under pressure — not feature count — decides what ships.

Every day should close clean

The measure of a business's operational health is not how sophisticated its analytics are. It is how quickly the day closes and how fast a problem becomes visible. A system that folds billing, inventory, CRM, accounting, and dashboards into one layer makes that possible: the day closes automatically, the exceptions that need attention are pushed to a phone, and the month-end scramble simply stops happening — because the month was always current.

This is what SPEXA is. Not a suite of apps a business assembles and integrates and maintains. A single operating system, configured in the business's own terms, deployed across every outlet it runs, and built to be trusted at the counter under pressure.

It is also, quietly, the same discipline behind everything Truffaire builds. A crop-diagnosis platform in a Karnataka field and a business operating system at a café counter look nothing alike. But the question underneath them is identical: will this hold up in the real conditions it was built for, on the worst day, in the hands of the people who actually depend on it? That is the only test that matters. Everything else is a demo.

Originally published at truffaire.in.