Building SERP Sonar: the First 6 Months (From Bitching to Beta)

My journey of building a micro-saas browser app business didn’t really start in the usual way. I had a serious problem that needed to be solved. It wasn’t the first time and, coming into 2022, I felt it more than ever.

Yes, I’d been grumbling (to myself and others) about a bunch of digital marketing challenges and workflow gaps for a long time. I’ve been building content sites in earnest for a few years now (and dabbling for much longer). So I had collected a long list of challenges that other tools weren’t addressing.

But none of these were that serious problem I was just talking about. That ever-growing problem was the need to build. I didn’t just need a solution…I needed to build the solution. 

Building the SERP Sonar app (and Business)

Stop Thinking, Start Building

I didn’t roll out of bed one day deciding to build a free SERP analysis tool. The first time I seriously considered the business opportunity in browser apps was as a result of the Nathan Latka book, “How to Be a Capitalist Without Any Capital.” One of his early successes involved micro M&A in the browser extension space. This made me more aware of the opportunities in this ecosystem. But getting motivated to get to work can be hard.

Fortunately, there were a few other early inspirations that led to starting from scratch and building SERP Sonar. The first was Keywords Everywhere. This unassuming tool is actively used by over 1 million people in the digital marketing space. And it delivers so much value (with more added all the time). I loved the product, but also the slow growth approach.

At the beginning of the year I finally stopped thinking about it and actually started building the browser app that I kept imagining.

Another powerful tool that many in the SEO industry use every day is the Detailed SEO plugin. Before it was widely released, digital marketing legend Glen Allsopp shared this little gem with the students in his SEO Blueprint course (of which I was one). The other inspiration was Kyle Roof and the Page Optimizer Pro business. I’ve had POP for a long time and when they built and launched the companion browser extension I took notice. So, with some dev resourcing tips and encouragement from Kyle I ventured forth.

At the beginning of this year I finally stopped thinking about it and actually started building the browser app that I kept imagining. Work on SERP Sonar began in January, 2022.

Clarify the Idea

To know your goals and business objectives, you have to know your needs and challenges…

SERP Sonar started with a classic ‘scratch your own itch’ issue. I have tried a bunch of tools. Some of these have free product options that have deteriorated in quality or just disappeared altogether over time. 

I know founders and product builders often say this but what I needed really didn’t exist.

There are some other, paid saas apps that offer more costly and sometimes less accurate or effective solutions. I know founders and product builders often say this but what I needed really didn’t exist.

Need to Have vs Nice to Haves

To start I decided to focus on just a couple, specific gap/features that were not out there. The first problem to address was that the ALLINTITLE search operator, commonly used in the keyword golden ratio equation, was broken. It produces seriously inaccurate data. 

There were numerous other ideas for derived analytics as well, based on my finance industry experience. Many of these are still in development.

Another feature I sought revolved around Google title rewrites, as well as page meta description rewrites. There was a large, untapped opportunity there to provide better visibility into what and how Google changed (and try to learn from it). 

There were numerous other ideas for derived analytics as well, based on my finance industry experience. Many of these are still in development. But I decided early on to leave the nice to haves until later.

Building Business Begins

Slow & Meticulous Research, Fast & Sloppy Design…

I did a lot of the research and design work ahead of finding tech resources to build it. I had a good idea of what was possible so lack of actual coding skills was not an issue. But if you give even the best developers a bad spec you will get a bad product. At best, you will pay much more for it than if you drafted a clear and detailed product plan.

I did not do wire frames, a traditional pain points and solutions doc, etc. I also didn’t bother with some of the now-standard product dev tools like Figma, etc.

So, I did provide product mock-ups, (fairly) detailed feature descriptions, and basic user stories. But I did not do wire frames, a traditional pain points and solutions doc, etc. I also didn’t bother with some of the now-standard product dev tools like Figma, etc. I used the Google suite, and that’s it. But I could have done it all much faster.

While I had been collecting notes and ideas for some time, I ended up spending about 2 months with a freelance developer to complete what would become the first ~2 sprints worth of work.

While I had been collecting notes and ideas for some time, I ended up spending about 2 months with a freelance developer to complete what would become the first ~2 sprints worth of work. We could have done most of it in half that time if I pushed harder, but the day job and life got in the way.

Securing Tech Resources

I started the resource search using most of the job posting and gig platforms. Note, however, that I never post jobs. I go and search out good matches based on the project requirements, and other signals found in CVs and (previous) customer reviews.

Perfect spoken language is not essential but certain other communications skills must be strong and this is best identified in a live, face to face setting.

Posting jobs means a flood of enthusiastic but not necessarily qualified candidates. And requires filtering and vetting all of them. Instead, I search and narrow down a short list myself.

I then invite them to the project with a personalized message, and ask for a camera-on live intro call. Perfect spoken language is not essential but certain other communications skills must be strong and this is best identified in a live, face to face setting.

Insights Are Behind the Answers

Clues can be found about some important skills by just reading the CV or reviews. Does their core expertise (tech & business skills) match your project requirements? Have previous client reviews indicated that they deliver work on time and per the spec? Do they have experience managing others (or at least working in a team setting)? 

Are they demonstrating an ability to understand and respond to multi-threaded questions or statements?

