What to Expect When You Hire a Google Apps Script Developer

Why This Guide Exists

Most businesses that hire a Google Apps Script developer have never hired one before. They know they need automation, they know they use Google Workspace, and they’ve been told (or discovered) that Apps Script is the way to do it.

But the process of working with a developer; what to prepare, what to expect, and what “done” looks like; is often unclear. This guide walks you through it.

Before You Start: What to Have Ready

You don’t need a technical specification. You don’t need to understand JavaScript. You need to be able to describe:

1. The manual process you want to automate. Walk through it step by step. “First, I check my email for new enquiries. Then I copy the details into this spreadsheet. Then I send a confirmation email. Then I create a folder in Drive.” The more specific, the better.

2. How often it happens. Once a day? Fifty times a day? Weekly? Volume affects how the automation is built; a process that runs 5 times a day needs different engineering than one that runs 500 times.

3. The exceptions and edge cases. What happens when the data is incomplete? When someone submits the form twice? When the email doesn’t have an attachment? The manual process probably handles these with human judgement. The automation needs explicit rules.

4. What “done” looks like. What should happen when the automation finishes? An email sent? A row updated? A file created? Be specific about the output.

5. Access to the Google Workspace tools involved. The developer will need access to the spreadsheets, forms, email templates, and Drive folders involved. They’ll likely need Editor access to the script project and viewing access to the data.

The Process: What Happens When

Stage 1: Discovery (30 minutes - 1 hour)

The developer asks questions. Lots of questions. Good developers ask about edge cases, failure modes, and “what if” scenarios more than they ask about the happy path.

Expect questions like:

“What happens if this field is blank?”
“How many of these do you process on your busiest day?”
“Who else touches this spreadsheet?”
“Has the format of these emails ever changed?”
“What should happen if something goes wrong at 3am?”

This stage determines the scope of the project and the quote.

Stage 2: Scoping and Quote

After discovery, the developer provides a scope document that outlines:

What the automation will do (in plain English)
What it won’t do (important for managing expectations)
What triggers it (form submission, time-based, manual button)
What outputs it produces
What error handling is included
How long it will take to build
How much it will cost
What access they need from you

Read this carefully. If something’s missing or doesn’t match your expectation, now is the time to say so. Changes after building has started are more expensive.

Stage 3: Development (days to weeks, depending on complexity)

The developer builds the automation. During this stage, expect:

Questions as edge cases emerge (“The spreadsheet has two tabs called ‘Archive’; which one should the script use?”)
Progress updates on multi-week projects
Requests to test with your real data (not just sample data)

A good developer tests with realistic data volumes and scenarios, not just a clean 10-row test sheet.

Stage 4: Testing and Review

Before deployment, you should see the automation run against your actual data (or a copy of it). The developer should show you:

The automation running end to end
What happens when data is missing or malformed
What happens when an error occurs
The logging and monitoring in place
Where to find records of what the script has done

This is your opportunity to catch things like: “Actually, when the client is in Scotland, we do it slightly differently.” Better to catch it now than after go-live.

Stage 5: Deployment

The script is deployed in your Google Workspace environment. It runs under your account, on your data, using your permissions. The developer sets up triggers, confirms they’re firing correctly, and verifies the first few automated runs.

Stage 6: Handover

A good developer doesn’t just deploy and disappear. Handover should include:

Documentation: What the script does, how it’s triggered, what to check if something goes wrong
Walkthrough: A 15-30 minute session showing you where everything lives and how to monitor it
Support window: A period (typically 1-2 weeks) where the developer is available for questions and quick fixes as the automation settles into real-world use

What Good Looks Like

Signs you’ve hired a good Apps Script developer:

They ask more questions than you expected. Curiosity about your process means they’re building for your reality, not their assumptions.

They talk about failure before success. “What should happen when this breaks?” is more important than “watch how fast this runs.”

They build monitoring. Logs, health checks, alerts. If the developer doesn’t mention monitoring, ask about it.

They document. Code comments, a plain-English description of what the script does, and instructions for common situations (how to pause it, how to restart it, how to update a template).

They test with your data. Not just a clean test sheet; your actual messy, real-world data with its quirks and inconsistencies.

They explain the trade-offs. “We could add feature X, but it would add £300 and 2 days. Here’s why it might or might not be worth it.”

What to Watch Out For

“I’ll build it in an hour.” Simple automations can be built quickly, but this shouldn’t be the default assumption. If the developer hasn’t asked detailed questions, they’re probably building for the happy path only.

No mention of error handling. Every automation fails eventually. If the developer doesn’t discuss what happens when things go wrong, they haven’t thought about it.

No monitoring or logging. A script without monitoring is a script you’ll discover is broken only when someone notices the work isn’t getting done.

Reluctance to explain. You don’t need to understand the code, but you should understand what the automation does, how to tell if it’s working, and who to call if it isn’t.

No documentation. If the developer gets hit by a bus (or just becomes unavailable), can someone else understand and maintain the script?

Questions to Ask Before Hiring

Can you show me examples of similar automations you’ve built?
How do you handle error situations?
What monitoring will be included?
What documentation will I receive?
What happens if I need changes after deployment?
Do you offer ongoing support or maintenance?
Who owns the code; me or you?
What happens if Google changes something that breaks the script?

The right developer will have clear, confident answers to all of these.

Ready to Start?

At Empower Automation, we follow this exact process for every client. Discovery, scoping, transparent pricing, proper testing, thorough handover, and ongoing support.

Book a free 15-minute automation audit →

No commitment, no jargon. Just a conversation about what you need and how we’d build it.

Nicola Berry is the founder of Empower Automation, based in Falkirk, Scotland. Making the process of hiring a developer as clear as the automation itself.