ProShop is a cloud-hosted ERP platform used by machine shops to manage critical business processes such as quoting, machine scheduling, purchasing, work orders, and invoicing. Many customers rely on desktop accounting software such as QuickBooks Desktop and Sage 50 to manage their financial records.

To eliminate duplicate data entry and streamline accounting workflows, ProShop provides accounting connector software that runs within the customer’s environment. The connector is installed on the same PC as the accounting application and uses the vendor-provided SDKs to create invoices, and bills generated within ProShop.

This architecture allows machine shops to continue using their existing accounting software while benefiting from the operational efficiencies of a cloud-based ERP platform. However, because the accounting applications run within the customer’s own environment, ProShop must maintain reliable communication between our cloud-hosted service and software operating inside customer networks.

As our customer base grew, the networking requirements needed to support this communication became increasingly difficult to deploy, support, and troubleshoot.

The original connectivity model was designed at a time when the customer base was smaller and the deployment process could be managed with a higher degree of individual attention.

To enable communication between the ProShop platform and the accounting connector running within a customer’s environment, network connectivity needed to be established between cloud-hosted services and software operating inside the customer’s network. While this approach worked well, it often required customer-specific network configuration and ongoing maintenance.

As ProShop continued to grow, several challenges began to emerge. Deployment and onboarding could be difficult for customers without dedicated IT resources, and troubleshooting connectivity issues often required investigating networking, firewall, routing, and workstation configuration across a wide variety of environments.

The solution also relied on customer-managed infrastructure and network configuration remaining consistent over time. Changes to internet services, network equipment, workstation configuration, or security policies could occasionally introduce connectivity issues that required additional support and investigation.

From an operational perspective, the architecture created support overhead and complexity that became increasingly difficult to scale as the customer base expanded. The team recognized an opportunity to simplify deployment, improve reliability, reduce support requirements, and move toward a more maintainable long-term solution.

To simplify deployment and reduce operational complexity, the team redesigned the connectivity model so that communication would be initiated from the customer environment rather than from the internet.

Instead of requiring customers to expose services within their network, the accounting connector established a secure outbound connection to cloud-hosted services running in AWS. Once connected, the connector could securely exchange information with the ProShop platform without requiring customer-managed firewall rules, port forwarding, or other specialized network configuration.

The new architecture significantly reduced the dependency on customer-specific networking environments while providing a more consistent and supportable deployment model. By shifting the responsibility for connectivity management to cloud-hosted services, the solution became easier to deploy, easier to troubleshoot, and less susceptible to environmental changes within customer networks.

The resulting architecture provided a more reliable foundation for communication between cloud-hosted services and customer-managed systems while reducing the operational burden placed on both customers and support teams.

A large part of my role was helping test and validate the new connectivity model in real-world environments. While the architecture looked straightforward on paper, every customer environment was different. Some customers had dedicated IT staff, while others were small shops managing their own networks and infrastructure.

As customers began adopting the new solution, I worked closely with implementations, support, and customers to troubleshoot issues, identify edge cases, and help ensure the architecture behaved reliably across a wide variety of environments. This often required investigating issues that crossed application, networking, operating system, and infrastructure boundaries.

What I enjoyed most about the project was seeing a complex operational problem replaced with a much simpler solution. Customers no longer needed to worry about networking concepts such as port forwarding or static IP addresses, and support teams spent less time troubleshooting connectivity issues. The result was a solution that was easier to deploy, easier to support, and more reliable for everyone involved.

The new connectivity model significantly simplified the deployment experience for customers while reducing the operational burden on internal teams.

Customers no longer needed to understand or manage networking concepts such as port forwarding, firewall configuration, or static IP addresses in order to connect their accounting systems to ProShop. This made onboarding faster and reduced the amount of technical assistance required during implementation.

The new architecture also proved to be more reliable over time. Because connectivity was no longer dependent on customer-managed network configuration, routine changes such as replacing internet equipment, changing service providers, or modifying workstation settings were far less likely to impact system operation.

From a support perspective, the solution reduced the number of connectivity-related issues that required investigation and allowed implementation and support teams to spend less time troubleshooting customer environments.

Most importantly, the project transformed a process that could be challenging for smaller organizations into one that was largely transparent to the customer, resulting in a simpler, more reliable experience for everyone involved.

One of the biggest lessons from this project was that operational simplicity is often just as important as functionality. The original solution worked, but as the customer base grew it became clear that reducing complexity would have a greater impact on reliability and supportability than adding new features.

The project also reinforced the importance of designing systems around real-world customer environments rather than idealized ones. Every customer network, workstation, and security policy is different, and solutions that depend on customer-managed infrastructure can become increasingly difficult to support at scale.

Finally, I gained a deeper appreciation for the value of shifting complexity away from customers whenever possible. By moving connectivity management into cloud-hosted services, the solution became easier to deploy, easier to troubleshoot, and more resilient to changes outside of our control.

Looking back, the most successful aspect of the project wasn’t the technology itself—it was the fact that customers no longer needed to think about it. The best solutions are often the ones that quietly do their job in the background.