DEV Community: Seb Hoek

AI created slow and expensive code. How I analyzed and fixed it.

Seb Hoek — Sun, 19 Apr 2026 08:30:04 +0000

My AI-built browser game portal was growing. That was good news - until Firebase bills started rising and performance got worse.

Now was the moment where I as a software engineer had to step in.

With an increasing user base playing more and more games every day, I slipped out of the free usage tier for Firebase Storage which I use for persistency.

Image: The costs increased to about 10 USD per months with a clear upward trend

Also, I noticed that the perceived performance of my HTTP services degraded over time.

This is less than optimal. What happened? It probably had to do with how AI has set up the HTTP requests and database queries.

How can I investigate the causes and what can I do to fix it? Let's dive into it!

Content

Finding the real bottlenecks
Problem #1: A nightly job burning reads
Problem #2: One endpoint doing too much
Problem #3: Random seeds were surprisingly expensive
Back to free tier
Conclusion

Finding the real bottlenecks

For me, observability is one of the most useful tools for finding and understanding problems.

Rather than guessing, I used three sources of data:

Google Cloud Billing Reports to see where costs came from
Firestore Query Insights to identify expensive collections
API latency metrics in Google Cloud Observability to spot slow endpoints

What the metrics revealed

The billing report identified Firestore as the only contributor to the costs. And within Firestore, it was clear that some collections had too many reads for the daily active users of my gaming portal.

With up to 1 million reads per day, my small system exceeded the free tier threshold of 50k reads per day by more than factor 10.

Image: Firestore usage showed too many reads and writes before the optimization

The Firestore Query Insights indicated that some collections like the profile, game completion and highscores were the main source of the reads.

After having set up the HTTP API metrics in Google Cloud Observability, I could see that the profile resource was queried too many times and had a high latency, and that the same applied to the random seed generator resource.

With this information, I could challenge my coding assistant:

Which parts of the code read those collections too often?
Why is the profile resource slow and called so frequently?
Why is the random seed generator so slow?

Three areas stood out immediately:

a nightly cleanup job,
the profile endpoint,
and the random seed generator.

Together they were driving most of the cost and latency.

Problem #1: A nightly job burning reads

The first surprise came from a background job that users never even saw.

The nightly cleanup function, written by the coding assistant, had an N+1 read pattern that scaled poorly with the number of profiles. At small scale I didn't notice it, but with real usage it became a major cost driver.

What was going wrong

The job iterated over every profile document and then ran a subquery per profile to find old game starts:

// loads ALL profiles
const profilesSnapshot = await db.collection(PROFILE_COLLECTION).get(); 

for (const profileDoc of profilesSnapshot.docs) {
    const oldGameStarts = await profileDoc.ref
        .collection(GAMESTATS_COLLECTION)
        .where("startedAt", "<", cutoffDate)
        .get(); // separate query per profile
    // ...
}

This means the job always performed one collection scan plus N additional subqueries, where N is the number of profiles - even if most profiles had nothing to clean up.

In practice, with ~500 profiles but only ~30 containing stale data, the job still executed ~501 reads instead of ~30 relevant reads.

How I fixed it

I replaced the per-profile loop with a collection group query that directly targets only the documents that need cleanup::

const oldGameStarts = await db
    .collectionGroup(GAMESTARTS_COLLECTION)
    .where("startedAt", "<", cutoffDate)
    .get();

const batch = db.batch();
for (const doc of oldGameStarts.docs) {
    batch.delete(doc.ref);
}
await batch.commit();

This shifts the cost from being proportional to the number of profiles to being proportional to the number of matching documents.

In the same example, that reduced the work from ~501 reads down to ~30.

Result

This single change removed a large portion of the Firestore cost baseline. It also made the cleanup job scale with actual data size
instead of user count, which was the underlying issue.

Fixing the cleanup job removed a major source of waste, but the profile endpoint was still dragging both cost and latency.

Problem #2: One endpoint doing too much

The second hotspot was the profile endpoint which was heavily used throughout the portal.

The profile endpoint had become one of the slowest and most expensive parts of the system. It was queried frequently, responded too slowly, and generated far too many database reads.

The analysis revealed that the real issue was not one single bug, but several small inefficiencies that had accumulated over time.

What was going wrong

Several small inefficiencies compounded into one expensive endpoint.

1. Too many duplicate requests

When the profile page opened, multiple React components requested the same profile data at nearly the same time. Because there was no deduplication, several identical requests were sent in parallel.

2. Each request loaded more data than necessary

The backend always loaded additional subcollections such as game stats and recent completed games, even though most components that requested profile data did not need them.

3. Maintenance tasks ran during normal user requests

