Rapid changes are sometimes scary. While working with AI is fun, it can also cause stress because it’s impossible to keep up with all the changes. Opening Twitter in the morning can lead to a mini panic attack because you missed new models that are way better than yesterday’s ones, Anthropic announced new deadlines for using their mythical models, new prompts that build products in one shot, tools, benchmarks, etc. Everything seems to be moving so fast that you forget you are in a bubble. Not the one that will burst tomorrow, but a bubble of early adopters.

Hamsters running

While this flood of daily updates often brings mostly noise, the effects, benefits, and downsides of AI and LLMs are real. They have already affected many things. Including changing the way we build products, especially software. One of the natural consequences of these changes is that now is probably the best time to build your own product. Not the easiest time. That does not exist. Building products is playing the game on hard mode.

Let me tell you a story of a product that my co-founder, Lav, and I recently built. It’s a bit weird to write a long-form text by hand while multiple agents write and publish the code and new pages for our marketing site, but not all stories can and should be told by AI.

Did AI shift the bottleneck for building products?

As the amazing book The Goal told us many, many years ago: there’s one main limiting factor for all organizations and for building anything. The book introduces the Theory of Constraints (TOC), which explains that we can move as fast as our main limiting factor (the bottleneck) allows.

Building products has always been hard, and many things have been real bottlenecks. Starting from the idea, then your investment (time and money spent building the product), taste and organization (what to build and how), actual product building (software development, design, testing, etc.), to the whole go-to-market motion (who do you sell the product to and how do you find people that would actually pay for it). But only one of these is the bottleneck for each organization. E.g., some organizations can add developers, designers, or testers, remove items from the backlog, or change how they manage products and projects to ship features faster and speed up the production pipeline, and make their production local bottleneck less restrictive. However, even with that, go-to-market may still be a bottleneck for them. Or you might have limited time to just a few hours each week, and no budget to hire anyone else, and no way to free up more time.

The actual bottleneck varies from organization to organization and from product to product. But, if we need to pick the most common one, it’s probably go-to-market. Building products is hard, but selling them - unless you are one of the lucky marketing and sales masters, it’s extremely hard.

So, did AI shift the bottleneck?

The answer is probably yes, but depending on your bottleneck, that could be good or bad news. Let me explain!

If your actual bottleneck was a lack of time for development, I have good news for you! AI can help you write code, design the app, write marketing copy, and even test the app.

But I also have bad news.

One of my favorite laws is the now 30-year-old Tog’s Law of Commuting, which pairs with Tesler’s Law of Conservation of Complexity: “The time of a commute is fixed. Only the distance is variable.” To put it in current terms: if we can write code and ship features faster, we won’t stop with the same amount of code/features as before and go fishing. Instead, we’ll spend the same time either shipping more features or code, or building other things.

That’s not bad news - you can do more by yourself! But the bad news is that others can too. So, the go-to-market strategy becomes an even bigger bottleneck, as it’s hard to reach the right potential customers and cut through all the noise and actual competitors.

Bottlenecks

Ok, but building products is faster now, right? If that guy on Twitter one-shotted the whole application using Claude Fable 5, everyone could do that, right? Well, not really. There’s a big difference between an amazing demo app and a product. But let me tell you our backstory first.

Backstory

As mentioned in my previous article, “Employees, AI, and AI employees,” more than 3 years ago, my cofounder, Lav, and I tried to create an AI cofounder (CofounderGPT, as we called it), had a lot of fun, and failed. Well, to be honest, that’s not 100% true anymore, as we have had an AI agent called CofounderGPT working with us for the last 6 months, and it played a big role in building our new product, but we’ll talk about that later. In the meantime, if you are curious, check https://cofoundergpt.ai for CofounderGPT’s weekly log. But let’s get back to the “origin” story.

Everything started with our own AI experiments. However, because the time we could spend building fun stuff with AI was our main bottleneck at the time, we hired someone and started an “R&D department.” That was fun, as we managed to rebuild some of the cool demos from Twitter (and most of them were cool only as demos and magic tricks), try out different models, and even fine-tune a few.

