Choose a topic to narrow the archive while keeping the articles easy to scan.

Browse by topic

A focused selection of systems and products shaped around real delivery constraints and measurable outcomes.

Selected software engineering, data platform, cloud, and product delivery projects by Muhammad Usman.

Projects

Practical notes on building reliable software, data platforms, and useful AI systems.

Software engineering notes on backend systems, data platforms, cloud delivery, and practical AI work.

Articles

<p>He wanted to build a platform that helps travellers fight disputes with airlines. He also wanted a travel planner, so customers could book flights, hotels and everything else in one place. And AI would be there to help with the disputes.</p><p>I asked where the problem came from. &quot;It&#39;s everywhere online,&quot; he said. &quot;People are always in disputes with airlines.&quot;</p><p>I asked him to share how he was planning the first version, even at a high level. He had nothing. </p><p>Then we spent the rest of our conversations on equity and the vesting period.</p><p>That wasn&#39;t unusual. Recently I talked to more than a dozen first-time, non-technical founders looking for a technical co-founder. Most of those conversations followed the same pattern. Not all of them, though. A few founders came with a genuine problem and real homework, and I&#39;ll come to them too.</p><p>This isn&#39;t a rant. We&#39;re all part of the same ecosystem, and I want to understand first-time founders better. But I also want them to understand what it looks like from the other side of the table.</p><h3>Starting is easier than ever. That&#39;s the problem.</h3><p>Why are so many people starting startups right now? AI and no-code tools have made building faster and cheaper than ever. LinkedIn, X and Reddit are full of founder success stories, so starting up looks exciting and within reach. </p><p>Layoffs and an uncertain job market have pushed many people to look for their own path. And a lot of people simply want to own their work instead of building someone else&#39;s dream.</p><p>Most of these reasons are good ones. But when it gets easier to start, more people start before they&#39;re ready. I&#39;ve seen this up close.</p><h3>Equity before the idea</h3><p>I went into these conversations excited. I wanted to join a founding journey and help solve the next big problem. But most of the time, we talked about equity split, dispute resolution and full-time commitment, not the problem itself.</p><p>To be fair, those concerns are valid. Fights between co-founders kill a lot of startups, and first-time founders have heard the horror stories. But these are mostly solved problems. A standard vesting schedule protects both sides: you earn your shares over four years, and if you leave in the first year (the &quot;cliff&quot;), you get none.</p><p>The real issue is the order. Equity comes up before there&#39;s anything worth splitting.</p><p><em>Would you put your savings into a shop with a partner who wants to agree on the profit split, but hasn&#39;t decided what the shop will sell?</em></p><h3>Experience is not the same as evidence</h3><p>Here&#39;s what stayed with me about the travel founder. He had something most first-time founders don&#39;t: he had been running a travel agency for three years. That&#39;s real domain knowledge. Real customers, real bookings, and almost certainly real disputes with airlines.</p><p>But he didn&#39;t use any of it. Instead of &quot;my customers lost this much in refunds last year&quot; or &quot;here&#39;s how my team handles disputes today,&quot; his proof was &quot;it&#39;s everywhere online.&quot;</p><p>And instead of one problem, he brought two products: a dispute tool and a full travel planner. Each one is a big build on its own. Which comes first? Who is the first customer? He didn&#39;t know, and he wanted me to decide.</p><p>Now look at it from my side. I would be the one building, probably for a year, with no income, running everything on free tiers and freemium tools, before anything reached a customer. When the person asking for that year can&#39;t tell me what we&#39;re building first, I can&#39;t think about equity. I&#39;m still stuck on the idea.</p><h3>If it&#39;s not written down, it&#39;s not real yet</h3><p>He wasn&#39;t the only one. When I asked about the problem, very few founders could explain it in detail. Most ideas lived only in their heads. There were no notes or slides, no competitor research, no market research, no business model, and no clear niche or customer.</p><p>If you can&#39;t explain the problem to me, how will you explain it to a customer or an investor? And if you&#39;re not serious enough about your idea to write it down, why should a technical founder take it seriously?</p><h3>Fluent in jargon, empty on proof</h3><p>Other founders had the opposite problem. They were deep into startup theory and jargon (MVP, PMF, TAM), but the theory didn&#39;t connect to any real problem. They had validated the idea in their heads, not in the real world.</p><p>A startup isn&#39;t theory. It&#39;s chaotic execution.</p><h3>Even the prepared founders think AI will build it</h3><p>Now for the founders who did their homework, because not all founders are the same.</p><p>One wanted to automate bookkeeping by pulling data from different sources and making reconciliation seamless, while still leaving room for an accountant to oversee the financial decisions. He had the idea, the potential customers and the research, and he had answers to my questions. That&#39;s the kind of founder I want to build with.</p><p>But he shared one belief with almost everyone I spoke to: that software engineering is now mostly automated. Claude or Codex will write the code, so building should be quick and cheap.</p><p>Then I shared a detailed scope document: how I would turn the idea into an actual product, what the infrastructure would cost and what development would really take. That&#39;s when founders went on the back foot.</p><p>AI hype has made founders very confident about their bargaining power. If AI can build it, why give a developer real equity? But I don&#39;t think that confidence is showing up in the quality of the outcomes yet. AI makes writing code faster. It doesn&#39;t yet replace the judgment of designing the system, keeping data secure, connecting messy real-world tools and keeping the product running when real users arrive. In something like reconciliation, where a small error means wrong numbers in someone&#39;s books, that judgment matters even more.</p><h3>Too many options, not enough focus</h3><p>There&#39;s one more pattern I noticed. Founders today have more options than ever. Build with no-code or AI tools, hire a freelancer or an agency, or find a technical co-founder. Launch one product or bundle three. Sell to consumers or to businesses.</p><p>Having options is good. The problem is choosing the one that fits your vision. Many founders I spoke to kept every option open, so every conversation started from zero. A clear vision makes most of these choices for you. Without one, every option looks equally good, and you end up choosing none.</p><h3>What I actually look for in a co-founder</h3><p><strong>1. Do they understand the problem?</strong> I don&#39;t mean how well they pitch it. I mean how well they know it. A good talker can still be wrong, so I look for evidence:</p><p></p><ul><li>How many potential customers have you talked to?</li><li>What surprised you?</li><li>Has anyone paid, pre-ordered or committed?</li><li>Have you tried solving the problem manually, without any tech?</li></ul><p></p><p>That last question matters more than it looks. The travel founder could have handled ten airline disputes by hand for his own agency&#39;s customers. In a month, he&#39;d know what goes wrong, how long it takes and whether people would pay for help. That&#39;s worth more than any slide deck.</p><p><strong>2. Are they an expert, or truly committed?</strong> Domain experience is a huge advantage, but only if they use it. If not an expert, I want to see that they&#39;re committed to this problem, not just to the idea of being a founder.</p><p><strong>3. What will they own every week?</strong> This is the question I should ask more often. While I&#39;m building, what&#39;s your job? Sales, distribution, fundraising, industry connections?</p><p>If the answer is &quot;the idea,&quot; that&#39;s not enough.</p><h3>To technical founders: Tell them the truth</h3><p>I&#39;ve seen the other side too: technical founders who say yes without understanding the idea or the business, just to make quick money. That usually ends in burnout for everyone, from founders to developers to investors.</p><p>So don&#39;t hesitate to tell a non-technical founder the truth. You&#39;ll be the one building first, often for months before anything reaches the market.</p><p>It&#39;s normal for the person who came up with the idea to take the bigger share. But equity should reflect what each person contributes from here on, not just who had the idea. If you&#39;re building the whole product, a very lopsided split like 80/20 is a red flag.</p><p>With a first-time founder, consider a hybrid approach: join on salary or contract until the product reaches the market, then talk about equity. If they can&#39;t afford a full salary, a smaller salary plus some equity, or equity tied to milestones, can work as a middle ground.</p><h3>To non-technical founders: Do your homework first</h3><p>Before you look for a partner, ask yourself honestly: what would I do every week while my co-founder writes code? Then do the work that only you can do.</p><p></p><ul><li>Research the market, study your competitors and write down what you learn.</li><li>Pick one problem to start with. The bigger vision can come later.</li><li>Write a rough scope for the first version. It doesn&#39;t need to be technical. It just needs to show you&#39;ve thought about what comes first.</li><li>Don&#39;t assume AI makes building free. When a technical partner shares a scope, a timeline and a cost estimate, treat it as a reality check, not an opening offer.</li><li>Validate the idea by talking to real potential customers about what they&#39;ve actually done in the past, not what they say they would do.</li><li>Use posts and polls to find people to talk to, but don&#39;t treat likes as proof. Pre-orders, deposits and letters of intent are much stronger signals.</li><li>Be fully transparent with your technical partner. Hiding things only breaks trust later.</li></ul><p></p><p>Better still, start with someone you know and have worked with before. Or hire a developer as a solo product builder first and see how they handle things. That gives you time to learn how they work and collaborate, and in the worst case you still own 100%. Just don&#39;t expect co-founder-level commitment from someone you&#39;re paying as an employee.</p><h3>The bottom line</h3><p>Equity is easy to split. A half-baked idea isn&#39;t.</p><p>AI can help you build faster. It can&#39;t tell you what to build, or for whom.</p><p>Come with the problem, the proof and a plan for what you&#39;ll own every week. Then the equity conversation will take five minutes.</p><p>And to technical founders: ask the hard questions before you say yes. Choosing the right partner goes both ways.</p>

