Build this in 10 min for my product @thegympilot and cost like 20rs.
What a great time to live in.
With almost no prompt. Opus 5.5 figured it out all by itself from code. ( Ofcourse Knowldgebase was there but shit🔥🔥🔥🔥🔥 )
Loved this Prespective on Problem Solving by @Hiteshdotcom sir.
Must Watch..
Building software is not problem solving youtu.be/y00gqVDwbv8?si=wduJ… via @YouTube
One thing I'm slowly realizing while building a SaaS...
I always assumed pagination would become a problem once I had thousands of members.
GymPilot has ~12 gyms now, averaging ~300 members each.
My thinking was:
"300 rows? That's nothing."
Turns out...
The rows were never the problem.
The images were.
Two things were quietly eating bandwidth:
• Every members page loaded ~300 profile photos at once - even the ones off-screen and even expired members nobody was looking at.
• Those photos were served at their original upload size. A 4 MB image... just to render an 80px avatar.
A few gyms have 6+ staff members using the app throughout the day.
Individually, none of this looked expensive.
Together, it meant tens of thousands of image requests every month for data the UI never actually needed.
The fix wasn't throwing more infrastructure at it.
It was asking for less.
Only request images that are actually visible.
Serve them at the size they're displayed.
Funny enough, I also stopped wondering why competitors charge more for additional staff accounts.
Every SaaS pricing page probably has a production incident behind it.
#LearningInPublic
🤖 Made with AI