Finally, we started working on CofounderGPT and building a small product with AI. Both things failed because you can’t really outsource product building, especially not in an emerging market like LLMs. Also, we were not patient enough. We wanted better models, and, at that time, thought that we were already late.

We still want to build a product with AI. But we needed to narrow it down. What if, instead of building the whole CofounderGPT, we built one small component? Something that would solve our problem, save our time, and give us better insights. There were many ideas, but one was focusing on an annoying problem that we had - someone needed to check our direct and indirect competitors’ websites, present the most important changes, and maintain that big and always outdated spreadsheet.

What an amazing job for an AI! And it should be easy. Famous last words.

After months of working on this, among other AI experiments, and with multiple people who worked on it, the results were disappointing. The tool worked, but it was picking up too much noise, and filtering out the noise is literally the main job it needs to do perfectly. Eventually, we closed the “R&D department,” and almost abandoned the idea.

Luckily, someone introduced us to a team of young, smart people who focused solely on AI. They said they could build this tool, and they actually delivered in less than 2 months. We decided to focus on its core function and remove everything nonessential. But we had a working version in September 2025.

The key part of the app was an email that you receive every Monday. It’s a tailored “newsletter” that tells you about all the key changes your competitors made over the past 7 days. They even added a brilliant feature - when you add competitors, they try to get an older version of their website from the Internet Wayback Machine so you can see a preview without waiting a week or longer. We set up Vacation Tracker’s competitors and invited a few friends to test it out. Then we almost forgot about it.

As time passed, priorities pushed the new product down the list. But we continued reading these Monday emails. Eventually, Lav and I managed to free up some time and decided to build some new products and retest the idea that we can build and maintain a product with AI alone. We needed a playground, and Competitor Tracker was a perfect one.

It took longer than I expected. Two months from the first prompt to a fully working product with a website that follows the brand voice and style and is indexed. The main problems that slowed us down are time, numerous unexpected roadblocks (crawling, various errors, timeouts, noise, etc.), and the use of Cloudflare, a platform I’m less familiar with than AWS. More on these choices below.

So, is it ready now?

Introducing Competitor Tracker

We can finally introduce our new product: Competitor Tracker! Competitor Tracker is an application that helps you - track your competitors. We are not very creative with names, obviously. Actually, figuring out the best name is not part of the MVP, at least not in our case. We can figure that out later if needed.

But Competitor Tracker, or, to be on-brand, Competitor Tracker & Co., is more than just another application that tracks competitors. The world changed with AI, so we built this product to be equally human and AI-friendly.

What does that even mean?

First, everything is an API (with detailed scope-based permissions). You can use the API with OAuth2 or an API key, but you can do absolutely everything using the API. That does not make the product AI-friendly, but if everything starts with an API and detailed documentation, then you are going in the right direction.

Then, the web app and MCP use that AI to expose all the functionality to humans and agents. Everything you can do from the web dashboard, your agent can do via MCP. No exceptions.

Competitor Tracker sends you a digest email every Monday. But agents get a webhook, so you do not need to give them access to your inbox. Same data, same filters, same time.

Finally, the website is built for humans and agents. We serve markdown for agents and HTML for humans. If you want to test it out, there’s a switch at the bottom of every page that helps you enter the Matrix. Pardon, it helps you see the “AI agent” view.

Besides humans and agents, we also have a dog - C. T. Lucky is our lead detective who guides you through our new noir platform and sends you Monday “dossiers.” It’s an AI dog, but still a good one.

So, it’s time - meet Competitor Tracker & Co.: the AI agency whose pack of agents tails your competitors’ public pages all week and files one short, ranked dossier every Monday, so your team reads the moves that matter instead of babysitting another alert feed - https://competitortracker.io.

Meet C. T. Lucky and Competitor Tracker & Co.

