There’s no doubt you’ve heard it before: the best way to learn is by building. But what if you took that a step further?

Instead of just building for practice, picture creating something that solves a real problem—something that makes a process easier, saves time, or fills a gap in the workflow at work or in your personal life.

Not only does this make your projects feel more meaningful, but it also gives you something powerful to show potential employers and clients.

For me, building something that has practical use has been a game-changer, and I want to share one recent experience.

I created a small utility add-on for Google Docs called Duplicate Link Finder, which is proving to be impactful on my team’s workflow and the company’s SEO efforts.

It’s nothing revolutionary, the add-on’s basic functionality is scanning a Google Docs’ content and finding duplicate links. But it serves a purpose and saves time so in my book, it’s a winner 😏

Small ideas are often what make the biggest difference!

Let me walk you through how this project came about and why building solutions to real problems is one of the best ways to learn—and grow—as a developer.

Related: The Truth About Becoming A Web Developer In 2024

Solving a real problem with duplicate links

At my job, the content team heavily relies on Google Docs to structure content with external authors. It’s where ideas are shared, articles are drafted, and the back-and-forth of edits and revisions take place.

While Google Docs offers a ton of functionality that makes collaboration easy, it’s not perfect, especially as we scale content.

One recurring issue we were running into was the problem of duplicate links. As content gets updated and repurposed, it’s easy for the same link to show up multiple times, often with different anchor text.

Then you also have different people editing—SEO, editors, writers, and other reviewers—who often add a link unaware it’s referenced elsewhere in the content.

While this might not seem like a big deal, duplicate links can be an issue for SEO.

Google likes to see diversity in linking structures, so when it sees the same link multiple times on a page or post, it can look a little spammy, impacting search performance.

And on a practical level, duplicate links make content look repetitive and cluttered.

The manual solution wasn’t cutting it anymore

For a while, duplicate links were handled manually. Someone would go through the document and check for repeated links, flagging any duplicates they found.

However, as our content scaled, this process became increasingly time-consuming and prone to human error. There, also, was heightened confusion as to who exactly was to make the discoveries and determine the handling of them.

It was clear that we needed a better solution—one that would take the pressure off the team and make the process of checking for duplicate links faster, easier, and more reliable.

That’s where my idea for a custom Google Docs add-on came in.

Building a Google Docs Add-on to detect duplicate links

I knew that if I could automate the process of detecting duplicate links, it would save us a lot of time and reduce mistakes.

Google Apps Script (GAS) provided the perfect environment to create this add-on.

If you’re unfamiliar with it, Apps Script is a cloud-based scripting language for lightweight app development in Google Workspace. It allows you to automate and extend Google’s apps—like Docs, Sheets, Gmail, and Calendar—using code that runs directly in Google’s cloud environment.

Since the code operates independently of users’ devices, it ensures anyone on the team can run the add-on without worrying about compatibility or installation.

Apps Script includes built-in libraries specifically for Google’s apps. Using classes like DocumentApp (for Google Docs), I can access and manipulate Google Docs content. For the duplicate links finder, this meant I could quickly scan documents, locate URLs, and flag duplicates, all within the Google Docs environment.

But that’s not all!

Because Apps Script operates within Google’s ecosystem, it adheres to Google’s security standards and can be accessed only by authorized users. This built-in security allowed for safe deployment, ensuring restricted material remains protected and accessible only by those with appropriate permissions.

Note: Though it’s nice to be secure, it definitely complicates the process if publishing add-ons with access to restricted Google APIs outside of a Google workspace (more on that below).

Plus, GAS is based on JavaScript, so it’s relatively easy to pick up if you have some coding background.

Now, with a simple click, the add-on checks for duplicate links, lists them along with their anchor references, and allows us to clean up SEO-damaging duplicates in seconds.

This one solution reduced the back-and-forth around duplicate links, improved document quality, and ultimately boosted team efficiency.

Step 1: Defining the requirements

The first step was to clearly define what this add-on needed to do. Here’s the list of features I knew would be useful for my team:

1. Identify Duplicate Links: Scan the document and identify any URLs that appear more than once.
2. Highlight Duplicate Anchor Text: Show the different anchor texts associated with the same link. This helps ensure each link has a unique, descriptive anchor and identifies the instance in the doc.
3. Easily Locatable: Display the duplicates in a sidebar so the team can quickly view and fix them.

Step 2: Coding the add-on

Using Apps Script, I wrote code to:

• access the content of the document
• recursively scan through each link in the document
• aggregate links and their occurrences
• find duplicates and send results to a sidebar

To make the output readable and useful, I added a UI component that lists each duplicate link in a sidebar along with the different anchors within the document.

In this way, anyone using the add-on can easily correct the links without manually clicking links in the entire document.

Here’s a basic outline of what the code looked like for finding duplicates:

function findDuplicateLinks() {
  const body = DocumentApp.getActiveDocument().getBody();
  const textElements = [];

  // Recursively find URLs in document body
  findUrlsInBody(body, textElements);
  
  // Aggregate links and their occurences
  const linkOccurences = textElements.reduce( (acc, { url, text } ) => {
	  if ( !acc[url] ) {
		  acc[url] = [];
	  };
	  
	  acc[url].push(text);
	  
	  return acc; 
	  
  }, {});
  
  // Find duplicates
  const duplicates = Object.entries(linkOccurences).filter( ( [ , texts ] ) => {
	  return texts.length > 1;
  } );
  // Optional formatting 
	const formattedDuplicates = duplicates.map( ( [ url, texts ] ) => {
		return { url, occurences: texts };
	} ); 
  
  // Send results to sidebar
  displayResultsInSidebar(formattedDuplicates);
}

