The short version:

• Client: A large vehicle parts distributor (anonymized) shipping to hundreds of dealerships, with tens of thousands of SKUs
• Context: Fresh off a merger, mid-migration from a legacy ERP to NetSuite with WMS and SuiteScript customizations
• My role: Consultant on the implementation: printing integration across the warehouse, team training, production debugging
• Engagement: Two months, fully remote

A merger, then an ERP

The sequence here is one PE readers will recognize, because it’s the standard playbook. The distributor merged, got bigger, and the legacy ERP that ran the old company couldn’t carry the combined one. Post merger integration almost always lands on the systems eventually, and for product businesses at this scale it usually lands on NetSuite.

By the time I was brought in as a consultant, the NetSuite implementation was underway: warehouse management, SuiteScript customizations, the works. Tens of thousands of SKUs moving through a warehouse and out to hundreds of dealerships, and all of it had to keep shipping while the systems changed underneath it.

Where I came in

My piece of the rollout was the part that connects software to the physical warehouse: making NetSuite talk to the printers, then making the people comfortable with both.

That sounds small until you watch a warehouse try to operate without it. Every pick, pack, and shipment at this scale runs on printed labels and scannable codes. If the ERP can’t reliably push a label to the right printer on the floor, the fancy new WMS is a very expensive way to stop shipping parts.

The printer problem

The integration ran through a desktop plugin bridging NetSuite to the printer fleet, and the fleet was mixed: standard office printers alongside Zebra thermal label printers. Anyone who has done Zebra printer setup at scale knows the deal. Thermal printers are workhorses right up until they’re not, and their failure modes are finicky: driver quirks, connection drops, labels that render fine on one model and misalign on the next.

I configured the plugin across the printer types, sorted out the per-model quirks, and got label output consistent from the warehouse floor’s point of view: scan, print, move on. The scanning workflow only works when the label side holds up, so that consistency was the whole job.

Training, then a production fire drill

Configuration is half of an implementation. The other half is the team actually using it without calling for help every hour, so I trained the staff on the new printing workflow as part of the engagement.

Then, after go-live, a connection issue surfaced between the printers and the system in production. This is the moment that separates a rollout that sticks from one that breeds workarounds: the warehouse is live, orders are flowing, and something between the ERP and the printer fleet is dropping. I debugged it remotely with my own remote tooling, traced the connection fault, and got it resolved without a site visit.

The whole engagement ran that way. Two months, entirely remote, from configuration through training through the production fix. Distance never cost the client anything, which matters if your operation isn’t down the street from your consultant.

The result

At the end of two months the distributor had warehouse printing running reliably across a mixed fleet inside NetSuite, a trained team running the workflow themselves, and a production issue diagnosed and closed. My workstream wrapped clean, and the operation kept shipping to its dealerships through all of it.

Why this one matters if you’re a buyer

The first two case studies on this site are about security and migrations. This one is here to make a different point: I work deep in the systems businesses actually run on, including one of the largest ERPs on the market.

When a PE firm buys a distributor, the value creation plan almost always touches the ERP, the warehouse workflow, or both. That work fails at the unglamorous layer: the label that won’t print, the scanner workflow nobody trained the floor on, the customization nobody documented. I’ve done that layer, at real scale, on NetSuite, and the same goes for the CRMs and finance systems on the other side of the stack.

If your deal thesis depends on systems doing what the model says they’ll do, that’s the work I do.

Have a rollout or an integration that needs to land? Get in touch.

The short version:

• Client: Two sister engineering firms, one in the US and one in Canada (anonymized), serving industrial clients
• Engagement: Seven years and counting of outsourced IT support and security
• Scope: Email security, cloud storage, remote and in-person helpdesk, phone systems, hardware
• Status: Both firms are now being acquired, primarily for their engineering talent. I still run their security today.

Two firms, one border between them

