Here are 17 lessons I learnt the hard way over the course of 1.5 year by launching my first business, a Google position tracker SaaS for SEO professionals.

The project #

Genesis #

A friend of mine who works in SEO reached out to ask how difficult it would be to build a Google position tracking software and how much it would cost. It’s one of the main tools for SEO professionals and from his experience these tools were often unreliable and overpriced. Which was true… at least at the beginning, in 2024.

I told him it was doable, but still, that it required a significant amount of work and would be way too big of a project and too expensive if I did it as a freelance job. Instead, I suggested we team up and build a company around that project. As the project was big, and we were doing it in addition to our full-time employee jobs, we also recruited another friend to work on the tech part with me, making it a team of 3.

We started working on it in June 2024.

Final tech stack #

By the time we released the product, we had:

• A Scraper capable of scraping Google pages (written in Python as the scraping ecosystem is richer in Python)
• An Engine ingesting the scraping results and computing the business metrics (written in Golang for a more robust/maintainable codebase and better performances than Python for the computation part)
• A component (that we called the “Fetcher”) to fetch useful data (e.g. CPC) not directly found in Google pages from external sources (written in Python as it was a small component not meant to grow, Golang would have been slower to develop for no real added benefit).
• An API gluing everything together and handling user accounts, payments, etc. (written in Python/Django to build fast – TypeScript/Hono/MikroORM would probably be my choice now as it allows to build as fast but with much more robust practices thanks to the strong & static typing of TypeScript).
• A web application (in TypeScript/React)
• Infrastructure in OVH Cloud (dedicated servers in a private network using OVH Private Cloud services and infrastructure as code with Terraform)

And here’s what the product looked like (it actually worked pretty well!):

The lessons #

Product development #

Biggest lesson: choose your dependencies wisely #

Our business relied entirely on scraping Google, to then be able to compute metrics the customers are interested in. The issue is: Google didn’t want us to do that. Google, like most services, doesn’t want anyone to scrape their data. Founding a business on something you cannot control is a big risk: it’s hard (you’re constantly playing an attack-defense game), and it’s unpredictable.

That being said, it can also be a perk for the same reasons. For many years (early 2000s to beginning of the AI era), the Google keyword tracking business was very lucrative as Google didn’t really care about scraping, probably because it didn’t cause them much trouble at the time.

However, with AI came the need for massive datasets to train models, and this time Google decided scraping was a big issue and invested into anti-scraping. Multiple mechanisms were deployed in 2024, 2025 and 2026, each of them making it harder and more expensive to scrape Google.

Big risks, big rewards, but in our case, we unfortunately started in the business at the worst time possible (just after the beginning of the AI era) and lost it all.

Ship an MVP fast (basic but very true) #

If for some reason the product requires a long development cycle (e.g. because a lot of features are needed to be even considered by prospects due to existing competitor products), perhaps it is time to rethink the project entirely. Investing months or years of your life into something that potentially no one will ever care about is not wise.

Plus, it is impossible to know for sure what the customers actually want and whether the market is ready or not for that product. Developing features blindly is almost guaranteed to result in a significant loss of time. Worse, if that “great feature” has an impact on your operating costs, you could be increasing prices for something the customer does not want. Getting feedbacks is a priority as it will help drive the product development in the good direction.

Time is precious. Get feedbacks ASAP and pivot or shutdown the project if needed.

Trust only the feedbacks of money #

Be very cautious with the feedbacks of friends or family (or anyone that is not actually paying for your product), especially if they’re positive. Giving a positive feedback is usually easier for people close to you than giving a negative one, and it is cheap (it’s free, actually), but you expect your customers to pay real money, so listen to them instead.

Take great care of UI and UX #

You know your product by heart, spent hundreds of hours on it, and have decent hardware (e.g. a modern screen with a decent size and resolution, a reasonably fast processor, enough RAM). Your customers may not have any of that and will give you a few seconds, or a few minutes at most, to convince them the product is good. If they don’t know where to click, if the UI is not responsive to their screen resolution, or if the app is too slow: they will leave instantly and may never come back.

A great tool for checking all this (customer behavior, whether the app works well or not, etc.) is PostHog with their Session Replay tool. Their free tier is generous and allowed us to spot many issues we didn’t even think of before releasing the product.

Define pricing model carefully from the beginning #

Getting the right pricing model for a product is hard (there are many models and factors to consider), and it almost always impacts development, so try to get it right from the beginning. For example, if there are different plans/packs which give access to different product features, the engineering team needs to implement something that grants/blocks access to these features.

• PAYGO → impacts development
• Plan system with different features → impacts development
• Trial period → can impact development
• Discounts → can impact development

Customer migration effort #

