From Founder to Senior Engineer: What Building a Startup Taught Me About Shipping Fast

There is a specific kind of pressure that comes from being the person who built the thing and the person who has to sell it. You are sitting in a pitch meeting explaining why your infrastructure is the right bet, and somewhere in the back of your head you are mentally debugging a race condition in the device onboarding flow. That was my life for a couple of years at Grandeur.dev. I would not trade it.

I am Talha (most people know me as Sameed), a senior full-stack and AI engineer based in Lahore. I currently work at Okara.ai, and before that I spent years building AI products on product teams. But before any of that, I co-founded an IoT backend-as-a-service called Grandeur.dev. We went through Alchemist Accelerator Class 29, raised a six-figure pre-seed from Hustle Fund, and built a distributed platform for connecting hardware devices to the cloud. What I learned in that stretch shaped every engineering decision I have made since.

The Leap: Building a Startup as an Engineer

Most engineers who become founders figure out pretty quickly that being a strong builder does not automatically prepare you for everything else a startup demands. Fundraising, user research, accelerator demos, investor updates. None of that shows up in a technical spec.

At Grandeur.dev, we were building infrastructure for IoT developers: a backend-as-a-service that let hardware teams connect devices, manage state, and ship cloud-connected products without standing up their own servers. The technical problem was genuinely hard. Distributed systems, real-time device communication, reliability at the edge. These are not toy problems.

Going through Alchemist Accelerator imposed a discipline I did not know I needed. You are surrounded by other founders moving fast, and the program pushes you to get specific: what are you building, for whom, and why does it matter right now? Raising from Hustle Fund added another layer. Investors backing pre-seed companies are betting on the team's judgment as much as the product, which meant I had to articulate engineering decisions in business terms and business decisions in engineering terms.

That translation skill is one of the most useful things I still carry.

The Lesson That Actually Stuck: Ruthless Prioritization

Here is a concrete example of what shipping fast actually looks like on a tiny team.

When we first built the device onboarding flow for Grandeur.dev, connecting a hardware device to the platform took anywhere from 30 to 60 minutes. For a developer trying to prototype something quickly, that is a brutal experience. You lose people in that window. They give up, go back to a competitor, or decide the whole thing is more trouble than it is worth.

We rebuilt the onboarding layer with a custom SDK and a platform abstraction that brought that time down to under one minute. The technical work was non-trivial, but the decision to prioritize it was not really a technical decision. It was an empathy decision. We had watched enough developers struggle through the old flow to understand that the first ten minutes of someone's experience with your product is not a nice-to-have. It is the product.

That lesson has followed me into every role since: the first piece of friction a user hits is the most expensive thing you can afford to ignore.

Ruthless prioritization does not mean doing less. It means being honest about what is actually blocking your user from succeeding, and treating that as more urgent than everything else on the roadmap.

Carrying Those Lessons Into Senior Engineering Roles

After Grandeur.dev, I moved into senior engineering roles on AI products. On one project, I owned an AI product used by over 100,000 users and was responsible for keeping it at 99.9% uptime while continuing to ship improvements.

Two things from that period are worth naming.

The first: on one project, I cut a core workflow from 30 seconds down to 6 seconds. That sounds like a performance optimization, but it was really a product decision. At 30 seconds, users were abandoning the flow. At 6 seconds, they completed it. The number that mattered was not the latency figure. It was the completion rate.

The second: on another project, I built a custom pipeline that ran roughly 30 times faster than the third-party service it replaced. The third-party tool was fine at low volume. At scale, it became a bottleneck and a cost center. The calculus was straightforward once you framed it correctly: what is this slowness actually costing us per user, per day?

Those are the kinds of questions a co-founder learns to ask. They do not stop being useful when you stop being a co-founder.

Now at Okara.ai, I work across a suite of more than ten AI agent products. One of the first things I focused on was app load time, and we achieved roughly a 15x reduction. Not a vanity metric. Faster load means more users reach the product, more users engage, and the whole system performs better at every layer above it.

Why I Work the Way I Work Now

I work directly with founders, product teams, and hiring managers who want a senior engineer who thinks about the product, not just the ticket.

That preference comes directly from the startup years. When you have been on the other side of the table, when you have been the person responsible for whether the company ships something worth shipping, you develop a strong opinion about what good collaboration actually looks like. It looks like direct communication. It looks like someone who asks why before they ask how. It looks like someone who will tell you when a feature is the wrong feature, not just build it because it is in the spec.

I am not interested in volume. I am interested in working on things that matter with people who care about the craft.

That is the version of engineering the startup years built in me, and it is the version I bring to every engagement now.