These two companies came to me about seven years ago. Sister firms, shared ownership, one operating in the US and one in Canada, both doing engineering work for industrial clients. Neither one had internal IT, and neither one needed a big MSP contract with a 40-page SLA. They needed someone who picked up the phone.

That’s been the shape of the whole relationship. I handle their email security, their cloud storage, and their day-to-day support, remote when that works and in person when it doesn’t. Over the years the scope grew the way it does with small firms: I’ve run their phone system migrations, built their workstations by hand when off-the-shelf machines didn’t fit the budget, and made a hundred small calls about where to spend money and where to hold off. IT support for small business lives in those decisions. The stack matters less than the judgment behind it.

The customer security test

A few years in, one of their major industrial customers raised the stakes. Before awarding project work, the customer required compliance with its corporate IT security policy and information security program. Buried in the requirements was a hard one: all project data had to stay in Canada.

That’s a data residency requirement, and it’s the kind of thing that quietly kills deals for small vendors. The engineering team just wanted to work. The customer wanted proof their data wouldn’t drift onto US servers. My job was to close that gap without blowing up the budget or the workflow.

I laid out three options with real time and cost estimates: client-side encryption with Canadian-held keys on their existing cloud storage, a locally encrypted vault, or a move to a Canadian-hosted cloud platform. They picked the Canadian platform. I ran the migration, kept the working copies flowing for the engineer who needed them daily, and mapped the setup against the customer’s security policy documents so the answers were ready before anyone asked.

Small firms lose big customers over vendor security assessments they can’t answer. This one kept theirs.

Then the acquisition came

Both firms are now being acquired by a larger company, and the deal is mostly about people. The acquirer wants the engineers. That’s the whole thesis.

Talent deals move slowly, and this one has. Which makes the IT story simple to state and hard to fake: through the entire drawn-out process, the engineers have kept working, the systems have stayed up, and the security stack has kept running. Seven years in, the incident count is still zero. Nobody on the buyer’s side has had to ask why the target’s email got breached or where the customer data lives, because those answers were settled years ago.

I’m not running this deal, and this case study isn’t about deal work. It’s about the thing that makes deal work easy: an acquirer doing diligence on these firms finds documented systems, a customer-vetted security posture, and a support relationship that didn’t wobble when ownership went into limbo.

What seven years buys

Here’s the honest math on long-term outsourced IT support. Any provider can look good for six months. The value shows up in year three when a customer’s security team comes knocking, and in year seven when a buyer does, and both times the answers are already written down.

These two firms got acquired for their talent. The reason talent was the only thing under negotiation, rather than talent minus a pile of IT risk, is seven years of unglamorous maintenance: patched systems, secured email, data where the contracts say it should be.

If your customers are bigger than you

Industrial customers push their security requirements downstream, and acquirers read your environment like a balance sheet. Both happen on their schedule, not yours. The firms that come through clean are the ones that treated security as routine long before anyone was checking.

If you’re staring down a customer’s vendor security assessment, a data residency requirement, or a sale where your IT needs to hold up to inspection, that’s the work I do.

Facing a security review you’re not sure you’d pass? Get in touch.

How 4.5 years of security work turned a single-location self-storage company into a clean acquisition target, and what a three-week technology handoff looks like when the buyer runs 50+ facilities.

The short version:

• Client: Single-location self-storage operator in Colorado (anonymized)
• Buyer: Private equity-backed storage operator with 50+ facilities
• My role: IT and security provider for 4.5 years, then transition lead on the seller side
• Handoff: Three weeks, kickoff to done

It started with a breach

They found me the way a lot of my clients do: mid-incident. Their previous IT provider had gone defunct, and the provider’s abandoned website was serving malware. Someone at the storage company opened that site looking for support and infected their machine instead.

I took the call, cleaned the infection, recovered their systems, and combed through everything for leftover malicious code. Then I rebuilt their stack so it wouldn’t happen twice: antivirus, EDR through Huntress, cloud backup, and same-day helpdesk, remote and onsite. All of it sized and priced for a single-location business.