If you want to meet C. T. Lucky and Competitor Tracker & Co., head to the “What is Competitor Tracker & Co.” page, see what our pack of agents can do, or check out the product demo (for humans and agents) and try it out (it takes a few minutes to set it up, and the first 25 coins are on the house).

Building Competitor Tracker

I saw an amazing tweet yesterday: https://x.com/krishdotdev/status/2077723982028210381.

It’s almost perfectly aligned with my experience building products with AI so far. You need an idea and a few hours for a breathtaking demo. Then you need months to finish the last 10%. Of course, that’s not a real 10%, it’s an illusion that tricks you into thinking you can do everything almost instantly.

I would go a step further and say that you need a few hours for a demo, a few weeks to implement 200% of the code, and then months to clean up all the AI slop and replace a small part of it with working features.

Idea -> Demo -> Done timeline

Image based on: https://x.com/krishdotdev/status/2077723982028210381.

Something similar happened to Competitor Tracker. But that wasn’t the fun part of the journey.

Personally, the fun part was setting everything up.

And everything started with a brand decision. I tried out a few styles, and the film noir one looked like the best fit. At the same time, I asked Claude Code to prepare the initial set of documents based on the prototype source code.

Then, because I know that Lav will connect his Hermes and OpenClaw agents to the repo, I decided to separate the product and marketing website repositories. Don’t get me wrong, I like both Hermes and OpenClaw, but I do not trust any AI agent with the full set of permissions.

The next step was picking up the platform. AWS was an obvious choice, as I know it well enough. But obvious choices are not fun. To make the process more fun and learn something new, I picked Cloudflare instead.

Why Cloudflare? I wanted to try it out for a long time. I know a few smart people who work there, and some other smart people I respect praised it. That was already a good excuse to try it out. However, there’s also another, probably even more important perspective: AWS was too low-level for this application, and Cloudflare has most of the critical pieces as services: Workers for compute, Browser Run for scraping, AI Gateway for accessing AI agents, R2 for file storage, and Email service for sending weekly emails. All boxes checked. The best of all was being able to calculate the exact cost of the system on a single platform and decide on the pricing for Competitor Tracker.

Cloudflare has its downsides, too. AWS is superior in many areas, including fine-grained permissions, monitoring, sub-accounts (staging, etc.), and more. E.g., AWS is a way better platform for our other product - Vacation Tracker. But Cloudflare still seems like a perfect fit for Competitor Tracker.

After selecting the platform, setting up tooling, a CI/CD pipeline, and a staging environment, and configuring all critical verifications and tests, it was time to onboard Lav’s agents.

And then, the magic started happening. Claude Code was in charge of features. Open Code with GLM-5.2 joined as a collaborator (and impressed me as I didn’t expect much). ChatGPT helped with images and to stay on brand. Hermes and OpenClaw started filling in the marketing website’s missing pieces and occasionally even worked on the product.

We finally migrated all the existing users to a new platform almost a month ago. And we had our first sign-up from someone we do not know! We also invited a few more friends, gathered some feedback, and made a few improvements to the platform. Then, we went on vacation. Well, it’s important to rest, probably even more important now with AI, because you can accomplish more when you are focused.

But now that vacation is over, it’s time to continue. The product seems stable enough. A limited number of users are onboarded, and we already track more than 2,000 companies! The goal is to track more than 130 industries and build quarterly industry overview pages. You can see the first ~30 of them on our website. It’s time to focus on the marketing. But before we do that, let’s talk about the architecture and how we set everything up.

Architecture

As I already explained, we picked Cloudflare this time. We could use a mix of AWS and Cloudflare to get the best of both worlds, but I prefer having a single platform for most of the infrastructure. You can call that vendor lock-in if you’d like (but our AWS bill of 1-1.5% of Vacation Tracker’s MRR after 8 years does not really care), or a single point of failure (but when Cloudflare or AWS are down, you probably have more significant problems than not being able to access the Competitor Tracker API). Still, these are all tradeoffs that we are willing to make. You can also argue that this could be a much simpler app on a Hetzner instance, but I still have PTSD from years of figuring out why the app crashed at 10 PM, and this is also more fun anyway.

