built a dashboard for schools this week. claude helped, and it came out with beautiful graphs and clean cards, everything rendering nicely. i was happy. it looked done.
took it to my lead and he asked one thing. why is this one page hitting the backend so many times.
so i opened the network tab. every graph was making its own api call. one dashboard, one page load, and the server getting hit eight separate times for data we could have pulled in a single call.
it looked fast on my screen, and that is the trap. my screen is one browser sitting next to the server on my own machine, so eight calls cost me nothing. but every school opening that dashboard was quietly making all eight, all day, every day. eight felt normal to me because i was counting per graph. the server counts per page load, multiplied by every school using it.
the fix was simple once i could see it. one endpoint, one response with all the dashboard data together, and the frontend splits it into the graphs.
this is the second time in two days i have learned the same lesson from a different direction. pagination was the exact same shape. the screen looked right and the work under the screen was wrong.
and claude built exactly what i asked. i asked for graphs, it gave me graphs. it did not think about the number of backend calls because i did not either.
a dashboard is not a pile of graphs. it is one screen asking the server one question.
#buildinpublic #softwareengineering #startup #learninginpublic #maahitatechnologies