DEV Community: Puneet Khandelwal

Scaling Civic Tech on a Budget: Lessons from the Trench

Puneet Khandelwal — Fri, 04 Sep 2026 09:29:02 +0000

When a municipal server goes down during a public comment period, citizens don't care about your elegant microservices architecture. They care that their government went dark. Building civic technology taught me a hard truth. We often over-engineer solutions for problems that just need simple, robust engineering.

Most civic tech projects start with high energy and low budgets. You grab a popular cloud framework, spin up managed databases, and wire up third-party identity providers. Then reality hits. The grant money runs out, volunteer developers move on, and the monthly hosting bill arrives. A platform meant to serve a local community becomes financially unsustainable. The code works, but the economics fail.

Scaling on a budget demands a return to boring technology. When my team took over a public notice mapping tool used by local neighborhood groups, our first move wasn't adding features. We cut costs and complexity. We migrated the monolithic node application to a compiled Go binary running on a single virtual private server. We replaced the managed search cluster with SQLite and full-text search extensions. We eliminated every paid SaaS dependency we could find.

The result ran counter to modern development culture. The application became faster, hosting dropped to a flat $5 monthly fee, and maintenance became manageable for a rotating roster of civic-minded developers. Removing layers of abstraction made the codebase accessible to volunteers who don't have weeks to learn proprietary platform quirks.

Civic infrastructure must outlive its creators. If your deployment pipeline requires twenty secrets managed across three paid dashboards, it's too fragile for community stewardship. We need to write software that can be audited by a single tired volunteer on a weeknight and deployed with a single shell script.

Let's measure our success not by how many cloud services we consume, but by how easily a small community can keep the lights on when nobody is watching.

Cutting Through the PR Hype: What Real AI Integration Looks Like

Puneet Khandelwal — Thu, 03 Sep 2026 09:21:49 +0000

Most software engineering teams treat language models like expensive text generators stuck in a browser tab. They build a sleek chat sidebar, wire up an API key, and call it an integration. Then production hits, latency spikes, and users find out the bot hallucinated a fake discount code. We spend years shipping flashy wrappers while ignoring the boring engineering required to make models behave inside a codebase.

Real integration isn't a conversational companion guessing what users want. It's a deterministic pipeline where an LLM acts as a glorified function mapper or a fuzzy search engine. If you build a SaaS product, your core architecture shouldn't depend on open-ended text generation for critical paths. Isolate the model behind strict schema validation boundaries. Force the output into structured JSON, check it against a strict schema, and fail loudly if the model deviates by a single token.

Take text-to-SQL workflows. The amateur approach sends the user prompt straight to the model, crosses fingers, and executes whatever query comes back against the production database. The professional approach uses the model strictly to translate natural language into an abstract syntax tree, runs that tree through a static analyzer, and applies explicit permission guards before a single byte touches storage. Here's a small, defensive parsing layer in Python:

import json
from pydantic import BaseModel, ValidationError

class QueryIntent(BaseModel):
 action: str
 target_table: str
 filters: dict

def parse_user_prompt(raw_llm_output: str) -> QueryIntent:
 try:
 data = json.loads(raw_llm_output)
 return QueryIntent(**data)
 except (json.JSONDecodeError, ValidationError) as e:
 raise ValueError(f"Model failed schema compliance: {e}")

Build this way, and the model stops being a magical oracle. It becomes just another flaky third-party service, like an unreliable payment gateway or a slow DNS lookup. Write retry loops, cache aggressively, and assume the output is hostile until proven otherwise. Developer tools should enforce this mindset out of the box instead of encouraging prompt engineering hacks that break the moment the provider updates their weights.

The real value in machine learning integration isn't in marketing copy or chatbot templates. It lives in the unglamorous plumbing of state management, fallback logic, and defensive programming. Stop marveling at what these systems can say. Start engineering strictly around what they can safely do.

Why storing user data securely is an act of digital self-care

Puneet Khandelwal — Tue, 01 Sep 2026 18:43:10 +0000