The endpoint also triggered cleanup jobs and daily event generation. Some of this work only needed to run once per day, but it was being checked on every request.

4. Extra network overhead on every call

The frontend forced a fresh Firebase auth token before each API request, creating an unnecessary extra roundtrip to 3rd-party services.

5. No effective response caching

Even if nothing had changed, the browser still downloaded the full profile response again.

How we fixed it

Together with the AI assistant, I optimized the endpoint in several layers:

1. Reuse cached auth tokens

I replaced getIdToken(true) with getIdToken(), allowing Firebase to use cached tokens until they actually expire.

2. Lazy loading

Game stats and completed games were removed from the default profile response and moved to separate endpoints. They are now only fetched when the user opens those sections in the profile view.

3. Move maintenance off the hot path

A lastMaintenanceAt timestamp now ensures cleanup and daily event generation only run once per day.

4. Request deduplication and caching with ETags

I added a short-lived in-memory cache on the frontend so simultaneous requests could reuse the first response instead of hitting the backend multiple times.

Additionally, if the profile has not changed, the server now returns 304 Not Modified, so the browser can reuse its cached version.

Result

The profile page became noticeably faster, backend latency dropped, and Firestore reads were reduced significantly.

Instead of one endpoint doing five jobs on every request, it now does only the work that is actually needed.

Image: Reduced reads on the profile collection after applying multiple improvements

After the profile endpoint, one last expensive pattern remained: seed generation.

Problem #3: Random Seeds Were Surprisingly Expensive

The final issue came from a feature that seemed harmless: random seed generation.

A seed is a number used to initialize a game so that players share the same world state. The system organizes seeds into hourly, daily, and weekly pools.

What was going wrong

Every backend request to retrieve a seed called getActivityWeights(), which computed selection weights based on multiple Firestore documents. Each seed in the pool was stored as a separate document.

Depending on the pool size, this resulted in 8 to 50 Firestore reads per request.

With ~200 daily users requesting seeds, this alone produced roughly 50k reads per day — effectively consuming the entire free tier budget.

How I fixed it

The issue wasn’t the weighting logic itself, but how it was stored.

Instead of computing weights by reading multiple documents on every request, I moved the computed state into the existing seedPools/{poolType} document, which was already being updated whenever a game finished.

Now the system maintains a seedWeights map directly inside that document.

When a seed is requested, the backend only reads this single document instead of fetching multiple entries from the pool.

Result

This reduced seed-related usage from ~50k reads per day down to ~2k reads per day.

The logic stayed the same, but the read pattern collapsed from N documents per request to 1.

After fixing all three issues, Firestore usage dropped back into free-tier limits.

Back to free tier

The optimized database reads directly resulted in going back into the free tier of Firebase, as the image below indicates.

Image: The billing report shows that the daily costs went to zero after the optimizations

In addition, the perceived performance improved is also visible in the HTTP API performance metrics. Most services respond within 100ms to 500ms, and the amount of requests of the profile resource was significantly reduced after the optimizations.

I am very happy now that costs dropped back into the free tier, and the system felt fast again. And I believe my users can feel the difference as well.

Conclusion

As discussed in earlier posts, AI code assistants help to ship and validate ideas fast. It is possible to create functioning and maintainable software at speed never seen before.

However, it seems that AI-generated code often prioritizes working solutions over efficient ones. Human review is still needed to optimize resource consumption (and therefore costs), scaling, and performance - ideally before cost explosions or performance degradation.

For me, AI coding assistance paired with human software engineering expertise is a game changer for the speed of shipping features and maintaining software systems.

AI Built My Game Portal - Then the Firebase Bill Arrived

Seb Hoek — Fri, 17 Apr 2026 15:27:00 +0000

My AI-built browser game portal was growing. That was good news - until Firebase bills started rising and performance got worse.

Now was the moment where I as a software engineer had to step in.

With an increasing user base playing more and more games every day, I slipped out of the free usage tier for Firebase Storage which I use for persistency.

Image: The costs increased to about 10 USD per months with a clear upward trend

Also, I noticed that the perceived performance of my HTTP services degraded over time.

This is less than optimal. What happened? It probably had to do with how AI has set up the HTTP requests and database queries.

How can I investigate the causes and what can I do to fix it? Let's dive into it!

Finding the real bottlenecks
Problem #1: A nightly job burning reads
Problem #2: One endpoint doing too much
Problem #3: Random seeds were surprisingly expensive
Back to free tier
Conclusion

Finding the real bottlenecks

For me, observability is one of the most useful tools for finding and understanding problems.

Rather than guessing, I used three sources of data:

Google Cloud Billing Reports to see where costs came from
Firestore Query Insights to identify expensive collections
API latency metrics in Google Cloud Observability to spot slow endpoints

