Why we built PartnerView

The shape of the problem

We run a partner services firm. That sentence sounds simple. The implications are not.

A partner services firm sells licenses on behalf of vendors. It delivers implementation services directly to clients. It subcontracts in both directions, sometimes the vendor subs to us, sometimes we sub for another partner. It earns money in three different ways at once: license commissions, direct services revenue, and recurring service revenue.

There is no off-the-shelf tool built for that shape. The CRMs are built for SaaS sales teams. The PSAs are built for agencies. The work management tools are built for tasks. None of them know what a vendor commission is, or that a deal can carry license revenue and services revenue at the same time, or that a subcontracting clause has a non-circumvention clock running quietly in the background.

So we did what every partner firm does. We stitched tools together with spreadsheets and human memory.

The tools we tried first

Six tools, before we ever wrote a line of our own code.

• A best-in-class sales CRM. Pipeline got cleaner. Then deals closed and the tool went dark. Delivery opened empty projects and started asking questions sales had already answered.
• An agency PSA. Great at hours-against-projects. Did not know what a vendor commission was, or that license revenue should never enter the project budget.
• A second spreadsheet, for commissions. It worked for a quarter. Then a vendor changed a rate and nobody noticed for two months.
• A work management tool, configured into an operating system. This one almost worked. Then a senior person left, and most of the logic holding the configuration together left with them.
• An accounting system, asked to do too much. Revenue recognition stretched into "if we just add another tag." It did not bend cleanly.
• A folder of SOWs, for subcontracting. Nobody reopened them. Twice we missed a non-circumvention window we did not know was counting down.

Six tools, one spreadsheet stitching them together, and a weekly standing meeting whose entire purpose was to make the spreadsheet honest.

What it actually cost

The tools were not the cost. The reconciliation was.

Every hour a senior person spent rebuilding the same join in the same spreadsheet was an hour we were paying for the fact that no tool understood our business. We measured it once. It was more than the cost of all six tools combined.

We started calling it the operating tax. There is a longer piece on it in the field notes.

Why we built instead of switched again

The honest answer is that we were a software-capable team and we ran out of patience.

Most partner firms cannot build their own. That is the whole point. Even we were not sure it was a good idea at first, partner firms should run partner firms, not write software. We talked ourselves out of it twice.

What changed our minds was a simple calculation. The operating tax was already costing us more than a full-time engineer. We were already paying for the system. We were just paying for it in lost hours and missed renewals instead of in code.

So we built it. The version we ran ourselves for ten months before opening it up to anyone else.

What PartnerView is, plainly

PartnerView is a CRM and PSA built specifically for partner services firms. Not a vertical configuration of a horizontal tool. A system that natively understands:

• License revenue and services revenue, as separate first-class concepts on the same engagement.
• Vendor commission economics, with rules per vendor, snapshot rates frozen at close, and reconciliation against vendor statements.
• Subcontracting in both directions, with split tracking, upstream payment timing, and non-circumvention windows that surface before they lapse.
• The full document chain from discovery to functional spec, with live joins and traceability back to tasks.
• People as a first-class layer, searchable by skill and proficiency, with real certification tracking, allocated by week against real bandwidth.

Every one of those is something we needed and could not buy. Every one of them is shipped today.

How we work

A few choices that are worth saying out loud.

• Built small on purpose. PartnerView is for boutique partner firms, the ones too large to run on spreadsheets and too small to absorb an enterprise PSA implementation. We have no plans to chase the enterprise end of the market. The competitive wedge is the right-sized fit.
• We ship one AI-assisted feature. Claude turns a DRD into a draft FRD. The SE reviews. Every other suggestion in the product is a deterministic rule we can explain in one sentence. No AI in the money math.
• The product is the proof. We did not raise a marketing round and write copy ahead of a half-finished tool. The capabilities on the features page are shipped, tested, and running. There is no roadmap asterisk.

What we want this to feel like

We are aware that buying any software is an act of trust. Especially software that holds your commission data and your client relationships.

We are not asking you to trust us as a leap. We are asking you to trust the specifics. Read the field notes where we describe the problems we ran into and how we solved them. Read the comparison pages where we are honest about where other tools are strong and where they are not. Read the features catalog where every capability is listed without marketing varnish.

If the specifics land, the trust follows.