Most developers spend hours optimizing database queries, yet treat user data security as an afterthought. We obsess over milliseconds while leaving encryption keys exposed in plain text configuration files. I learned the hard way that protecting sensitive user data is not just a compliance checkbox. It saves you from late night panic attacks.

When we build applications for wellness, lifestyle, or personal tracking, users trust us with their most vulnerable moments. They log sleep cycles, dietary struggles, fitness goals, and private reflections. If that database leaks, the damage goes far beyond a broken business model. It breaches a deeply personal trust. Early in my career, I deployed an analytics feature without properly sanitizing or hashing incoming telemetry payloads. Discovering a misconfigured endpoint three days later ruined my entire weekend. The lingering anxiety of wondering if user records were compromised taught me a permanent lesson about defensive architecture.

Good security starts with treating sensitive fields as radioactive waste. Do not log them, do not cache them carelessly, and do not store them in plaintext. If you handle sensitive user information, implement envelope encryption at the application layer before it ever hits the disk. Here is a simple mental model I use during code reviews. If a database dump leaks tomorrow on a public forum, would I sleep soundly knowing the data is useless without keys stored in a completely separate vault system? If the answer is no, the code does not ship.

from cryptography.fernet import Fernet

class SecureVault:
 def __init__(self, master_key: bytes):
 self.cipher = Fernet(master_key)

 def encrypt_sensitive_note(self, note: str) -> bytes:
 return self.cipher.encrypt(note.encode())

 def decrypt_sensitive_note(self, encrypted_note: bytes) -> str:
 return self.cipher.decrypt(encrypted_note).decode()

This snippet takes two minutes to write, but it forces a mindset shift. By keeping encryption logic tightly scoped, you protect both your users and your own peace of mind. Writing clean code that respects data boundaries lets you close your laptop at five o'clock without that nagging dread in the back of your mind.

How to Hide Your Living Room Router Without Drilling Holes

Puneet Khandelwal — Tue, 01 Sep 2026 18:21:03 +0000

That flashing plastic box next to your TV is an eyesore. If you rent, the temptation to shove it inside a metal filing cabinet or behind a stack of books is high. Doing that wrecks your ping, drops packets, and bakes your networking gear.

Radio frequency signals hate interference. Thick walls, heavy furniture, and metal enclosures choke wireless range. Instead of treating your router like trash to be buried, treat it like a placement puzzle with an engineering workaround.

The easiest zero-drill win is the woven basket trick. Grab a shallow, open-weave wicker basket and stick your router inside on a high shelf. The gaps let air circulate so your hardware stays cool, and the texture tricks the eye into seeing decor.

If you want wall-mounting without breaking your lease, heavy-duty hook-and-loop strips or industrial mounting tape work on smooth drywall. Attach a lightweight plastic shelf using renter-safe adhesives, and place the router high up to maximize signal coverage. High placement beats low placement because Wi-Fi signals radiate downward and outward.

Another option is stacking hollow decorative books on your media console. Gut a few old hardcovers by removing the pages, cut a small notch in the spine for the power and ethernet cords, and slide the router inside. It looks like a literary display while keeping your gear out of sight.

Before you finalize any spot, run a speed test on your phone to check your throughput. Balancing clean aesthetics with reliable bandwidth takes a bit of testing.

Closing the Loop on Civic Tech

Puneet Khandelwal — Mon, 31 Aug 2026 16:16:25 +0000

When a municipal app quietly drops a reported pothole into a database, the citizen loses trust long before the asphalt cracks. We write the ingestion scripts. We optimize the database queries. But we rarely build the mechanism that tells the user their input actually moved a human being to action.

Building software for municipal governments exposes a harsh engineering truth. Most civic projects fail because the feedback loop is closed off from the public, not because the code runs slow. A resident submits a report via a clean frontend form. The payload hits an API gateway. A database record increments. From an engineer's perspective, the pipeline succeeded. From the citizen's perspective, the report vanished into a black hole.

To fix this, we need to treat transparency as a core architectural constraint instead of a nice-to-have feature ticket tacked onto the end of a sprint. If a state change occurs in the backend, the user who triggered it deserves a verifiable trace. That means moving past generic confirmation screens. We have to design event-driven notifications mapping directly to real-world municipal workflows.

