Lessons Learned: Building Simple SEO Tools

Almost a month ago, we released the anchor text tool, a simple URL by URL anchor text analyser that plugs in to the Anchor Text Linkscape API.

If I’m honest, the tool was as much a learning device for future tool development as it was an opportunity to give something back to the community. I definitely think there’s a ton of scope for other SEO folks out there to experiment with building their own SEO tools without any formal development skills, and I think that they should!

On that note, let me share some learning and explain how the tool was built.
Set some early objectives and principles

A great starting point for your embryonic tool idea is to write a few, clear objectives for the tool. Right at the start, you’ll have a set of principles to adhere to, and objectives to review at the end of your work. Even if the objectives can be really simple, for example “the user should receive their data with as few clicks as possible”, is a pretty reasonable objective for a small project.
Don’t make assumptions

One of the first, and probably biggest mistakes I made was to assume something about the data output of the API. That assumption cost a little time to resolve, delaying the launch of the tool. I know how obvious this is about to sound, but I’ll say it anyway: read the API documentation, then read it again. Is the tool you’re about to build even possible within the limits of the API output, your development resource and budget?
Mock up your UI

If I could go back and do one thing first, it would have been mock-ups. What could possibly go wrong with such a simple idea? You don’t have to be a design genius to create a decent mockup, especially not with the plethora of UI and wireframing tools available for free. A good friend of mine (who happens to be a Ruby developer) insists on basic UI mock-ups at the beginning of a project, even for the simplest developments.

Why? In his words:

“Some of the things you learn from reviewing the UI can influence fundamental aspects of the database and code design. Having to add / remove items at a later date because the mock ups were inadequate can be murder.”

Write a clear specification

Using the UI as a starting point, writing a clear specification should be easy. You don’t have to create a literary masterpiece, just an outline of the core purpose of the tool, and what each control should do. Don’t forget the outputs, specifying exactly how you’d like the user to see or interact with their results.
Set limitations in the specification

The full Site Intelligence API service will happily play back a lot of data, if you ask it to. Obviously a public (free) version of the tool can’t just give away every single detail in the Linkscape API, but because of a lack of instruction on the maximum input URLs and the maximum results, the test version of the tool would happily play everything back in one go. The initial version had no upper limit on the URLs you could paste in, slowing the tool down for thousands of URL requests.
Think about performance

If I could start again on the build of the tool, I’d ask that some kind of stress testing work was carried out in QA. Again, I know how obvious it sounds to state: “make your tool able to cope with multiple users” but initially, the test version of our tool was quite poor under load.


Get a freelance developer

If you don’t have an in-house developer, no problem. Brief your project in at Freelancer.com or Odesk targeting suppliers with a minimum level of feedback. You can make projects non public, and if you’ve had recommendations from friends on good developers to use on either network you can reach out to them individually.

The first project you embark on can be daunting and to some extent can feel a bit like a gamble. Frankly, it is a gamble – a risk mitigated by experience and support from friends. I think it’s definitely worth having a go though, if you have a tool idea, see what you can do for $250!