Coding as Sikh Seva: A Practical Discipline of Digital Care

You know how to build software. A gurdwara, Sikh charity, community organiser, or neighbour needs technical help. The difficult question is not whether your skills are useful. It is whether using them in this situation can honestly be called seva.

It can, but the label does not come from the programming language, an unpaid invoice, or a charitable logo. Coding becomes seva when it answers a real need, preserves the dignity and agency of the people served, and leaves them with less burden rather than a new dependence on the developer.

Test the work before calling it seva

The question of whether coding can be seva opens a more demanding question: what must be true of the work, the method, and the motive? In Sikh life, seva is practical service shaped by humility. It is not a spiritual title we attach to anything that looks generous.

Use four tests before accepting or proposing a project:

• Need: Can the people affected describe the burden in their own words? A developer’s interesting idea is not yet a community need.
• Consent: Have the intended users asked for this solution, or at least helped choose it? Doing something to a community is different from serving with it.
• Conduct: Are you listening, protecting private information, sharing control, and accepting correction? Good intentions do not excuse careless methods.
• Consequence: Will the work save effort, widen access, reduce confusion, or remove another concrete obstacle? If nobody can name the change, the project is still a hypothesis.

Payment does not settle the question. An unpaid vanity project can fail every test. A paid professional can still work with honesty, restraint, and concern for the common good. Keep the arrangements clear, however. If some work is donated and some is contracted, say which is which. Ambiguity about money, ownership, or future support eventually becomes a burden for the very people you meant to help.

Let the sangat define the problem

Technical volunteers often arrive with a solution already in mind: an app, a new website, an automated registration system, or a database. Begin one step earlier. Ask what people are trying to do, what stops them, and how they manage now.

A disciplined discovery conversation can be short. Ask:

• Who experiences the problem directly?
• What task are they unable to complete, or what repeated work consumes their time?
• What is the current workaround?
• Who must be able to update, approve, or correct the information?
• What would a satisfactory improvement look like in ordinary language?

Then write the outcome in one sentence without technical terminology. For example: “A volunteer should be able to update weekly programme information without contacting a developer.” That sentence gives you a better design boundary than “build a modern community platform.” It tells you who needs control and what the system must make easy.

Sometimes the right answer is less code. If a well-configured page, form, shared calendar, or written procedure solves the problem, a custom application may add cost without adding service. Restraint matters because every new system also creates passwords, updates, training, hosting decisions, and future failures.

Write a one-page seva brief

Before opening a repository, record the following:

• People served: Name the actual users rather than a vague “community.”
• Burden removed: Identify the task, delay, exclusion, or confusion the work should reduce.
• Smallest useful change: Define what can help without creating an unnecessary platform.
• Decision owner: Name the person or group authorised to approve content, access, and changes.
• Long-term steward: Decide who will hold credentials, receive documentation, and arrange maintenance after you step away.

If you cannot fill in the last two lines, pause. The project does not yet have enough community ownership to be safe.

Treat craftsmanship as care for the next person

Working software is not necessarily serviceable software. A tool can function perfectly on launch day and still become a liability when only its creator knows how it works. In digital seva, maintainability is part of the offering.

Your definition of done should include:

• Community-controlled access: The organisation, not one volunteer’s personal account, should control essential domains, hosting, repositories, and administrative credentials.
• Plain documentation: Explain setup, routine updates, backups, restoration, deployment, and the route for getting help. Write for the next capable volunteer, not for a copy of yourself.
• Accessible use: Check whether people can navigate the service by keyboard, enlarge text, understand labels, and use it on the devices and connections they actually have.
• Minimal data collection: Ask only for information the service genuinely needs. Every unnecessary field creates another fact that can be exposed, misused, or left behind.
• Limited permissions: Give each account only the access required for its role. Convenience is not a good reason to make everyone an administrator.
• A handover: Walk another person through the ordinary tasks and let that person perform them while you are still available to correct gaps.

Be especially cautious when a proposed system would hold identity documents or information about health, finances, immigration, children, or people facing hostility. A volunteer-built database is not harmless merely because its purpose is charitable. If the organisation lacks clear authority, security practices, and a responsible data steward, do not collect the information. Use a lower-risk process or obtain qualified legal and security guidance first.

The quiet work often carries the greatest value: correcting instructions, simplifying a form, fixing an inaccessible menu, removing abandoned accounts, documenting a deployment, or teaching someone to make updates independently. None of it produces a dramatic launch. All of it reduces another person’s dependence.

Guard against ego, dependency, and burnout

Technical competence creates power. You may control the vocabulary, estimate, architecture, passwords, and pace of delivery. Seva asks you to notice that imbalance and deliberately return agency to the people affected.

Watch for warning signs:

• You choose tools for portfolio value when a simpler option would serve users better.
• You dismiss disagreement as resistance from “nontechnical” people.
• You spend more energy announcing the launch than arranging maintenance.
• You keep credentials or knowledge to remain indispensable.
• You treat feedback as ingratitude because the work was donated.

The correction is practical. Show unfinished work early. Explain trade-offs without using jargon as leverage. Give authorised community members access from the beginning. Invite someone else to review the code and the user experience. Make it easy for the organisation to replace your solution or your services.

Boundaries matter too. Do not promise permanent, immediate support because the work feels sacred. State what you can maintain, how quickly you normally respond, what counts as an emergency, and when your commitment ends. A limited promise that you keep serves the community better than limitless availability that collapses without warning.

If you have little time, choose a complete unit of service: an accessibility review with fixes, a simplified registration flow, a security cleanup, a documentation package, or a training session with handover. Small does not mean spiritually lesser. A contained task can be owned, verified, and completed without leaving an unfinished system behind.

Key takeaways

• Coding can be seva when it responds to a real need, respects consent, protects dignity, and produces a concrete benefit for others.
• Start with the community’s task and current burden, not with your preferred technology.
• Choose the smallest useful intervention. Sometimes configuration, documentation, or training is better than custom code.
• Treat accessibility, privacy, maintenance, shared control, and handover as core requirements.
• Do not use donated labour to justify unclear ownership, careless data collection, or perpetual dependence on one developer.
• Set an honest boundary around your availability, then leave the community able to continue without you.

Choose one burden you can remove completely. Speak to the people carrying it, write the one-page brief, and agree on ownership before you build. The code may be sophisticated or ordinary. Its value as seva will be visible in what becomes easier for others after you are gone.

References

• SikhNet – News – Can Coding Be Seva?