I talked to a dozen first-time founders seeking a technical co-founder. Most discussed equity before the idea. Here's what I look for before saying yes.

Looking for a Technical Co-Founder? Read This First

I Talked to a Dozen First-Time Founders. Most Wanted to Discuss Equity Before the Idea.

A practical view of how Islamic finance can move beyond conventional banking through ownership, shared capital, and fintech.

Building Islamic Finance from the Ground Up

How can an Islamic bank offer credit-card-like financing without interest?

How an Islamic Credit Card Actually Works

After eight years of continuous work, I took a career break—not to chase productivity, but to learn how to be still. The hardest part was doing nothing. Journaling, walking, exercising, spending time with family, and simply slowing down helped me understand my thoughts, habits, guilt, and priorities. The biggest lesson was that sometimes peace requires stepping away from the constant pressure to be productive.

The Art of Doing Nothing: Reflections from the Quiet Phase

An overview of SonarQube quality rules introduced for newer Java versions, with practical examples of common code smells and bugs involving local variable type inference, Java Streams, primitive arrays, and collection operations.

SonarQube quality rules for newer Java versions - An Overview

Financial independence is not just about earning more money. It is about building the freedom to make decisions without being constantly constrained by financial dependence. A reflection on money, work, independence, and what financial freedom really means.

Be independent financially

Book a focused call. We'll pin down the problem, what you already have, and the smallest product that proves it.

Have a problem worth building a product around?

AI product architect helping startups and enterprises turn fintech, retail and big-data problems into working products with the team, data and budget they already have.

Muhammad Usman

AI product architect and technical co-founder. I turn fintech, retail and data problems into products that ship, using the resources you already have.