If your product requires some sort of heavy setup on the customer side (e.g. in our case, have thousands of keywords imported and configured in the tool), this is a significant barrier to entry for your customers. Even if they say their current solution/provider is suboptimal, the question is: is the pain with their current solution greater than the pain of going through the tool migration? Plus, they could also lose their historical data when changing providers (which was our case). If there is some sort of migration required, you should study the possibility of developing an easy tool to migrate, without which you risk losing many prospects.

Be aware of cloud costs #

Computing power is extremely expensive in the cloud (3 to 5 times the price of bare-metal). If you’re self-funded and/or you already have competitors which require you to have low operating costs, then you might not be able to do it in the cloud. Depending on your usage, you can still use other cloud services such as queues, object storage, etc., but perhaps not computing.

Choice of cloud vs. bare-metal needs to be carefully studied service by service based on constraints:

• Funding (costs might not be an issue yet if you’re VC-funded or have significant initial “love money”)
• Deadlines (development is usually faster in the cloud)
• Technical needs

Prefer statically typed programming languages #

This is a purely technical topic, but which can greatly impact product development and timelines. When in the rush of developing a new product with tight deadlines, code isn’t always well-structured and documented. Using a statically typed language like Golang, or even better, TypeScript, makes it much easier to onboard new people on the project but also to keep a steady productivity as an existing contributor who has several codebases to maintain with lots of context. Not only it is easier to navigate in the code, but errors are caught early on (not in production by your first customers).

Finance #

How to split equity #

Every first time founder wonders how to split equity. After this first experience, I believe equity is what people risk and bring before launch, not after. Why? Because once the product is launched, either:

• It is somewhat successful, and it quickly becomes “easy” to work on it as risk of failure is much lower.
• It is a failure and the people who were meant to work on it or bring something after launch won’t have to do anything – or at least not for long. In either case, the people who are supposed to bring significant work/risk after the launch don’t lose much, that’s why they shouldn’t get much equity either.

Converting prospects into customers takes time #

Studies show (and my experience is the same) that for SMBs (<$10k ACV), it takes ~4 weeks (2 to 6 weeks) from first contact to signature/payment. That means if you have a 3 months runway at launch (because you’re self-funded, have significant expenses, don’t have tons of cash…), your runway is actually closer to 2 months. For mid-market and enterprise, it is even worse: deals can take months, or even more than a year. Take into account in your runway the time required to turn prospects into customers.

Company management #

No one should be IDLE #

No one in the team should be IDLE for long while others are working: there is always work, whether it’s in engineering, marketing, company paperwork, product strategy, regardless of the stage the company is at. Having part of the team not working is a very effective way to demotivate others.

Set clear expectations, hold people accountable #

Goals and their deadlines should be clear to everyone. If a deadline is missed, hold the people responsible for it accountable right away. Do not wait or “give another chance”. Time is precious.

Anticipate administrative delays #

Bank and company registration can take more than a month (although this may vary depending on country and period of the year) just to get the company registered. Then, there can be additional delays, e.g. if you want to set up a Stripe account to receive payments. Paperwork and administrative processes take time. Anticipate delays.

Marketing #

Track users origin #

You will probably have several marketing strategies: emailing campaigns, influencers, direct reach on LinkedIn, etc. It is very important to be able to track where users come from, otherwise you won’t know what’s working and what’s not. Worse, you could be paying an influencer who actually doesn’t bring you any customer because their audience is not your main target.

Emailing campaigns have very low efficiency #

Average conversion rate from an email sent to a somewhat qualified lead (i.e. a person who has an interest in the topic, not yet in the product) is anywhere in the range 0.5-5%. This means that on 1000 unique email addresses (which can already be hard to gather depending on the size of the market), only 5 to 50 people will register. Then, 2% to 20% of these people will actually buy a subscription. In the end, you can expect to have between 0.01% and 1% of paying users, i.e. 0 to 10 paying users for 1000 unique email addresses.

I know the range (0.01-1.00%) is large, but it varies widely depending on many factors: sector, email quality, domain reputation, etc.

General #

No wishful thinking, only trust the data #

Listen to no one, including a founder, saying that “X” or “Y” is true for sure (e.g. “everyone wants this feature for sure”, “there is no doubt we’ll get to 4k MRR within 2 months at launch”, etc.). There are usually lots of parameters you cannot control in these statements and no one knows the future. Rely only on data. If there is no data, work on getting some. For example, survey qualified prospects to validate or choose between features before starting development.

Understand and verify the data #

Having numbers in an Excel sheet doesn’t mean you have reliable data. Numbers can be manipulated, or even plain wrong. Make sure you understand the data before you use it for anything.

Conclusion #

Launching a business for the first time is definitely not straightforward, very time-consuming and also pretty expensive. I spent over 1,000 hours on the project, and we spent (i.e. lost) in total close to 10,000€ in 1.5 year when counting everything: company registration, bank and accountant fees, infrastructure, other providers, company dissolution.

On the positive side, the product worked well, had several happy customers, and most of all it was an incredibly valuable learning journey.

I’m looking forward to apply all these lessons to the next project!