What is Jugaad?
Somewhere in the Thar Desert, in a village where the nearest power line is twenty kilometers away and the nearest computer repair shop might as well be on the moon, a fourteen-year-old boy named Hardev built a windmill. Not from a kit. Not from a YouTube tutorial. Not from anything that a mechanical engineering textbook would recognize as legitimate materials. He built it from a broken bicycle wheel, scrap metal salvaged from a dumped truck chassis, a hand-wound copper coil, and sheer, stubborn refusal to accept that his family should live without electricity.
The windmill was ugly. It wobbled. The blades were cut from flattened tin cans and they whistled in the wind like a tea kettle having a breakdown. But it worked. It generated enough power to light a single bulb in his family’s home. That one bulb changed everything. His younger sister could study after dark. His mother could cook without squinting at the kerosene lamp. His father, a farmer who had never seen the point of formal education, sat under that bulb one evening and said, “Maybe the boy should stay in school.”
That windmill was jugaad.
In Hindi, the word “jugaad” does not translate neatly into English. The closest you can get is something like “creative improvisation” or “frugal innovation,” but both of those feel too sterile, too corporate, too much like something a management consultant would put on a slide deck. Jugaad is earthier than that. It is the auto-rickshaw driver in Pune who fixes his broken throttle cable with a piece of wire from his wife’s clothesline. It is the street food vendor in Delhi who keeps his chutney cold using a terracotta pot nested inside another terracotta pot with wet sand in between — a zero-electricity refrigerator that works on the same evaporative cooling principle that engineers at fancy research labs write papers about. It is the teenager in Mumbai’s Dharavi who built a working radio from electronic waste that the rest of the world had thrown away.
Jugaad is not hacking. Hacking implies breaking into something. Jugaad is building out of nothing.
It is not a workaround. A workaround implies there is a proper solution that you are avoiding. Jugaad often IS the proper solution — the one that the textbook never imagined because the textbook was written for people with budgets.
It is not “making do.” Making do implies resignation. Jugaad is the opposite of resignation. It is the fierce, creative, sometimes absurd insistence that a solution exists and you are going to find it, even if it means using a coconut shell as a bearing housing.
I grew up watching jugaad. I grew up in Pune, a city that runs on it. Every workshop in Pimpri-Chinchwad, every small-scale manufacturer in Hadapsar, every street-side mechanic who can rebuild an engine with three wrenches and a prayer — they are all practitioners of jugaad. I did not know, back then, that this was a philosophy. I thought it was just how things worked. It was only after I became an engineer and started working with people who had access to unlimited cloud credits and enterprise software licenses that I realized: jugaad is not a consolation prize for the resource-poor. It is a superpower that the resource-rich have forgotten they need.
The Three Laws of Jugaad Engineering
Every discipline has its fundamental laws. Thermodynamics has three. Robotics has Asimov’s three. Jugaad engineering, as I have come to understand it over years of building things with insufficient budgets, impossible deadlines, and an abundance of chai, also has three.
Law 1: Constraints Are Features, Not Bugs
There is a famous story about the early days of Twitter. The 140-character limit was not a design choice born from some deep meditation on brevity and communication. It was a constraint imposed by the SMS protocol that Twitter was built on top of. SMS messages could carry 160 characters. Twitter needed 20 characters for the username. That left 140 for the message. A technical limitation became the defining feature of an entire platform. It forced a new form of communication into existence. It became the thing that made Twitter feel like Twitter.
This is the first law of jugaad: the constraint is not the thing standing between you and your solution. The constraint IS the solution. Or at least, it is the force that shapes the solution into something more elegant than it would have been if you had unlimited resources.
When you have a massive budget, you throw money at problems. You buy the enterprise solution. You spin up the Kubernetes cluster. You hire the consultant. When you have no budget, you think. You think harder than you have ever thought before, because you have to. And that thinking — that desperate, constrained, back-against-the-wall thinking — produces ideas that money cannot buy.
I have seen this play out a hundred times. A startup with no money and three engineers builds a product that a well-funded competitor with fifty engineers cannot match, because the startup was forced to make every line of code count, every architectural decision matter, every feature justify its existence. The constraint was not their weakness. It was their edge.
Law 2: Perfect Is the Enemy of Working
In my first year as a professional engineer, I spent three weeks building a data pipeline. It was beautiful. It had retry logic with exponential backoff. It had schema validation at every stage. It had comprehensive logging. It had a monitoring dashboard. It had unit tests with 94% coverage. It was architected with such care that you could have framed it and hung it on a wall.
My senior engineer looked at it and said, “This is very nice. But the client needed this data flowing two weeks ago. Could you not have just written a cron job?”
He was right. A ten-line bash script running every fifteen minutes would have solved the problem on day one. I could have spent the remaining two weeks and six days making it better, or — and this was the actual lesson — I could have moved on to the next problem, because in the real world, there is always a next problem.
Jugaad does not care about elegance. Jugaad does not care about best practices, design patterns, or what the architecture review board thinks. Jugaad cares about one thing: does it work? If it works, ship it. If it is ugly but it works, ship it. If it makes other engineers wince when they look at the code but it solves the user’s problem, ship it and move on.
This does not mean quality does not matter. It means that a working solution today is worth infinitely more than a perfect solution next month. You can always refactor. You cannot un-miss a deadline.
Law 3: Every Problem Has Been Solved by Someone Who Did Not Know It Was Impossible
The Wright brothers were bicycle mechanics. They had no aeronautical engineering degrees. They had no wind tunnels (until they built one in their shop, out of a wooden box and a fan). They had no government funding. They had no computational fluid dynamics simulations. What they had was the unshakable conviction that humans could fly, and the practical, hands-on, build-it-and-test-it mentality of people who fixed bicycles for a living.
If they had known how impossible heavier-than-air flight was supposed to be — if they had read all the papers by credentialed scientists explaining why it could not work — they might have given up. But they did not know. So they built it anyway.
This is the third law, and it is the most important one. The most dangerous thing in engineering is not ignorance. It is expertise. Expertise tells you what cannot be done. Expertise tells you the accepted limits. Expertise builds a fence around the possible and says, “Do not cross this line.” Jugaad looks at that fence and says, “Who put this here?”
Some of the best solutions I have ever seen came from people who were new to a domain. They did not know the rules, so they did not know which rules they were breaking. They asked questions that the experts had stopped asking years ago. They tried approaches that the experts had dismissed as naive. And sometimes — not always, but sometimes — they made things work that the experts said could not.
Jugaad in Software
Let me get specific. Let me talk about the world I live in: software engineering. Jugaad is everywhere in software, but we rarely call it by its name. We call it “pragmatic engineering” or “scrappy solutions” or, when we are feeling less charitable, “tech debt.” But the DNA is the same.
The Cron Job That Saved a Startup
I once worked with a startup that needed a job scheduler. Their first instinct was to evaluate workflow orchestration platforms. Airflow, Prefect, Temporal — they spent two weeks reading documentation and watching conference talks. They were three engineers. They had four months of runway. They were burning time they did not have on a problem that had been solved since 1975.
I suggested cron. They looked at me like I had suggested we use carrier pigeons.
But here is the thing: their scheduling needs were simple. Run this script every hour. Run that script every night at 2 AM. Run this other script on the first of every month. Cron does all of that. It has been doing all of that, reliably, on every Unix system ever built, for half a century. It does not need a cluster. It does not need a database. It does not need a web UI. It does not need a Helm chart.
They set up cron. It took twenty minutes. They moved on to building the features that would actually save their company. Last I heard, they are doing well. The cron jobs are still running.
The Bash Script That Replaced an ETL Pipeline
Here is a real piece of jugaad I am particularly fond of. A team needed to pull data from an API every day, transform it slightly, and load it into a database. The “proper” solution would have been a Python ETL pipeline with error handling, logging, data validation, an ORM, and probably a requirements.txt longer than the actual code. Here is what they wrote instead:
#!/bin/bash
# Daily data sync - the jugaad way
set -euo pipefail
DATE=$(date +%Y-%m-%d)
LOG="/var/log/sync_${DATE}.log"
echo "[$(date)] Starting sync" >> "$LOG"
curl -s "https://api.example.com/data?date=${DATE}" \
| jq '.results[] | [.id, .name, .value] | @csv' -r \
| psql -d mydb -c "\copy records(id, name, value) FROM STDIN WITH CSV" \
2>> "$LOG"
ROWS=$(psql -d mydb -t -c "SELECT count(*) FROM records WHERE created_date='${DATE}'")
echo "[$(date)] Synced ${ROWS} rows" >> "$LOG"
if [ "${ROWS}" -lt 1 ]; then
curl -s -X POST "https://hooks.slack.com/services/T.../B.../xxx" \
-d "{\"text\":\"Warning: Zero rows synced for ${DATE}\"}"
fiTwelve lines. It fetches data from an API, transforms it with jq, loads it into PostgreSQL with a native COPY command, logs the result, and sends a Slack alert if something looks wrong. No dependencies beyond curl, jq, and psql — tools that are already installed on any reasonable server. No virtual environment. No Docker container. No CI/CD pipeline for the pipeline. It just works.
Is it perfect? No. Does it handle every edge case? No. Will it need to be rewritten if the data volume grows by 100x? Yes. But right now, today, for the scale they are operating at, it is exactly the right solution. That is jugaad.
SQLite: The Jugaad Database
I have a confession. For the first version of almost every personal project I build, I use SQLite. Not Postgres. Not MySQL. Not MongoDB. Not some managed cloud database that costs money and requires configuration. SQLite. A single file. Zero configuration. Zero network overhead. Shipped with Python, shipped with every phone, shipped with most of the software you use every day without knowing it.
People look at you funny when you say “I am using SQLite for this.” They think you are not serious. They think you do not understand scale. But here is what they do not understand: you do not need scale on day one. You need to build the thing. You need to prove it works. You need to show it to users. SQLite lets you do all of that without spending a single minute on database administration.
And here is the secret that the database vendors do not want you to know: SQLite handles more load than you think. The SQLite website itself is served by SQLite. It handles around 500,000 HTTP requests per day. If your side project gets 500,000 requests per day, you do not have a database problem. You have a success problem, and that is a very good problem to have.
WhatsApp as Infrastructure
The most jugaad thing I have ever seen in production was a logistics startup in India that used WhatsApp as their notification system. Not the WhatsApp Business API. Just WhatsApp. A shared phone sat on a desk in the office. A Python script sent messages through it using a library that automated the WhatsApp Web interface. Delivery confirmations, pickup notifications, delay alerts — all through WhatsApp.
Was it against WhatsApp’s terms of service? Probably. Was it reliable? Surprisingly, yes. Was it the right solution for a five-person startup that needed to reach delivery drivers who did not check email and did not want to install another app? Absolutely. Every driver already had WhatsApp. Every driver checked WhatsApp thirty times a day. The engagement rate was close to 100%.
They eventually migrated to the official API when they raised funding. But for the first year, jugaad kept them alive.
When Jugaad Goes Wrong
I would be dishonest if I told you that jugaad is always the answer. It is not. Jugaad has a dark side, and any honest guide to it must reckon with that darkness.
The Temporary Solution That Never Leaves
There is a joke in software engineering: there is nothing more permanent than a temporary solution. Every engineer has a horror story. The “quick fix” that is still running in production five years later. The bash script that was supposed to be replaced “next sprint” and is now the single most critical piece of infrastructure in the company, understood by no one, documented nowhere, running on a server that nobody is allowed to restart because the last time someone restarted it, the script did not come back up and three people had to work through the night to figure out why.
I have seen production databases where the “temporary” migration script became the de facto data model. I have seen authentication systems built on “just for now” token logic that handled real user credentials with the security posture of a screen door. I have seen Slack bots that started as a joke and ended up being the only way to trigger critical business processes.
Jugaad without a plan for replacement is not resourcefulness. It is procrastination in a clever disguise.
The Security Shortcut
This is where jugaad becomes genuinely dangerous. Hardcoded API keys. Passwords stored in plain text. Authentication bypassed because “we will add it later.” CORS set to allow everything because the engineer could not figure out the right configuration and the deadline was tomorrow.
Good jugaad never compromises security. Full stop. You can use duct tape on the architecture. You can use baling wire on the deployment process. But you cannot use duct tape on the lock. The lock has to be real, even if everything around it is held together with hope and string.
The Difference Between Good and Bad Jugaad
The line between good jugaad and bad jugaad is not always obvious, but here is a test I use: good jugaad simplifies. Bad jugaad hides complexity.
Good jugaad: using a cron job instead of a workflow orchestrator because your scheduling needs are simple. You have reduced complexity. The system is easier to understand, easier to debug, easier to maintain.
Bad jugaad: using a cron job instead of a workflow orchestrator because you do not want to deal with the complexity of your actual scheduling needs. You have hidden the complexity. It is still there, lurking in the gaps between your cron jobs, waiting to surface as race conditions, missed runs, and silent failures.
Good jugaad is a conscious choice. Bad jugaad is a shortcut taken under pressure and never revisited. The difference is awareness. Know what you are trading off. Write it down. Put a comment in the code. Create a ticket. Set a reminder. Do whatever you need to do to make sure that future-you (or future-someone-else) knows that this was a deliberate, temporary decision and not the intended architecture.
Jugaad at Scale
There is a common misconception that jugaad only works at small scale. That it is fine for startups and side projects but does not belong in serious, large-scale engineering. I would like to introduce some evidence to the contrary.
ISRO and the Mars Orbiter Mission
In 2014, the Indian Space Research Organisation put a spacecraft in orbit around Mars on its first attempt. This alone would be remarkable — the United States, Russia, and China all failed on their first Mars missions. But the truly staggering part was the cost. The Mars Orbiter Mission, known as Mangalyaan, cost approximately 450 crore rupees, which was about 74 million US dollars at the time.
To put that in perspective: the Hollywood movie “Gravity,” which is a fictional film about space, cost more to make than India’s actual mission to Mars. The movie’s budget was around 100 million dollars. India reached Mars for less than the cost of pretending to be in space.
How? Jugaad at an institutional level. ISRO used a smaller, lighter spacecraft. They used a less powerful rocket — the PSLV, which did not have enough thrust to send the spacecraft directly to Mars, so they used a series of orbit-raising maneuvers around Earth to build up speed before slinging it toward Mars. It was like using a running start because you cannot jump high enough from a standstill. They reused proven technology from previous missions instead of developing everything from scratch. They kept the team small and the bureaucracy minimal.
Every decision was made through the lens of “what is the simplest way to achieve this that we know will work?” That is jugaad. Applied to interplanetary space travel.
UPI: The Payment Revolution
India’s Unified Payments Interface is perhaps the most successful example of jugaad thinking applied to financial infrastructure. Before UPI, digital payments in India were a mess. Every bank had its own app. Every payment gateway had its own integration. Sending money from one bank to another was a multi-step ordeal that involved IFSC codes, branch names, and a prayer that NEFT would process your transaction before the end of the business day.
UPI did not try to replace the existing banking infrastructure. That would have been expensive, slow, and politically impossible. Instead, it built a thin, open protocol layer on top of what already existed. It gave every bank account a simple address — like a phone number or a short ID — and let any app built on the protocol send money to any other app. The banks kept their systems. The users got a unified experience. The protocol was open, so anyone could build on it, which meant competition drove innovation.
The result: over 10 billion transactions per month. Street vendors accepting digital payments. Auto-rickshaw drivers with QR codes taped to their dashboards. A grandmother in a village sending money to her grandson in Bangalore in two seconds, for free. No credit cards required. No expensive point-of-sale terminals. Just a phone, a bank account, and a protocol designed with the jugaad principle of working with what you have rather than demanding what you wish you had.
Jio and the Democratization of Data
When Reliance Jio launched in 2016, India had some of the most expensive mobile data in the world. Most people could not afford to use the internet on their phones regularly. Jio changed that, essentially overnight, by offering free data for months and then settling at prices so low that the competition had no choice but to match them.
But the jugaad was not in the pricing. The pricing was a business strategy. The jugaad was in the engineering. Jio built an entirely 4G network — no legacy 2G or 3G infrastructure to maintain, no backward compatibility to worry about. While other carriers were spending money keeping old networks alive, Jio started fresh with a single, modern, all-IP architecture. They leveraged the falling cost of fiber optics and commodity hardware. They built a network that could serve hundreds of millions of users because they designed it from the ground up for that scale, without the baggage that incumbents carried.
The result was transformative. India went from a country where mobile data was a luxury to one of the largest and cheapest data markets in the world. Hundreds of millions of people came online for the first time. Entire industries — from digital payments to ed-tech to telemedicine — became possible because suddenly everyone had a phone with affordable internet.
The Jugaad Mindset
I want to close with something personal.
I grew up in Pune. My father is an engineer. His father was a mechanic. I come from a family where fixing things, building things, and making things work is not a profession — it is a way of being. In our house, nothing was ever “broken beyond repair.” Everything was “not yet fixed.”
When I was twelve, our ceiling fan stopped working during a May afternoon — the kind of May afternoon in Pune where the air itself feels tired, where the heat sits on you like a weighted blanket and the world outside shimmers like a mirage. My father opened up the fan, found a burnt capacitor, and replaced it with one he salvaged from an old radio. The fan worked for another eight years.
That moment stuck with me. Not because it was technically impressive — replacing a capacitor is basic electronics. But because of the mindset it revealed. My father did not look at the broken fan and see a problem. He looked at it and saw a puzzle. He did not think about what he did not have (a new capacitor, a nearby electronics shop open on a Sunday). He thought about what he did have (a broken radio in the storage room, a soldering iron, and the knowledge of how circuits work).
That is the jugaad mindset. It is not about being cheap. It is not about cutting corners. It is about seeing possibilities where others see limitations. It is about understanding that the constraint is not a wall — it is a door to a different room, one that might contain a better solution than the obvious one.
What Jugaad Means for Engineers Today
We live in an age of abundance. Cloud computing gives us virtually unlimited resources. Open-source gives us libraries for everything. Stack Overflow and AI assistants give us answers to almost any technical question. In theory, we have never had it easier.
And yet. The best engineers I know still think like jugaad engineers. They still ask, “What is the simplest thing that could work?” before reaching for the complex solution. They still prototype in bash before building in Kubernetes. They still choose SQLite before PostgreSQL, text files before databases, simple scripts before frameworks. Not because they do not know the sophisticated tools. Because they understand that sophistication should be earned, not assumed.
Every abstraction has a cost. Every dependency is a risk. Every layer of infrastructure is a layer of things that can go wrong. The jugaad mindset is a constant, gentle reminder: do you actually need all of this? Or are you building a cathedral when a tent would do?
A Letter to My Younger Self
If I could go back and tell my younger self one thing about engineering, it would not be about any specific technology. Technologies come and go. Languages rise and fall. Frameworks are born and die and are reborn with a different name and the same ideas.
What endures is the mindset. The willingness to look at a problem and think, “I can make this work.” Not “I can make this work if I have the right tools, the right budget, the right team, the right timeline.” Just: “I can make this work.”
That is jugaad. That is the lesson from every auto mechanic in Pimpri, every street vendor in Camp, every farmer in Rajasthan who built something impossible out of nothing at all. It is the lesson from ISRO reaching Mars on a shoestring. It is the lesson from UPI connecting a billion people to the financial system. It is the lesson from every engineer who ever solved a problem that the experts said could not be solved.
The world will always tell you that you need more. More resources, more time, more people, more money, more tools. Jugaad is the quiet, stubborn voice that says: “What you have is enough. Start building.”
So start building. The windmill does not have to be pretty. The fan does not have to be new. The solution does not have to be textbook.
It just has to work.