Look at a simple webhook listener architecture built to update citizens on local infrastructure tickets. When an inspector flips a status flag inside the municipal internal system, that database mutation triggers an event. Instead of swallowing the event inside a closed dashboard, we expose a public audit log.

// Simplified event emitter for public ticket status updates
app.post('/api/v1/tickets/:id/status', verifyInspectorAuth, async (req, res) => {
 const { id } = req.params;
 const { newStatus, publicNote } = req.body;

 const updatedTicket = await db.tickets.update({
 where: { id },
 data: { status: newStatus, notes: publicNote, updatedAt: new Date() }
 });

 // Emit to public event stream for citizen transparency
 await eventBus.publish('ticket.status.changed', {
 ticketId: id,
 status: newStatus,
 timestamp: updatedTicket.updatedAt
 });

 return res.json({ success: true, data: updatedTicket });
});

Code like this forces accountability into the open. Municipal workers act differently when their status updates instantly show up on a public ledger, shifting the incentive to clear backlogs. The tech stops acting as a shield for bureaucratic delay and starts acting as a mirror for public efficiency.

We can't code our way out of bad governance, but we can stop building systems that hide it. When we write civic software, uptime and request throughput shouldn't be our primary metrics. The real metric is whether the citizen feels heard by the city they help fund.

Stop Building Microservices Unless You Run a Monopolistic Tech Giant

Puneet Khandelwal — Sun, 30 Aug 2026 15:36:43 +0000

We love distributed systems because they make us feel like enterprise architects, even when we are building CRUD apps for three hundred daily active users.

Every time a junior engineer suggests splitting our monolith into a dozen microservices, they talk about fault tolerance and independent deployments. What they actually build is a distributed monolith with network latency, asynchronous race conditions, and a deployment pipeline that requires three people and a ritual sacrifice to update a button color.

Service-oriented architecture is a solution to a very specific organizational problem. That problem is having thousands of engineers working in the same codebase, stepping on each other's toes, and grinding feature velocity to zero due to merge conflicts. If your team fits in a single Slack channel, you don't have an organizational scaling problem. You have a code organization problem, and microservices won't save you from bad modularity.

Take authentication. In a monolithic SaaS application, checking a user session is a function call. It accesses shared memory, executes in microseconds, and fails gracefully because the database connection is right there. The moment you move to services, that single function call transforms into an HTTP request or a gRPC stub over a private network. Now you have to worry about timeouts, circuit breakers, retry logic, and distributed tracing just to figure out who is clicking your dashboard.

# What we think we are building
class OrderService:
 def create_order(self, cart_id):
 user = auth_client.get_user_by_cart(cart_id)
 inventory = inventory_client.reserve(cart_id)
 return database.commit(user, inventory)

# What we actually have to write to handle network partitions
class RobustOrderService:
 def create_order(self, cart_id, retry_count=3):
 try:
 user = self._call_auth_with_timeout(cart_id)
 except NetworkTimeout:
 if retry_count > 0:
 return self.create_order(cart_id, retry_count - 1)
 raise DistributedSystemFailure("Auth service is down again")

When you add AI integrations or local LLM wrappers into a distributed stack, the complexity curve goes vertical. Debugging a hallucinated token stream across three different microservices is a masterclass in frustration. You end up writing more infrastructure code to glue your services together than actual business logic that brings revenue.

Modular monoliths give you the best of both worlds. You enforce strict boundaries through directory structures and package visibility rules, keeping your domain logic isolated without paying the operational tax of network boundaries. You can still scale your database reads, you can still optimize hot code paths, and you can still refactor with a single click in your IDE.

Next time someone proposes breaking your SaaS into smaller services, ask them what specific business metric will improve by introducing a network layer between your objects. If the answer is anything other than team organizational scale, keep your code in one repository.

Debugging My Focus: What Three Months of Time-Tracking Taught Me

Puneet Khandelwal — Sat, 29 Aug 2026 12:50:55 +0000

