A daily earning of about Rs350, roughly three days to produce a saree and a selling price of Rs15,000–20,000 are different kinds of numbers. They were part of the concern I was trying to understand through Kindred Hands. Subtracting one from another would not explain the whole route: materials, finance, selling work and the people receiving the money matter too.
The purpose was to help weavers and handicraft producers reach customers more directly. A partner NGO's commitment to redirect purchases for about 5,000 garments was encouraging, but a commitment and garments already ordered, delivered and paid for are different stages. I care about the human purpose of the work more than a feature list. That makes it more important to be precise about who might benefit and how, rather than let the purpose make a technical result sound larger.
I want to look again at what joining the service involves. Who explains it? Who helps with the first product? Who can answer a question once the page exists? A person may have the information needed for a listing without wanting to manage an unfamiliar set of screens. That does not mean they are uninterested in selling. It may mean the route asks them to do a task that somebody else could help with.
A situation helps me see the difference. In this case, a supplier is willing to share product details but needs help entering them. If the platform only makes sense for someone who can do every step independently, the willingness to participate has not become a usable route. Helping with entry could be part of the arrangement, as long as the supplier still understands and agrees to the information.
The details of an order need the same attention. A buyer should understand what they are requesting and what happens next. The person supplying the product should know what is expected of them. The person managing the site should know where help is needed. A process can involve several people without being confusing, but only if their responsibilities are understandable.
There’s another question I don’t want the software story to make disappear: who benefits when a product sells? The person preparing threads, the person weaving and the person supplying the finished saree may have different roles. A better receipt for the seller does not tell me what each worker was paid. I should not borrow the scale of a social problem to make a technical outcome sound larger than the evidence shows.
That’s why the distinction between a working setup and an improvement in livelihoods matters. The setup can make a task possible or easier to organise. Actual benefits need their own observations and records. What happened to the sale, the costs, the payment and the people involved? I can’t answer those questions from a screenshot of the site, even if the screenshot looks convincing.
I’m also thinking about whose feedback I need. The person who manages the software can tell me whether it is easy to maintain. A person entering product details can tell me whether a step is confusing. A supplier can tell me whether the information and responsibilities make sense. Those are different perspectives. Asking only the person most comfortable with the website would leave part of the experience out.
The challenge is to listen without turning every comment into a new feature immediately. A confusing step might need clearer wording or a different arrangement of help. It might need a software change. I should understand the difficulty before deciding which kind of solution it asks for. Otherwise I could keep adding things while the original obstacle stays in place.
This connects back to the early cost questions too. A setup that is affordable to obtain but difficult for people to use can create continuing support work. A setup with fewer features may still be useful if the important tasks are clear. The technical and human parts keep returning to each other. I can’t finish one completely and then add the other at the end as a paragraph about purpose.
I don’t need to make the software seem unimportant to recognise its limits. Getting the pieces connected takes real effort, and I care about doing that well. The limit simply tells me what the result means. I can describe the technical work accurately and still leave room for the larger work of participation, trust and understanding whether people actually benefit.
There’s no need to turn every conversation into evidence for the result I hope for. A person being willing to try something is useful information. It’s not the same as a completed sale or a lasting improvement. I want those stages to stay distinct so that listening remains a way to learn, rather than a way to collect encouraging sentences for the final story.
What I want the next stage to keep visible is the person whose task should become easier. If that person cannot understand the route, the feature list has not answered the important question. The setup matters because of what it helps them do. Coming back to that thought makes the choices feel less like a collection of software decisions and more like one project again.