An oversimplified architecture would look like the following diagram.

Competitor Tracker architecture

In short:

  1. The Competitor Tracker app treats humans and AI agents as equal users.
  2. Humans can use either the web dashboard or an API. Or they can simply talk to their favorite AI agents.
  3. AI Agents use the API or the MCP.
  4. Our marketing website is created for both humans and agents. We serve HTML to humans and Markdown to AI agents (based on the browser user agent). You can also test both views by switching from the “In person” (human) view to the “By wire” (AI agent) view.
  5. The Web dashboard is a React application served via Cloudflare Pages. There’s nothing especially interesting there.
  6. MCP is a Node.js application that runs in a Cloudflare Worker. It supports all auth types (OAuth2 and API key) and all cool things we found.
  7. Both the web dashboard and MCP use the Competitor Tracker API. Everything you do in Competitor Tracker you can do using our API. The public one.
  8. We also run multiple AI agents that work on a marketing website and use the API to fill in the data. Of course, agents work on the app, too. I personally wrote up to 3 lines of code. It was faster than explaining to my coding agent what to change.
  9. API is another Node.js app in a Cloudflare Worker. It uses the OpenAPI spec, which also generates up-to-date API docs with each deployment. The API docs worker is not in the diagram, but it uses fumadocs, and it’s built as a static app (I am not a fan of SSR React apps). The API requires either a bearer token or an API key.
  10. A dedicated auth worker is the identity provider for all apps: a self-hosted OAuth 2.0/OIDC server with passwordless email login and PKCE-secured authorization-code flow, issuing short-lived ES256 JWTs with rotating refresh tokens. It supports Dynamic Client Registration and standard discovery, so clients like the MCP server can register themselves and validate tokens against its JWKS with zero manual setup.
  11. The core of the system is another Cloudflare Worker that hosts the scraper. The scraper runs on a schedule and uses Cloudflare Browser Run and a few backup systems to convert all websites into HTML snapshots, screenshots, and markdown files. This is the most complex part of the system, as it handles the business logic, AI interactions, data storage, and all workflows with retries and self-recovery mechanisms.
  12. As already mentioned, the scraper uses multiple AI models to detect changes and filter out the noise. We decided to use the Cloudflare AI Gateway for everything so we can easily calculate the cost of each competitor we track.
  13. All pages (HTML and markdown files, and screenshots) are stored in the archive (Cloudflare R2).
  14. All changes and metadata are stored in the SQLite database (D1).
  15. Each Monday, another Cloudflare worker uses AI (via AI Gateway) to prepare Monday dossiers for humans and agents.
  16. Once the dossier is ready, humans receive emails on Monday morning (via Cloudflare Email service).
  17. At the same time, your AI agents receive the same dossier via webhook event.

Of course, there’s much more than this. We needed observability, alerts, fallbacks, Slack integration, CI/CD, multiple coding agents, etc.

How things work

The idea is simple: outsource as much as possible to AI agents while still maintaining control over output quality. Or, to get back to our bottlenecks story from the beginning of this article: optimize the flow around our time, focus, and taste to maximize that local bottleneck as much as possible.

What does that mean in practice? Many things, but the most important is the ability to verify the output of all our AI agents (coding and others) as much as possible before we review it. Ok, that seems logical, but how do you do that? By adding another LLM to check the output?

No, not really. LLMs are not deterministic, which means that asking it the same question 10 times yields (often many) different answers. And that’s the main reason why they feel magical, and it’s also the main reason why you can’t just trust them. However, adding another LLM (even a different one) to verify the first LLM’s output does not fix the problem. It probably helps in many cases, but not in 100% of the cases. And when you know there’s a small chance that it can generate some weird output that can hurt your business, you need to keep your attention on 100% to be able to catch that if or when it happens.