Other characteristics can only be identified through live interaction. Do they exhibit an ability to be flexible, but without being too flexible (saying ‘yes’ to everything)? Or, instead, do they come across as confident in their abilities and ready to lead yet seem too rigid and unable to adapt or compromise?

Are they actively listening when you are speaking? I look for people that think before answering, and replying in an engaged way. Are they demonstrating an ability to understand and respond to multi-threaded questions or statements? Sometimes multi-layered dialogue will be hard for non-native speakers, so if someone checks the other boxes I will see if they can at least do this in written communications. 

After ~2 sprints worth of work we decided to add another resource, and that has added both dev cycles and redundancy…

In the end, I found a few guys that are all talented and experienced. It was a close race but I think I got the best one for me and this project. After ~2 sprints worth of work we decided to add another resource, and that has added both dev cycles and redundancy (since my tech lead is expecting a baby soon).

Product Dev Toolkit & Workflow

I have decades of product dev and management experience but mostly in a corporate context. And the tooling and constraints there are quite different than with a bootstrapped, ultra-lean startup. But there are still a ton of commonalities. 

Our current workflow draws on the experiences of both the tech team and my own priorities. And my focus is on both ease of operations in the short term and longer term data and information management, to best scale as the product and business evolves into the future.

Current Tools and Platforms In Use

• Gig Platforms for resource recruiting (% of transaction);
• Google Docs/Sheets/Slides for initial brainstorming and planning (free);
• Google Meet for sprint kick-off calls (free);
• Slack for ongoing communications (free);
• Jira for ticket tracking (free);
• BitBucket for code repository (free);
• Wise for payment transfers (% of transaction);
• WP/Gutenberg for site management w/entry level hosting (standard hosting $);
• Lead capture via simple mailto type forms in WP for beta user sign-ups; 
• Email… None. I am directly emailing beta users, but will get a proper EMS soon.

For our dev workflow we are following an agile-style approach, from a ticket/sprint and recurring status update standpoint. Based on having waaaayy too many enhancements and features on the roadmap, and not enough time or users (yet) to validate and test them, I am intentionally slowing the dev–deploy-iterate process.

A continuous deployment approach would be nice but we (the business side, at least) are nowhere close to that yet.

This allows me to better bucket complimentary features and plan stories for marketing SERP Sonar. A continuous deployment approach would be nice but we (the business side, at least) are nowhere close to that yet.

Site Build & App Pre-Launch

As development on the browser extension continued, while waiting on early package builds, I worked on the site plan and content marketing strategy. 

From early on I had ideas for niched down content pieces and in-depth research studies. I could start with the former based on my experience, and the browser app would help facilitate the latter, in time. Another key function of the site was to collect “early access” beta users, which we did, slowly but surely. 

I took the extra time and cost of working through him to do the initial build, and then took delivery of the site.

I wanted a fairly standard site architecture and design, to keep the focus on the content and the product. And, while I have built all my previous sites myself, for this site build-out I sought out help. I have been meaning to bite the bullet and get on Gutenberg so I used the opportunity to find/hire a web dev that had the core skills to help tutor and guide me.

I took the extra time and cost of working through him to do the initial build, and then took delivery of the site. This allowed me to leverage his guidance when I got stuck on something, and learn Gutenberg by doing (but not have to build from scratch).

The site served its initial purpose well, acting as a platform for beta user signups and information sharing.

As expected, I had lots of questions about blocks in general and Kadence in particular, which he helped with. I really liked working with the guy and plan to use him for future builds and migrations. I also invested in some one-off design services for the logo and some related collateral. Additionally, I used a brand new hosting company for this project, in part to diversify (away from the main one I currently use) and also to keep a clear line of delineation between my content sites and this micro saas business.

The site served its initial purpose well, acting as a platform for beta user signups and information sharing. There were no indexing issues and, for the relatively niched down subject matter, we got relatively high ranking for the early posts.

…since no one is paying, I wasn’t worried…

Annnnd We’re Live (in Beta)

When is enough enough? There is no hard rule about when a product like this can or should be released. Especially given that this is a free browser extension delivering somewhat novel functionality, reputational risk is not really a concern. And since no one is paying, I wasn’t worried about refunds, etc. But I want SERP Sonar to be awesome. I want it to kick ass. 

In my experience every tech project has at least one major bug or speed bump. If this is ours then I consider us lucky. 

So, I settled on a certain subset of features and planned to move into ‘open beta’ once those were delivered. Over about 4 months (of active development) we completed ~4 rounds or sprints of work to get to that point. 

This could have been achieved in less time were it not for my own external schedule and energy limits. We also encountered (are are still working on) an occasional problem that causes the app to continue scanning. In my experience every tech project has at least one major bug or speed bump. If this is ours then I consider us lucky. 

Early Feedback Is Positive

The feedback from the initial users has been very positive; it’s clear that I am not alone in my needs and the early users are super engaged. I was also able to leverage the plugin in a research report I did for the Internet Marketing Gold SEO testing community. This effort gave way to a whole bunch of new use cases and ideas. 

…maybe they are all different from each other, so its hard to really compare.

So, I guess the path to launching SERP Sonar is not so different than that of other, similar businesses. Or maybe they are all different from each other, so its hard to really compare. Regardless, if you are interested in following along as we build out the business, I will definitely provide another update in the next 6 months (or sooner). 

And if you have read this far and have an interest, please sign up to get the browser extension for yourself. Thanks!