What Co-founding With Non-Technical Partners Actually Taught Me

When Mohamed Suleman first pitched me the True Wills idea over dinner in November 2019, he suggested we build it on Wix.com. I chuckled inside. I did not say anything immediately, but it was the first signal that this founding experience was going to be different from anything I had done before.

Mohamed is a solicitor by day and an Islamic teacher by night. His connection on the project was a marketing professional. I was the product person and the only one who had ever built software before. On paper, that is actually a strong founding team: legal, marketing, and product. In practice, it meant I spent a significant portion of the next two years translating between very different worlds.

Here is what I learned.

The Wix moment was a gift

My initial instinct when Mohamed suggested Wix was to correct him immediately. I had a decade of product and engineering experience. I knew Wix was not the right tool. We needed something API first, something we could build properly, something that would scale.

But I held back and listened first. And what I heard underneath the Wix suggestion was not a technical preference. It was an expectation about complexity and cost. Mohamed and his co-founder were worried about building something too complicated, too expensive, too slow. The Wix suggestion was really a question: can we actually do this?

Once I understood what was behind it, I could address the real concern rather than just winning an argument about tools. We ended up with a React frontend and a Python and Django backend, hosted on AWS, with Stripe for payments and Segment and Amplitude for analytics. Not because I pushed it through, but because we talked through what the product needed to do and worked backwards to what would actually build it.

That taught me something I now apply constantly: when a non-technical stakeholder makes a technical suggestion that sounds wrong, the suggestion is rarely the point. Listen for the concern underneath it.

Teaching the MVP concept was harder than building the product

If the technology conversation was one kind of challenge, the MVP conversation was another entirely.

My co-founders had a backlog of validated and unvalidated problems they wanted to solve. All of them felt important. All of them probably were, at some level. But they wanted to build everything before launch.

I had to pause the product work and spend real time explaining what a Minimum Viable Product actually is, why it matters, and why launching with less is almost always better than launching with more. This is not an obvious concept if you have not built software before. From the outside, "launching with less" sounds like cutting corners. It takes time to understand that it is actually the opposite: it is discipline about what matters most.

We had some heated conversations. The co-founders felt strongly about certain features. I had to be honest about what was essential versus what was desirable, while making sure they felt genuinely heard rather than overruled.

We got there. We launched a well-defined MVP that addressed the core user need: creating a valid Islamic will online, affordably, without needing a solicitor. Everything else came later.

What each person in the room actually contributed

Looking back, the non-technical make-up of the team was a strength as much as a challenge.

Mohamed's legal expertise meant our Islamic will template was genuinely sound. We worked with some extraordinary Islamic scholars including Dr Mufti Abdur-Rahman ibn Yusuf Mangera, Shaykh Haitham Al-Haddad, and Shaykh Mohammed Daniel to get the compliance right. Mohamed could have those conversations credibly in a way I never could.

Our marketing co-founder brought discipline to the go-to-market thinking that I would not have had on my own. The webinar strategy, the Facebook group outreach, the WhatsApp broadcast approach, even the two days spent handing out leaflets at the Halal Food Festival: all of that came from someone who understood how to reach real people in a community, not just how to run paid ads.

My job was to hold the product vision, make the technical calls, keep the team aligned, and translate between legal requirements, marketing instincts, and what was actually buildable. It was the most complete version of a product leadership role I have ever had.

The patience required is not optional

The most important skill I developed through True Wills was patience. Not passive patience, waiting for things to resolve themselves. Active patience: staying in the conversation, explaining things multiple times without condescension, finding the version of an argument that lands for the person in front of you rather than the one that is technically correct.

Non-technical co-founders are not a liability. They bring perspectives and capabilities that most technical founders lack. But the person in the room with the product and engineering background carries a specific responsibility: to make the complexity accessible without making the others feel small.

Get that wrong and you lose the team. Get it right and you build something none of you could have built alone.

That is what we did with True Wills. And I would do it again.