Most productivity advice treats the human brain like a stateless microservice that runs at peak capacity forever. That model breaks down fast.

I got tired of guessing why some days felt effortlessly productive while others dissolved into a haze of context switching and tab hoarding. As an engineer, I refuse to troubleshoot a production issue by guessing. I need logs. So, for three months, I wrote a lightweight logging script to capture my actual computer usage alongside subjective energy ratings. Every hour, a silent notification prompted me to score my focus from one to five and log my current context.

I expected my coding output to peak during long, uninterrupted blocks of four or five hours. The data completely demolished that assumption. My telemetry showed that deep focus rarely exceeded ninety minutes before yielding diminishing returns. Beyond that threshold, my error rate for pull requests climbed sharply, and the time required to solve simple debugging puzzles doubled. The system was running out of memory. Pushing past that wall didn't produce more work; it just created technical debt in my own head that I had to pay back the next morning with sluggish thinking.

Armed with these metrics, I refactored my schedule. Instead of white-knuckling through four-hour coding sessions, I implemented hard context boundaries. Every ninety minutes, I forced myself to walk away from the desk, grab a glass of water, and let the background threads clear out. It felt counterintuitive at first. Stopping when momentum felt high went against every productivity myth I had absorbed over the years.

Yet the output metrics told a different story. Total daily lines of clean code increased, while late-night debugging sessions dropped to near zero. Treating my attention span as a finite resource with hard architectural limits turned out to be the most effective optimization I have ever shipped to my daily routine.

We spend so much energy optimizing build pipelines and database queries, but almost nothing on the wetware running the whole operation.

Why GraphQL Saved Our Civic API from Over-Fetching

Puneet Khandelwal — Fri, 28 Aug 2026 12:34:57 +0000

When municipal budgets run dry, bloated API payloads aren't just bad architecture. They burn public money. Last year, our civic tech dashboard lit up with thousands of local transit requests where mobile apps tossed out ninety percent of the JSON we sent them. We relied on old REST endpoints built a decade ago, forcing every client to swallow the exact same rigid structure.

Devs default to REST because the tooling just works and routing takes five minutes. But public sector apps break that mold. A neighborhood group running on five-year-old Android phones needs tiny payloads to map broken streetlights. At the same time, an academic studying urban density needs deep relational queries connecting zoning laws, transit stops, and census tracts all at once. Trying to serve both with standard REST meant spawning a dozen brittle endpoints or making low-income citizens download massive, monolithic documents.

We moved our core civic data layer to GraphQL. The win was immediate client-specified querying. Instead of maintaining separate endpoints for web and mobile, we deployed one schema. Now our mobile app asks for just the coordinates and status ID of a pothole. The research dashboard grabs the entire relational graph down to the last municipal amendment. Network traffic dropped in the first month, stretching our cloud hosting budget without asking taxpayers for a dime.

The migration hurt. Caching got messy because clients could write arbitrary queries instead of hitting predictable URI paths. We had to build persistent queries on the server side to stop resource exhaustion attacks and let our CDN actually cache responses. We also spent weeks writing strict type definitions so legacy municipal databases mapped into a clean graph without leaking internal IDs.

Infrastructure in civic tech carries real weight. When we ship tools that respect bandwidth limits, we lower the barrier for civic participation. We help local journalists and neighborhood hackers build software that holds governments accountable. By adopting GraphQL, we stopped dictating how people consume public data and let them query it on their own terms.

Stop Racing Your Linter: Why Speed Without Architecture Is Just Technical Debt

Puneet Khandelwal — Thu, 27 Aug 2026 12:31:27 +0000

Every sprint review sounds like a race track. The team merging the most pull requests wins an imaginary trophy, while the engineer reading the execution plan gets buried under Jira notifications. Coding assistants make it effortless to spit out 500 lines of boilerplate in the time it used to take to write a single robust function. Volume isn't velocity. Velocity needs a vector, and a vector requires a direction.

