SMB Digital Way – Digital Solutions for Your Business - Before You Spend Lakhs on Software, Read This

I built a working field operations app in four days. No agency. No budget. No app store. Just a Google Sheet, some Apps Script, a single HTML file, and an AI tool doing most of the heavy lifting on t

 · 7 min read

I have been working with a small NGO in Bangalore for a few years now. A group of genuinely passionate people who care about the environment, specifically about roadside saplings that get planted every year by corporation as part of drives, and then mostly forgotten.

This group doesn't forget. They go back. They water, repair tree guards, remove wires that are strangling young trees. They do this quietly, without much recognition, for at least three years after each sapling is planted.

For all the years I have known them, the one thing missing was a simple way to keep track of everything. Which sites. Which volunteers. Which saplings need attention. Who is going where this Sunday morning.

What I Tried Before This

I tried Google Sheets. Everyone had a different version. Data was all over the place.

I tried shared Maps. Volunteers couldn't figure out how to add pins reliably from mobile.

I tried WhatsApp coordination. If you have ever tried to manage field operations on WhatsApp, you know how that ends.

I reached out to college interns computer science students who I thought might enjoy building something for a good cause. I shared a detailed requirements document. They were enthusiastic initially. Nothing ever came of it. Motivation fades when there is no grade attached.

For a while I just accepted that this was probably a problem that needed a proper app, which meant a proper budget, which meant it probably wasn't going to happen for a volunteer group with no money.

Then I Tried Something Different

I decided to build a working prototype myself, using a completely free technology stack  Google Apps Script connected to Google Sheets as the backend, a single HTML file as the front end, hosted on Cloudflare Pages at zero cost. AI tools helped enormously with the code, I could not have done this at this speed otherwise.

The intention was modest. Build something rough. Put it in the hands of volunteers. See what actually happens when real people try to use it in the field. Expect it to be incomplete. Expect to learn more from the failures than the features.

The results genuinely surprised me.

Within a few days volunteers were using it. On their phones. In the field. At six in the morning.

What It Actually Does

The prototype now lets volunteers do things that would have required a ₹5-8 lakh custom app just a couple of years ago:

  1. See all plantation sites on a map with GPS coordinates and photos
  2. Register as a volunteer and log new sites directly from the field — photo, GPS, done in three taps
  3. Raise a maintenance request for any sapling that needs attention — watering, guard repair, wire removal, whatever the issue is
  4. See only the sites they personally added, and edit them
  5. Find the nearest site needing attention using live GPS location
  6. Plan upcoming visits so volunteer time gets used well

The entire thing runs on a Google Sheet. The database is a spreadsheet tab. There are no servers to maintain, no subscriptions to pay, no IT department needed.

And it works. That is the part that surprised me most.

What This Made Me Think About

Somewhere around week three of watching volunteers use this in the field, I started thinking about MSMEs the small business backbone of India.

Because the problem this NGO had is not unique to NGOs. It is the same problem that a fire protection company with 20 technicians has. Or a pest control network spread across a city. Or a textile manufacturer trying to coordinate with weavers across three districts. Or a distributor whose sales team still sends end of day reports on WhatsApp.

The problem is always the same: operations are running on a combination of memory, WhatsApp, and disconnected spreadsheets. Everyone knows it is not working well. Everyone agrees something needs to be done. And then someone gets a quote for ₹10-15 lakhs for a custom application, and the conversation stops.

What I want to suggest is that there is a step in between doing nothing and spending ₹10 lakhs.

Build a Working Prototype First

Not a PowerPoint. Not a demo. Not a vendor showing you screenshots of their product.

A working prototype that your actual team uses for actual work for 30 to 60 days.

Here is what that tells you, which no requirements document ever will:

You find out which features people actually use and which ones they ignore. You find out where the process breaks in ways you did not anticipate. You find out that the field team has completely different needs from the office team. You find out that the thing you thought was the main problem is actually a symptom of a different problem entirely.

In the NGO case, we built an Add Site form that asked volunteers to type in a road name. Seemed logical. Turned out that at six in the morning, standing at a roadside median, most volunteers have no idea what the road is officially called. They just know they are standing there and they want to log the site quickly and get on with their work.

