DEV Community: Ahmet Ulutaş

How I got ~500k organic search clicks with a vibe-coded app: the architecture, phase by phase

Ahmet Ulutaş — Tue, 10 Nov 2026 20:30:11 +0000

Originally published on my blog.

A note before starting: this post is not written by AI, but the diagrams were generated with AI.

Since the introduction of early AI tools, I have been really into using them actively, both for my professional career and in my free time, to try to catch up with their evolution (which, as everybody here knows, is pretty hard to do). As a result, I vibe-coded a web application (100% vibe-coded) for astrological calculations. Bear in mind I have zero knowledge of astrological math and calculations, so I should give AI tools good credit for that.

Initially, Cursor was my IDE to vibe-code and Claude was the primary LLM to write the code. As the application got real users I had to roll up my sleeves, since this app needed to scale and AI felt short on architectural decisions. Plus, as you know, I'm obsessed with web performance, so I wanted to see how far I can go combining my skills with AI.

This post dives deep into this project's architecture.

Early architecture

Technical

Early technical architecture

The app was running on a fully Next.js platform with client-side calculation methods, an open-source places API for location search, and user comments and feedback saved into a free-tier Supabase. A user types in their information, client-side calculations produce the result, the user gets it and leaves. Sounds smooth and easy. It was mostly vibe-coded: I set up my Cursor files very well, and the skills and commands work so well that I one-shot each new calculator page. Life is good.

Content

Early content architecture

For content I use the Sanity Studio free-tier plan, and it's enough because all of my pages are SSG'ed (statically generated at build time, so I query Sanity only when my Next.js app rebuilds). AI writes my content, I publish it, a Sanity webhook triggers my deploy, and I get a fresh build with fresh content. Sanity Studio is cloud-hosted by Sanity, which is included in the free plan.

Phase 1: ~5K monthly users

The app is running on the free-tier Vercel plan and nothing breaks.

Another challenge at this step was the free places API's limits. For an astrological calculation app, location search is essential: location input is required for almost every calculation. I solved this with Redis (Upstash) for my place searches, so I didn't query the free API that often. It solved my problem at this step, but Upstash Redis itself has a free-tier limit too, just harder to hit than the location API's.

Phase 1 architecture

I decided to add more pages to grow my audience, and as the audience grew I wanted to move to a more professional setup. It was not a must in this phase, but a preparation for future traffic spikes. So I moved my app to AWS Amplify, with CloudFront for security.

This is also the phase where I started to dive deep into the app's performance. I constantly analyzed the bundle size, optimized the codebase, and ran dead code detection (knip is very useful). I added a JavaScript performance observer that logs users' metrics to my Supabase database, and built a dashboard on that data to monitor user metrics, rather than using ready-made tools like Sentry or New Relic. Monitoring RUM (real user metrics) will surprise you, as you will clearly see that users do not have fast devices :) And for ranking higher on Google you need to serve a good user experience, so it became an obsession at this point. I simplified all the components, removed heavy UI component libraries, lazy-loaded the birth chart library to get it out of the bundle, and so on. It's also hard to believe how many users are still on very slow devices.

Web performance is not something you can focus on, solve and forget. It is something you need to consider and monitor constantly.

Google Search Console, Core Web Vitals report for mobile: 229 URLs rated good, none poor or needing improvement.

Phase 2: ~10K monthly users

AWS Amplify ran smoothly, but the Lambda functions and CloudFront started to get costly, and I have no monetization plan other than Google AdSense. I didn't want to give it all back to AWS.

Phase 2 architecture

Another challenge with AWS: I had published more than ~200 pages to this application for organic SEO, and I hit the wall of bundle size. Platforms like AWS Amplify and Vercel only allow a bundle of 200 MB, and since I'm SSG'ing all my pages, my bundle grew larger than that. So I had to find a way.

Phase 3: ~30K monthly users

I decided to move away from AWS and host the app on an Ubuntu VPS with Coolify, so the bundle size limit disappeared. Now I can statically generate as many pages as I want. Plus, it's a lot cheaper.

Cloudflare Web Analytics for the project, last 24 hours, bots excluded.

