TL;DR: I have co-founded two consumer AI products from Lahore with partners in the US: LectureNotes AI with Benjamin Rhodes and Lifemaxxing AI with Benjamin Siegel. LectureNotes reached around 15 million organic Instagram views in two months, nearly 10,000 users and roughly $1k MRR. What makes a cross-border founding team work is not more calls. It is a clean split of ownership (the partner owns proximity to the market, the technical co-founder owns the product actually existing), a handoff written down every day so the time difference becomes a relay instead of a delay, a build that can react to marketing within a day, and numbers both people read the same way. Here is how I think about the technical side of that partnership, and what I would tell anyone about to start one.
Most of what I write here is about client work: AI voice agents, CTO roles at startups, AR systems. This piece is about the other half of my work, the products I build as a co-founder rather than a contractor. The difference matters more than people expect. A client tells you what to build. A co-founder has to decide it with you, from nine to twelve hours away, and then both of you have to live with the result.
Why a Lahore and US founding team makes sense at all
The obvious objection is distance. The less obvious truth is that for a consumer product aimed at US users, the split can be an advantage if each side owns what they are closest to.
A US partner is close to the market. They know how the target user talks, what they already use, which platforms they spend time on, and what a price feels like to them. For LectureNotes AI the audience was students, and the growth came from short-form video that spoke directly to a student's week. That kind of cultural fluency is very hard to fake from outside.
I am close to the build. I have spent more than seven years shipping software, from Unity and AR to full-stack products and now AI agents, and I can turn a decision into a working app faster than most teams can schedule a meeting about it. For an early product, that speed is the thing that keeps the loop tight.
The partnership works when neither person tries to do the other's job badly. It fails when the technical co-founder starts guessing at marketing or the market-facing co-founder starts specifying implementation.
Split ownership, not tasks
The single most useful decision in a two-person founding team is writing down who owns what. Not who does what this week, but who has the final say.
The split I have found works:
- Market-facing co-founder owns: positioning, content and distribution, pricing conversations with users, what the product promises in public.
- Technical co-founder owns: architecture, the AI pipeline, what ships and when, app store releases, cost of running the product, and whether a promise can actually be kept.
- Shared, decided together: what the core loop is, what we will not build, and what number we are trying to move this month.
"Owns" means that person makes the call after hearing the other one out. It does not mean they work alone. But when you are asleep while your partner is making a decision, you need to know in advance whose decision it is. Ambiguity that costs a five-minute chat in the same office costs a whole day across a time gap.
Turn the time difference into a relay
The time difference is either a relay or a queue. A queue is when a question sits unanswered for a night and blocks work. A relay is when each person ends their day by handing the other a clear baton.
What makes it a relay:
- A written end-of-day handoff. What shipped, what is blocked, what I need an answer on, and what I will do if I do not get one. The last part is the one people skip, and it is the one that stops a question from costing a day.
- Defaults instead of open questions. "I will ship the onboarding with the shorter copy unless you object" moves work forward. "Which copy do you prefer?" waits.
- One overlap window, protected. A short daily or near-daily slot when both people are awake, used for decisions and disagreement, not for status. Status goes in writing.
- Everything in one place. Decisions, links and numbers live in one shared doc or channel, not scattered across personal messages.
I learned the same thing serving US clients from Pakistan, which I wrote about in going from the ICPC World Finals to US clients: Lahore evenings are US mornings, and if the handoff is good, the client wakes up to progress instead of a question. A co-founder is the same, except the stakes are shared.
The build has to move at the speed of marketing
The part of LectureNotes AI that surprised me most was that growth mattered more than code, and I wrote the full retrospective in how LectureNotes AI got 15 million organic Instagram views. The technical lesson inside that story is about loop speed.
When organic content starts working, it changes what the product needs, fast. A video lands with a particular kind of student, new users arrive with a particular expectation, and the first screen they see either matches that promise or does not. If the build takes two weeks to react, the moment has passed.
What that means for the technical co-founder:
- Keep the core loop small. For LectureNotes it was record a lecture, get a summary, key takeaways and an outline back. A small loop is one you can change in a day.
- Make onboarding cheap to edit. Copy, first-run screens and paywall placement should not need a full release cycle to adjust, wherever the platform allows it.
- Instrument the funnel from day one. You need to see where a wave of new users drops off within hours, not at the end of the month.
- Keep release discipline anyway. Moving fast does not mean shipping untested builds to the stores. I carry the same habits I use for Unity and mobile release pipelines: reproducible builds, a checklist, and a rollback story before you need one.
AI products add a cost your partner cannot see
In a consumer AI app, every active user costs money every time they use the core feature. Transcription, summarization and plan generation are real compute. A market-facing co-founder sees users and revenue. The technical co-founder has to see the third number: what a user costs to serve.
That matters most at the moment growth arrives. A sudden wave of free users is great for reach and potentially painful for the bill. Before any push, I want to know the rough cost per active user, which features are expensive, and whether the free tier is generous in the cheap places and careful in the expensive ones.
The choice of model and pipeline is also a product decision, not only an engineering one. Lecture audio is a very different speech-to-text problem from a phone call, which I compared in speech-to-text for lectures vs phone calls. Picking the right tool for the input is where a lot of both quality and cost is decided.
Agree on what the numbers mean
The fastest way for a remote founding team to drift apart is to read the same dashboard differently. One person sees 15 million views and feels the product is winning. The other sees nearly 10,000 users and around $1k MRR and sees a funnel leaking at every step. Both are right, and if you never say it out loud you end up optimizing for different things.
What helped:
- One definition per metric. What counts as a user, an active user, and a paying user, written down once.
- One number per month. The single metric both of us are trying to move. Everything else is context.
- Honest ratios over headlines. The views were the headline. The ratio from view to user to paying user was the lesson, and that ratio is what told us where to work next.
The same principle ran through the Amazon seller analytics dashboard at Bettershop: one definition of the truth everywhere, or the people reading it end up arguing about numbers instead of acting on them.
Two products, two different problems
LectureNotes AI and Lifemaxxing AI look similar from far away, two consumer AI apps built with a US partner. Underneath, the core problem is different.
LectureNotes turns an input the user already has, a lecture, into something more useful. The value is obvious in one sentence, which made it spreadable. Lifemaxxing AI helps people plan and track self-improvement with personalized plans. The value there builds over time and depends on people coming back, so the engineering questions shift toward personalization, tracking and giving users a reason to return.
The founding-team lesson carries across both: agree early on which of those problems you are solving, because it changes what the technical co-founder should build first. A spreadable one-shot product and a habit product need different first screens, different metrics, and different definitions of a good week.
What I would tell a technical co-founder starting remote
- Write the ownership split down before writing code. Who decides positioning, who decides architecture, what you decide together.
- End every day with a handoff that includes your default. Make the time difference a relay.
- Protect one overlap window for decisions, not status.
- Build a small core loop you can change in a day. Marketing will ask you to.
- Know your cost per active user before growth arrives.
- Agree on metric definitions and one number per month.
- Keep release discipline even when moving fast. Rejected or broken store builds cost you the moment you were moving fast to catch.
None of this is about distance really. It is about making implicit things explicit, which a same-office team can get away with skipping and a cross-border team cannot. The upside is that a team forced to write things down usually ends up clearer than one that never had to.
I build my own products with US partners and engineer AI agents and software for startups across the US, UK and Europe. If you are a non-technical founder looking for someone who can own the build end to end, or you want a second opinion on the technical side of an early product, more about me is here, or book a call.