Four and a half years of quiet

For the next 4.5 years I ran their IT and security. Webroot and Huntress covered the endpoints. Backups ran to the cloud and got checked. When something broke, I fixed it the same day. No repeat incidents, no drama.

That stretch of quiet matters more than it sounds. When a buyer showed up years later, the company had a documented, monitored environment with a real security history behind it. Most small businesses walk into a sale with none of that.

Then a buyer showed up

A private equity-backed storage operator with 50+ facilities acquired the company. Deals like this live or die in diligence, and the buyer’s team had two questions about IT: is this environment secure, and is it cost-effective?

That’s technology due diligence in one sentence. Buyers want proof, and on small acquisitions they rarely get it, because the seller’s IT knowledge lives in one person’s head or a defunct vendor’s filing cabinet. Here, I had run the environment for years and could answer with documentation instead of guesses. That alone shortened the timeline.

The three-week handoff

Post merger IT integration for this deal came down to four workstreams.

RMM migration. The buyer standardized every acquisition onto their own remote management platform. Instead of touching each machine by hand, I wrote a script that deployed their agent and removed mine (ConnectWise Automate, at the time) across all systems in one pass.

Backup migration. I moved their cloud backups off my platform and onto the buyer’s, and verified restore points on both ends before cutting over. A migration without verified restores is a gamble, and nobody gambles during a closing.

Access control. The buyer’s team ran the access control migration themselves. I supported from the client side, kept credentials flowing, and made sure nothing on our end held them up.

Data cleanup and destruction. The buyer’s compliance requirements meant old data had to go, and go for real. I purged stale records the business no longer needed, then dealt with the retired hard drives that held customer data: a seven-pass wipe on each drive, and then I opened them up and pulled the platters out. Nobody is recovering that data. The platters make decent coasters, if you’re wondering.

Secure data destruction is the step small-business acquisitions skip most, and it’s the one that turns into a lawsuit years later when a drive full of customer records surfaces at a pawn shop.

Total time, including the buyer’s inspection and the back-and-forth between their team and my client: three weeks.

The result

The buyer got what diligence teams almost never get from a small acquisition: a documented environment, a working security stack, verified backups, and proof that legacy customer data was destroyed instead of forgotten in a closet. My client walked into closing without IT sitting on the deal as an open issue.

And the whole thing traced back to a malware infection five years earlier. The same work that saved them from a breach made them a cleaner company to buy.

Why this matters if you’re buying or selling

Most small businesses run on undocumented IT held together by whoever set it up. In an acquisition, undocumented becomes risk, and risk becomes a price reduction or a delayed close. Buyers now run cybersecurity due diligence on deals of every size, and sellers who can’t answer basic questions about their environment pay for it at the negotiating table.

If you’re a buyer, a searcher, or an owner planning an exit, the cheapest time to fix your technology story is before diligence starts. That’s the work I do: assess the stack, close the gaps, and run the handoff so the deal keeps moving.

Working a deal and want a second set of eyes on the technology? Get in touch.

I’m currently using ClickUp for the following + what it’s replaced:

• Time tracking (starting today) – I used to use Toggl
• To-do lists (primary) – Used to use To-doist
  • Both for work and for personal stuff like Shopping lists
• Project Tracking (primary) – Used to use Asana/Trello/Monday + others in the past
• Company Chat – I used to use Slack

It’s starting to replace a lot of apps / functionality so I’m not bouncing from app to app throughout the day. It’s nice only using one app for a lot of different use cases. We’ll see if it can help me organize and bring synergy to my businesses.

They are everything I look for in upgraded street pads in comparison to the OEM pads. As their website says “HPS 5.0 is a Ferro-Carbon compound that provides advanced braking characteristics to enhance the driving experience. This compound combines the safety and quality of aerospace design with the braking technology of motorsports. The results are shorter stopping distances, improved performance under heavy braking conditions, and street car friendly characteristics.” – hawkperformance.com

