Before starting, I would like to inform you that this blog is written by hand and images generated by AI.
Since the introduction of early ai tools, I have been really into using them actively both for my professional career and on my free times to try to catch up with their evolution (which as everybody here knows is pretty hard to do). As a result, I have vibe coded a web application (100% percent vibe-coded) on astrological calculations. Bear in mind I have zero knowledge on astrological math and calculations so I should give AI tools a 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 blog is going to dive deep into this project’s architecture.
Early architecture
Technical
The app was running on fully next-js platform with client-side working calculation methods. An open-source places-api for location search. User comments and feedbacks are saved into free-tier supabase. A user types in their information => client-side calculations calculate their results. User gets their result and leave. Sounds smooth and easy. Mostly vibe-coded (I set up my cursor files very well. skills and commands are working perfectly so I one-shot each new calculator page generation, life is good.)
Content
For content I’m using sanity studio free-tier plan and its enough as all of my pages are SSG’ed (statically generated at build-time so I query sanity only when my nextjs app rebuilds.) AI writes my content => publishes it => sanity-webhook triggers my deploy => fresh build and fresh content. The sanity studio is cloud hosted with sanity (included in free plan)
Phase 1: ~5K Monthly Users
The app is running on free-tier vercel plan and nothing breaks.
Another challenge in this step was the free places api’s limitation. For an astrological calculations app location search is very essential and basically location input is required for almost every calculations. I solved this problem using redis (upstash redis) for my places searches so i didn’t query the free api that often. It solved my problem at this step.
I decided to add more pages to grow my audience as my audience grows I wanted to move to a more professional set up. Not a must in this phase but a prep for future traffic spikes. So I moved my app to AWS Amplify and Cloudfront for security.
This is also the phase that I started to deep dive on the app’s performance. I constantly analyzed the bundle size, optimized the codebase, ran dead code detection tests (knip is very useful).
I added a javascript performance observer method to log the users’ metrics to my Supabase database. On this data I have set up another dashboard to monitor the user metrics rather than other ready to use tools like Sentry or Newrelic. Monitoring the 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 searches you need to serve a good user experience so it became an obsession at this point. I have simplified all the components, removed heavy ui component libraries, lazy loaded birth chart library to get it out of the bundle etc. Its also very hard to believe that there are still a lot of users using very slow devices.
Web performance is not something you can focus, solve and forget, it is something you need to consider and monitor constantly.
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, only Google Adsense and I didn’t want to give it back to AWS.
Another challenge with AWS was I have been publishing around 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 allows a bundle of 200 mb and since I’m SSG’ing all my pages my bundle size got more than that. So I had to find a way.
Phase 3: ~30k Monthly Users
I decided to buy move away from AWS and host the app on a Ubuntu VPS with Coolify so the limit of bundle size disappeared. Now I can statically generate as many pages as I want. Plus it’s a lot cheaper.
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 to run purge for cloudflare when a new deploy or content changes happens.
I have added a user review form to the applciation to interact with the users for feedbacks. Very often, I get messages that the calculations are 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. Made some research and found the issue. Remember our calculations are done in the client’s browser with client side javascript calculations. Therefore, the calculations differed from device to device and time-zone was not consistent.
Another reason was there are a lot of libraries that provides planets’ positions and the one that I have been using was not very popular and preferred / used by professional astrological calculations.
Plus, at this point I have decided to create a mobile app for app store and I wanted both my web and mobile to give the same results. Therefore, client side calculations weren’t enough for a consistent app.
Phase 4: API that provides for my web + mobile app
Professinoal planet positions libraries are licensed. But luckily there is a good community in python that provides the same data as open source so I had to deploy a python api. Next to which my Node.js server and this python api can only be queried by this Nodejs server. I got 98% correct calculations when compared to professional paid libraries. Also, with the help of my own api now I can provide correct calculations for my multi-platform apps correctly. A strict orchestration of Claude has helped me to develop this robust and precise api. I have an orchestration workflow all the way from planning to uat testing now.
Another profit I got from seperaitng my calculations to another api is that my nextjs app’s INP scores have remarkably healed as it became less dependant on browser scripting.
You can view the site on : https://burcapp.com/
Finally
It has been a good side-project that taught me a lot about vibe-coding and handling a web application with real life users end-to-end. I started this project to practice on AI 15 months ago. Back then I used Cursor for coding and now I’m on Claude. The llms I have been using have remarkably got better since then. I have learned a lot about AI from this project. Looking back to where I started I have come a long way where I have learned how to orchestrate the agents, creating rules and commands, when to use skills or when to delete rules etc. I have come into this conclusion.
You can’t vibe-code an app and expect people to use it without giving what it does a thought. But if you know what you are doing, AI is a very powerful tool to improve productivity and its outcome is getting much better everyday.
