A form for football parents became our first product

"Did you pay October?"

If you've had a child at a football club, you've heard that on the touchline. And if you've been the one asking, you hate it.

Here's what happened.

In September I wrote to a football academy to find a time to show them, step by step, a program we were building to manage players and fees.

What I most wanted to show wasn't the dashboard. Everyone shows dashboards.

It was the parents' form.

A parent signs their child up. Fills in the details. And the system generates the first payment and every fee that follows, on its own.

No spreadsheets. No coordinator chasing families at the start of the month. No "did you pay October?".

The form wasn't collecting data. It was starting the whole relationship, money included.

Generating isn't collecting

There was a gap. Not a small one.

Generating fees is one thing. Collecting them is another. If every family has to come back each month and pay by hand, you've just moved the chasing. From the coordinator to the parents. Congratulations.

So that month I got on with the banks. First I asked ours to activate payment by reference on our virtual POS. Towards the end of the month, I asked another bank for the same for a club. Tokenisation: the family pays once with their card, and the following fees are charged automatically, without asking for the card again.

Banks don't switch that on lightly. They want to know the process. When the card is added. What the cardholder is told about frequency and amounts. Why charges can run without them present.

Writing that down was useful in itself. It forced me to describe the product as a flow, not a list of screens. And that's where you see the difference between a list of fees and a subscription.

A product starts when the thing you built for one client solves the same problem for the next one without changes.

Suspecting isn't knowing

Mind you, I didn't know whether it was a product or just a good project.

We'd built plenty of custom tools. Almost all of them stayed custom. One client, one use, one invoice.

What was different was the problem. Every grassroots club I could think of had the same one. Volunteers, families, monthly fees and someone stuck in the middle trying to keep track. That volunteer, I think, is who you build for.

But "every club has this problem" is also what everyone says right before building something nobody buys. I knew that. I had no proof. I had a demo call and a couple of bank requests.

For years, our services paid for everything. That was the plan: patient money, no investors, and build our own products when the services gave us room.

But a product doesn't appear because you put it in a plan. It turns up in some ordinary form, and you have to be paying attention to see it.

That September I wanted to show a football academy a form.

What I was really asking myself was whether every club needed the same one.

P.S. If your software helps someone get paid, you don't need to explain much. A club only has to hear "fees". A bank, you'd better bring the process in writing.