At Kluvex, we watched teams burn entire quarters refactoring codebases generated in a weekend. The pattern is always identical. A developer prompts an LLM to spin up a microservice, hooks it to a message queue, and calls it a day. The tests pass because the mock data is clean. The code looks pristine because the syntax is spotless. Then the system hits staging, network partitions happen, retries overlap, and the database connection pool exhausts itself within ten minutes.

The real bottleneck in software engineering was never typing speed. If it were, dictation software would have solved our industry decades ago. The bottleneck is comprehension. When you pull in 10,000 lines of AI-generated abstraction without understanding the state transitions underneath, you're just renting code. You pay the interest later with compound penalties during an outage.

Look at a concrete example. Consider a standard idempotency check in a distributed payment pipeline:

async def process_payment(payment_id, amount):
 if await db.exists(payment_id):
 return {"status": "already_processed"}
 await db.insert(payment_id, "pending")
 result = await payment_gateway.charge(amount)
 await db.update(payment_id, result.status)
 return result

It looks clean. It passes basic unit tests. But under concurrent requests, it suffers from a race condition between the existence check and the insertion. A deliberate approach requires thinking about database isolation levels, distributed locks, and failure modes before writing the first line of logic. Quality means designing for the failure state first, because success takes care of itself.

When we optimize exclusively for deployment frequency, we train ourselves to treat software as disposable. We throw away the craft of profiling queries, understanding memory allocations, and tracing asynchronous event loops. Tools should amplify human judgment, not bypass it. If your primary contribution to a feature is hitting enter on a generated block of code you haven't fully traced, you're operating as a delivery mechanism rather than an engineer.

Slow down the merge queue. Force code reviews to focus on system boundaries and failure modes rather than variable naming conventions. The best code is often the code you delete, and the most valuable engineer in the room is the one who knows when to stop typing and start thinking.

How to Hide Your Living Room Router Without Drilling

Puneet Khandelwal — Wed, 26 Aug 2026 12:29:17 +0000

That blinking plastic box ruins your setup, but shoving it into a closed cabinet tanks your throughput.

Living rooms in rentals come with strict rules about modifications. Hiding networking gear becomes a unique puzzle when you can't drill holes for custom shelving and heavy cable routing is out of the question. Stuffing your access point inside a dense media console or a metal filing cabinet creates a Faraday cage. Devices drop packets, latency spikes during calls, and hardware overheats because airflow stops.

Physics hates dense obstructions. Placing gear too low or behind your TV kills coverage. Treat the router like functional hardware that needs strategic camouflage instead of total imprisonment.

Start with items you already own. A shallow woven basket on an open table works. Natural gaps in the weave let air circulate while blocking flashing LED lights. Just make sure the equipment doesn't touch the sides tightly.

Vertical height matters, and you don't need a power drill for it. Heavy-duty mounting strips designed for temporary setups secure lightweight plastic shelves to painted drywall without stripping paint when you leave. Put this shelf near the top of a bookcase rather than the bottom, letting radio waves propagate downward across the room.

A vintage suitcase or hollow decorative book box also works as a disguise. Remove the back spine of the book box or leave the suitcase lid cracked for ventilation. Thermal throttling is real, and overheating network gear causes random reboots right during a deploy.

Balancing signal strength with interior design takes some testing. Check out the full guide on how to hide your router in a rental living room without drilling to keep your ping times low while the room looks sharp.

Hardening the Ballot: What Engineers Can Do to Stop Election Interference

Puneet Khandelwal — Tue, 25 Aug 2026 09:24:07 +0000

When municipal election servers dropped offline during a routine autumn update cycle last year, the immediate panic was political. As a backend engineer peering into the incident logs, however, I saw a familiar technical failure. The root cause wasn't a sophisticated state-sponsored cyber weapon. It was an unauthenticated configuration endpoint left exposed by a third-party vendor during a hasty pre-election patch.

We talk about election interference as a geopolitical abstract involving troll farms and foreign intelligence agencies. Yet the physical and digital infrastructure of voting remains software dependent, and software has bugs. When we treat election security solely as a policy problem, we ignore the layers of code, database queries, and network configurations that actually process a citizen's ballot.