We changed the flow to capture GPS first, let the map suggest the road name, and require only a photo and a tap to save. The whole form went from something nobody wanted to use to something people actually used.

We would never have known that from a requirements meeting. We learned it from watching someone try to use it in the field.

And Then There Is the AI Layer

This is where it gets genuinely interesting for businesses right now.

Most businesses already have data in spreadsheets. Purchase records, inventory, customer enquiries, attendance, service logs. The data is there. What has been missing is intelligence acting on that data automatically.

That gap is closing very quickly.

A supplier invoice arrives by email. Apps Script extracts the attachment, parses the line items, and populates your purchases sheet. An AI call then checks each item against last month's prices and flags anything that has gone up significantly. Your purchase manager gets a WhatsApp message: "Invoice from Raj Textiles ₹2.3 lakhs. Three items above last month's rate."

A field technician completes a service job and submits a photo. AI reads the photo, identifies the equipment, checks the service record, and logs the completion automatically. Your operations sheet updates in real time.

A customer fills an enquiry form. Within 90 seconds they get a personalised first response, and your team gets a lead scored and prioritised in their sheet.

None of this requires a SaaS subscription or a developer on retainer. A reasonably technical person with a few days of learning can build and maintain these flows. The AI does the heavy cognitive lifting. Apps Script does the orchestration. Sheets holds the data.

A Framework That Actually Works

From what I have seen, the approach that works looks something like this:

Pick the one operational process causing the most pain. Not three processes. One. The one that costs you time, money, or customer trust most visibly.

Spend one afternoon building the data structure in a Google Sheet. What information do you need to capture? What does a completed record look like? Who enters what? This exercise alone usually surfaces assumptions that people in the same organisation disagree on.

Then wire it together with Apps Script. Connect the data entry points forms, emails, WhatsApp to the sheet. Set up a basic alert. Make it ugly but functional. This is your prototype.

Put it in front of real users. Not in a demo. In actual daily use.

Watch what happens for thirty to sixty days. Note what breaks, what gets ignored, what people ask for that you did not build. This is your real requirements document.

Then and only then decide whether you need a full application, and what that application actually needs to do.

Why Most Software Projects Fail

Most software projects for MSMEs fail not because the software is bad but because the requirements were wrong.

And requirements are wrong not because people are careless but because you genuinely cannot know what you need until you have used something.

Every feature request that came in after volunteers started using the prototype was something we never would have thought to put in a requirements document. Show me only the sites I added. Let me mark a site as urgent from the field. Show me what is nearest to where I am standing right now.

Each of these was a few hours of work on the prototype. In a ₹10 lakh agency build, each would have been a change request, a meeting, a revised timeline, and a revised invoice.

The prototype that costs nothing to change is worth more than the system that charges ₹50,000 for every correction.

Who This Is For

If you are running a business with 15 to 200 people and your operations team is coordinating on WhatsApp, this approach is worth considering before your next software investment.

If you are about to sign a contract for a large ERP implementation, spending one month building a working prototype of even one core workflow will make that investment significantly safer.

If you have already been burned by a software project that did not deliver  and a surprising number of MSME owners have  this is a lower-risk way to get back in the game.

These free stacks have limits. They will not handle tens of thousands of transactions. They are not replacements for a properly built application at scale. But for validating whether a solution actually solves a problem, for testing whether your team will adopt something, for learning what you actually need before you commit serious money they work better than almost anything else I have seen.

To Close

I did not set out to build a technology solution for this NGO. I set out to solve a coordination problem for a group of people I respect.

The technology was just the path that worked.

What it taught me along the way about requirements, about user behaviour, about the gap between what people say they need and what they actually need — is something I think has real value for anyone building or buying software for their business.

Build something first. Use it. Learn from it. Then invest.

That sequence matters more than any technology choice you will ever make.

If you are working on something like this or wondering whether this approach could work for a specific operational problem, I am happy to talk through it.

What operational headache in your business has been waiting the longest for a solution?


#MSME #Prototype #OperationsManagement #DigitalTransformation #AI #GoogleSheets #LowCode #StartupIndia #TechForGood #FieldOperations
















No comments yet.

Add a comment
Ctrl+Enter to add comment