Skip to content
willowark

The custom software scope your MSP has been turning down

Willowark works as a subcontract engineering partner to IT services firms and managed service providers. You have help desk, endpoint management, networking, backup, and infrastructure covered, and we compete with none of it. What gets declined is the other category: a client wanting a custom application, cloud architecture past lift-and-shift, an integration between two line-of-business systems, or an AI project their board asked about.

We work under your flag, white-label or as a disclosed specialist. In white-label work we never contact your client; communication runs through your project lead. Non-solicitation is mutual, and we do not approach your customers during an engagement or after it. Deliverables land with you — source in your repositories, architecture notes, runbooks, a handoff session — so tier-one support stays yours. We quote fixed scope for a proposal you mark up, or hourly against a block you resell.

The first engagement is typically one client project you have scoped in outline: a portal for a client's customers, a sync between their ERP and a system it was never meant to talk to, or a workflow tool replacing a spreadsheet the office depends on. We write the spec with your project lead, quote it fixed, and build it under your brand with a weekly status you can forward. Small MSP teams and client SLAs shape how we work: nothing we build should add tickets to your board, so monitoring, logging, and a runbook ship with the code.

Reviewed

Illustrative: a software team's open office with monitors showing dashboards

Sound familiar?

If you've said any of these, we should talk.

A client asked us to build them an app and we had to say no.

That is the work we take. We scope it with you, quote it so you can price it into your proposal at your margin, and build it under your name. It is your project — you keep the relationship, the invoice, and the source code.

My techs are billable and utilized. Nobody can go on a three-month build.

Project work does not fit an MSP staffing model, and carrying a software engineer between projects is an expensive bench. You turn our capacity on for the length of an engagement and off afterward, and the team that wrote the first project already knows the environment when the next one comes.

Every client wants AI now and I cannot tell what is real.

We scope it honestly, including saying when the answer is a report rather than a model. The projects that work are unglamorous: retrieval over a client's own documentation, classification and routing of inbound requests, extraction from documents a back office keys in by hand. We design the review step in.

I am not handing a partner my client list.

Reasonable, and it goes in writing first. Non-solicitation runs both directions, we work white-label unless you want us disclosed, and every conversation routes through your project lead. We are an engineering subcontractor with no managed services line of business, so we have nothing to sell your clients.

If the thing breaks at 2 a.m., my help desk is the one that gets the call.

We design for that from the start. Every deliverable includes health checks and alerting wired into your monitoring, structured logs your techs can read, and a runbook covering the failure modes we know about. We offer a defined support window after handoff, and the escalation path to us is written into the agreement rather than assumed.

How this industry actually runs

The operation as we usually find it.

An MSP runs a recurring-revenue business measured per seat or per endpoint, built around predictability: an RMM and PSA stack, techs measured on utilization, and a gross margin that erodes quietly when a client generates more tickets than the contract assumed. Project work sits badly against that. A three-month build cannot be staffed off a dispatch board, and pulling your best tech onto it costs the recurring work they were covering, so the request gets declined or referred — and referring a client to a software shop is how relationships drift. Meanwhile QBRs keep surfacing software and data problems that a networking answer does not solve.

Product, integrations, and the AI feature behind themAPIstructured callsYour productweb, mobile, APIBackend servicesqueues, jobs, evalsAI featureretrieval, review gatesData & integrationswarehouse, third parties

Product, integrations, and the AI feature behind them

Components:

  1. Your product (web, mobile, API)
  2. Backend services (queues, jobs, evals)
  3. AI feature (retrieval, review gates)
  4. Data & integrations (warehouse, third parties)

Connections:

  • Your product to Backend services (API)
  • Backend services to AI feature (structured calls)
  • Backend services to Data & integrations
Product, integrations, and the AI feature behind them

What we build

Starting projects that fit IT Services & MSPs.

  • Custom line-of-business applications for your clients, delivered under your brand
  • Cloud architecture past lift-and-shift: landing zones, identity, network design, cost control, Terraform or Bicep
  • Integration between client systems — ERP, CRM, e-commerce, accounting, and the undocumented legacy database
  • AI and automation with honest boundaries: retrieval, classification, extraction, drafting with review
  • Internal tooling: RMM and PSA data joined into margin reporting, ticket triage, onboarding automation
  • Fractional senior engineering attached to vCIO conversations so software questions get real answers
  • Client portals and customer-facing web apps built on the systems your client already runs
  • Modernization of a client's aging line-of-business application before it becomes a ticket source

Capabilities we bring

Working in IT Services & MSPs?

Tell us the line.

What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.

We reply within one business day. No newsletter unless you ask. Privacy

Common questions

What IT Services & MSPs teams ask first.

Will you ever contact or solicit our clients?

No. Non-solicitation is mutual and written into the agreement: we do not approach your customers during or after an engagement, and you do not recruit our engineers. In white-label work we have no direct client contact at all.

How does pricing work for partner engagements?

Two ways. For a client proposal we quote fixed scope against a written spec, so you add your margin and present one number. For ongoing work we bill hourly against a block you resell. Either way you see our rate and set yours.

Have you built software like this before?

Yes. We built AI operating software for Jaguar Land Rover's training schedulers, saving hundreds of hours a year, plus a training video game — full-stack development, cloud architecture, and distributed systems across the JLR ecosystem. That shape, custom software solving one operational problem inside a larger organization, matches most MSP client projects.

How do we present this to our client without it looking like we outsourced it?

Most partners present it as their own capability, which is accurate: you own the relationship, the scope, the pricing, and the delivery commitment. We typically join scoping calls alongside your project lead if you want us on them, introduced as part of your team, and every document carries your brand. If a client asks directly, we suggest saying you bring in specialist engineers for software projects. That is the truth, and clients usually respond well to it.

Who supports the software after it ships?

Tier one stays with you, and we build so that it can: monitoring and alerts land in your stack, logs are readable, and the runbook covers the failures we anticipated. For anything past that, we typically agree a support arrangement up front — a block of hours you resell, or a monthly retainer for changes and upgrades. Usually the same engineers who built the system handle the escalation, so there is no re-learning when something needs attention.

Strategy. Software. Systems.

Engineering for IT Services & MSPs.

Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.