For caching I use Cloudflare, which offers a generous quota, and I cache all the requests hitting my VPS aggressively, which has also improved my Lighthouse metrics. I have a cache purge method that runs against Cloudflare whenever a new deploy or a content change happens.

Phase 3 architecture, 30k users

I added a user review form to the application to get feedback from users. Very often I got messages saying the calculations were giving wrong results. In the end it is vibe-coded, and you know how it is. The next challenge at this point was the inconsistency of the astrological results. I did some research and found the issue. Remember that our calculations were done in the client's browser with client-side JavaScript. Therefore the calculations differed from device to device, and the time zone handling was not consistent.

Another reason was that there are a lot of libraries that provide planets' positions, and the one I had been using was neither very popular (there are different techniques to calculate the result, and some of them are more popular and preferred) nor used by professional astrological calculators.

Plus, at this point I had decided to create a mobile app for the app stores, and I wanted web and mobile to give the same results. Client-side calculations weren't enough for a consistent app.

Phase 4: an API for my web and mobile apps

Professional planet-position libraries are licensed. But luckily there is a good Python community that provides the same data as open source, so I deployed a Python API. Only my Node.js server can query it. I got 98% correct calculations when compared to professional paid libraries. And with my own API I can now provide correct calculations to my multi-platform apps.

A strict orchestration of Claude helped me develop this robust and precise API. I now have an orchestration workflow all the way from planning to UAT testing.

Another benefit of separating the calculations into their own API is that my Next.js app's INP scores have remarkably healed, as it has become less dependent on browser scripting.

You can view the site at burcapp.com.

Phase 4 architecture, API

Finally

It has been a good side project that taught me a lot about vibe-coding and about handling a web application with real users end to end. I started this project to practice with AI 15 months ago. Back then I used Cursor for coding and now I'm on Claude. The LLMs I have been using have gotten remarkably better since then.

Take the claude-seo skill for instance. It is a very powerful tool to quickly scan your pages across many different aspects of SEO, report what you are missing, and help you improve your organic traffic.

I have learned a lot about AI from this project. Looking back at where I started, I have come a long way: I learned how to orchestrate agents, create rules and commands, when to use skills and when to delete rules, and so on. I came to this conclusion:

Google Search Console result for the last 12 months: 481K clicks and 4.23M impressions. The interface is in Turkish, where "B" means thousand and "Mn" means million.

You can't vibe-code an app and expect people to use it without giving a thought to what it is really building. However, if you know what you are doing, AI is a very powerful tool to improve productivity, and its outcome is getting much better every day.

A birth time is a wall clock, not an instant: how one timezone bug moves a rising sign

Ahmet Ulutaş — Tue, 10 Nov 2026 20:15:45 +0000

If you turn "14:00 on 15 July 1990" into a Date on whatever device runs your code, you get a different instant on every device. For an astrology calculator that is not a rounding problem: the same birth data produced four different rising signs. The fix is to store the wall-clock reading together with the IANA zone of the birth place, and to convert on the server, never from the runtime's own zone.

I build Burcapp, a free set of Turkish astrology calculators, and this bug is why birth time now travels through the whole app as a wall clock plus a zone. Here is the whole thing with the numbers.

A wall clock is not an instant

A birth certificate says "14:00". That is a reading on a clock at the birth place. It becomes an instant only once you know which zone that clock was in on that date.

JavaScript's Date parser treats a date-time string without an offset as local time, meaning the local time of the device that runs it:

const wall = new Date("1990-07-15T14:00:00");
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone, wall.toISOString());

Running that with TZ set to four different zones:

Device zone	Instant (UTC)
Europe/Istanbul	1990-07-15T11:00:00.000Z
UTC	1990-07-15T14:00:00.000Z
America/New_York	1990-07-15T18:00:00.000Z
Asia/Tokyo	1990-07-15T05:00:00.000Z

A spread of 13 hours for one birth. If that code runs in the browser, the answer depends on where the visitor lives. If it runs on your server, it depends on the server's zone, which says nothing about the birth place.

What it does to a chart

I sent the same birth, 14:00 on 15 July 1990 in Istanbul (41.0082 N, 28.9784 E), to our calculation service four times. Only the zone used to read "14:00" changed:

