Joe asked the same questions and then wrote a collection of CGI programs/scripts in one of those languages which start with the letter P. It was dull and uninteresting. There were a half-dozen commands the devices needed to call, so he hand-wrote the SQL, making sure to use the appropriate techniques to insert parameters instead of "string building" and opening the client to injection attacks. His code thus resembled very small filters: HTTP requests mapped into SQL, and then results mapped back to the client's output requirement (unspecified in the story).
His code wasn't super fast and wouldn't win any awards for being clever, but he got it done quickly and it worked. They were able to ship. Over the years, as they moved from one web server to another and from one platform to another, the maintenance programmers they brought on later (for Joe had moved on, as people do) were able to adapt it without too much trouble. The CGI aspect meant it could run on IIS or nginx or whatever else they found.
It would never scale to huge numbers of queries per second, but it wasn't supposed to. It needed to handle 500 devices in the first year polling about once an hour. That's 12000 queries per day, or .138 QPS (queries per second). You could almost service those requests by hand if the timeouts were high enough and people were cheap enough: just cut and paste!
Bob asked the same questions, wrote CGI and hand-coded SQL too, but made a mess of it. It took him three times as long to write. It had numerous security problems and took the site down when someone discovered they could pull a "Bobby Tables" attack and change everyone's recipes to involve dog poop. Customers rioted and demanded refunds. The company went out of business.
They used the same technologies and got two different results... and this happens constantly.
Some technologies are used to create only garbage, sure, but the technology itself won't guarantee success.