Now they are going for around 180 for front pads (I still need to do my rear pads here shortly)

I tend to use my brakes more than engine braking, so I have a pretty good idea how they feel. A bit soft on the initial response (which I like personally). They grab nicely when you put adequate pressure. Used them in the snow for a season, and they do well with the ABS when sliding on ice.

My only gripe with them is they seem to produce more dust than the OEM – so cleaning the wheels takes a bit longer and I can live with that. I’ll certainly buy them again when I need to replace my pads on my MK7.

Note to self: When I do replace them, I’ll try to come back with the pictures and the mileage achieved with the Hawk hp street 5.0 pads

The Problem

My server load was pinned at 100%, with php-fpm processes consuming the bulk of the CPU. Using tools like htop and ps, I traced the activity back to a few specific WordPress sites hosted on the server.

The common culprit? Bot traffic hammering uncached pages and XML-RPC endpoints.

The Fix (3-Part Solution)

1. Block Bots with .htaccess

I edited the .htaccess file for each affected site and added rules to block known abusive bots by user agent:

# Block bad bots by user-agent
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} (semrush|ahrefs|mj12bot|dotbot|python-requests|curl|wget|masscan|sqlmap|fimap|nmap|nikto) [NC]
RewriteRule .* - [F,L]
</IfModule>

This simple change started deflecting unnecessary load before it could hit WordPress or PHP.

2. Install and Configure Fail2Ban

I installed Fail2Ban to automatically block IPs that triggered suspicious patterns in my Apache logs (like repeated bot-like requests):

sudo yum install epel-release -y
sudo yum install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Then, I created a jail to detect and ban bad bots:

/etc/fail2ban/jail.d/apache-badbots.conf

[apache-badbots]
enabled = true
port    = http,https
filter  = apache-badbots
logpath = /usr/local/apache/logs/access_log
maxretry = 10
findtime = 300
bantime = 3600

/etc/fail2ban/filter.d/apache-badbots.conf

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*(crawler|bot|spider|python|curl|wget).*HTTP.*"

With this in place, the server now proactively bans repeat offenders and malicious bots.

3. Restart PHP-FPM and Apache to Flush Load

Once the defenses were in place, I restarted the two main services to clear out any bloated or stuck processes:

systemctl restart ea-php81-php-fpm
systemctl restart httpd

This dropped my CPU usage almost instantly and gave the server a clean slate to work with.

Summary

After these changes:

• CPU usage dropped from 100% to <10%
• PHP-FPM processes normalized
• The server has stayed stable under load, even with continued traffic

If you’re running cPanel/WHM and notice unexplained high load:

• Check your access logs
• Filter bots at the .htaccess level
• Set up Fail2Ban to auto-ban bad actors
• And always restart PHP-FPM/Apache after config changes

CISCO DESIGNED Business CBS220-24P-4G Smart Switch | 24 Port GE | PoE | 4x1G SFP | 3-Year Limited Hardware Warranty

The CISCO CBS220-24P-4G Smart Switch is a versatile network switch designed for small to medium-sized businesses. Here’s a quick breakdown:

• Ports: 24 Gigabit Ethernet (GE) ports
• Power over Ethernet (PoE): Supports PoE, allowing it to power compatible devices like IP cameras, phones, and access points directly through Ethernet cables.
• Uplink Ports: 4 SFP (Small Form-factor Pluggable) ports at 1G each for high-speed uplinks to other network devices or the internet.
• Smart Features: Designed to offer easy configuration and monitoring, providing essential Layer 2 network features that support efficient traffic management without complexity.
• Warranty: Comes with a 3-year limited hardware warranty.

This switch is suited for businesses needing a reliable, secure, and simple solution to expand their network and support PoE devices.