What the metrics revealed

With up to 1 million reads per day, my small system exceeded the free tier threshold of 50k reads per day by more than factor 10.

Image: Firestore usage showed too many reads and writes before the optimization

The Firestore Query Insights indicated that some collections like the profile, game completion and highscores were the main source of the reads.

With this information, I could challenge my coding assistant:

Which parts of the code read those collections too often?
Why is the profile resource slow and called so frequently?
Why is the random seed generator so slow?

Three areas stood out immediately:

a nightly cleanup job,
the profile endpoint,
and the random seed generator.

Together they were driving most of the cost and latency.

Problem #1: A nightly job burning reads

The first surprise came from a background job that users never even saw.

What was going wrong

The job iterated over every profile document and then ran a subquery per profile to find old game starts:

// loads ALL profiles
const profilesSnapshot = await db.collection(PROFILE_COLLECTION).get(); 

for (const profileDoc of profilesSnapshot.docs) {
    const oldGameStarts = await profileDoc.ref
        .collection(GAMESTATS_COLLECTION)
        .where("startedAt", "<", cutoffDate)
        .get(); // separate query per profile
    // ...
}

This means the job always performed one collection scan plus N additional subqueries, where N is the number of profiles — even if most profiles had nothing to clean up.

In practice, with ~500 profiles but only ~30 containing stale data, the job still executed ~501 reads instead of ~30 relevant reads.

How we fixed it

We replaced the per-profile loop with a collection group query that directly targets only the documents that need cleanup::

const oldGameStarts = await db
    .collectionGroup(GAMESTARTS_COLLECTION)
    .where("startedAt", "<", cutoffDate)
    .get();

const batch = db.batch();
for (const doc of oldGameStarts.docs) {
    batch.delete(doc.ref);
}
await batch.commit();

This shifts the cost from being proportional to the number of profiles to being proportional to the number of matching documents.

In the same example, that reduced the work from ~501 reads down to ~30.

Result

This single change removed a large portion of the Firestore cost baseline. It also made the cleanup job scale with actual data size
instead of user count, which was the underlying issue.

Fixing the cleanup job removed a major source of waste, but the profile endpoint was still dragging both cost and latency.

Problem #2: One endpoint doing too much

The second hotspot was the profile endpoint which was heavily used throughout the portal.

The profile endpoint had become one of the slowest and most expensive parts of the system. It was queried frequently, responded too slowly, and generated far too many database reads.

The analysis revealed that the real issue was not one single bug, but several small inefficiencies that had accumulated over time.

What was going wrong

Several small inefficiencies compounded into one expensive endpoint.

1. Too many duplicate requests

When the profile page opened, multiple React components requested the same profile data at nearly the same time. Because there was no deduplication, several identical requests were sent in parallel.

2. Each request loaded more data than necessary

The backend always loaded additional subcollections such as game stats and recent completed games, even though most components that requested profile data did not need them.

3. Maintenance tasks ran during normal user requests

The endpoint also triggered cleanup jobs and daily event generation. Some of this work only needed to run once per day, but it was being checked on every request.

4. Extra network overhead on every call

The frontend forced a fresh Firebase auth token before each API request, creating an unnecessary extra roundtrip to 3rd-party services.

5. No effective response caching

Even if nothing had changed, the browser still downloaded the full profile response again.

How we fixed it

Together with the AI assistant, I optimized the endpoint in several layers:

1. Reuse cached auth tokens

I replaced getIdToken(true) with getIdToken(), allowing Firebase to use cached tokens until they actually expire.

2. Lazy loading

Game stats and completed games were removed from the default profile response and moved to separate endpoints. They are now only fetched when the user opens those sections in the profile view.

3. Move maintenance off the hot path

A lastMaintenanceAt timestamp now ensures cleanup and daily event generation only run once per day.

4. Request deduplication and caching with ETags

I added a short-lived in-memory cache on the frontend so simultaneous requests could reuse the first response instead of hitting the backend multiple times.

Additionally, if the profile has not changed, the server now returns 304 Not Modified, so the browser can reuse its cached version.

Result

The profile page became noticeably faster, backend latency dropped, and Firestore reads were reduced significantly.

Instead of one endpoint doing five jobs on every request, it now does only the work that is actually needed.

Image: Reduced reads on the profile collection after applying multiple improvements

After the profile endpoint, one last expensive pattern remained: seed generation.

Problem #3: Random Seeds Were Surprisingly Expensive

The final issue came from a feature that seemed harmless: random seed generation.

A seed is a number used to initialize a game so that players share the same world state. The system organizes seeds into hourly, daily, and weekly pools.

