I spent twenty years complaining about this problem. Then I built the thing.

Every IT vendor I have worked with in twenty years has run its partner programme on a spreadsheet and an inbox.

Deal registration arrives as an email to a shared mailbox. Someone copies it into a sheet. The partner chases three weeks later and nobody can say whether the deal was approved, because the approval lived in a reply that went to one person who has since left the business. MDF works the same way, with receipts attached. Commission claims are worse, because now there is money attached to the ambiguity and two parties who remember the conversation differently.

I have been on both sides of it. I have been the partner chasing a registration into silence, and I have been on the vendor side running the programme, knowing exactly how poor the visibility was and having no budget to fix it.

So I built PartnerFlo. Deal registration and tracking, partner agreements with e-signature and audit trails, commission and rebate claims, MDF management, a collateral hub, and analytics that tell a vendor what is actually happening in their channel. Multi-tenant, with branded partner portals, billing through Stripe, and a 30-day trial. It is live and it is a commercial product.

This post is not a launch announcement. It is everything I wish I'd known first.

Why nobody had fixed it

The enterprise partner relationship platforms exist. They are built, priced and scoped for vendors with hundreds of partners and a team to administer the programme.

That leaves most of the market out. A vendor with forty partners has exactly the same problems, in the same shapes, at a size that cannot justify six figures and an implementation project. So they use a spreadsheet, and everyone involved quietly accepts that the channel is being run on vibes and goodwill.

That gap was not a market insight. It was twenty years of watching the same thing go wrong from different seats. Even as far back as my Solution Architect days, finding out that dealreg hadn't been completed correctly, so the margins had now changed, through to my time running marketing for a multi-billion dollar company, finding out that our MDF claim was rejected because brand guidelines (that existed only on an email sent to someone who had since left the business) had not been followed to the letter, and finally again running a partner programme for a startup deals were being registered simply because a customer need three quotes to meet procurement rules, artificially inflating pipeline. Foggy partner engagement, whichever side of the fence you're on, is bad for business and causes far more stress than it should.

What AI genuinely collapsed

I built this on my own, using AI assistance throughout, across Next.js, TypeScript, AWS, PostgreSQL and Stripe. Being precise about what that did and did not do matters, because the current discourse is useless in both directions.

It collapsed the blank page. Scaffolding a new module, wiring up a form, the first structural version of a feature: minutes instead of a morning. Over a product with this many moving parts, that compounds into something that genuinely changes what one person can achieve.

It collapsed unfamiliar territory. Stripe webhooks, e-signature flows, PDF generation, the parts I had never built before. I was not learning from documentation and a blank editor. I was reading a working first attempt and correcting it, which is a much faster way to learn something than starting cold.

It collapsed the first seventy per cent of almost everything. That number has been true for me since GitHub Copilot went GA in 2022 and it has not really moved. What changed is how big the thing is that seventy per cent applies to.

What it did not collapse

Multi-tenancy. Every query in a multi-tenant application needs a tenant boundary, and a model will cheerfully write one that does not have it. The code looks correct. It passes the test you thought to write. A missing tenant filter is not a bug you find in testing, it is a bug you find when one customer sees another customer's deal registrations, and at that point you do not have a bug, you have an incident and a disclosure, usually followed by a termination notice, or worse.

Billing edge cases. Trial expiry, mid-cycle downgrades, a failed payment followed by a retry, a plan change that should be prorated. Plausible, confident, wrong in ways that cost real money and are invisible until a month has passed.

Anything security-critical. I treated AI output in authentication, authorisation and tenant isolation the way I would treat a pull request from a capable stranger who has not read the rest of the system. Read every line, assume nothing.

And it did not help at all with knowing what to build. The idea for this came from my own frustrations and experiences from the last 20 years of my career, something that AI doesnt have, know or understand. It made some suggestions along the way, some were useful, most were just added fluff that would deliver little value to either a vendor or reseller.

The honest summary: AI collapsed the cost of starting. It did not collapse the cost of being right.

The half nobody warns you about

Building the product was the easier half.

The other half is a marketing site that explains what the thing does, onboarding that gets someone to value before they lose interest, a trial that works without a sales call, a pricing page, billing, and a support process for when any of it breaks. None of that is engineering, all of it is required, and none of it can be skipped on the basis that the product is good.

Pricing was the single hardest decision I made, and it is the one no model could make for me. Price it low and you signal it is a toy. Price it high and you are competing with platforms that have teams and a decade of features. I landed on three tiers starting at £299 a month because that is roughly the number at which a vendor stops treating it as a purchase and starts treating it as an obvious cost of running the programme properly.

This is where the years I spent running marketing turned out to be useful. I had watched capable technical organisations fail to explain their own products over and over. Writing the positioning for my own was the same job, with nobody else to blame for getting it wrong.

If you are in the channel and thinking about it

Pick a problem you have lived with rather than one you researched. The reason I could define this product quickly is that I did not have to discover the requirements. I had been the user, badly served, for twenty years.

Assume the product is the easy half, and plan accordingly.

Treat anything touching auth, tenancy or money as a draft written by someone who has not read your codebase.

Ship before it is finished. I did, and the first weeks of real usage told me more about what mattered than another two months of building would have.

What actually changed

Twenty years ago, what I have just described needed a team, a funding round and eighteen months. The constraint was never the idea. It was that building software at commercial quality required more hands than one person has.

That constraint has moved. It has not disappeared, and anyone telling you it has is selling something. But it has moved far enough that the limiting factor is now knowing which problem is worth solving and being able to explain it to the people who have it.

That part still takes twenty years.