DEV Community: Jatin Vohra

A small calculator for checking the cost of a manual workflow

Jatin Vohra — Sun, 18 Oct 2026 06:43:43 +0000

Lumox has a small Manual Work Cost Calculator for putting a number against one repeated task before deciding whether to change it.

It is free to use, with no signup. Five inputs produce weekly hours, annual hours and an annual labour-cost baseline. The calculation happens in your browser; entered calculator values are not sent to Lumox.

A worked example

The illustrative defaults are:

10 repetitions per week
15 minutes per repetition, per person
3 people involved each time
48 working weeks per year
AUD60 loaded hourly cost

That gives 7.5 hours a week, 360 hours a year and AUD21,600 in annual labour cost. These are example assumptions, not a client result or a promised saving.

The arithmetic is deliberately visible:

annual hours = repetitions/week × minutes ÷ 60 × people × working weeks
annual labour cost = annual hours × loaded hourly cost

Count active effort, rather than the time something sits in an approval queue. If different roles spend different amounts of time or have different hourly costs, calculate them separately and add the results. Avoid counting the same effort twice.

What it does not answer

The baseline does not tell you how much work can safely disappear. Exceptions, necessary judgement, change costs and ongoing support still matter. Simplifying the process or using an existing product may be enough; custom software is one possible outcome.

Try the calculator, or use the blank workflow worksheet to collect assumptions first. Keep business figures in your own private copy.

If you try it, which assumption would you want made more explicit before using the result in a software decision?

A software handover should prove one recovery path

Jatin Vohra — Sat, 17 Oct 2026 02:16:04 +0000

Before agreeing to support an unfamiliar application, ask a practical question: can the team recover one important workflow using the handover material? A walkthrough turns missing context into specific work before an ongoing support arrangement is scoped.

Start with one ordinary business path

Choose something the organisation depends on, such as opening a dashboard and exporting an accurate report. Define the expected result, its information source and who can confirm that it is correct. Keep the walkthrough in an isolated test environment with dummy or appropriately redacted data.

A handover walkthrough

Identify the running version. Record the source revision, deployment reference and environment. A repository link alone does not show which release is actually serving users.
Check the access boundary. Identify the people permitted to investigate, deploy and restore. Document how authorised access is obtained; keep credentials out of the runbook itself.
Trace the business path. List the services and data stores needed for the chosen workflow. Include any scheduled job that must finish before the result is current.
Make failure visible. Describe what a user sees, what the monitoring shows and which evidence helps distinguish a stale result from an unavailable service. Agree who investigates the alert.
Rehearse recovery. Use an approved test environment to demonstrate the relevant rollback or restore procedure. Record the test date, version, outcome and remaining limitations. A successful file restore does not by itself prove that the business workflow works again.
Check recovery consequences. Identify work that may have occurred after the restored point. Define how it will be reconciled. Avoid blindly replaying operations that can create duplicate or irreversible effects.
Assign the next decision. Identify who can approve a rollback, pause a workflow or accept a temporary workaround. Record the escalation route and expected contact window without assuming round-the-clock coverage.
Leave usable evidence. Store a short runbook, relevant references and the unresolved items somewhere the authorised support team can find them. Have another person follow it and note where they need help.

Turn the gaps into a bounded support brief

Use this outline for a new support enquiry:

System and business owner:
Workflow that must keep working:
Observed problem and business impact:
Known version, dependencies and access owner:
Recovery evidence already available:
Unresolved risks and decisions:
Required support window:
One-off stabilisation work versus ongoing scope:

The walkthrough informs the scope; it does not establish a response-time guarantee, certification or production readiness. Agree responsibilities, included work and exclusions against the actual system.

Repository ownership and incident responsibility also need to be distinguished. GitHub's CODEOWNERS feature requests reviews for relevant changes. An operational escalation rota and authority to restore service need their own agreement.

From Lumox Technologies

Lumox is a Canberra-based software engineering company. If you are evaluating support for a business application, send a non-confidential outline of what should work better through Lumox’s enquiry form. Scope and availability would be discussed against your actual requirements.

For practical examples of software handoffs and integrations, follow Lumox on LinkedIn.

An Integration Is Not Done Until the Failure Has an Owner

Jatin Vohra — Mon, 07 Sep 2026 05:25:56 +0000

Most integration diagrams end at the arrow.

System A sends a request. System B receives it. A neat line connects the two boxes, and the design appears complete.

The difficult work begins when nobody can answer a more ordinary question: what happens if the arrow only half works?