What was going wrong

Every backend request to retrieve a seed called getActivityWeights(), which computed selection weights based on multiple Firestore documents. Each seed in the pool was stored as a separate document.

Depending on the pool size, this resulted in 8 to 50 Firestore reads per request.

With ~200 daily users requesting seeds, this alone produced roughly 50k reads per day — effectively consuming the entire free tier budget.

How we fixed it

The issue wasn’t the weighting logic itself, but how it was stored.

Instead of computing weights by reading multiple documents on every request, we moved the computed state into the existing seedPools/{poolType} document, which was already being updated whenever a game finished.

Now the system maintains a seedWeights map directly inside that document.

When a seed is requested, the backend only reads this single document instead of fetching multiple entries from the pool.

Result

This reduced seed-related usage from ~50k reads per day down to ~2k reads per day.

The logic stayed the same, but the read pattern collapsed from N documents per request to 1.

After fixing all three issues, Firestore usage dropped back into free-tier limits.

Back to free tier

The optimized database reads directly resulted in going back into the free tier of Firebase, as the image below indicates.

Image: The billing report shows that the daily costs went to zero after the optimizations

I am very happy now that costs dropped back into the free tier, and the system felt fast again. And I believe my users can feel the difference as well.

Conclusion

As discussed in earlier posts, AI code assistants help to ship and validate ideas fast. It is possible to create functioning and maintainable software at speed never seen before.

For me, AI coding assistance paired with human software engineering expertise is a game changer for the speed of shipping features and maintaining software systems.

Retention Over Clicks: A Surprising Lesson from Browser Game Analytics

Seb Hoek — Wed, 04 Mar 2026 16:30:17 +0000

Retention Matters More Than Traffic

In this series, I discuss various aspects of developing my browser game portal Pausen Games.

For this portal, it is crucial to find users, to keep them engaged, and for them to come back regularly. I usually use the terms acquisition, engagement time and retention to describe their behavior.

The hard lesson I learned: The way the users are acquired determines their engagement time and retention. I need to find those users who are more likely to enjoy using my website, even if that means higher efforts during acquisition and fewer total number of users.

In this post I will dive into the details of this mechanic.

Why paid traffic might not find the users you want

For acquisition, I am combining organic search (SEO) and paid traffic. I am still learning and experimenting and trying out different ideas.

For paid traffic, I can use an ad network like Google Ads, assign a daily budget and select the region and languages my ads should be targeting.

In addition, for the bidding strategy's incentive, I either aim for clicks, or, with additional implementation effort within my website, define and optimize for a conversion value which in my case would be determined by how many games a visitor plays.

Then naturally, the ad network will try to maximise the conversion goal with the given budget:

For click-based strategy, find as many users with the lowest cost-per-click as possible
For conversion-value-based strategy, still find the most users possible with the lowest cost-per-click, but also consider their conversion value.

To get me started, I selected random regions in the world and chose the conversion value strategy, hoping that the ad network would find me many users who would enjoy using my game portal.

Unfortunately, this didn't quite happen. Over a longer period of time, my ad budget was used to direct many users to my website, but most of them would never come back a second time.

The average weekly retention figures were discouraging. Was my game portal really so bad?

How Acquisition Context Shapes Player Behavior

Using the user analytics capabilities I discussed in my last post, I could segment my users along different properties such as region, language, used platform etc.

By filtering these properties I could identify three different groups as illustrated in the weekly retention charts below:

Group 1 shows short-term engagement and low multi-day return. This is the biggest group
Group 2 show repeated return and is progression-oriented. We see retention rates of whopping 60%! By digging into detailed user data, I could even find a few individual users who come back on a daily basis for weeks and play the same game over and over again (yay! someone seems to enjoy my stuff!)
Group 3 is somewhere between the other two groups

Group 1: Short-term engagement and low multi-day return

Group 2: Repeated returns and progression-oriented

Group 3: Somewhat engaged and returning

Now comes the really interesting part: These groups seemed to correlate with how much I was paying for their acquisition!

If I paid a lot for acquiring a user, they were more likely to engage with my game portal and come back over days and weeks.

If I attracted users with low cost-per-click, they were more likely to engage less with my game portal and they didn't come back much over days and weeks.

This made it clear that optimizing for low acquisition costs would jeopardize my engagement numbers.

Applying what I just learned, I adjusted my acquisition strategy.

Using Retention Insights to Guide Strategy

For me, weekly retention and multi-session engagement matter far more than total visits. I prefer my users to be active and have fun on my gaming portal.

Now that I learned that retention varies by acquisition source and campaign cost (not by the people themselves), I could adjust my strategy to find users.

