What does a Google Apps Script developer do?
A Google Apps Script developer writes JavaScript that runs on Google’s servers and controls Google Workspace products: reading and writing Sheets, sending Gmail, creating Docs and PDFs, moving Drive files and booking Calendar events. The script lives inside your account, so there is no server to rent.
Apps Script is the glue for businesses that already run on Google tools. A sales team logs enquiries in a sheet; accounts keep an outstanding list in another; operations uses a Form for site reports. Each of those involves someone copying, formatting, emailing and reminding. A Google Apps Script developer removes those manual hops so data entered once flows where it needs to go.
The work is smaller than a software project but more technical than it looks. A good script handles blank rows, duplicate submissions, people renaming tabs, and Google’s daily quotas. A careless one works in the demo and fails quietly in week three, when a column moves. Most of our effort goes into that second, unglamorous half: validation, logging and alerts.
What can Google Apps Script automate? App by app
Apps Script can automate almost anything a person does by hand inside Sheets, Forms, Gmail, Drive, Docs and Calendar, and it can call outside services over HTTP. These are the jobs we are asked for most often, grouped by product.
Google Sheets
Clean and validate imported data, build summary tabs, highlight overdue rows, archive old records to another file, lock rows after approval, and add menus or buttons that run the steps staff repeat daily.
Google Forms
On every submission: assign a reference number, route the response to the right person, create a document, send a tailored confirmation and update a master sheet. Forms can also be pre-filled or rebuilt from a list.
Gmail
Send personalised emails with attachments from sheet rows, read incoming mail by label or sender, pull order numbers out of the text and save attachments to Drive.
Google Drive and Docs
Create folders per client or project, copy templates, fill placeholders in a Docs template, export PDFs and set sharing correctly.
Google Calendar
Create events from bookings, invite participants, block slots, and write back the event link so staff can see what is scheduled.
Outside Google, the UrlFetchApp service calls any HTTPS API. That is how a sheet can pull IndiaMART enquiries, push leads to a CRM, fetch a currency rate or trigger a WhatsApp template.
A custom menu adds your own commands to the Sheets toolbar, such as “Generate invoice for selected row”, so staff run a tested routine instead of following a written procedure. It is often the cheapest, most visible win a Google Apps Script developer can deliver.
Menus are added when the file opens. Behind each item is a function: take the selected row, check required fields, build the document, and report success or the exact problem in a message box. Sidebars and dialogs, built with Apps Script’s HtmlService, go further: a small form inside the sheet with dropdowns and validation, which is far safer than typing directly into cells.
A Google Apps Script developer uses these interfaces for three reasons. They reduce training: a new staff member learns one button, not a process. They protect data: the script writes to the right columns in the right format. And they make the automation visible: people trust what they can press and see working.
A caution. A sheet with many menus and sidebars starts to look like software, and people begin to expect software behaviour: multiple users editing at once, permissions per role, audit trails. Sheets can only half-provide those. When that expectation arrives, read the section on moving off Sheets further down this page.
How do triggers work in Google Apps Script?
Triggers make scripts run on their own: when a file opens, when a cell is edited, when a form is submitted, or on a timer such as every hour or every morning at 8. Choosing the right trigger is half the design of any Apps Script automation.
Simple triggers such as onOpen and onEdit run automatically but with restrictions: they cannot use services that need the user’s authorisation, such as sending email on the user’s behalf. Installable triggers are created once by an authorised user and can do more, including time-driven schedules and form-submit handling. Google’s quota page caps triggers at 20 per user per script, and limits total trigger runtime per day (90 minutes on consumer accounts, 6 hours on Google Workspace).
- On form submit: best for anything that must happen the moment a response arrives.
- On edit (installable): useful for approvals or status changes, but fires often; keep the work light.
- Time-driven: reports, reminders, syncs with outside APIs, archiving. Predictable and easy to monitor.
- On open: menus and lightweight checks only.
One design point prevents many headaches: an installable trigger runs as the person who created it. If that person leaves and their account is removed, the automation stops. We create triggers from a shared or admin-owned account agreed with you, and document which account owns what.
The classic Google Apps Script job is this: a Form or sheet row comes in, a Docs template is filled with its values, the result is saved as a PDF in the correct Drive folder, emailed to the customer, and the PDF link and send time are written back to the sheet.
It suits quotations, admission letters, service reports, delivery notes, rent receipts, certificates and offer letters. The template is an ordinary Google Doc with placeholders like {{CustomerName}} and {{Amount}}, which your staff can restyle without touching code.
Details that decide whether it works for a year or a week:
- A unique reference number assigned under a lock, so two simultaneous submissions never share one.
- Validation before generation: missing email, wrong GSTIN length or empty amount stops the run and flags the row.
- Folder rules by month or client, so Drive does not become one folder of thousands of PDFs.
- A status column (Pending, Sent, Failed with reason) that staff can filter.
- Email volume checked against the daily recipient quota for your account type.
If the customer would rather receive that PDF on WhatsApp, the same flow can hand it to the WhatsApp Business API; our send WhatsApp messages from Google Sheets page covers that part.
Connecting Google Sheets to outside APIs with Apps Script
Apps Script’s UrlFetchApp service can call any HTTPS API, so a Google Apps Script developer can connect your sheets to lead portals, CRMs, payment-link services, accounting software and messaging platforms without a separate server.
Typical integrations we write: pulling enquiries from IndiaMART’s Lead Manager API into a leads sheet every few minutes; pushing qualified rows into a CRM; fetching order data from an online store; sending WhatsApp template messages through the official Business API; posting rows to a Tally sync bridge that runs on the office PC.
API keys never go in the sheet or in the code. They sit in the script’s Properties Service, which Google limits to 9 KB per value, plenty for keys and tokens. Every call is wrapped with retry for temporary failures, and every failure is logged with the row it concerned, so a broken connection shows up as a clear list rather than as missing data.
Quotas matter here too: Google’s published daily URL Fetch limit is 20,000 calls on consumer accounts and 100,000 on Workspace. That is ample for most small businesses, but a script that calls an API once per row on a 50,000-row sheet will run into it. Batching requests and only syncing changed rows keeps you well inside the limit. For the IndiaMART side in detail, see IndiaMART CRM integration.
Google Apps Script quotas and limits every developer must plan for
The limits that shape most business scripts are the 6-minute cap on a single run, daily email recipients, daily URL Fetch calls and total trigger runtime per day. Google publishes them on its Apps Script quotas page, and they differ between free Gmail accounts and Google Workspace.
From Google’s quotas page, checked this month: a script can run for at most 6 minutes per execution on either account type; custom functions (formulas you write yourself) get 30 seconds; email recipients are capped at 100 a day on consumer accounts and 1,500 on Workspace; URL Fetch calls at 20,000 and 100,000 a day; trigger runtime at 90 minutes and 6 hours a day; and quotas reset 24 hours after the first request.
How a careful Google Apps Script developer designs around them:
- Read and write ranges in one call instead of cell by cell; this alone often cuts run time dramatically.
- Process long jobs in chunks, saving a bookmark so the next timed run continues where the last stopped.
- Count emails before sending and stop cleanly with a clear message if the day’s quota would be exceeded.
- Use a Workspace account for anything customer-facing at volume; the higher quotas are worth it.
- Log every run with duration, so a slow creep towards the limit is visible before it fails.
Is Google Apps Script free to use?
Yes. Apps Script comes with any Google account and Google Workspace plan at no extra charge; you pay nothing to Google for the scripts themselves. What you pay for is the developer’s time to build them and, if you need higher quotas, a Workspace subscription you may already have.
The difference between a free Gmail account and Workspace is mostly quotas and control. Workspace gives higher daily limits, a company domain for the sender address, and admin control over who can run or edit scripts. A business sending customer emails from a script should be on Workspace for the higher recipient quota and for an address customers recognise.
Outside services called by the script can carry their own costs. The WhatsApp Business API charges per message category through Meta and your provider, IndiaMART’s API is available to paid sellers only, and some CRMs limit API calls by plan. We list those third-party costs in the quote so the total is clear before you approve anything.
Compared with a subscription connector, the saving is steady: a well-written script has no per-task fee, which matters when the flow runs thousands of times a month. The trade-off is that changes need a developer, not a drag-and-drop editor.
How much does a Google Apps Script developer cost in India?
With BtechWaleTech, a single Apps Script workflow starts at ₹40,000; larger builds that act as web portals or replace Sheets with a database start at ₹60,000. Rates across the market vary widely, and the gap is mostly explained by testing, error handling and handover, not by the code itself.
What moves the price of any Google Apps Script developer’s quote:
- Number of services touched: a Sheets-only script is simpler than one spanning Forms, Docs, Drive, Gmail and Calendar.
- Outside APIs: each new API adds authentication, error handling and testing.
- Data quality: merged cells, free-text dates and inconsistent names need clean-up logic.
- Volume: quota-aware batching and chunking take extra design at thousands of rows.
- Interface: a sidebar form or web app costs more than a plain menu item.
- Handover: documentation, a test copy and training for the person who will own it.
Gigs and hourly bids on marketplaces such as Upwork or Fiverr can look cheaper for a one-off script. It often is, for a truly small job. For anything your operations depend on, compare what is included: validation, logs, alerts and a written handover. You receive our quote itemised along exactly those lines.
How to scope work before hiring a Google Apps Script developer
Write down, in plain language, what triggers the work, what data it reads, what it produces and who needs to know when it fails. A one-page scope like that gets you an accurate quote from any Google Apps Script developer and prevents half the arguments later.
A useful scope answers six questions. Where does the data start: a Form, a sheet typed by staff, an email, an outside system? What should happen, step by step, in the words your team uses? How often: on every submission, hourly, or once a day? What is produced: a document, an email, a row elsewhere, an API call? What counts as an error, and who should be told? And who owns the files and account the script runs under?
Share a copy of the real sheet with sample rows, including the messy ones. Screenshots hide the details that matter, such as hidden columns, formulas that break when rows are inserted, or dates stored as text. We ask for a copy, never edit access to your live file during scoping.
Finally, decide what success looks like: “quotations go out within five minutes of a form entry, with no manual step” is testable. “Make the sheet smarter” is not. We write the acceptance test into the quote so everyone knows when the job is done.
How to vet a Google Apps Script developer
Ask for a short paid test on a copy of your own sheet, and judge the result on error handling and clarity, not only on whether it runs. A capable Google Apps Script developer will ask about edge cases before writing a line.
- Do they read and write in batches, or loop cell by cell?
- Does the script check for missing or malformed data before acting?
- Where do API keys live? The right answer is the Properties Service, not a cell.
- What happens at the 6-minute limit on a large sheet?
- Which account owns the triggers, and what happens if that person leaves?
- Do they use version control (for example, the clasp command-line tool with Git) for anything non-trivial?
- Will you get a plain-language note on how to change the template or schedule yourself?
If the answers are vague, the script will probably work until the first unusual row. It is also fair to ask how they would log failures; “you will see it in the execution log” is weaker than “failed rows are marked and an email lists them.” For broader automation hiring, see Python automation freelancer, which suits jobs that outgrow Workspace.
Who owns the code a Google Apps Script developer writes, and is it secure?
The script belongs to whichever Google account owns the file it is bound to, or the Drive where a standalone script lives, so it should always be created in your business account, not the developer’s. Access is controlled by the same sharing settings as your sheets.
When a script written by any Google Apps Script developer first runs, Google shows the permissions it requests, such as reading your sheets or sending email as you. A tidy script asks only for what it needs; we narrow scopes where Apps Script allows it. Anyone with edit access to a bound script can change it, so we suggest limiting edit rights on automation files to one or two people.
Data handling rules we follow: API keys in the Properties Service, not in cells; no customer data copied into our own accounts; test runs on a copy with sample rows; and removal of our access once handover is done, if you prefer. The code, templates and a short README stay in your Drive.
For customer data at scale, Sheets has limits as a data store: no row-level permissions, and Google’s Drive help caps a spreadsheet at 20 million cells or 100 MB. If you are storing sensitive records for thousands of customers, that is a reason to consider a proper database behind a small web app.
What a Google Apps Script developer should hand over
Good Apps Script code has named settings at the top (sheet names, column headers, folder IDs) instead of numbers buried in functions, looks up columns by header rather than position, logs each run and emails someone when something fails. That is what makes it maintainable by the next developer.
For anything longer than a page, our Google Apps Script developer team works locally with Google’s clasp tool and keeps the code in a Git repository you own, so changes are tracked and reversible. Deployments to the live file happen after testing on a copy. A small README explains what each function does, which triggers exist, who owns them and how to pause the automation in an emergency.
We also leave a “health” tab in the sheet: last run time, rows processed, rows failed and the reason. Staff can glance at it without opening the script editor. If the last run time is old, the trigger has stopped; if failures pile up, something upstream changed. This one tab prevents most “it stopped working and nobody noticed” stories.
After launch you get two months of free fixes. After that, maintenance is optional from ₹8,000/mo, useful when Google changes a service or your process changes.
When should you move off Google Sheets and Apps Script?
Move off Sheets when several people edit the same rows at once and overwrite each other, when you need permissions per role or per record, when scripts keep hitting the 6-minute limit despite batching, or when an auditor asks who changed what and the version history cannot answer clearly.
None of these means Apps Script was the wrong choice. It is often the right first step: it proves the process, cheaply, with the tools people already know. The logic written in Apps Script also transfers well, because it is JavaScript and because the process has been debugged in real use.
The next step depends on who uses the system. Field staff on phones with patchy signal often do well on AppSheet, which builds mobile apps on top of Sheets; see AppSheet developer. An office team that needs roles, audit trails and reports usually needs a small custom web app with a real database; see converting spreadsheets into software. A business already running accounts, stock and production in separate sheets may be ready for an ERP; our ERPNext implementation page covers that jump.
Hiring a Google Apps Script developer across India
Working with a Google Apps Script developer is fully remote by nature: we need a copy of your sheet, a call to understand the process, and access to a test account. Location does not matter; clarity does. We work in English and Hindi and reply on WhatsApp seven days a week.
Businesses that ask us for Sheets automation come from everywhere: coaching institutes in Jaipur tracking batches and fees, startups in Bengaluru running operations on Workspace before they buy software, logistics firms in Kolkata logging trips, tour operators in Kochi sending itineraries, schools in Lucknow issuing certificates, real-estate brokers in Hyderabad juggling site-visit bookings, NGOs in Bhubaneswar handling donor receipts and distributors in Nashik chasing collections.
India-specific details we handle routinely: GSTIN and HSN validation in forms, Indian number formatting (lakh and crore separators) in generated documents, dates in DD-MM-YYYY, Hindi text in Docs templates, and messages that link to UPI payment pages. Many owners only ever see the output on a phone, so we keep emails short and PDFs readable on a small screen.
Worked example: a hypothetical Apps Script setup for a tiles showroom
Say a tiles and sanitaryware showroom with twelve staff keeps enquiries, quotations and site-measurement visits in three Google Sheets and a shared Gmail inbox. This is how a Google Apps Script developer might automate it; the business and details are invented for illustration.
Step one: a Google Form for walk-in and phone enquiries writes to a leads sheet; on submit, a script assigns a reference, emails the salesperson on duty and creates a follow-up task date. Step two: a “Create quotation” menu item takes the selected lead and a product list, fills a Docs template with item codes, sizes, box counts and GST, saves the PDF in a folder per month and emails it to the customer from the showroom’s Workspace address.
Step three: the Google Apps Script developer adds a “Book measurement visit” sidebar that creates a Calendar event for the site engineer with the address and phone number, and blocks double-booking. Step four: a time-driven trigger at 8 each morning emails the owner yesterday’s enquiries, quotations sent and visits booked, and lists quotations with no follow-up after three days.
Scoped this way, the first two steps would be one quoted workflow from ₹40,000, with the calendar and morning digest as a second line. If the showroom later wants the digest on WhatsApp, or the leads fed from IndiaMART, those plug into the same sheet.