Sanket Pixel Technologies
Sanket Pixel Technologies
Technology • Innovation • Research
Technology • Innovation • Research
Volume 1, Issue 1 — Winter 2026 (October–December) Publisher: Sanket Pixel Technologies Website: https://sites.google.com/view/susankarkarmakar ISSN: [Applied For] Frequency: Quarterly Language: English
Publisher: Sanket Pixel Technologies, West Bengal, India Editor-in-Chief: Susankar Karmakar Editorial Board: [Add names, affiliations, and short bios here before ISSN submission — the ISSN Centre requires real, verifiable editorial board members, ideally including at least a few senior/established professionals alongside the founding editor.] Frequency: Quarterly (4 issues per year) Copyright: © 2026 Sanket Pixel Technologies. Published under a Creative Commons Attribution-NonCommercial 4.0 International License (CC BY-NC 4.0) — articles may be shared and cited with attribution, for non-commercial use. Contact: susankarkarmakar-pixel (GitHub) · https://sites.google.com/view/susankarkarmakar
Editorial — Two Desks, One Discipline
Technology Article — Offline-First Design for Low-Bandwidth India
Technology Article — Voice-First AI and the Case for Designing Down
Case Study — The Gazole Scheme Proposal Workflow
Public Technology & Governance — Low-Code as a Force Multiplier in Block Administration
Technology Review — Electron and React for Public-Interest Desktop Tools
Author Information
Call for Papers — Issue 2
There are two desks in this editor's working life. At one, files move on paper and on portals — welfare scheme disbursals, electoral rolls, grievance registers, the daily grammar of block-level governance in Gazole, Malda District, West Bengal. At the other, the same day's evening hours go into a text editor, building small, unglamorous tools: a note-taking app, a PDF editor, a scheme-tracking form, a browser experiment.
Sanket Technology Review exists because these two desks turn out to share a discipline. Public administration and software engineering are both, at bottom, exercises in designing systems that ordinary people can trust to work the same way every time — whether that system is a grievance redressal workflow or a mobile form for logging an infrastructure proposal. The failure modes are similar too: overcomplicated interfaces, undocumented assumptions, and tools built for the demo rather than the daily user.
This journal is an attempt to write down what that overlap looks like in practice — not as abstract theory, but as case studies drawn from real, small-scale builds; as technical notes on the design choices that matter when bandwidth, literacy, and device access can't be assumed; and as an open invitation to others doing similar work in public systems and independent software to contribute their own record of what worked and what didn't.
Issue 1 draws entirely on a working portfolio of open-source and departmental tools built over the past year — offline-first apps, a voice-first assistant for senior citizens, and a Google Apps Script system now in use inside a block administration office. None of it is presented as a finished answer. It is a field notebook, made public.
— Editor-in-Chief
A large share of software written for the Indian market still assumes a stable, always-on connection — a reasonable assumption in a metro office, a poor one almost everywhere else. Two projects in this portfolio, Sanket-Notes (a Dart-based note-taking app) and Sanket-PDF-Studio (an Electron/React/TypeScript PDF viewer and editor), were both built around the opposite assumption: connectivity is the exception to design for, not the default to rely on.
Three design commitments recur across both:
1. Local-first storage as the source of truth. The device's own storage — not a remote server — holds the canonical copy of a user's data. Sync, when it happens, is an enhancement layered on top, not a precondition for the app to function. This single decision eliminates an entire category of failure: the spinner that never resolves because a request timed out on a 2G connection in a rural block.
2. Sync as reconciliation, not dependency. Where sync exists, it is designed as an eventual, conflict-tolerant reconciliation step rather than a blocking call. The user should never be staring at a loading screen because the network is slow; the app should be usable now, and consistent later.
3. Editing and viewing must work fully offline. For a document tool like Sanket-PDF-Studio, this means the entire render-edit-save cycle happens locally. Offline is not a degraded mode with missing features — it is the primary mode, with connectivity as the optional extra.
None of this is a novel discovery — offline-first is a well-established pattern in mobile and desktop engineering. What is worth stating plainly, though, is how rarely it gets applied to tools meant for Indian government or semi-urban contexts, where the gap between "works in the office" and "works in the field" is often exactly a connectivity gap. Building offline-first by default, rather than retrofitting it later, is one of the cheapest reliability investments a team building for this market can make.
Sanket-Sneho is a voice-first, AI-powered application built specifically for senior citizens in India — a demographic that mainstream consumer software routinely designs around rather than for. Typed interfaces assume comfort with a keyboard; multi-step menus assume patience with navigation; English-first UI assumes a level of literacy and language exposure that cannot be taken for granted across an ageing Indian population.
Designing a voice-first assistant for this group means designing down deliberately, in ways that run counter to most consumer-app conventions:
Fewer options presented at once, rather than more. A senior user benefits from a small number of clear, spoken choices far more than from a feature-rich menu.
Forgiving input handling. Speech recognition for older voices, regional accents, and slower speech patterns needs wider tolerance than a system tuned only on younger, urban voice samples.
Redundant confirmation, not redundant friction. Voice interfaces succeed or fail on trust — a senior user needs to hear back what the system understood before an action is taken, without that confirmation feeling like an interrogation.
Regional language as a first-class citizen, not an afterthought. For meaningful reach in India, language support cannot be an English core with translations bolted on.
The broader argument this project makes is a governance one as much as a technical one: digital inclusion for senior citizens will not arrive through simplified versions of youth-oriented apps. It requires purpose-built design, starting from the constraints of the user rather than the convenience of the platform.
Context. Gazole Block's infrastructure scheme proposals — the record of what gets proposed, where, and under what scheme — were tracked in a way that made retrieval and verification slower than it needed to be. The Gazole Block Scheme Proposal App was built to close that gap using tools already available to a block office: Google Apps Script and Google Sheets, with no new infrastructure procurement required.
Design problem. A proposal is tied to a specific Gram Panchayat (GP), and within that GP, to a specific Mouza with its own J.L. Number — a three-level dependency that is easy to get wrong with free-text entry, and a common source of downstream data-cleaning work.
Solution. The form was restructured as a cascading selection: choosing a GP filters the available Mouza list; choosing a Mouza auto-fills the correct J.L. Number from a maintained reference sheet ("GP Wise Mouza List"). This removes an entire class of manual-entry error at the point of data capture rather than trying to catch it afterward.
Review-before-submit step. Rather than submitting directly, the form includes a "Save & Review" stage: a preview of the entered record before final submission, followed by a success confirmation showing the generated record ID. This small addition — standard in consumer e-commerce checkouts, rare in departmental forms — meaningfully reduces the volume of "please correct my entry" follow-up work.
Access model. Any authenticated user can view and edit records, with a "My Records" view that is searchable and filterable by GP — useful in a block with fifteen Gram Panchayats, where a flat, unfiltered list quickly becomes unusable.
Takeaway. None of the individual techniques here — cascading dropdowns, a review step, filterable views — are advanced. What made the difference was applying them to a genuinely low-code, zero-procurement stack that a block office can maintain without external vendor dependency. For resource-constrained public offices, the ceiling on "good enough" software is often set by what a small, internal effort can sustain, not by what is technically best-in-class.
A recurring theme in this issue's case study is the deliberate choice of low-code tools — Google Apps Script and Sheets — over conventional custom-built software stacks. This is worth stating as a governance position, not just a technical convenience.
Block-level offices in India typically do not have a dedicated software development budget, an IT team, or the procurement runway to commission and maintain bespoke systems. The realistic choice is rarely "custom software versus low-code tools" — it is "low-code tools built in-house versus no digital tooling at all." Judged against that real alternative, a well-designed Apps Script system that removes a genuine bottleneck is a meaningful governance improvement, even though it will not resemble enterprise software in scale or architecture.
This has a practical implication for anyone in public administration considering similar tools: the constraint is not technology, it is time and in-house skill. The tool used in this issue's case study is free, requires no server infrastructure, and can be maintained by one person alongside a full-time administrative role. The bottleneck to more of this kind of tooling appearing across India's block offices is not availability — it is awareness that officials can build it themselves, without waiting for a vendor contract.
Two projects in this portfolio — Probaho Browser, a lightweight custom web browser, and Sanket-Desktop-Assistant — are built on the Electron + React (with TypeScript) stack, a combination that has become close to a default choice for cross-platform desktop tools built by small or solo teams.
What the stack gets right for this use case. Electron lets a single codebase ship as a native-feeling Windows, Linux, or macOS application without maintaining separate platform-specific code paths — valuable when the entire engineering team is one person building alongside a full-time job. React's component model keeps UI logic manageable as an app grows past its initial prototype, and TypeScript's type checking catches a meaningful share of bugs before they reach a user, which matters disproportionately when there is no dedicated QA process to catch them later.
What it costs. Electron apps are heavier than native equivalents — more memory, larger install size — a real trade-off for users on older or lower-spec hardware, which is not a rare case in the intended user base for tools like these. The honest assessment is that Electron is the right choice for getting a genuinely useful cross-platform tool built and shipped by a small team, and the wrong choice if minimal resource footprint is the primary design constraint.
Verdict. For public-interest and independent developer tooling — where the realistic alternative is often no tool at all rather than a leaner native one — Electron plus React remains a defensible, pragmatic choice. It optimizes for the actual bottleneck (one developer's time) rather than for a resource constraint (device performance) that, while real, is secondary to the tool existing in the first place.
Susankar Karmakar is a government official serving in block administration at the Block Development Office (BDO), Gazole Block, Malda District, West Bengal, India, with responsibilities spanning welfare scheme administration, electoral management, and grievance redressal across Gazole's fifteen Gram Panchayats. Alongside this administrative role, he is an independent software developer maintaining more than a dozen open-source and departmental projects — including Probaho Browser, Sanket-Notes, Sanket-Desktop-Assistant, Sanket-Sneho, Sanket-Setu-Alert, and Sanket-PDF-Studio — and a prolific independent author with published nonfiction and fiction works.
GitHub: github.com/susankarkarmakar-pixel Website: sites.google.com/view/susankarkarmakar
Sanket Technology Review invites submissions for its next issue on the following themes:
Digital governance and e-governance case studies from India and comparable contexts
Low-code and no-code tooling in resource-constrained public administration
AI and machine learning applications for public service delivery
Cybersecurity and digital safety in citizen-facing government systems
Data science and analytics for welfare scheme monitoring
Submission format: Research articles (1,500–3,000 words with abstract and keywords), technology/case-study articles (1,000–2,000 words), or short technology reviews (500–1,000 words). Contact: [add submission email once the website is live] Deadline: [set based on your quarterly schedule]
This is a working draft for Issue 1. The license and issue date below have been set as defaults (CC BY-NC 4.0; Winter 2026) — change either if you'd prefer something else. Before publishing and submitting for ISSN, you still need to: (1) fill in real Editorial Board members and their affiliations, and (2) verify each project's current description matches its GitHub repository at the time of publishing.