In my ads network, I need to only target those users that show the best engagement figures. This is probably very specific to the kind of product offered, but it is a mix of the following:

Optimize for intent not volume. I need to match expectations created by ad assets with actual product (advertising free beer might create many cheep clicks but high-churn users)
Combine targeted regions, platforms, languages according to what I find to be the best working audience for my product
Separate high and low cost-per-click audiences by setting up different campaigns and budget. This will make it easier to identify useful patterns and to avoid optimizing for the wrong audience.

Conclusion

I am aware that for someone with a marketing background, this might not be super new. But for me as solo indie dev, this was quite relevant, surprising and new.

Quantitative user analytics enables me to identify the audience which enjoys my product most. The way I configure my ad campaign determines which audience I attract. Matching both yields in making me happy when I look at the statistics, because happy users are what drives me.

I'd be interested to know if you have similar or contrary experiences - feel free to leave a comment.

Google Analytics, SaaS, or self-hosted? How I chose my analytics stack

Seb Hoek — Fri, 13 Feb 2026 14:58:26 +0000

Why I need user analytics

In previous parts of this series, I already introduced Pausen Games, my little browser game portal.

When developing any digital end-user product, the core questions for me are:

How many Daily Active Users (DAU) do I have?
What is their demographics (country, browser language)?
What technology do they use (desktop/mobile, OS, browser)?
How engaged are they (session length, retention)?

With this specific product, the following additional questions are relevant to me:

Which games do my users play most?
What are my games' completion rates?
Which other features like profile view, highscore view etc. are they using?

To answer these questions, user analytics platforms can be used to track and aggregate user behavior in event databases and to visualize relevant metrics in beautiful dashboards.

Defining requirements before picking a tool

To understand my choice, it is relevant to discuss my context and preferences.

In this project, I am a solo developer with limited budget and limited time. Also, I don't want to place any cookie banners on my portal because I believe this distracts and annoys users.

In summary, here is what is important to me:

Minimal consent friction in my product - no data sharing with 3rd-parties
Access to raw events
Ability to define custom events
Ability visualize custom metrics
Low operational overhead
Reasonable cost at low to medium traffic

Now that the why and what is clearer, we can look at different solutions.

The default choice: Google Analytics

Google Analytics appears to be the obvious choice when it comes to tracking user analytics for websites and mobile applications.

Why it’s attractive

Google Analytics is popular because:

it is free to use even at scale
it is pretty mature
it comes with a useful user interface with default charts and which allows to add custom charts (with limitations).

In addition, it integrates well into the rest of Google's ecosystem:

You can use Google Looker Studio (for free) to connect to Google Analytics to create custom dashboards
You can export the raw time series data to Google's BigQuery with a standard connector, create custom data tables using scheduled queries and connect Google Looker Studio directly to your custom data tables for complete flexibility.

From my experience, using Looker Studio directly on Google Analytics exhausts the daily query quota quickly. But even with a moderate amount of events collected over a few years and a significant number of daily scheduled queries, you can stay within the free tier of Google BigQuery, which makes this my preferred option.

The diagram below summarizes the different options to visualize and analyze user analytics events with Google Analytics.

The internet is full of (more or less) beautiful and free Looker Studio dashboards for Google Analytics as shown in the example below. They can be used as an inspiration and as a starting point for custom dashboards.

This example is randomly picked from some people on the internet; I am not affiliated.

Why it doesn’t fully fit my needs

In other projects, I use Google Analytics both for web applications and for mobile applications since many years, and it serves me well. I applied the setup with Google BigQuery and Looker Studio and I have created many insightful charts which are still driving business decisions.

The main reason why I find the use of Google Analytics problematic for new projects is the friction that it creates when my website has to ask to user to allow collecting and correlating their data by a third-party provider.

Users who choose to not participate create gaps in my user analytics data, and I believe that many users would decide to do so.

Therefore I was looking for a solution where the collected data is fully under my control, not shared with any third-party, but which still has the power and flexibility of a data warehouse with custom charts.

Option 2: Hosted analytics SaaS

I don't want to go into too much detail here to compare individual offers. The tools I looked at include:

Plausible (hosted)
Fathom analytics
Simple Analytics
PostHog Cloud

Their benefits

They all have more or less the following in common:

Easy to set up
Trial period or free tier to get started
No infrastructure to manage
Privacy-friendly default

Their limitations

Coming from my previously described setup with a custom data warehouse (Google BigQuery) and a custom charting layer (Google DataStudio), I found them all to have the following drawbacks:

Sooner or later there will be costs, often growing as traffic grows.
There is limited or paid access to raw data for further processing.
The existing dashboards are opinionated and it might be tedious to visualize my KPIs the way I want.
And still, the date is not with me but with some third-party which I need to explain to my users.

