I'm catching issues as I can as the head of IT at an org replacing our Danfoss systems with something else, but it wasn't until about 1.5 years since the initial decision to replace them that I'm finding out from a sub-contractor of the contractor that there's a cloud app our HVAC network will need to talk to - which is not-so-funnily enough a requirement by the state for us to receive associated grant funding for a portion of the new system cost. This was never mentioned to me at all as the head of IT. It's not even a convenience vs security issue, it's a misaligned corporate communications and approval channels issue. In other words, the capacity to secure your technical systems is downstream of political organization.

Now imagine you had 50 such stores.

MPLS? Multi-site Domain? VXLAN? Absolute fantasies, can't be done.

But seriously, networked fridge systems are one of the most straight-forwardly practical use cases for networking tech to improve logistical latency in a supply chain. There are definitely lots of different solutions for securing it depending on scale though.

Could the same thing be done with SMTP way more securely than opening up your firewall to some random AWS EC2 instance? Yeah no doubt.

Do you think grocery retail execs actually understand computers past Microsoft Word and Excel? I report to one, they can barely listen to me say the word WAN failover.

Like all things in IT, experience is the best teacher. Organizations will fail to invest in their technology, security included, and only then will the execs start to trust that the wizards in the backroom are telling them truths instead of asking for new toys - if they're lucky enough to still be the same exec that heard they should take security seriously before the Bad Thing happened.

The guys deploying the new system ($2 million for a single location) are having HVAC schlubs terminate CAT5E and leave the gateway controller just hanging, unmounted to the wall or anything. Lo and behold, the RJ45 port has been broken and you have to send me a new gateway.

All the replacement controllers (for a system that is supposed to be better than Danfoss) are being set to 192.168.0.x. Each individual device, based on the "technician" descriptions are running individual DHCP servers inside them. And they just deploy them, no asking IT about approval or correct network config, just deploy and then make it our problem on a random day when they realize nothing is talking to each other.

They are just now in the late 2020s realizing what a VPS with an API is - truly, nothing to worry about with baby's first public IP address when baby doesn't understand what the implications of multiple DHCP servers on a single network might be.

The people "designing" and deploying these systems are HVAC guys with a little bit of software and networking knowledge. The networking (and security lmao) are the lowest priority part of what they're doing, they're more concerned with crimping pipe and moving onto the next project.

The people doing the project management and buying decisions are likely not IT at most operations, but the Facilities guys, and they'll slap a microcontroller anywhere until IT catches them or tells them they can't do what they want as easily as they'd like. There are no security reviews before deployment because the people heading the project don't even know what security is if it isn't petty theft and they don't want to hear that it will take longer than the contractor is promising them.