However, there’s one powerful tool that we use every day that can convert some of these checks to deterministic ones - a linter. When you write your code, you often have formatters (e.g., prettier, or in our case oxfmt) and linters (e.g., eslint, or in our case oxlint) that format your code and check if it follows the rules. Luckily, most of these formatters and linters are extendable - you can create a JavaScript plugin that checks your specific thing. But writing these plugins is not always easy and pleasant. But, again, luckily, your AI coding agent is quite good at writing these.

With these deterministic checks, we can verify expected outcomes, such as whether our code follows the architecture guidelines (e.g., hexagonal architecture), whether migrations are destructive (we use deprecate-then-drop), and whether CSP is up to date. However, we also do deterministic checks for less common things, such as the voice of the application (we check for some specific words, and ban them, e.g., “harness,” that one is my favorite), or if our developer documentation leaks the implementation details (e.g., Cloudflare Workers, D1 database, R2, etc.).

These deterministic checks catch many problematic issues before they reach our review. We also run them as part of the CI/CD pipeline, so we can let agents do more, since they know how to recover.

On recovery, we also try to make linter errors as descriptive as possible and include the instructions on what to do instead. For example, instead of saying “destructive migrations are not allowed,” we say “stop using X in a prior commit … then land this destructive migration in a later commit,” and, when applicable, tell the agent about the escape hatch.

But why stop there? These error hints are useful for both AI agents and humans, so we also baked them into the product. Each product error also returns the resolution hint.

In addition to deterministic checks, we build various tools for our agents. We have tools that gather data and generate specific pages, tools for videos, tools for SEO checks, etc. The goal of these tools is to save our time and ensure that the agents have all the correct information. Then we use our time to review the output and do things agents can’t.

Another big benefit in the age of AI agents is having the whole product in a monorepo. Your agent can verify features and capabilities before describing them on the product page, etc. You can also ask them to provide screenshots or even videos as part of the task to visually verify their work before running everything.

Finally, you can also benefit from the specific cron jobs and background tasks, or, as they call them today, loops.

For example, if you report the issue via our dashboard or an API (everything is an API, remember), it goes to our Linear board. Once Lav or I review these issues, we add additional instructions and the “autofix” label. Then our AI agents pick these up in the background, fix them, make a pull request, and provide screenshots or videos.

We use Linear for issues and an amazing new product called Votito for product feedback and surveys. Votito allows you to score ideas from the idea bank using the Impact x Confidence x Ease (ICE) score by uploading documents such as A/B tests, market data, and usability studies. One of the future experiments is to try to make another background process that checks Votito for all ideas with a score over, e.g., 75, and builds them. We would still need to be in the driver’s seat and provide some of these documents, but it would be more fun.

Lessons learned

It’s still too early for a definite list of lessons, but so far, the key learnings are:

  • Deterministic checks save you a lot of time. They can be linter plugins, or Claude Code PreToolUse/PostToolUse hooks. It does not matter, as long as they work for your setup.
  • Descriptive errors with resolution hints help your AI agents (and also your users) to recover without bugging you.
  • Monorepos give AI agents additional superpowers. E.g., your marketing agent knows how the product works. This also works for humans.
  • Build custom tools for your agents and your setup. They’ll speed you up, allow you to change agents, and give you better outputs.
  • Build cron jobs and background processes that can do things that do not need your input. Your AI agents can prepare everything and send it to you for a review.
  • Have fun, because building with AI is fun! And it seems that our CofounderGPT might be possible, but not in the way we first imagined.

Or, as they say on Twitter lately: build your own harness and loops :D

But also be careful, because there are real people using your product. Beyond having fun, it needs to solve real-world problems. No one likes using AI slop.

What’s next

The potential roadmap is long, but our next step is to validate our product-market fit. This will probably mean the focus will be on marketing rather than the product. That’s also fun, and we have many ideas we want to try.

If we manage to automate Competitor Tracker enough, and if Vacation Tracker allows, we might build some other products, too. I’ll keep you posted.

And for you? Have fun and build cool and useful things. And, if you have competitors, you know, track them. I know a guy, pardon, a dog detective who can help you.