To fulfill my needs of accessing and transforming the raw data so I can create my custom charts and not sharing the data with 3rd-parties, I'd have to get my hands a bit dirty it seemed.

Option 3: Self-hosted analytics

By self-hosting a user analytics solution, I can fulfill my requirements.

I am fully in control over the selected data.

I can predict and control the costs of the approach.

I can freely transform the data to perform deeper analysis and custom visualizations.

Why I chose Plausible

While evaluating Plausible, I found that they offer an open source solution which I can download and run on my own infrastructure.

I liked the simple and straight-forward programming model of collecting the events which works across programming languages and also include mobile applications. Tracking multiple applications and adding custom events is very easy.

It seemed to be lightweight enough to run on a small virtual machine.

I am not going into the details of self-hosting Plausible. If you you interested, let me know and I can create a dedicated post about it. If you want to get started, check out their Getting Started repository with a handy Docker compose file.

By self-hosting the the solution and therefore also the collected data, I implement a privacy-friendly approach where I don't share any data with 3rd-parties.

Out of the box, Plausible provides a few useful charts, but again I had the appetite to access to the raw data, transform it into different shapes, to calculate additional KPIs and to visualize them.

The screenshot below shows how my self-hosted Plausible instance provides basic insights into how users find and use my gaming portal.

With this setup in place, I was ready to take my user analytics to the level I envisioned.

Connecting a data warehouse and custom charts

To visualize my custom KPIs in Google's Looker Studio, I had to find a way to export the raw data in a data source Looker Studio can read out of the box and which I can use without any costs.

Finally, I found a project where I could apply the knowledge I acquired for my (already expired) Google Cloud Architect certification!

Here is my approach:

(1) From my application, user analytics events are sent to my self-hosted Plausible instance.
(2) In my VM, set up a cron job that exports yesterday's raw analytics events into a CSV file.
(3) After the export, the CSV file is copied to a Google Bucket (cloud storage).
(4) A Google Cloud Function detects the arrival of the file and appends its content into an existing time-series table in Google BigQuery.

While I could now set up Looker Studio directly to the raw events table in Google BigQuery, I found the schema a bit too complex to visualize easily.

(5) Therefore I set up scheduled queries in BigQuery which extract the raw data and transform it into a schema that is much easier to visualize in Looker Studio.

In these scheduled queries, I could:

omit irrelevant columns,
flatten nested attributes, for example from events,
pre-calculate relevant columns, for example the session number of a specific user.

(6) Finally, I could connect Google Looker Studio directly to the transformed data in my BigQuery and define the charts I wanted.

The overall approach is depicted in the diagram below.

I have to admit that using my favorite LLM chat has significantly accelerated the design and implementation of this architecture.

Creating complex, somewhat correct and efficient SQL queries for BigQuery was something that had cost me hours and days in the past.

With the tools available today, this is still nothing that works on the first attempt, but the overall speed of bootstrapping queries and understanding and debugging problems is at a different order of magnitude.

With this setup in place, I could start defining the charts I wanted.

What I can answer now (that I couldn’t before)

In addition to the charts that Plausible provides by default, I wanted to answer the following questions:

From the daily active users (DAU), how many are new users and how many are returning users from previous days?
For every day, how many games are played in total?
In average, how many games are users playing per day?
What is the completion rates of my games? How many games are actually finished compared to how many were started?
And most difficult: What is my weekly retention rate? (Meaning: For every user cohort that joined a specific week, what are the return rates for the second, third, and the following weeks?

Now answering these questions just means creating a custom scheduled query that produces the time-series events with the relevant data in BiqQuery, scheduling this query for a daily (or weekly) run, and connecting a chart in Looker Studio to visualize the data on a timeline.

Below you can find two real-life examples of charts I defined to answer the above questions. As you can see, some metrics still leave a lot of room for inmprovements :) (which I will be talking about in a different post).

This flexibility however comes at some costs as I will discuss in the following chapter.

The tradeoff I accepted

Self-hosting a user analytics stack does not come for free. Here are some of the costs (I am willing to accept):

Running and maintaining a VM costs money and time. Currently, I still pay around EUR 6 per month for a VM with 8GB RAM, for vCPUs and 120GB disk. I had to increase the VM and disk after a while because the smaller ran out of capacity.
There is a considerable amount of work to be invested for the initial setup of the stack (even with the help of smart and confident AI chats).
It is essential to spend a few thoughts security considerations. A self-managed VM exposed to the internet should not go without solid protection.
I am responsible for data backups and regularly updating the stack.

Conclusion