Consider voter registration databases. These are often legacy monolithic applications bolted onto state-level networks. They suffer from SQL injection vulnerabilities, weak identity and access management controls, and zero-day risks in outdated framework dependencies. If an attacker wants to disrupt an election, altering vote tallies inside a closed-circuit tabulator is difficult. But locking voters out of the rolls by corrupting a registration lookup table on election morning achieves the exact same political outcome with a simple script.

To build resilience, we must apply the same zero-trust principles to civic technology that we use for high-availability financial systems. That starts with immutable audit logs. Every time a registration record changes, or a provisional ballot is logged, the event should append to a cryptographically verifiable ledger. If a database row gets modified outside the standard execution path, the system should instantly flag the anomaly to security operations teams.

Here is a basic pattern for creating a verifiable audit trail in Python, ensuring that records cannot be altered retroactively without breaking the cryptographic chain:

import hashlib
import json

class AuditLog:
 def __init__(self):
 self.chain = []
 self.create_block("genesis")

 def create_block(self, data):
 previous_hash = self.chain[-1]["hash"] if self.chain else "0"
 block = {
 "index": len(self.chain),
 "data": data,
 "previous_hash": previous_hash
 }
 block_string = json.dumps(block, sort_keys=True).encode()
 block["hash"] = hashlib.sha256(block_string).hexdigest()
 self.chain.append(block)
 return block

 def verify_integrity(self):
 for i in range(1, len(self.chain)):
 current = self.chain[i]
 previous = self.chain[i-1]
 if current["previous_hash"]!= previous["hash"]:
 return False
 return True

Implementing basic cryptographic validation is only half the battle. We also need deterministic builds for voting machine firmware. If election officials cannot independently compile and verify the binary running on a precinct machine against the source code published on a public repository, the software is a black box. Trust in code must be earned through reproducibility, not assumed through authority.

Civic technology often operates under tight municipal budgets, leading to deferred maintenance and reliance on overworked local IT staff. This creates a dangerous asymmetric reality. Attackers only need to find one vulnerable API endpoint. Defenders have to secure every surface, every time.

Bridging this gap requires developers to step up and contribute to open source civic infrastructure. We can volunteer our time to audit local government repositories, help county clerks implement multi-factor authentication, and push for modern continuous integration pipelines that run automated vulnerability scans before any software touches a polling place.

Democracy runs on code today. If we want our elections to remain free and fair, we have to start building them with the same defensive rigor we demand of the systems handling our money.

OpenAI vs Anthropic: How CUAs Are Killing Fragile RPA Pipelines

Puneet Khandelwal — Sun, 23 Aug 2026 18:25:16 +0000

Traditional enterprise automation is a maintenance nightmare. A single CSS class change or arbitrary DOM update breaks the whole pipeline. For years, engineers relied on rigid RPA tools and brittle scraping scripts just to move data between legacy web apps and desktop UIs. That era is over.

Computer-using agents, or CUAs, treat the monitor like a human operator. Instead of hitting hidden APIs or raw HTML trees, these models ingest screenshot frames, turn visual state into intent, and execute clicks and keystrokes directly. They parse native desktop environments without caring about underlying markup shifts. When a button moves five pixels left, the model adapts visually instead of throwing an exception.

The engineering challenge moved from writing selectors to managing multi-step visual feedback loops (field notes here). You are giving an LLM a continuous stream of image buffers and an event-dispatching mouse driver. Token overhead is high. Still, inference optimizations and multimodal speedups bring round-trip latency down to acceptable thresholds for background worker tasks.

Architectural divergence between major lab offerings comes down to state and safety boundaries. One approach leans into deep native OS hooks and tight sandboxing for deterministic safety. The alternative optimizes for fluid multimodal reasoning over raw browser and desktop frames, letting workflows adapt faster across varied software stacks.

I broke down the core differences in tooling, execution reliability, and cost per task between leading platforms. If you are architecting autonomous workflows or deciding whether to patch legacy automation scripts, check out the full breakdown of how these agents stack up in production.

Read the complete analysis on computer-using agents for benchmark data and architectural trade-offs.