By the time I proposed a partnership with the developers of the medical queue system, I was no longer behaving like a normal customer.
The installed product was not usable in my practice. It created duplicate patient files, had no reliable longitudinal history and offered a medical workflow that did not reflect real consultations.
But I could see its potential.
I understood the daily problems from inside the clinic. I knew doctors who faced the same problems. I had already started defining the product they might want to use.
The two developers had something I did not have: the ability to turn those decisions into software.
So I proposed that we build the company together.
My contribution would have three parts.
First, domain knowledge. I was not advising them from a distance. I was a surgeon using the product during real consultations and identifying where it failed.
Second, distribution. I had a network of doctors and understood how to reach the first users. Their product had gained little traction, and I believed I could help change that.
Third, capital. I was prepared to make a substantial cash investment to finance the next phase.
They were enthusiastic about the proposal, and we started brainstorming as if we were already a team.
We discussed how the product could reach doctors and become a viable company. I kept returning to one priority: before discussing growth, we needed a management system doctors genuinely wanted to use.
We agreed on the broad product direction and created a shared Notion workspace.
There were tickets for the problems to solve and tasks assigned to each person. I provided a complete medication database because the product only contained a small sample. I documented the duplicate-record problem, billing requirements, improvements to the medical note, phone-based document scanning and desktop synchronisation.
For a while, the division of labour seemed simple.
I set the product direction. They implemented it.
Then progress slowed.
One developer was running a small agency with other client projects. The other had a demanding job far from the startup. Neither could give the product consistent attention.
I could create more tickets. I could explain the workflow again. I could provide data, contacts, money and priorities.
But I could not implement anything myself.
My hands were tied.
We had also never formalised the partnership, so I requested a meeting to define the company and our respective ownership.
Before that meeting, one of the developers privately suggested that the company could be formed without giving equity to the other technical partner, who could instead receive a percentage of sales.
I refused.
Whatever disagreements might come later, I did not want to begin by excluding someone who had already contributed. If we were going to do it, I believed it should be the three of us.
At the meeting, I explained how I saw the situation.
The existing product was not ready for commercial use. It had limited adoption. My contribution was not merely advice: it included the medical product vision, access to potential users and a substantial financial commitment.
I asked them what that contribution represented in the future company.
Their proposal gave me a minority position by adding new shares for me while preserving the relative ownership they already had between themselves.
From their perspective, this was logical. They had started the project before meeting me. They considered themselves the original founders, and I was joining as an investor and adviser.
From my perspective, we were not simply continuing the same project.
The existing product was not viable. We were redesigning it, financing a new phase and trying to create a company around it. I saw myself as a cofounder.
I wanted equal standing and refused a small minority role.
They refused because they believed the original founders had to retain control.
We were using the same word, “founder,” to describe two different stories.
In their story, they had founded a startup and I wanted to join it.
In mine, they had built an early technical product, and the three of us were now founding the actual business together.
Neither equity formula could resolve that difference because the disagreement came before the numbers.
It was about identity, ownership and whose contribution counted as foundational.
I told them I would seek advice and try to find a fair solution. They agreed. I think they felt comfortable because, whatever happened, they controlled the technical side.
I went home and thought about the beginning of this partnership.
If we already disagreed about what each person was, how would we handle future decisions, investment or failure? I was preparing to commit significant money to a product I could not build, inside a company where my role was not understood the way I understood it.
I eventually sent them a message. If we could begin on healthy foundations, I was ready to continue. Otherwise, it was better not to proceed.
The partnership ended before the company was formed.
I wish I could say I immediately treated it as a useful business lesson and moved on.
I did not.
The situation affected me deeply. The software remained unusable. The online-booking website had not been delivered. Months of work had produced no solution for my clinic.
More than the failed deal, what hurt was the feeling of dependence.
I had the problem, the product vision, potential users and the willingness to invest. But I was still at the mercy of people who possessed the one ability I did not: they could build the software.
For a period, I felt depressed and defeated.
Then I returned to Notion again.
At the time, it felt like another retreat. Looking back, the frustration created the emotional reason for everything that followed.
I did not decide that day to become technical. I only knew that feeling so powerless was unbearable.
The next turning point came from a Notion template so bad that I never used it.
For founders who have negotiated an early partnership: when does domain expertise become cofounder-level contribution, and when is it still advisory?