Overall, and that's my conclusion, spending the additional effort to set up a self-hosted user analytics solution and connect it to a managed data warehouse and charting tool is absolutely worth it for me.

I believe I achieved my goals, I had fun setting this up and I might have learned something on the way.

Although I have some monthly costs and some maintenance work, the additional insights I gain into user behavior and the fact that I don't need to share user analytics data with 3rd-parties outweigh the drawbacks for me.

User analytics gives me the insights I need to understand the weaknesses of my product and the impact of new features I released.

In future posts, I’ll talk about how I’m continuing to work on my Pausengames portal.

How I built a browser game portal using AI and what I had to fix myself

Seb Hoek — Wed, 14 Jan 2026 16:09:51 +0000

I created a game portal in the browser to see how fast I am using AI code generators. Today I have a working product, many daily users and five playable games. This series describes my journey.

In this article, I describe how I got started using an AI code generator. I share my early successes and later struggles with the generated code and my workflow.

Why I chose a browser-based vibe-coding tool and React

The vibe-coding tool I started with allows quickly creating running web applications based on an initial prompt:

I want to build a puzzle games website where people 
can play different brain teasers and logic puzzles. 
Users should be able to create accounts, track their scores, 
and compete on leaderboards. 
Use react and vite.

I deliberately chose a tech stack I am somewhat familiar with so I can judge the quality of the generated code. And it was pretty impressive!

Here is what I was impressed with during my first experiments:

The first version was already pretty good, both visually and technically.
The tool understands my prompts and executes them quite nicely.
The tool looks like VSCode in the browser and allows switching between source code and the running web application.

First successes

As mentioned, the game portal was running quickly in the browser AI coding tool. I could adjust the overall appearance by vaguely describing my preferences:

Use different colors. It should be bright and friendly.
Also, make sure it looks good on mobile screens.

I think the colors, game logos and texts chosen by the AI code generator are pretty good as the screenshot below suggests.

The first games that were added by the code generator without me specifically asking for it were a memory game and minesweeper. Both games worked instantly and only needed minor adjustments, for example regarding colors, the game buttons and the layout for different screen sizes - all done by using non-technical prompts:

Add buttons for restarting the game and starting the 
game of the day. While all games are randomly initialized, 
the game of the day should be the same game for all users.

The code generator invented a concept using a seed number and implemented a pseudo-randomized seed function based on the current date. This worked like a charm!

Adding variations of the game by introducing different sizes of the game field again was just a matter of asking the AI to just do it. I was truly impressed!

These early wins worked well because the games were simple. That changed as soon as I tried to build more complex games.

Where AI struggled: complex games & visuals

The AI code generator consistently produced React game components with roughly the following structure:

import React from "react";
...

// types and constants