For additional context here, given everyone talking about the tightness of margins in retail grocery, until 6 months ago our network backbone switches in an environment where we need true on=prem servers to run operations, were still 10/100 Cisco Catalyst 2000s. Previous generations had fucked up the networking so hard with such little documentation and wacky misunderstandings that it took me several years to unfuck bits and pieces slowly and then schedule an actual maintenance window (because those mean potential lost sales, can't do that!) to cutover the rest to a more reasonable series of 1Gbps switches. We do mid 8 figures in a single location and I had to go through an entire song and dance to get budget approval for scheduling the 4 hours of OT for my sysadmin to do a maintenance window with me at midnight. Granted, we post mid 5 figures in actual net income most years, so yeah, margins are incredibly tight for smaller players and those of us actually trying to do a good job in any of the different sectors of the business are constantly trying to fix messes that wouldn't exist if there'd been better understanding or honesty about the long term costs of short term savings.

In any case, I'm sure there are more business segments out there like grocery HVAC where the networking is a simple means-to-an-end and the people deploying these networks barely understand the depths of the waters they're swimming in. There is absolutely a need to coordinate all the constituent subsystems to keep inventory stable until it sells, but yeah, if I'd even have been in the room during decision time with the contractors I'd have shot down any plan with external access without very precise deployment specs and plans. But I wasn't, I'm just the guy finding out some just certified HVAC chucklefuck is deploying DHCP bombs on my network 4 months into their contract and thinking they're doing me a favor. Without a doubt, a sufficiently informed and motivated attacker could knock out many SMBs that don't have a suitably knowledgeable IT department or god forbid an MSP charging them extortion rates for little real value.

Really love that I'm finding out our current HVAC system is getting exploited in France and at US Army bases on the first day of my vacation. Honestly think my only winning move here is to either buy a completely separate ISP ingress for the HVAC system or set a new subnet with only enough address space for the handful of microcontrollers needed for this new system. Time to start pushing on when the Danfoss is being retired and with how much gusto.

On the other hand, I also get the sense that for a very large organization with siloed teams that sure, the org moved to bring all the endpoint timestamps to a standard 3339 and either you never got the memo or your endpoint being misaligned would get caught at code review time and changed then but the agent was proactive here and went ahead and saved some time. Like, truly, I get that the marginal gains there add up on the balance sheet.

But what about when it is important that your APIs timestamps stay unaligned as epoch? Do you now need to set an override to meta-program that field for the AI as an additional token in the context window every time it runs?

Part of me is impressed for sure about what’s being achieved, but then another part is like “is the boilerplate of copying in the database field names and then shift+alting to write 100 lines of { get; set; } at the same time really so terrible for everyone?” I’m being hyperbolic for effect but I think my point is clear.

There’s also a third part of me that feels like I’m watching the creation of credit-default swaps of tech debt. If no one has time to do the changes that seem like a lot of work to a large organization with inertia because no one has the breadth of mastery needed to implement them as efficiently as possible, how the heck is anyone going to audit and fix the behavior when subtle mistakes eventually cascade?

Is this just the coding version of Amazon outsourcing their shipping to third party contractors that definitely led to people dying but shielded Amazon from liability? Like, “oops, sorry we don’t know why the AI changed our code and your bank account got emptied, we’ll look into it, but it’s not our fault, just the vagaries of fate!”

Again, I do understand the possible business savings in the short term in terms of administrative overhead, but I really shudder at the possible downstream effects of agentic code at scale and I’m trying to understand the real savings for a user that outweighs the downside risk of blowing up your production system and then being in a position of no one suited to fixing it who is responsible to do so.

One thing I think you've got very right here is the relatively spare use of fields in your schema models. I can't emphasize enough how much that will help a seller that uses this, since so many small business owners and employees out there don't know what they don't know and are making it up on the fly and tend to focus on the wrong things. Not a lot of headspace for the "nothing missing, but nothing unnecessary" approach when you're trying to juggle every hat because you're understaffed, and doubly so when you've never even heard the term many-to-one. Of course, because this is open-source, if users want they can extend these schemas (and even extend the views to use them! etc.), but they'll have to go out of their way to do that, not start with a tangled mess of concepts and pare them down. Really, it seems like no big deal, but humble schemas are so so important. At my current job I'm having the fun time of maintaining true spaghetti software with hundreds of fields in tables, a lot of which are null (or empty string! but which is it?), and all of which have no field names beyond a number...to power a POS/inventory system. But don't worry, none of the data is normalized and it pre-aggregates your transactions to compress itself, and then writes those compressed records into an always existing "temp" table and then reads them every time you want a report, and look at that, it takes 5 minutes to generate a COGS report for last week that is a sub 5 ms SQL query. Ugh.

I guess where I'm going with this is that there is so much crapware out in the world, absolute trash that needlessly overcomplicates the problem it addresses, that continues to get its license renewed every year because the clients its sold to now believe its a truly hard problem, but if you look under the hood it's actually just some WSYWIG editor generated garbage that is trying to be everything and so instead is nothing usable, and their sales staff will tell you "just upgrade to our new microservices design to solve those legacy issues!" Every project like yours that takes what is a fairly traditional, well-trod problem and brings it into the open-source realm in a readable and straightforward way is a big win for small-time entrepreneurs. Please keep going with this.

I think you have something here, but the hardest part will be marketing it if you're trying to do this for a living. There are absolutely an absurd number of small businesses out there living or dying by their ecommerce sales who are either struggling to actually use the tools and workflows they currently have or are paying far more than they need to for sub-optimal solutions to this problem. They will not come to you first over the internet because they are not looking for open-source sales software, because they don't know what open-source is, but some honest shoe-leather work pounding the pavement and identifying the larger businesses around you physically or trawling through the business formation records in your county might pay real dividends, even if it's just an HN "lifestyle" business for you with recurring revenue comparable to the average salary.

As a final thought, when you do get to integrating Seller Central, you should look at bringing the different API services out there into your project for dashboards and the like. Maybe you don't want to deal with all that, but being able to flip through market metrics from all the different sales channels and even integrate them together would be a killer feature. In particular I'm thinking of https://keepa.com/#!, but I know other people use https://www.rainforestapi.com/ too. Don't know about the other e-commerce marketplaces out there but I'm sure they have them too.

Congrats on a getting a ten year long lurker to actually post.