Clients regularly ask for custom web applications. They want a portal where customers can log in and view their service history. They want an internal dashboard that aggregates data from three different systems into one interface. They want a scheduling tool that integrates with their operational software. These are legitimate business requirements and your client is not wrong to want them.
The problem is that building a web application is a software development project, not an infrastructure project. It requires a different set of skills, a different development workflow, and a different ongoing maintenance commitment than the managed services you deliver. When your team takes on a web portal project to accommodate a client request, you absorb all of that complexity into an engagement model that was not designed for it. These projects are often underscoped, underpriced, or delayed. Your best engineers spend weeks on custom application development while routine infrastructure tickets accumulate. The client relationship can strain under delayed timelines. Your margins can disappear.
You need a way to say yes to the client’s request without absorbing the project yourself.
Why Web Portals Keep Landing on Your Desk
Clients bring web portal requests to their MSP because you are the trusted technical relationship. You understand their systems. You know where their data lives. You have credibility when it comes to anything involving technology and security. From the client’s perspective, this request is a natural extension of the relationship. From yours, it is a scope expansion with no clean boundary.
The challenge is that you cannot simply say no and leave the client without a solution. If you decline and they hire a random web development agency, that agency will likely do one of several things that create problems for you. They may try to access internal systems without understanding the security requirements. They may build integrations that introduce unauthorized access pathways into the network you manage. They may deliver a portal that requires ongoing support you end up providing informally because the development agency disappears after launch.
One of the safest ways to protect your client relationship and your operational scope is connecting the client with a web development partner you trust, who operates under a defined agreement, and who builds the application in a way that your team can manage the infrastructure around cleanly.
Scoping the Project Before It Starts
Many custom web portal projects run over budget because the scope was not defined precisely enough before development began. Your engineering team understands this principle well from infrastructure projects. It applies equally to software development.
Before any web developer writes a line of code, the data architecture for the portal needs to be specified. This is where your expertise is genuinely valuable and where your involvement adds concrete benefit to the client.
Work with the client to identify the exact data points the portal needs to display, accept, or manipulate. Be specific. Not “customer account information” but the specific fields: account number, service tier, contract start date, last service date, and current ticket status. Not “reports” but the precise aggregations: total service calls in the last thirty days, average resolution time, and open invoices over sixty days. This exercise often reveals that clients want less than they initially describe. The first conversation produces a list of ambitious features. The exercise of specifying exact data points produces a much shorter list of actual requirements.
Once the data points are defined, specify the access control requirements. Who can see what? A customer logging into the portal should see only their own account data, not other customers’ records. Which employees have administrative access? Does the portal need role-based permissions? These requirements need to be documented before development begins because retrofitting access controls into an application that was built without them is expensive and error-prone.
Finally, specify the integration requirements precisely. If the portal needs to pull data from an internal system, define the exact API endpoint or database view that will serve that data. Define the authentication method. Define the data format. This specification becomes the technical contract between your infrastructure and the web application. The developer builds to the spec. You control what the spec exposes.
Designing the Integration Boundary
The security architecture of the data connection between the internal system and the web portal is the most critical technical decision in the project. Done correctly, it keeps your managed infrastructure protected while giving the portal access to the data it needs. Done incorrectly, it creates an opening in the network perimeter that the web application and its hosting environment can reach through.
Two common approaches exist for this boundary.
An API gateway is the more modern and often preferable solution. Your team builds or configures a dedicated API endpoint that lives at the edge of your managed network. This endpoint accepts authenticated requests from the web portal, queries the internal system for the specific requested data, and returns a structured response. The internal system does not need to receive broad direct traffic from the public internet. The web portal does not need database credentials or direct network access. The API gateway becomes the primary point of contact between the two environments, and it is built to expose exactly the data the portal needs and nothing else.
A dedicated VPN tunnel is appropriate for situations where the data requirements are more complex and an API gateway alone is insufficient. The web hosting environment connects to a dedicated, narrowly scoped VPN tunnel that provides access to a specific internal resource. This tunnel is not the general client VPN used by employees. It provides isolated access to a single defined endpoint, authenticated by certificates you manage, and monitored for traffic anomalies.
Both approaches keep your internal systems protected. Both approaches create a clean separation between the web layer and the infrastructure layer. Both approaches give you visibility and control over what the web portal can access.
The Partner Agreement That Protects Your Relationship
The practical concern that makes MSPs hesitant to introduce any outside vendor to a client is the fear of losing the account. You built that relationship. You understand the client’s environment. A web developer who becomes embedded with the client has both the opportunity and potentially the motivation to expand their footprint.
This concern is legitimate and it should be addressed directly in writing before any work begins.
A formal noncompete and referral agreement with your web development partner specifies exactly what the partner can and cannot do. The partner is engaged to build and maintain the web application. They do not solicit the client for network management, infrastructure support, cybersecurity, or any other service in your scope. They do not establish direct billing relationships with the client for services outside their defined scope without your explicit consent. They coordinate all project-related communications that touch your infrastructure through you. Violations have defined consequences.
This agreement protects you. It also gives the client confidence that the two vendors serving them operate within clear boundaries and are not competing for the same scope of work.
The Business Case for This Model
Consider the alternative. Your team accepts a web portal project. You estimate forty hours and quote accordingly. The project runs to one hundred twenty hours because the initial data integration was more complex than anticipated, the client added three features during development, and the launch uncovered a compatibility problem with the internal system version you tested against. Your margin is negative. Two senior engineers spent three weeks on the project. The client is happy with the final result but frustrated about the delays and cost overruns.
Now consider the referred model. You bring in a web development partner under the agreement described above. You scope the data integration boundary. You provide the API specification. The web developer builds the application to that spec. You review the integration architecture before launch. Both teams stay in their lane. The project is delivered on budget. The client is happy. You get a referral fee or a strengthened relationship. Your engineers spent five hours on the project rather than one hundred twenty.
Boston Web Group builds secure custom web applications and portals that integrate cleanly with the infrastructure our MSP partners manage. We work from your API specification or collaborate with your team to define one. We are comfortable working under referral and noncompete agreements when the partnership requires them. We handle ongoing application maintenance, security updates, and feature development after launch through structured support plans. You stay in control of the infrastructure and the client relationship. We stay in our lane.
Your clients’ needs are real. The question is who builds what. Getting that division right protects your margins, protects your team’s capacity, and delivers a better result for the client than an engineering team working outside their core competency.
Related reading: The MSP’s Guide to Web Agency Partnerships, Part 4: How to Vet a Web Agency Partner, The MSP’s Guide to Web Agency Partnerships, Part 3: Structuring the Agreement, and Eliminating Information Silos by Connecting Disparate Software Systems.