Here’s the csv format for the headers and for the Folders – I couldn’t get it to link via the name so I have it cross-reference the Label ID to match the folders:
email, label
example_email@yahoo.com, Label_55

This is what the output looks like:

Here’s my code if anyone wants to make their own python script:

import os
import pickle
import pandas as pd
import base64
from google.oauth2.credentials import Credentials
from google.auth.transport.requests import Request
from googleapiclient.discovery import build
from googleapiclient.errors import HttpError
from google_auth_oauthlib.flow import InstalledAppFlow
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

# Step 1: Authentication and Service Initialization
def authenticate_gmail_api():
    SCOPES = ['https://www.googleapis.com/auth/gmail.modify']
    creds = None

    if os.path.exists('token.pickle'):
        with open('token.pickle', 'rb') as token:
            creds = pickle.load(token)
    
    if not creds or not creds.valid:
        if creds and creds.expired and creds.refresh_token:
            creds.refresh(Request())
        else:
            flow = InstalledAppFlow.from_client_secrets_file(
                'credentials.json', SCOPES)
            creds = flow.run_local_server(port=0)
        with open('token.pickle', 'wb') as token:
            pickle.dump(creds, token)

    service = build('gmail', 'v1', credentials=creds)
    return service

# Step 2: Read Filters from CSV File
def read_filters_from_csv(csv_file):
    filters_df = pd.read_csv(csv_file)
    return filters_df

# Step 3: Search for Matching Emails
# Step 3: Search for Matching Emails
def search_emails(service, query):
    try:
        # Modify the query to explicitly search only within the INBOX
        query = f'label:inbox {query}'
        results = service.users().messages().list(userId='me', q=query).execute()
        messages = results.get('messages', [])
        return messages
    except HttpError as error:
        print(f'An error occurred: {error}')
        return []


# Step 4: Apply Filters and Move Emails
def apply_filters(service, filters_df):
    for index, row in filters_df.iterrows():
        email_filter = row['email']
        label = row['label']

        query = f'from:{email_filter}'
        messages = search_emails(service, query)

        if not messages:
            print(f'No emails found for {email_filter}')
            continue

        for message in messages:
            msg_id = message['id']
            # Move email to the specified folder (label)
            service.users().messages().modify(
                userId='me',
                id=msg_id,
                body={'addLabelIds': [label], 'removeLabelIds': ['INBOX']}
            ).execute()
            print(f'Email from {email_filter} moved to {label} and archived.')

# Step 5: Retrieve and List Label IDs
def list_labels(service):
    results = service.users().labels().list(userId='me').execute()
    labels = results.get('labels', [])

    if not labels:
        print('No labels found.')
    else:
        print('Labels:')
        for label in labels:
            print(f"{label['name']} - {label['id']}")

# Step 6: Main Function
def main():
    # Authenticate and create the Gmail API service
    service = authenticate_gmail_api()

    # Uncomment the line below to list all labels and their IDs
    list_labels(service)

    # Load filter rules from CSV
    csv_file = 'filters.csv'  # Replace with your CSV file
    filters_df = read_filters_from_csv(csv_file)

    # Apply filters to emails
    apply_filters(service, filters_df)

if __name__ == '__main__':
    main()

1. Most importantly drink water or if already feeling meh, mix 2/3 water with 1/3 Gatorade or some other electrolyte and sugar drink.
   • If already feeling meh after flying – drink some warm bone broth
2. Dark chocolate prior to flying helps? Not sure why but chocolate in general is good before a flight
3. Lysine or L-lysine – is an essential amino acid protein block. It’s used for building proteins and it’ll help boost your immune system. It can be found in meat fish, dairy, eggs, and supplements. Take 500mg before flying.
4. Glutathione – is a Master anti-oxidant that is capable of preventing damage to important cellular components caused by sources such as reactive oxygen species, free radicals, peroxides, lipid peroxides, and heavy metals.