Google Senior Engineer Nishant Motwani on Why the Hardest Part of Civic Tech Isn’t Building It — It’s Getting It to the People Who Need It
Photo by Matheus Bertelli on Pexels.com
The leader behind a $200 million growth program and a gaming platform launched on 10 million Sony devices spent two weeks evaluating open-source tools for social good — and found that the gap between a working prototype and a deployed product is where most civic tech quietly dies.
Most hackathon projects die the same death. Not from bad ideas or poor execution, but from a failure to solve the problem that comes after the demo: how do you get this into the hands of the people who actually need it?
Nishant Motwani has spent his career at Google solving exactly that problem — at a scale that makes the question unavoidable. As a Partnerships Manager specializing in enterprise innovation and platform partnerships, he led the Partner Growth Program that generated over $200 million in revenue from a single pilot. He pioneered a multi-view gaming solution deployed across 10 million Sony connected televisions. In both cases, the technology was the prerequisite, not the product. The product was the infrastructure that delivered it to millions of users who never thought about the engineering underneath.
When Motwani evaluated ten projects at sudo make world 2026 — a 72-hour hackathon organized by Hackathon Raptors focused on building open-source tools for social good — he brought that growth strategist’s lens to submissions that ranged from anti-scam AI agents to offline education platforms to food waste redistribution networks. The technical execution impressed him. The deployment thinking, in most cases, did not.
“There’s a pattern I see in civic tech that mirrors what I’ve seen in enterprise product development,” Motwani observes. “Teams build for the demo. They optimize for the moment when someone says ‘wow, that’s clever.’ But the question that actually determines impact is different: can this reach a million users without the founding team manually onboarding each one?”
The Offline Paradox and the Last-Mile Problem
The project Motwani scored highest in his batch was Offline-Learn by team lossy bird — a platform designed to deliver educational content to users with limited or no internet connectivity. The project finished seventh overall at 3.987/5.00 but earned Motwani’s strongest evaluation at 4.20/5.00, driven by what he identified as a rare alignment between the technical architecture and the actual deployment constraints of its target users.
“Most educational platforms assume bandwidth,” Motwani explains. “They assume a student can stream video, download resources, sync progress to the cloud. Offline-Learn starts from the opposite assumption: the user has nothing. No reliable connection. No guaranteed device continuity. Possibly no electricity for half the day. That constraint forces architectural decisions that most teams never have to make.”
The offline-first architecture resonated with Motwani’s experience shipping to constrained environments. His multi-view gaming solution for Sony required engineering for devices with fixed memory budgets, unreliable network conditions, and update cycles measured in months rather than days. “When you build for 10 million televisions, you learn very quickly that you cannot assume anything about the runtime environment,” he says. “The TV might be running firmware from two years ago. The network might drop mid-session. The user might not understand what a software update is. Offline-Learn applies that same discipline to education — and that discipline is exactly what makes something deployable versus demonstrable.”
What elevated the project beyond technical correctness was its content delivery model. Rather than requiring continuous synchronization, the platform implements a store-and-forward pattern where educational materials are pre-cached during brief connectivity windows and delivered progressively as the student works through the curriculum. “This is a growth engineering problem disguised as an education problem,” Motwani notes. “The question isn’t ‘can we build a learning platform?’ — that’s been answered a thousand times. The question is ‘can we build a learning platform that works for someone who gets thirty minutes of WiFi at a community center twice a week?’ That’s a fundamentally different engineering challenge.”
When the Product Is the Platform
NextPlate by Team BetterWorld, the competition’s third-place finisher at 4.462/5.00, presented Motwani with a civic tech project that had already crossed the threshold from prototype to platform thinking. The food waste redistribution system connects three nodes — restaurants with surplus food, NGOs coordinating distribution, and end consumers — through a logistics layer that includes real-time inventory management, route optimization, and carbon footprint tracking using the WRAP methodology.
“What struck me about NextPlate is that it’s not one product — it’s three products stitched together by a logistics backbone,” Motwani says. “You have a restaurant-facing inventory tool, an NGO-facing coordination dashboard, and a consumer-facing marketplace. Each of those products has different users, different interaction patterns, different deployment requirements. The team understood that, and their architecture reflects it.”
The multi-key Gemini API pool with exponential backoff caught Motwani’s attention as an indicator of production maturity. “That’s not a hackathon pattern. That’s a pattern you implement when you’ve thought about what happens at 10,000 concurrent requests. It tells me the team has either shipped production systems before or studied how they work. Either way, it’s a signal of scalability awareness.”
But Motwani also identified what he considers the central challenge for platforms like NextPlate: the cold-start problem across a three-sided marketplace. “You need restaurants listing surplus food before NGOs will use the coordination tools. You need NGOs on the platform before consumers see value. And you need consumer demand before restaurants bother listing anything. Every multi-sided marketplace faces this, and it kills most of them. The technology is ready. The growth strategy is the actual challenge.”
The Ghost Meals feature — where consumers can purchase meals that are donated directly to those in need — represents what Motwani calls a “growth hack embedded in the product.” “It gives consumers a reason to engage even before the local restaurant network is built out. That’s smart product thinking. It’s not just a feature — it’s a customer acquisition mechanism disguised as a social good feature.”
The Architecture of Deception at Scale
Scam_BaitAI by NinjaCodes, the competition’s second-place finisher at 4.587/5.00, demonstrated a technical ambition that Motwani recognized from his own work on systems designed to handle adversarial interactions at scale.
The tool reverses the traditional anti-scam approach: instead of blocking fraudulent communications, it deploys AI-powered personas that engage scammers in sustained conversations, wasting their time while extracting intelligence about their operations. The LangGraph-based agent orchestration manages over 30 concurrent conversations with session-based locking, hybrid machine learning detection combining TF-IDF and SVM classifiers, and anti-hallucination filtering to prevent AI personas from breaking character.
“From a platform engineering perspective, this is one of the most architecturally interesting projects in the batch,” Motwani says. “You’re running a real-time conversational AI system against adversarial counterparties who are actively trying to extract information from you. The session management alone — maintaining 30+ concurrent stateful conversations, each with its own persona, its own conversation history, its own intelligence extraction targets — is a non-trivial distributed systems problem.”
The team’s reported metrics — 87% intelligence extraction success, 12-minute average scammer engagement, 4.2 data points extracted per conversation — suggest the system has been tested beyond a sandbox environment. Motwani sees both the promise and the scaling challenge: “The metrics prove concept viability. The question is operational: how do you scale this to handle thousands of concurrent scam attempts across multiple communication channels while maintaining persona consistency and avoiding detection?”
The voice pipeline — integrating Twilio for call handling, Deepgram for speech-to-text, LLM processing for response generation, and ElevenLabs for text-to-speech — adds another layer of complexity. “You’re essentially building a real-time conversational system that has to sound human, respond naturally, and never reveal that it’s artificial — all while extracting structured intelligence from an unstructured conversation,” Motwani observes. “That’s a harder problem than most production chatbot deployments I’ve seen in enterprise contexts.”
His experience with the Partner Growth Program informs his perspective on the deployment path. “Growth isn’t just about user acquisition. It’s about building systems that get better as they scale. Every conversation Scam_BaitAI has should make the next conversation more effective — the intelligence extraction should feed back into scammer classification, the persona responses should learn from what works. If the architecture supports that feedback loop, this stops being a clever tool and becomes an intelligence platform.”
The Telegram-first deployment strategy also signals product maturity. “You deploy where your users already are,” Motwani says. “Building a standalone app for scam prevention means competing for attention with every other app on the phone. Building inside Telegram means you’re meeting users in the channel where scams actually happen. That’s the same distribution insight that drives every successful growth program — don’t build a destination, build an integration.”
The Decision Engine That Needs Its Own Decisions Made
Foresight by Decision Dynamo, the fourth-place finisher at 4.375/5.00, took a conceptual approach to civic tech that Motwani found both polished and revealing. The platform transforms abstract decision queries into structured scenario matrices with color-coded comparison cards, timeline projections, and irreversibility risk flags — making structured decision frameworks accessible to non-expert users.
“The UI is genuinely impressive,” Motwani observes. “They’ve taken something that consulting firms charge thousands of dollars for — structured scenario planning — and made it available through a clean, intuitive interface. The three-path comparison with weighted trade-offs is exactly the kind of tool that could help a first-generation college student decide between job offers, or a small business owner evaluate expansion options.”
But Motwani identifies a tension at the core of the product that mirrors a challenge he’s encountered in enterprise AI deployment: the gap between generated content and genuinely personalized analysis. “The scenarios are well-structured but tend toward generic outputs. When I tested it with a specific context — a particular city, a particular industry, a particular user constraint — the analysis didn’t visibly incorporate those specifics. It felt like the AI was filling a template rather than reasoning about my situation.”
This observation connects to a broader principle from Motwani’s platform engineering experience. “At Google, we’ve learned that AI features need to pass what I call the ‘so what’ test. The user shouldn’t be able to get the same output by pasting their question into a general-purpose chatbot. If they can, your product is a UI wrapper, not a platform. Foresight has the UI and the framework — now it needs the data layer that makes the analysis genuinely specific to each user’s context.”
The team’s decision to require users to supply their own OpenAI API key also flagged a deployment concern. “That’s a developer-friendly choice, but it’s a growth-hostile choice. Your target user — someone who needs help making a major life decision — probably doesn’t have an OpenAI API key. Probably doesn’t know what one is. You’ve built a tool for everyone but deployed it for developers only.”
When Ambition Outpaces Accessibility
CrisisCommander’s ReliefNet-AI, finishing tenth at 3.925/5.00, represented a category of submission that Motwani sees frequently in both hackathons and enterprise product development: technically ambitious systems that fail at the most basic level of user verification.
The disaster response platform integrates multi-variate climate data with a deployed Hugging Face NLP model for incident classification, implements explainable AI for decision transparency, and includes duplicate detection and low-confidence flagging — features that demonstrate genuine domain expertise in emergency management systems.
“The backend architecture is enterprise-grade,” Motwani acknowledges. “Integrating temperature, humidity, rainfall, wind speed, and population density as features alongside incident descriptions shows real technical sophistication. The explainable AI component — requiring administrators to review the model’s reasoning before approving an incident — is exactly the right design for a high-stakes emergency context.”
But the submission lacked a live demo. “In my experience launching products to millions of users, the demo is not optional — it’s the product’s first user acquisition event,” Motwani says. “You can have the most sophisticated backend in the world, but if I can’t click a link and see it work, you haven’t shipped. You’ve written code.”
This is not merely an aesthetic critique. In disaster response contexts, the consequences of inaccessibility are measured in response time, not bounce rates. “When Hurricane Katrina hit, the systems that worked were the ones that were already deployed, already tested, already accessible to the people who needed them,” Motwani says. “Nobody was installing new software during the disaster. The tools that mattered were the ones that were already on someone’s phone.”
The observation extends beyond a hackathon scoring critique into what Motwani considers a systemic pattern in civic tech development. “I’ve seen this at Google, too. Engineers build extraordinary infrastructure and then treat deployment as an afterthought. But for civic tech — where your users might be emergency responders working from a mobile phone in a disaster zone — deployment isn’t the last step. It’s the first requirement. If a disaster coordinator can’t access your system on their phone in two taps, the sophistication of your NLP model is irrelevant.”
What Growth Engineering Can Learn From Civic Tech
Across ten evaluations, Motwani identified a framework that connects his experience at Google to the specific challenges of building technology for social impact. The projects that earned his highest scores shared a common trait: they didn’t just solve a technical problem — they demonstrated awareness of the deployment environment their users actually inhabit.
“Enterprise product development often starts with the assumption that users will find you,” he explains. “You build it, launch it, run ads, optimize conversion funnels. Civic tech doesn’t have that luxury. Your users are refugees without smartphones. They’re elderly scam victims who don’t know what an app is. They’re students in regions where bandwidth is a commodity, not an assumption. The product has to go to them — they’re not coming to you.”
This inversion of the growth model has implications that extend beyond civic hackathons. As technology platforms expand into markets with infrastructure constraints — rural areas, developing economies, disaster-affected regions — the assumptions embedded in standard growth engineering become liabilities. A signup flow that requires email verification excludes users without email. An onboarding tutorial that requires video playback excludes users without bandwidth. A feature that requires real-time connectivity excludes users in exactly the situations where the product would be most valuable.
“The teams at sudo make world that built for the most constrained users were solving a harder version of the problem every platform eventually faces,” Motwani concludes. “How do you deliver value to someone who doesn’t have the infrastructure you assumed they’d have? At Google, we’re starting to ask that question at scale. These teams were asking it from day one — because their users gave them no choice.”
sudo make world 2026 was organized by Hackathon Raptors, a Community Interest Company (CIC #15557917) supporting innovation in software development. The event brought together 26 teams over 72 hours to build open-source tools for social good, evaluated by a panel of 38 judges across five weighted criteria: Impact & Vision (35%), Technical Execution (25%), Innovation (20%), Usability (15%), and Presentation (5%). Nishant Motwani served as a senior judge evaluating projects in the competition’s second evaluation batch.
