Daniel sent us this one — he's been thinking about systems integrators and managed service providers ever since that hotel automation conversation. He used to work at an industrial IoT gateway company called Ayeka, and he remembers that a huge part of their challenge was finding good systems integrators in different markets, people who knew how to implement sensor networks and integrate with SCADA systems in operational technology environments. That expertise doesn't come cheap, but it's a great niche for people who know Schneider and Siemens hardware inside out. He wants us to talk about who systems integrators actually are, then contrast them with managed service providers — the MSPs that handle outsourced IT for companies. How many of them are out there, what's the career trajectory look like, and where are the main differences between the two models.
By the way, DeepSeek V four Pro is writing our script today. Which explains why I keep wanting to cite Wikipedia.
I was going to say, you sound suspiciously well-researched already.
Look, I did my homework on this one. Daniel's prompt hits something that most people in tech never think about — there's this entire parallel universe of industrial computing that operates on completely different assumptions than the IT world. The systems integrator sits right at the boundary between those two worlds, and almost nobody outside the industry knows what they do.
Let's start with the obvious question. What is a systems integrator, and why does Daniel's hotel architect wife need one?
A systems integrator is the person or company that takes all the disparate subsystems in a building or industrial facility and makes them talk to each other. In a hotel, you've got the lighting control system from one vendor, the HVAC from another, the access control and door locks from a third, the entertainment system from a fourth, maybe automated blinds from a fifth. None of these things speak the same language out of the box. The systems integrator wires them together, programs the logic, configures the interfaces, and makes sure that when a guest checks in, the room knows to set the temperature, unlock the door with their phone, and turn on the lights to a welcome scene.
Daniel's point is that none of his home automation knowledge transfers to this.
Home automation runs on consumer protocols — Z-Wave, Zigbee, Matter if you're fancy, maybe some Wi-Fi devices. Industrial and commercial building automation uses entirely different stacks. You're talking about BACnet for HVAC, Modbus for industrial controllers, KNX for building management in Europe, DALI for lighting control. The cabling is different, the voltage levels are different, the failure modes are different, and the regulatory requirements around fire safety and life safety systems are completely different. A consumer smart home hub has no idea what to do with a BACnet trunk.
That's before you even get to the software layer.
In industrial settings, everything flows into a SCADA system — supervisory control and data acquisition. This is the software that gives operators a visual interface to monitor and control everything from water treatment plants to factory floors to hotel energy management. SCADA networks run on protocols like OPC-UA, a machine-to-machine communication standard for industrial automation. The systems integrator needs to know how to configure OPC-UA servers, set up the data tags, create the dashboards, and make sure the whole thing is cyber-secure in a way that doesn't break real-time performance requirements.
When Daniel says he worked at Ayeka making gateways for connecting industrial sensors to networks, they were building the hardware that sits between the sensor layer and the SCADA layer.
Their whole business model depended on finding systems integrators in different regions who could actually install and configure those gateways properly. The gateway is just a box with ports and firmware. The systems integrator is the one who knows what to connect to it, how to map the data, and how to troubleshoot when something inevitably doesn't work as documented.
Which brings us to the uncomfortable reality Daniel's pointing at. This expertise doesn't come cheap, and it shouldn't.
No, it absolutely shouldn't. A good systems integrator needs to be fluent in multiple vendor ecosystems. Siemens has its own entire universe — Simatic controllers, TIA Portal engineering software, WinCC for SCADA. Schneider Electric has EcoStruxure, Modicon controllers, their own programming environments. Rockwell Automation owns the Allen-Bradley ecosystem, which dominates North American manufacturing. Each of these is a career's worth of knowledge by itself, and a systems integrator often needs to be competent across two or three of them plus a bunch of specialty protocols.
The stakes are different from consumer tech. If my smart bulb doesn't turn on, I'm mildly annoyed. If a hotel's entire lighting system fails the night before a conference, or a factory's production line SCADA goes down, we're talking about real money.
We're talking about downtime that costs thousands of dollars per minute in some industries. The systems integrator market globally was estimated at somewhere around five hundred billion dollars recently, and it's growing. The industrial automation side alone is projected to push past four hundred billion within the next couple of years. This is not a niche cottage industry — it's just invisible to most people because it happens behind walls and inside equipment racks.
Let's talk about who actually becomes a systems integrator. What's the career path?
It's almost never a direct path. Most systems integrators start as either electricians who got interested in controls, or engineers — typically electrical or mechanical — who gravitated toward the software and configuration side. You'll see people who spent five years as a maintenance technician in a factory, learned the PLC programming for their specific plant, then moved to an integration firm where they could apply that knowledge across multiple clients. Or you'll see electrical engineering graduates who joined a firm like Arup or WSP on the building services side and specialized in building management systems.
The compensation reflects the scarcity.
A mid-career systems integrator in North America can expect somewhere between eighty and one hundred twenty thousand dollars. Senior people who can architect entire building automation systems or design SCADA networks for industrial plants can push well past one hundred fifty thousand. And if you're independent — running your own integration firm with a handful of engineers — you're billing at rates that make lawyers look affordable. Two hundred to three hundred dollars an hour is not unusual for specialized industrial integration work.
The thing I find interesting is how regional this expertise is. Daniel mentioned that Ayeka struggled to find good integrators in different sales markets. It's not like you can just hire someone remotely to configure a SCADA system in a factory in Malaysia.
That's one of the fundamental constraints of this industry. You need people on site. The hardware is physical, the wiring is physical, and a lot of the configuration requires being physically connected to the controllers during commissioning. There are remote diagnostics tools — most SCADA systems have some form of remote access now — but the initial setup and integration almost always requires boots on the ground. This means the availability of skilled integrators in a given geography directly determines whether industrial IoT companies can sell into that market.
Which creates this weird dynamic where a company like Ayeka can have a technically superior gateway, but if there's nobody in Thailand or Brazil who knows how to integrate it with the local SCADA infrastructure, they can't sell there.
That's exactly why Daniel's framing this as a great market to be in for people with the right expertise. The barrier to entry is enormous — you can't just take a six-week bootcamp and become a systems integrator. You need years of hands-on experience with specific vendor hardware, you need to understand the regulatory environment in your region, and you need the kind of troubleshooting intuition that only comes from having seen things go wrong in dozens of different ways.
Let's pivot to the other side of this conversation. Managed service providers. Daniel wants to know how they compare.
An MSP is a completely different animal. If a systems integrator is a neurosurgeon who specializes in making specific systems talk to each other, an MSP is more like a general practitioner who handles the ongoing health of a company's entire IT environment. The MSP model emerged in the late nineteen nineties and early two thousands as companies realized they didn't want to staff a full internal IT department for commodity services.
What does "commodity services" mean in this context?
Network management, help desk, email, file servers, backups, security patching, user provisioning, device procurement and management. The stuff every company needs but few want to build expertise around internally. The MSP takes over these functions, typically charging a per-user or per-device monthly fee, and the client gets a predictable IT cost rather than the unpredictable expense of hiring, training, and retaining IT staff.
Daniel called it the bread and butter of outsourced tech management. How big is this market?
The global MSP market was estimated at around two hundred seventy billion dollars recently, and it's growing at roughly twelve to thirteen percent annually. There are estimates that put the number of MSPs worldwide at somewhere between forty thousand and fifty thousand firms, though that's a fuzzy number because it depends on how you define an MSP. A lot of small IT consultancies do some managed services without calling themselves an MSP.
The career trajectory is different from systems integration.
More accessible, for one thing. The typical MSP career starts at the help desk — answering tickets, resetting passwords, troubleshooting printer issues. From there you move to a more specialized role — network administrator, systems administrator, security analyst. After a few years you might become a technical account manager or solutions architect, designing the overall IT environment for clients. The top of the ladder is typically either a senior engineer role with deep specialization in something like cloud migration or cybersecurity, or moving into management and eventually running the MSP yourself.
What does the compensation look like compared to systems integration?
Generally lower at the entry level, but with more predictable progression. A help desk technician at an MSP might start at forty to fifty thousand dollars. A network engineer with a few years of experience can hit seventy to ninety thousand. Senior architects and security specialists can reach one hundred twenty to one hundred forty thousand. The ceiling is lower than systems integration for individual contributors, but the floor is higher and the jobs are more plentiful.
The more specialized the skill, the higher the ceiling but the fewer the chairs.
MSPs have something that systems integrators generally don't — recurring revenue. An MSP signs a client to a three-year contract at a fixed monthly rate. That creates a predictable business model that makes MSPs relatively stable employers. Systems integration is more project-based. You get hired for a specific building or factory, you do the work, you get paid, and then you need to find the next project. The really successful integrators build long-term maintenance contracts on top of their project work, essentially adding an MSP layer to their integration business.
There's actually some convergence between the two models.
There is, and that's something Daniel's prompt hints at without stating it directly. The smartest systems integrators realize that once they've built the automation system for a hotel or a factory, they're in the perfect position to be the ongoing managed service provider for that system. They know the configuration better than anyone, they have the relationships with the vendors, and they're already trusted by the client. Why let some other company pick up the maintenance contract?
What stops them from doing that more often?
Different skill sets, mostly. Running a managed service requires a different operational model. You need a help desk, you need service level agreements, you need monitoring tools that can alert you to problems before the client notices. A lot of systems integrators are engineers who are great at designing and commissioning systems but have no interest in running an ongoing service operation. The business models are genuinely different, even if the technical domains overlap.
Let's talk about the MSP landscape specifically. Daniel asked how many of them are out there and what the structure looks like.
The MSP market is highly fragmented. You've got a handful of very large players — companies like Cognizant, DXC Technology, and the managed services divisions of the big consulting firms — but the vast majority of MSPs are small businesses. A typical MSP might have five to twenty employees serving small and medium businesses in a specific city or region. The barriers to entry are low compared to systems integration. You can start an MSP with a few certifications, some remote management tools, and a handful of clients who know and trust you.
Which explains the sheer number of them.
If you look at the United States alone, there are probably fifteen to twenty thousand companies that could reasonably be called MSPs. Most of them are invisible to the broader tech industry because they're not building products or raising venture capital. They're just quietly keeping the IT infrastructure running for law firms and dental practices and manufacturing companies and nonprofits.
The career trajectory for someone who wants to help people solve technical challenges, as Daniel put it?
MSP work is actually a great fit for that personality type, because you're constantly dealing with different environments and different problems. One day you're migrating a client from on-premise Exchange to Microsoft three sixty-five, the next day you're figuring out why a point-of-sale system won't print receipts, the day after that you're designing a backup strategy for a company that's never had one. If you enjoy variety and you like the satisfaction of being the person who fixes things, MSP life can be rewarding.
What about the downsides?
Burnout is real. MSPs often operate on thin margins, which means they run lean on staff. When multiple clients have emergencies simultaneously — and they always seem to happen simultaneously — you're working long hours. There's also the challenge of dealing with clients who don't understand or value what you do. You'll get the call that starts with "the internet is slow" and turns out to be a failing switch that nobody budgeted to replace.
That sounds familiar from every IT person I've ever known.
The other structural challenge for MSPs is that cloud services are eating into their traditional revenue. When a company moves their email to Microsoft three sixty-five and their files to SharePoint and their line-of-business apps to SaaS platforms, there's less on-premise infrastructure to manage. The smart MSPs have pivoted to become cloud management specialists — configuring and securing cloud tenants, managing identities, handling the integrations between different cloud services — but it's a different skill set than managing on-premise servers.
Let's go back to the systems integration side for a moment. Daniel mentioned SCADA and operational technology specifically. I think a lot of listeners might not appreciate how different OT is from IT.
This is one of those distinctions that matters enormously in practice. IT is about managing information — email, databases, web servers, file storage. The priorities are confidentiality, integrity, and availability, typically in that order. OT is about controlling physical processes — assembly lines, power grids, water treatment, building climate. The priorities are reversed. Availability is everything. If a SCADA system goes down, production stops. Safety is paramount — you cannot have a software update introduce a failure mode that could injure someone. And real-time performance is non-negotiable. A control system that takes three seconds to respond to a pressure sensor reading is not doing its job.
When you're integrating systems in an OT environment, the entire mindset is different.
In IT, you can reboot a server at three in the morning and nobody cares. In OT, you might need to schedule downtime six months in advance to coincide with a planned plant shutdown. You can't just push a Windows update to a SCADA workstation. The workstation might be running an operating system that's fifteen years old because the control software isn't certified on anything newer, and replacing it would require revalidating the entire manufacturing process with regulators.
Which is why systems integrators who understand OT are so valuable. They know how to work within those constraints.
They know the vendor ecosystems. Daniel mentioned Schneider and Siemens specifically, and those are the two giants of industrial automation. Siemens has something like thirty percent of the global industrial automation market. Their Simatic PLCs are everywhere. If you can walk into a factory and troubleshoot a Siemens S7 controller running Step seven or TIA Portal, you will never be unemployed. Schneider's Modicon line is the other major ecosystem, especially strong in process industries like oil and gas, water treatment, and food and beverage.
Rockwell with Allen-Bradley in North America.
Rockwell owns something like sixty percent of the North American PLC market. Their ControlLogix and CompactLogix platforms are the default choice for American manufacturing. The programming environment is different from Siemens — ladder logic is much more common in the Rockwell world, while Siemens shops tend to use more structured text and function block diagrams. An integrator who's fluent in both ecosystems can command a serious premium.
Daniel's original point was that none of his home automation knowledge transfers to this. I want to dig into why that is, beyond just the protocols being different.
The fundamental difference is determinism. A home automation system can be best-effort. You tell Alexa to turn off the lights, maybe it takes half a second, maybe it takes two seconds, it doesn't really matter. An industrial control system has to be deterministic. If a sensor detects that a pressure vessel is approaching its safety limit, the control system must respond within milliseconds, every single time, with no variation. This requires real-time operating systems, deterministic networking, and redundancy at every level.
The hardware reflects that.
Industrial controllers are built for environments that would destroy consumer electronics. They operate in extreme temperatures, high humidity, vibration, electrical noise. A PLC in a steel mill might be sitting ten feet from a furnace. The hardware is ruggedized, the components are rated for industrial temperature ranges, and the mean time between failures is measured in decades. A consumer smart home hub has a life expectancy of maybe five years before the manufacturer stops supporting it.
That last point is actually crucial for the hotel context. A hotel is a building that's expected to operate for decades. The automation system needs to be serviceable and expandable over that entire lifespan.
Which is where the systems integrator's role becomes even more important. They're not just installing a system — they're designing an architecture that can evolve. When the hotel wants to add a new wing in ten years, the integrator needs to have specified a system that can scale. When a particular sensor model is discontinued, there needs to be a migration path. When cybersecurity threats evolve, the system needs to be patchable without breaking the integrations.
This is why Hannah, as an architect, needs to bring in a systems integrator early in the design process rather than treating automation as something you figure out after the building is designed.
The integrator needs to be at the table when decisions are being made about electrical infrastructure, network cabling, equipment rooms, and even the physical layout of spaces. You can't just run BACnet over whatever cabling happens to be available. You need to plan for it. The number of building projects that treat automation as an afterthought and then end up with a mess of incompatible systems is staggering.
Let me bring this back to the career question Daniel asked. Suppose someone's listening and thinking, this sounds interesting, how do I get into either of these fields?
For systems integration, the most reliable path is through an electrical engineering or controls engineering degree, followed by working for an established integration firm. The big ones are companies like ATS Automation, JR Automation, and a bunch of regional players. You'll get trained on the job, you'll shadow senior integrators on commissioning trips, and after three to five years you'll have enough experience to lead projects yourself.
For the MSP side?
More entry points. You can start with an IT support role, get certifications — CompTIA A plus, Network plus, Microsoft certifications, eventually something like the Cisco CCNA or the Certified Information Systems Security Professional if you want to specialize. Many community colleges have IT programs that feed directly into MSP jobs. The key is demonstrating that you can troubleshoot and that you can communicate with non-technical clients. MSPs value soft skills more than most tech employers because you're constantly interfacing with people who are stressed and confused.
What about the entrepreneurial angle? Daniel seemed interested in the idea that these are good markets for people who know their stuff.
Both models are very entrepreneur-friendly. Starting an MSP has relatively low capital requirements — you need a remote monitoring and management platform, a professional services automation tool for ticketing and billing, and some basic infrastructure. The hard part is building a client base, which usually means starting with a few clients who followed you from a previous employer and growing through referrals. Starting a systems integration firm requires more upfront investment in engineering talent and vendor relationships, but the revenue per project is much higher.
The exit opportunities?
MSPs are acquisition targets. There's been a wave of consolidation in the MSP space over the past few years, with private equity firms rolling up smaller MSPs into larger platforms. If you build an MSP with a few hundred thousand in annual recurring revenue and a stable client base, you can sell it for a multiple of EBITDA. Systems integration firms are harder to sell because they're more dependent on the founder's expertise and relationships, but the really successful ones do get acquired by larger engineering firms.
I want to circle back to something Daniel mentioned in his prompt — the idea that finding good systems integrators in different sales markets was a major challenge for Ayeka. That feels like it's still an unsolved problem.
It absolutely is. The talent shortage in industrial automation is severe and getting worse. The generation of engineers who learned PLC programming in the eighties and nineties is retiring, and there aren't enough young engineers entering the field to replace them. Part of the problem is that industrial automation isn't glamorous. It doesn't have the cultural cachet of working at a tech startup or building consumer apps. But the work is interesting, the pay is good, and the job security is exceptional.
Because factories and buildings will always need to be controlled, regardless of what happens in the software industry.
The physical world doesn't go away. We're not going to stop needing water treatment plants and power grids and manufacturing lines. If anything, the push toward reshoring manufacturing in the United States and Europe is going to increase demand for industrial automation expertise. Every new factory needs integrators.
There's also the cybersecurity dimension, which we haven't really touched on. OT security is a growing concern.
It's a massive concern. The Colonial Pipeline incident a few years back was a wake-up call, but the reality is that a lot of industrial control systems were designed before cybersecurity was even a consideration. They run on air-gapped networks that aren't actually air-gapped, they use protocols with no authentication, and they're connected to IT networks for reporting and analytics purposes. Securing these environments without breaking the real-time performance requirements is a specialized skill that combines OT knowledge with cybersecurity expertise. Systems integrators who can do both are among the most in-demand professionals in the entire tech industry.
Let's talk about the hotel automation example specifically, since that's what kicked off this whole conversation. What does the systems integrator actually do on a hotel project?
It starts during the design phase. The integrator works with the architect and the MEP engineers — mechanical, electrical, plumbing — to specify the control systems. They decide what protocol the building automation system will use, typically BACnet for commercial buildings in North America. They lay out the network topology — where the controllers go, how they connect to the supervisory system, where the operator workstations will be located. They specify the sensors and actuators for each zone. Then during construction, they oversee the installation, commission each subsystem, and verify that everything works.
The guest room experience that Daniel was originally asking about?
That's a separate layer on top of the building automation system. The guest room control — lighting scenes, climate control, blinds, do-not-disturb indicators — typically runs on a dedicated room controller that talks to the building automation system for HVAC but has its own logic for the guest-facing features. The integrator programs the room controller to respond to occupancy sensors, to the property management system so it knows when a room is checked in or checked out, and to the guest's preferences if the hotel has a loyalty program integration.
The integration with the property management system is the hard part, I assume.
It's one of the hard parts. The PMS is the hotel's operational brain — it tracks reservations, check-ins, check-outs, housekeeping status, billing. Getting the room automation system to talk to the PMS reliably is non-trivial. Different PMS vendors have different APIs, different data models, different quirks. The integrator has to build and test that integration for every combination of PMS and room control system. This is exactly the kind of thing that makes hotel automation a systems integration problem rather than a consumer technology problem.
This is what Daniel meant when he told Hannah she probably wants to work with a systems integrator.
An architect can design a beautiful building, but she shouldn't be expected to also be an expert in BACnet commissioning and PMS API integration. That's not her job. Her job is to know that the expertise exists, to bring the integrator in at the right time, and to make sure the automation requirements are reflected in the construction documents.
I think we've covered the systems integrator side pretty thoroughly. Let's give the MSP side its due. Daniel asked specifically about the differences between the two models, and I think the core distinction is project versus service.
That's the simplest way to put it. A systems integrator is typically engaged for a specific project with a defined scope, timeline, and deliverables. They design, install, commission, and then hand over. An MSP is engaged for ongoing operations. They monitor, maintain, update, and support. The integrator builds the house. The MSP keeps it running.
As we discussed, the lines blur when integrators add managed services.
When MSPs start doing projects. A lot of MSPs will do network infrastructure upgrades, server migrations, Office three sixty-five deployments. Those are projects, not ongoing services. The distinction is more about the business model than the technical work. Integrators make most of their money from project fees. MSPs make most of their money from recurring monthly revenue.
What does the typical MSP client look like?
Small to medium businesses, typically between ten and five hundred employees. These are companies that are large enough to need professional IT but not large enough to justify a full-time IT staff. A law firm with thirty attorneys, a manufacturing company with a hundred employees, a chain of dental offices with five locations. The MSP provides them with the IT capabilities of a much larger company at a fraction of the cost.
The MSP is managing everything from the network infrastructure to the end-user devices.
The whole stack. Firewalls, switches, wireless access points, servers whether physical or virtual, backup systems, email, identity management, endpoint security, mobile device management, and the help desk for all of it. The MSP's value proposition is that the client doesn't have to think about any of this. They just pay a per-user fee and get a working IT environment with someone to call when things break.
What's the margin structure like for MSPs?
It varies enormously. A well-run MSP might have gross margins of fifty to sixty percent on their managed services revenue. The biggest costs are labor — the technicians and engineers — and the tools. Remote monitoring and management platforms, professional services automation tools, security software licenses. The economics get better with scale because the tools cost per endpoint decreases as you add more endpoints, but the labor costs are relatively fixed.
The competitive landscape?
Extremely competitive at the low end. If you're offering basic help desk and network management to small businesses, you're competing with every other MSP in your city plus the option of the business just hiring one IT person. The differentiation tends to come from specialization. An MSP that focuses on healthcare and understands HIPAA compliance, or an MSP that specializes in financial services and knows the regulatory requirements, can charge significantly more than a generalist.
Which brings us back to the career question. If someone wants to enjoy helping people solve technical challenges, as Daniel put it, the MSP path offers more direct client interaction than most technical roles.
It does, and that's both the best and worst part of the job. When you solve a problem that's been plaguing a client for weeks and they're grateful, it's incredibly satisfying. When you're explaining for the fifth time why they can't use the same password for everything, it's less satisfying. But if you like variety, if you like being the person people turn to when things go wrong, and if you're comfortable with the reality that you'll never master any one technology because you have to be competent across dozens, MSP work is a good fit.
I think we should also mention the certification ecosystem, because that's a big part of both career paths.
For systems integration, the key certifications are vendor-specific. Siemens has their own certification ladder for Simatic and TIA Portal. Rockwell has theirs for ControlLogix. Schneider has theirs for EcoStruxure. There are also vendor-neutral certifications like the Certified Automation Professional from the International Society of Automation. For MSPs, the certification landscape is broader. CompTIA for fundamentals, Microsoft for cloud and server, Cisco for networking, various security certifications from ISC squared and CompTIA, and increasingly certifications around specific cloud platforms like AWS and Azure.
The investment in certifications is different.
MSP certifications are generally cheaper and more accessible. You can study for a CompTIA A plus on your own and take the exam for a few hundred dollars. Siemens TIA Portal training courses can run several thousand dollars and often require in-person attendance at a Siemens training center. The barrier to entry for industrial automation is higher in every dimension — cost, time, and access to the hardware you need to practice on.
Which is why the talent pipeline is tighter.
Why the people who do make it through can command such a premium. It's simple supply and demand. The global demand for industrial automation expertise is growing faster than the supply of qualified integrators. That's not going to change anytime soon.
To summarize what Daniel's actually asking — if someone's looking at these two career paths, what's the tl;dr?
Systems integration: higher barrier to entry, more specialized knowledge, higher earning ceiling, more project-based, requires deep expertise in specific vendor ecosystems and industrial protocols. MSP: lower barrier to entry, broader skill requirements, more predictable career progression, recurring revenue business model, more client interaction, easier to start your own business. Both are good markets for people who actually know what they're doing. Both suffer from a shortage of skilled practitioners. Neither is going to be automated away by AI anytime soon, because both require physical presence and hands-on troubleshooting.
The hotel automation example that started all of this is a perfect illustration of why the systems integrator exists as a role. It's not just that the technology is complex — it's that the integration across different vendors and different subsystems is inherently a custom engineering problem. Every building is different, every combination of systems is different, and there's no off-the-shelf product that makes it all work together.
The integrator is the person who absorbs all that complexity so the architect and the hotel operator don't have to. That's the value proposition. And it's the same in industrial settings. The factory manager doesn't want to know about OPC-UA tag mapping. They want to know that when they look at their dashboard, they can see what's happening on the production line. The integrator makes that abstraction real.
Now: Hilbert's daily fun fact.
Hilbert: The collective noun for a group of porcupines is a prickle.
actually kind of perfect.
A prickle of porcupines. I'm going to use that.
Our thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. You can find every episode at myweirdprompts dot com.
If you enjoyed this, leave us a review wherever you get your podcasts.
Until next time.
