An online session should not decide whether local work exists

The customer had the project on her computer. The application still asked for a live cloud session before it would open. When the service was unavailable, the screen made locally stored work appear unavailable too. The files had not vanished, and the customer was not asking to acquire something new. Our product had placed a shared online entry point in front of several different actions. The design was convenient to explain inside the team until an interruption exposed what that convenience meant to someone trying to continue her work.

The February 2024 interruption produced ninety-six reports. Seventy-four concerned eligible projects already downloaded, while twenty-two involved files not present locally. Those two groups needed different explanations and different recovery paths. I did not want them combined into a single claim that all reported work could simply become offline. Nor did I want the absent files to obscure an unnecessary dependency affecting the seventy-four. A useful engineering decision began by understanding what the person was trying to do and what that action genuinely required.

## Separate reopening from acquiring

Improving service availability was the first proposal. It was a reasonable part of the response, because some actions did depend on the service and customers should be able to rely on it. But higher availability would not answer whether a current session belonged in front of an eligible file already held on the computer. I asked the team to examine that relationship separately. Otherwise we would spend on the shared service while leaving the product unnecessarily vulnerable to any future interruption, however brief or unusual it might be.

Reopening existing work, obtaining a new design and checking a permission for another action are related in a product but not identical. The application needed rules that respected those differences. Product colleagues and the relevant licensing owners established what could remain available and under which existing rights. The engineering work did not create a route to acquire an unpurchased design or disregard a restriction attached to a file. Removing a needless session dependency required clarity about legitimate use, not an assumption that every local file was automatically eligible for every operation.

We approved ₹48 lakh for the client changes and their review. The spending supported a narrower dependency, rather than a claim that the entire product had become offline. I wanted that description from the beginning because broad language would have created another customer expectation we could not meet. Files absent from the device still had to be obtained through the appropriate service. New transactions and other actions with a stated online requirement retained that requirement. The work concerned the specific interruption between a person and eligible material already in their possession.

The distinction also affected how we described the outage. The ninety-six reports were a recorded set of contacts, not a census of every person affected or a complete measure of commercial loss. The seventy-four and twenty-two explained the work within that set. I resisted translating them into a large revenue estimate because we did not have evidence for one. The case for the product change was practical enough without it: a dependency unrelated to the intended local action had prevented work, and we could redesign that dependency within the relevant rights.

## Make the exception useful to support

After the change, we reviewed 180 defined local-project scenarios. One hundred and seventy-four opened successfully without a current cloud session. Six involved damaged files and still required recovery. Those six mattered because a customer sees the inability to open a project, not our internal distinction between session state and file condition. The application and support process had to explain the difference accurately. It would have been misleading to report a successful offline change as though it meant every unreadable file had been repaired or every possible project was now supported.

The recovery path preserved the customer's existing copy rather than silently substitute a different version. A file can carry work the support team does not fully understand from its name or last-saved date. We wanted the customer to know which copy was being examined and what any proposed recovery would change. The detailed method belonged to the engineering and support specialists, but the product principle needed leadership support. Resolving a technical error should not make it harder for a person to understand the state of their own work.

The twenty-two original reports involving absent files remained a separate matter. Those customers needed the relevant service to become available so their content could be obtained. We handled that path after restoration rather than imply that the client change could conjure material not stored on the device. This seems obvious when written plainly, yet product announcements often compress several different conditions into one reassuring word. Offline can describe a useful capability while becoming misleading if nobody states which actions, files and permissions it covers.

I asked support colleagues to help review the explanations before the change was described as complete. They knew the questions customers asked when a project would not open and the language likely to create another misunderstanding. Their involvement was not a substitute for technical tests. It helped ensure that the tested states could be explained in the service. A product can distinguish errors internally and still leave a customer with one unhelpful message. The engineering account should therefore include both the behaviour and the practical route available when that behaviour does not produce the desired result.

## Design the dependency around the action

The broader lesson was about how dependencies enter a product. A team may build one opening flow because it is easier to maintain, because a new service needs a session or because several features are introduced together. Over time, the shared path can make the network appear essential to activities that do not inherently require it. That does not mean shared flows are always wrong. It means their consequences should be examined at the level of the customer's action, especially when a continuing service has been added around work that previously happened locally.

I would now ask earlier which part of the action depends on a remote service and why. What must be obtained? Which right needs to be established? What is already available, and what evidence supports using it? What can the product explain when one part is unavailable? These questions help the team choose an architecture with an intelligible purpose. They also help commercial colleagues understand the limits of the promise they are making. A customer does not need our implementation details, but they do need an accurate account of what they can continue doing.

For a board, this becomes a question about the relationship between a service dependency and the business obligation. Directors should not design client behaviour or decide every permission rule. They can ask whether management knows which customer activities stop during an interruption, which genuinely require the unavailable service and what alternatives have been considered. They can also ask whether resilience spending includes reducing unnecessary dependence, rather than only making the central service larger or more available. The answer may differ by action and product, which is why a single uptime figure is incomplete.

Our change did not remove every interruption or establish that all future files would behave like the test set. It gave a defined group of legitimate local actions a more appropriate path. I regard that as a worthwhile product improvement precisely because the claim is specific. The customer who has already downloaded eligible work should not have to understand our organisational preference for a common entry screen. Engineering should examine that preference before it becomes an unexplained condition on the work the product exists to support.