DEV Community: Sayyed Amaan Ali

Building the Credit System for My AI Prompt Optimizer

Sayyed Amaan Ali — Sun, 12 Jul 2026 04:50:50 +0000

Today I completed one of the core backend features of my AI Prompt Optimizer: the credit management system.

At first, I thought it would be as simple as decrementing a counter. It turned out to be much more than that.

What I implemented
Plan-based credit allocation (Free & Pro ready)
Automatic daily credit reset for free users
Database-level credit deduction using PostgreSQL functions
Credit validation before processing optimization requests
Proper handling when users run out of credits
Integrated everything with Next.js and Supabase
What I learned

Building a SaaS isn't just about AI models or UI. A lot of the complexity comes from business logic.

While working on this feature, I learned more about:

PostgreSQL Functions
Triggers
Foreign Keys
Row Level Security (RLS)
Supabase RPC
Designing a scalable credit system

It took several iterations and a lot of debugging, but seeing everything work together was worth it.

Next up: payment integration, history improvements, and preparing for the beta launch.

Building in public, one feature at a time. 🚀

buildinpublic #NextJS #Supabase #PostgreSQL #AI #SaaS #WebDevelopment

How I Built a 25+ Page Agency Website with Next.js, TypeScript & Material UI

Sayyed Amaan Ali — Thu, 09 Jul 2026 06:44:22 +0000

Recently, I completed a freelance project where I redesigned the website for Aetibar Information & Technologies.

The goal was to build a modern, scalable, and SEO-friendly website that could handle a large amount of content while remaining fast and easy to maintain.

Live Website: https://www.aetibar.in

Tech Stack
Next.js
TypeScript
Material UI (MUI)
Project Highlights
25+ responsive pages
240,000+ words of website content
Dynamic blog with an admin panel for content management
SEO-friendly architecture
Responsive design across devices
Optimized for performance and maintainability
Challenges

One of the biggest challenges was organizing a content-heavy website without sacrificing performance or maintainability. The project required building reusable components, keeping the UI consistent across dozens of pages, and ensuring the architecture would scale as more content is added.

What I Learned
Designing reusable UI components saves significant development time.
Planning the project structure early makes large websites much easier to maintain.
Performance and SEO should be considered from the beginning, not added later.
Building content-heavy applications requires balancing user experience with maintainable code.

I'd love to hear your thoughts or suggestions for improvement. Feedback from the developer community is always appreciated.

I Spent 5 Hours Debugging an AI Backend. I Didn't Ship a Feature, But It Was Worth It.

Sayyed Amaan Ali — Sun, 05 Jul 2026 22:36:29 +0000

Today started with a simple goal: finish a feature on an AI-based project I'm building.

That didn't happen.

Instead, I spent almost five hours debugging.

At first, I was convinced the database was causing the problem. After fixing that, another issue appeared. Then I thought it was the queue. Then the AI API. Then the fetch logic.

The interesting part wasn't the bugs—it was how I was approaching them.

I stopped trying random fixes and started tracing the request from start to finish.

Request
↓
Queue
↓
Worker
↓
AI Response
↓
Database
↓
UI

At every step, I added logs and asked one question:

"Did the data reach this point?"

That one change completely changed how I debugged the project.

Some of the issues I found:

A database constraint that no longer matched the application's behavior.
An insert operation that was actually successful, but I interpreted it as a failure because I misunderstood the response.
A fetch query making assumptions that were no longer true after changing the database schema.
AI API quota limits exposing weaknesses in my model selection strategy.

The last one was probably the biggest lesson.

I had implemented a simple round-robin scheduler for AI models. It worked... until multiple models started hitting their quota limits.

The scheduler kept selecting models that were already exhausted.

That made me realize that round-robin alone isn't enough.

A production-ready scheduler also needs to know which models are healthy, which are cooling down, and which should be skipped temporarily.

I didn't expect API limits to teach me something about system design, but they did.

At the end of the day, I still hadn't shipped the feature I planned to.

But I understand the system much better than I did this morning.

Sometimes the most productive coding session isn't the one where you write the most code.

It's the one where you finally understand why your existing code behaves the way it does.

Have you ever spent hours debugging only to realize the actual problem was somewhere completely different from where you started?