With this, I was able to detect and catalog duplicate links and their associated anchor texts. After that, I built a sidebar UI using HTML to display the results.

Step 3: Testing and publishing the add-on

After the initial build, I tested it quite a bit. I ran the add-on on several documents and tweaked the code to handle edge cases, like links embedded in lists or tables.

The testing phase was crucial to make sure the add-on was robust enough to handle our content and that it wouldn’t cause more issues than it solved.

Note ✏️
This initial QA round is by no means final—more features can be added and some existing features may need tweaking—but it covers current requirements. Every good developer knows that the products you build demand ongoing maintenance to keep them relevant!

When I was satisfied with the performance and dealt with the last tweaks, it was time to publish!

There’s a particular (somewhat nuanced) process for publishing apps/add-ons that access what Google classifies as restrictive APIs.

Since my add-on needs to access Google Docs content and inject a sidebar into the doc, it prompted a user to authenticate using the OAuth screen.

Tip 👀
If your app/add-on requires a user to sign in using their Google credentials, it’s a good sign that you’ll need to get your project reviewed and approved by Google before you can publish for public use.

The submission process involves filling in some information, providing a privacy policy, and uploading a YouTube video showing the product.

It’s certainly a lot of additional steps but a good test to see how committed you are to what you built!

After about two weeks of back and forth with Google reviewers (because terminology and compliance are no joke), I was able to have my add-on published. This, however, didn’t mean it was available for my team to install in their respective Google Docs instances (remember, we’re not using Google Workspace which would have simplified a lot of things if keeping the add-on for internal use only).

Next, I had to list the add-on in the Google Marketplace to make it publicly available. Yet another submission was necessary here with uploaded listing icons, graphics, and information. Additional requirements included a request for a support URL (I used the About Us page here on THT since it’s how you can get in touch!) and terms of service.

By this point, I really considered hiring a lawyer as a personal assistant 🫠

Finally, once the add-on was listed, I rolled it out to the team and trained those who would interact with it on how to use it.

The response was overwhelmingly positive—individuals appreciated the time it saved and how easy it was to catch duplicate links without having to do the “find and scroll” dance manually.

How this add-on changed our workflow

Since implementing this add-on, the team has seen significant improvements in the workflow. Here’s what changed:

1. Faster Review Process: Before the add-on, it could take hours to comb through documents looking for duplicate links. Now, anyone on the team can do it in a matter of seconds cutting back on a lot of unnecessary back-and-forth.
2. Improved SEO and Readability: By reducing duplicate links, we’re keeping our linking practices clean, positively impacting SEO performance. Articles are more readable and less cluttered, a win for us and our readers.
3. Scalability: As our content continues to scale, the add-on will remain a critical tool, ensuring we maintain high standards without bogging down our workflow.

Why building solutions matters (and how it helps your career)

This project wasn’t just about fixing a problem—it was about creating something useful that has practical value.

Here’s why building real solutions is so impactful, both for your learning and your career.

1. You get hands-on experience

There’s no better way to learn than by doing and building something that solves a real problem forces you to dig deeper, research, troubleshoot, and test code in ways that a practice project never will.

This project taught me so much about Google Apps Script, UI development within Google Workspace, and the nuances of automating workflows.

Was I aiming to become a certified Google Apps Script developer? No. Did I utilize existing skills while expanding their scope and picking up a couple of new ones? Yes. Win 🙌

2. You build confidence

Seeing my add-on make a tangible difference to the team’s workflow was a huge confidence boost. It reminded me of the impact we can have with the right skills and a little initiative.

Every time you complete a project like this, you’re building up a portfolio of accomplishments that you can showcase in your resume, during interviews, or even as a freelancer.

And, if it ends in a flop, even better! You can talk about how it could have succeeded and what the failure taught you 💡

Read: Do This One Thing To Overcome Web Dev Jitters

3. It creates a portfolio piece

If you’re looking to break into development, having practical examples of your work is invaluable.

When you build a tool that solves a problem—especially one that others use—you’re showcasing your coding skills and problem-solving abilities and initiative.

There’s nothing better, no tutorial, that can triumph over practical implementation.

4. It teaches you how to work with real constraints

Building for real-world use isn’t just about getting the code right—it’s about building something user-friendly, adaptable, and efficient.

In this case, I had to make sure the add-on was intuitive for my team, that it didn’t slow down their workflow, and that it was easy to implement across multiple documents.

It, further, had to be accessible with the correct safety guards! All these constraints presented a challenge that is very much the reality of developers daily.

Tips for your own problem-solving project

Ready to try building something for yourself? Here are a few tips to help you get started:

1. Identify a real problem: Look around for pain points in your daily life, your job, or even in a hobby. Is there something repetitive or frustrating that can be improved with a bit of automation?
2. Start small and build iteratively: It’s easy to get ambitious, but don’t overwhelm yourself. Start with a simple, working version of your solution and gradually add features as you go.
3. Get feedback: If your tool is for others to use, ask for feedback early on. You’ll learn a lot from seeing how others interact with your creation!
4. Document your process: Keep notes of what you build and the challenges faced while building. Not only will this help you remember what you’ve learned, but it’s also a great reference when you encounter something similar.

Now off you go creating! See ya 👋