export function Game({seed, gridSize: initialSize}: GameProps) {
  // state hooks
  const [isRunning, setIsRunning] = useState(false);
  // ...

  // set up grid
  const initializeGame = () => {
    // ...
  }

  // side effects
  useEffect(() => { ...  }, []);
  // ...

  // handlers
  const onNewGame = () => { ... };

  // JSX
  return (
    <div className="...">...</div>
  );

If the game gets more complicated, this immediately creates the following problems:

The code of the component is pretty long and hard to read.
The code block has too many responsibilities - game logic and presentation logic are mixed into one code block.
Game logic could not be tested in isolation, for example by writing a unit test.
Code cannot be reused.

All this makes the game and the portal harder to maintain. Little bugs are harder to fix both for me and the AI code generator.

I learned this the hard way when creating a game where the user is asked to connect a grid of pipes:

You can try the Pipes game here: https://pausengames.com/en/waterpipe.

The initial version of the game did not work out of the box. The game had the following issues:

Creating an initial solution as the starting point of a game did not work.
Detection of when the player won the game did not work.
Visualizing the connected pipes in a different color did not work.
Drawing the pipes with an outline stroke using SVG did not work.

My way of approaching and resolving the issues successfully was:

Ask the code generator to refactor the component.
- Separate the game logic into another file. Create an proper TypeScript class with state and methods.
- Separate the solution generator into a separate file.
- Create a reusable component for the game buttons and use it across all games.
Start reading and actually understanding the generated code.
- At this point I switched from the browser-based code generator to a general-purpose LLM chat.
- I asked the chat about typical data structures and algorithmic approaches for the problems I needed to solve.
Write my own implementation of the game logic and the solution generator
- I didn't see a way to avoid actually understanding what I was doing here.
- I could use the LLM chat to quickly learn the data structures and algorithms needed. No need to read a paper or some university slides!
- I could use the LLM to create implementations the way I needed it and to have conversations about alternative implementations.

Regarding the SVGs to render the pipe, I saw no alternative to again work closely and iteratively with a LLM chat to create the implementation the way I liked.

Key takeaways and conclusions

Using a vibe coding tools was fun and led to first results quickly! It created a prototype that was ready for testing with actual users.

But quickly I realized that AI code generators still seem to have limitations.

For me it was critical to jump in where the AI code generator failed. Together, we could refactor and simplify the code. With a general purpose LLM chat, I could find an implementation that was correct, reliable and maintainable.

Even in the age of AI code generators, good engineering practices like clean code, test automation and thoughtful architecture still matter - maybe even more than ever.

AI can help me (and probably you) code faster, but only with my engineering judgement I can build maintainable, stable, secure software.

What should I write about next?

For the next post in this series, I’m considering diving deeper into one of these areas:

Security considerations for browser-based games (cheating, attacks, runaway cloud costs)
Low-cost end-to-end architecture (from AI-generated React code to a deployable, maintainable production setup)
Privacy-compliant user analytics (how I measure player behavior without sharing user data with 3rd-parties)
Acquisition (how people actually find and start playing the games with a limited budget)

Let me know which one you’d find most useful.

This is what I learned from vibe-coding five browser games

Seb Hoek — Wed, 07 Jan 2026 08:07:07 +0000

Hey, this is my first post.

Last year I started using a vibe coding platform to quickly create a browser-based game portal and built five games. While I could see the first results quickly, I also encountered interesting challenges on my way to setting this up properly as a product for real users

Today I have something running with real users but I have plans to extend it further.

I plan to go into details in future posts and I can think of the following topics:

My observations from coding and maintaining a project using an AI code assist. How can I keep confidence and quality?
The tech stack I used for my 3-tier web application. Can I keep it low-cost but ready to scale?
My approach to user analytics. How can I avoid Google Analytics and create insightful charts about the behavior of my users?
Security considerations: How to protect from cheaters as well as from run-away cloud costs and other attacks?
User acquisition: How can I attract new users with low budget and limited time using paid marketing and SEO? (this is still a question which is quite unanswered)
User retention: How to keep my users on my site and how do I make them come back regularly?

You can also let me know what you are interested in and I am happy to talk about it.

If you want to check it out yourself: https://pausengames.com.

(Disclaimer: This text was written without the help of any LLM.)

DEV Community: Seb Hoek

AI created slow and expensive code. How I analyzed and fixed it.

Content

Finding the real bottlenecks

What the metrics revealed

Problem #1: A nightly job burning reads

What was going wrong

How I fixed it

Result

Problem #2: One endpoint doing too much

What was going wrong

1. Too many duplicate requests

2. Each request loaded more data than necessary

3. Maintenance tasks ran during normal user requests

4. Extra network overhead on every call

5. No effective response caching

How we fixed it

1. Reuse cached auth tokens

2. Lazy loading

3. Move maintenance off the hot path

4. Request deduplication and caching with ETags

Result

Problem #3: Random Seeds Were Surprisingly Expensive

What was going wrong

How I fixed it

Result

Back to free tier

Conclusion

AI Built My Game Portal - Then the Firebase Bill Arrived

Contents

Finding the real bottlenecks

What the metrics revealed

Problem #1: A nightly job burning reads

What was going wrong

How we fixed it

Result

Problem #2: One endpoint doing too much

What was going wrong

1. Too many duplicate requests

2. Each request loaded more data than necessary

3. Maintenance tasks ran during normal user requests

4. Extra network overhead on every call

5. No effective response caching

How we fixed it

1. Reuse cached auth tokens

2. Lazy loading

3. Move maintenance off the hot path

4. Request deduplication and caching with ETags

Result

Problem #3: Random Seeds Were Surprisingly Expensive

What was going wrong

How we fixed it

Result

Back to free tier

Conclusion

Retention Over Clicks: A Surprising Lesson from Browser Game Analytics

Retention Matters More Than Traffic

Why paid traffic might not find the users you want

How Acquisition Context Shapes Player Behavior

Using Retention Insights to Guide Strategy

Conclusion

Google Analytics, SaaS, or self-hosted? How I chose my analytics stack

Why I need user analytics

Defining requirements before picking a tool

The default choice: Google Analytics

Why it’s attractive

Why it doesn’t fully fit my needs

Option 2: Hosted analytics SaaS

Their benefits

Their limitations

Option 3: Self-hosted analytics

Why I chose Plausible

Connecting a data warehouse and custom charts

What I can answer now (that I couldn’t before)

The tradeoff I accepted

Conclusion

How I built a browser game portal using AI and what I had to fix myself

Why I chose a browser-based vibe-coding tool and React

First successes

Where AI struggled: complex games & visuals