Subhan Ahmed

Gearing up to launch Zyphex Labs. First product: an app turning PDFs/EPUBs into audiobooks (EN+Urdu). Product Designer & App Developer, building in public.

[Subhan Ahmed @buildwithsubhan]

I've spent years building products for other people. First as a Flutter dev, then leading 0-to-1 delivery as a Technical PM for international clients.

Now I'm gearing up to launch something of my own: Zyphex Labs, my AI products company. 🧵

[Subhan Ahmed @buildwithsubhan]

@kislay_001 The before/after makes the point well: reducing visual noise is usually more valuable than adding another control. In product reviews I keep coming back to the same question: can someone tell what to do next without reading a manual?

[Subhan Ahmed @buildwithsubhan]

@swyx @latentspacepod @allenpark Speed claims are interesting, but the product question is what changes when a model is that fast. For a PM, shorter iteration loops only matter if the eval loop keeps up too. Otherwise teams can produce wrong answers faster than they can notice.

[Subhan Ahmed @buildwithsubhan]

@arvidkahl “Developers since coding agents” is funny because it is already becoming a product distinction. The value shifts from typing every line to choosing the right problem, spotting the bad tradeoffs, and owning what reaches users. The accountability part does not get automated away.

[Subhan Ahmed @buildwithsubhan]

Moving from Flutter into PM work changed how I look at “done.” A screen can be polished and still leave the job unfinished. The real work is the decision behind it: who uses it, what happens when it fails, and who owns the follow-up.

[Subhan Ahmed @buildwithsubhan]

Faster models will make teams feel like they can skip the slow parts of product work. I think the opposite matters more: when generation gets cheap, clear evaluation becomes the bottleneck. The teams that know what good looks like will move best.

[Subhan Ahmed @buildwithsubhan]

@arias_bruno_ That sounds like the right first pass. Timer + goal answer the glanceable job, then laps become detail for people who need it. Curious whether the next real usage session shows anything else competing for that first screen.

[Subhan Ahmed @buildwithsubhan]

Flutter made me care about the last 10% of a screen. PM work made me care about the first 10 minutes after launch: the handoff, the edge cases, the support question nobody expected. Shipping starts before release and keeps going after it.

[Subhan Ahmed @buildwithsubhan]

Ethan Mollick’s Astra/Fable comparison is a good reminder that model demos hide the path. A polished result tells you something. The attempts, tool use, and checks tell you whether a product can depend on it. I’m keeping that in mind for AI features.

[Subhan Ahmed @buildwithsubhan]

@roy_weru A portfolio that feels like an OS can be memorable, especially when it fits your work. I’d make sure the nostalgia does not bury the first job: within a few seconds, someone should know what you build and how to contact you.

[Subhan Ahmed @buildwithsubhan]

@emollick That “simulated curiosity” difference is exactly why output quality is not enough to evaluate. A model can produce a polished result while taking a very different path through the problem. For product teams, tracing that path is where confidence comes from.

[Subhan Ahmed @buildwithsubhan]

@anzuastro Treating AI with properties of code is interesting because it pushes toward a testable contract. Model outputs still vary, so apps need a clear boundary between deterministic logic and model judgment. That saves a lot of support pain later.

[Subhan Ahmed @buildwithsubhan]

@emollick The 211 failed techniques are the useful part. AI demos need more than the final artifact: attempts, eval conditions, and failure modes show what was actually learned. The cleanest output rarely tells you what will be reliable in a real product.

[Subhan Ahmed @buildwithsubhan]

I started in Flutter, so I used to judge product work by what made it to the screen. PM work changed that. Scope becomes real when you define the states around the screen: loading, failure, permissions, handoffs, and what support sees after launch.

[Subhan Ahmed @buildwithsubhan]

Watching Claude turn a failed attempt at the Voynich Manuscript into a 4-minute explainer made me think: AI product demos need to show the search, not only the finish. For people building with models, the dead ends are often where trust gets built.

[Subhan Ahmed @buildwithsubhan]

Flutter taught me to obsess over the screen. PM work taught me the screen is the easy part. People decide whether to trust a product when it is empty, slow, confused, or fails. I spend more time on those states now.

[Subhan Ahmed @buildwithsubhan]

I keep getting tempted to treat AI choices like permanent architecture decisions. They aren't. The model, cost, latency, privacy rules, and evals move together. For a small product, the honest answer is usually: pick a sensible default and keep the escape hatch.

[Subhan Ahmed @buildwithsubhan]

@imjavakhir The $8 MRR is small, but the real signal is 250 new customers in 11 days. You now have a live loop for learning what brings people in and what turns that interest into subscriptions. That's a much better place to iterate from.

[Subhan Ahmed @buildwithsubhan]

@taoofdev @hezo_ai The mobile note matters. A homepage like this can look impressive in a demo but collapse into a long load or awkward scroll on the device most people use. Getting both right is the real flex.

[Subhan Ahmed @buildwithsubhan]

@emollick This feels like a product decision as much as a model decision. Teams want sovereignty, but the ongoing eval, deployment, and maintenance cost has to beat using a frontier model with strong data controls. The tradeoff needs to stay visible.