"14:00" read as	Rising sign (Ascendant)
Europe/Istanbul	Libra 29°10'
UTC	Sagittarius 4°33'
America/New_York	Aquarius 1°51'
Asia/Tokyo	Leo 18°10'

Four zones, four signs. Only the first is correct, and it sits 50 arcminutes before the Scorpio boundary. The Ascendant sweeps the whole zodiac in a day, about one degree every four minutes on average, so a clock error of a few minutes can flip even the correct zone's answer. That is why a rising-sign calculator has to be exact about the instant in a way a horoscope-by-month page never was.

The offset is not a property of the city

The usual shortcut is "Istanbul is UTC+3". It is now, and the rows below show it was not always. The service resolves the offset from IANA tzdata for the exact date. Same city, same clock reading at noon:

Date	Europe/Istanbul offset
1970-07-01	+02:00
1985-01-15	+02:00
1985-07-15	+03:00
2016-12-15	+03:00

A fixed offset per city would be wrong in half of these rows. You need the zone name and the date, and a library that knows the history. For births before 1970, tzdata is best-effort, so the zone field has to stay user-editable.

The fix

Never build the instant from the runtime's zone. Carry { date, time, zone } as data and convert with the zone you were given. With plain Intl, no dependency:

// Offset of `zone` at a given instant, in minutes.
function offsetMinutes(zone, instantMs) {
  const parts = Object.fromEntries(
    new Intl.DateTimeFormat("en-US", {
      timeZone: zone,
      hourCycle: "h23",
      year: "numeric",
      month: "2-digit",
      day: "2-digit",
      hour: "2-digit",
      minute: "2-digit",
      second: "2-digit",
    })
      .formatToParts(new Date(instantMs))
      .map((p) => [p.type, p.value]),
  );
  const asUtc = Date.UTC(
    +parts.year,
    +parts.month - 1,
    +parts.day,
    +parts.hour,
    +parts.minute,
    +parts.second,
  );
  return (asUtc - Math.floor(instantMs / 1000) * 1000) / 60000;
}

export function wallClockToInstant(date, time, zone) {
  const [y, mo, d] = date.split("-").map(Number);
  const [h, mi] = time.split(":").map(Number);
  const guess = Date.UTC(y, mo - 1, d, h, mi);
  // Pretend the wall clock is UTC, then correct by the zone's offset.
  let instant = guess - offsetMinutes(zone, guess) * 60000;
  // The offset can differ at the corrected instant (a DST edge): take it once more.
  instant = guess - offsetMinutes(zone, instant) * 60000;
  return new Date(instant);
}

Call it for 14:00 on 15 July 1990 with each zone and run it under any TZ: the Europe/Istanbul call returns 11:00Z, UTC 14:00Z, America/New_York 18:00Z and Asia/Tokyo 05:00Z every time, because the runtime's zone is no longer an input.

Two honest limits. On the night a clock jumps forward, a wall-clock time can not exist; on the night it falls back, it happens twice. This function picks one answer silently. A product that cares should ask the user which one. And if a ready-made Temporal.ZonedDateTime, Luxon or date-fns-tz is available to you, use it rather than this sketch.

Better: do not convert in the browser at all

Our forms send the wall clock and the zone as they are, and the calculation service turns them into an instant:

{
  "birthDate": "1990-07-15",
  "birthTime": "14:00",
  "latitude": 41.0082,
  "longitude": 28.9784,
  "timeZone": "Europe/Istanbul"
}

The zone is filled in from the chosen city, and it stays editable. If no zone can be found, the service says so in the response and the page shows a warning, instead of quietly using the visitor's device zone.

Coordinates and the zone do two different jobs. The coordinates say where the observer stands, which sets the Ascendant and the house cusps. The zone says what the clock reading means. Getting one right does not get the other right, so every request carries both.

Test it the boring way

The check I rely on: open the same result link in a browser set to Europe/Istanbul, then UTC, then America/New_York. The page must render identically. In Node, run the test suite three times with TZ=Europe/Istanbul, TZ=UTC and TZ=America/New_York and compare the output.

I wrote up how the service computes positions, and what it checks them against, on the Burcapp calculation methodology page. The birth chart calculator that uses this flow is Doğum Haritası Hesaplama (Turkish).

Disclosure: I build Burcapp. It is free and needs no sign-up.