A timeout does not tell you that nothing happened. The receiving system may have committed the change and lost the response. A retry may be correct, or it may create a duplicate. A green HTTP response may confirm that a message entered a queue, not that the business outcome completed.

This is where many technically functional integrations turn into operational debt. The happy path is automated. The uncertainty is handed to a person who was never named in the design.

Model the handoff as a state transition

Treat the integration as a business state transition, not merely an API call.

For each handoff, write down five things:

the authoritative record before the handoff;
the event or command being sent;
the evidence that proves the receiving system accepted responsibility;
the evidence that proves the business outcome completed; and
the owner of every state between those two confirmations.

Suppose a website sends an approved order to an operations system. A 202 Accepted response may prove receipt. It does not prove that stock was allocated, the order was scheduled, or a human exception was resolved.

Those are different states and should be visible as different states.

approved -> submitted -> accepted -> processing -> completed
                         |             |
                         v             v
                      rejected      exception

The names will differ by system. The important point is that submitted and completed are not collapsed into a single boolean called synced.

Give every request a stable identity

Retries are unavoidable. Duplicate effects are not.

Generate an idempotency key or stable business-event identifier before the first attempt and reuse it for every retry of the same intended action. Store it with the local record. The receiver should either return the original result or reject conflicting reuse.

POST /orders
Idempotency-Key: order_8421_submit_v1

The key must identify the intention, not the network attempt. Creating a fresh key after each timeout defeats the protection.

There is also a less obvious requirement: operators need to be able to search by that identifier across logs, queues and the receiving system. A technically idempotent request that cannot be traced still creates expensive investigation work.

Separate transport success from business success

An integration usually has at least three kinds of outcome:

Outcome	What it means	Typical next action
Transport failure	No reliable acknowledgement was received	Retry with the same identity
Accepted but incomplete	The receiver owns the work, but the business result is pending	Observe, poll or await an event
Business rejection	The request was understood but cannot proceed	Route to a named decision owner

These outcomes should not share one generic catch block.

A retry policy belongs to transport uncertainty. A business rejection usually needs different data, approval, or a corrected decision. Replaying it without changing anything merely produces more noise.

Make reconciliation a first-class path

Even carefully designed flows drift. Events arrive out of order. Credentials expire. An operator corrects a record directly in one system. A deployment interrupts a consumer at the wrong moment.

Build reconciliation before production, not after the first unexplained discrepancy.

A useful reconciliation job compares authoritative identifiers and states, then emits a small set of actionable differences:

present in the source but missing from the receiver;
accepted but not completed inside the expected window;
completed remotely but not reflected locally;
rejected without an assigned owner; and
conflicting versions that cannot be resolved automatically.

The output should be a work queue with ownership, timestamps and evidence. It should not be a spreadsheet someone has to remember to download.

Design the manual path as carefully as the automated one

Human intervention is not automatically a failure of automation. Unplanned human intervention is.

For each exception, define:

who is allowed to decide;
what evidence they see;
which actions are safe;
whether an action can be reversed;
how the decision is recorded; and
how the workflow resumes.

Avoid a generic retry button that repeats an unknown operation. Give the operator the current state, the last confirmed transition and the effect of the next action.

If the system cannot explain what it knows, what it does not know and what will happen next, the operator is being asked to guess.

Test ambiguity, not only errors

Most integration tests cover clear success and clear failure. Production incidents often live between them.

Add tests for:

the receiver commits the change, then the response is lost;
the same event is delivered twice;
events arrive out of order;
the sender restarts after dispatch but before recording acknowledgement;
a downstream operation remains pending beyond its expected window;
a user changes the source record while processing is underway; and
reconciliation runs while a retry is in flight.

The expected result is not always that the request succeeds. It may be that the system enters an explicit uncertain state, prevents a conflicting action and assigns the case to the right owner.

A small review before shipping

Before calling an integration complete, ask:

Can we distinguish receipt from business completion?
Can the same intention be retried without duplicating its effect?
Can an operator trace one handoff across every component?
Does every rejection, timeout and stale state have an owner?
Can the systems reconcile without relying on memory?
Does the manual path preserve an audit trail?

If any answer is vague, the missing work is not polish. It is part of the system boundary.

Lumox uses the same questions when assessing whether a connected system is ready for production. The broader enterprise software readiness checklist covers ownership, information boundaries, assurance, recovery and handover.

The arrow on the diagram is the easy part. The real integration is the agreement about who owns the uncertainty around it.