Working at big tech and established companies like Google and Amazon has its own benefits, no question. But for me, I think I was feeling stagnant with growth. To be more precise, the rate of growth had slowed down, and I wanted something more challenging. A faster-paced environment.

The other thing was that I wanted bigger responsibilities and bigger decisions. I wanted to see how my decision-making would actually affect the outcome, the company's direction, the company itself. At big tech your work impacts billions of users, and that's real. When I worked on the Google Meet third-party API, I could see it being used the moment it shipped. You feel the impact through the sheer number of lives it touches. But I wanted something more. I wanted something big.

I wanted to know what it feels like when the guardrails come off. When you have to make the call and there's no safety net underneath you. Where your decisions can genuinely make or break things, where they have the power to skyrocket a company or sink it. I wanted to experience that firsthand. And not just from the engineering side. I wanted to see how the product gets prioritized, how it thinks about customer use cases and maps them into actual features. What the go-to-market strategy looks like, how we handle marketing, how we reach people, how funding works and what it actually takes to raise it. I wanted to see all of it, as close up as I could get.

The first thing is the ownership. The decision-making and the responsibility that come with it, the freedom to make the call but also the accountability that sits right next to it. I wanted that. It's appealing, and at the same time it's exactly the risk I wanted to sign up for.

The second is the feedback loop, which at an early-stage startup is short. You can experiment quickly. At Google it might take six months to a year to build a new feature or capability, and then another six months to actually learn from it. That's a slow loop. At a startup you ship every week and you learn from it right away. You learn from how customers respond, you see what's working and what isn't, and you move. That speed is hard to overstate.

The third is operating with very little clarity, especially early on. You don't have a clean picture of how much to do or where to draw the line, so it becomes a balancing act between how much you invest and what you get back. Almost nothing is clear in those early stages. The real skill is making high-ROI decisions anyway, and learning from each one as you go.

Since my college days I wanted to build something that I could call mine and I could be proud of having built from the ground up. But early in the career, I wasn’t sure of joining a startup and also was a bit more fascinated by working at big tech, specially Google.

In late 2023-early 2024, 2 things happened at the same time. My daughter was born and I went up for a promotion that was denied. I took 3months  of paternity leave and that time gave me a chance to reflect on what I want my future to look like and if it was time for me to take all the accumulated experience of building products at scale and invest my next few years helping build something from scratch. 

To me leadership starts with accountability, and that applies to everyone regardless of title or position, including myself. The whole team is held to the same bar. That's the foundation everything else sits on.

The bigger shift for me has been thinking about the success of the company, not just engineering. As a founding engineer I can't sit in my lane and optimize my piece. I work closely with the founder and CTO to understand where they want to take the company, so I can plan and prioritize the engineering direction and strategy around that. Engineering is in service of the business, and you can't lead it well if you don't know where the business is going.

That's also why I stay engaged in conversations that aren't strictly my project. If something's being decided that affects the product or the direction, I want to be in that room, whether or not it's my immediate area. At a small company the boundaries between functions are thin, and being plugged in across them is how you make decisions that actually hold up.

I also try to stay active publicly, keeping in touch with where the industry is moving. That's not just for engineering. I bring what I learn back into marketing, ops, finance, wherever it's useful. Part of leading at this stage is being a channel for outside signals, not just managing what's already inside the building.

And a lot of it is relationships. I spend real time building and maintaining connections with external partners and professionals, both for finding solutions to problems we hit and for hiring. The network you build is often what unblocks you, and that's a leadership responsibility as much as anything technical.

Decision-making: The biggest difference in decision making is the speed. At big tech, something that could take 2-3 weeks to decide, it just takes a call to decide on something. The process around decision making is more red-tape at big-tech. For example, each feature at big tech needs to go through a few different kinds of review depending on the scope of the feature,  for example engineering design review, security review, api design review to name a few. However, these are just a call away at startup. We would do a virtual huddle that would take 15m to 30m. Anything taking longer than that is probably a good candidate to be put on a doc for everyone to review.

In terms of innovation, big tech have a lot of resources to spend on innovation. In fact, that is the one thing that keeps them going for long term. If you take the example of Google, they spend enormous resources on innovation. Things like LLM, quantum computing, etc are all results of innovation. However, at an early stage startup, unless the product itself is truly a novel engineering solution to a problem, there is not much resources spent on innovation. The focus is more on getting product-market fit and achieving the next milestone. There is only after a certain stage in the lifecycle of a startup that they start investing in R&D and innovation.

Execution wise, big tech rides on guardrails that are invisible to us until they are gone. These guardrails are built from years of experiences and many failures. The result is, it slows them down. Take all the engineering processes at Google, for example.  They exist in order to prevent outages and protect the company from monetary losses and protect the brand value. On the flip side, startups do not have a brand yet. They are still in the making. They can afford to execute faster and they build guard rails as and when they need it. For example, we didn’t build a CI/CD automated rollout and process around deployments until we really started getting users. Before that, any engineer could just get the code merged and deploy it right away.

The thing I keep coming back to is stablecoins. If we remove the speculation from the equation,  you have money that moves across borders, fast, cheap. That's a real improvement over rails that are slow and expensive for normal people. Although, crypto and blockchain are still far from most people's daily lives. But look at where the money is actually going. Stablecoins, real-world assets. The direction is pretty clear. The tech disappears and what's left is faster, cheaper plumbing that a normal person uses without ever thinking about the chain underneath.

The part that keeps me interested is the engineering, because that's where it gets hard. The moment you put real value on a consumer-scale system, the easy assumptions break. Consumer scale wants you fast and loose. Real money wants you exactly. Doing both at once is the actual problem and most of the space hasn't solved it. At Share.xyz that tension is basically the day job. So I stay skeptical and curious at the same time, and the question I keep asking is what it takes to make these systems trustworthy enough that someone builds a real part of their life on top of them.

The most useful thing I carried over is counterintuitive. Knowing what scale really costs is what lets me not build for it prematurely. At big tech you see the full price of distributed systems, the operational weight and the failure modes. It is easy to push yourself to over-engineer early with those experiences. For example, in consumer space where we operate, the scale at launch is often mostly speculative and there is no clear indication of how many users we would onboard. This leaves us to overthink and build for a huge user base and solve problems that we would not hit at small cases. For example, in a social media app, notification from a popular celebrity’s activity is a common problem. But it is only a problem at scale. If the total users on the app is in the range of thousands, the problem does not exist. But as engineers, we tend to over-engineer and solve problems anticipating it may arise in future. The big tech lesson here is to not invest in building a very scalable solution because it requires big investment and it might not be the right problem to solve at that moment.

Most of the spend in an AI system sits where people don't look first. The model gets the attention, but the routing, the token volume, and the serving layer are usually where the money goes. Three places I'd focus.

• Smart routing and downsize the model. Reserve frontier models for the tasks that need them. Put a lightweight router in front that sends routine queries to small models and escalates only real reasoning tasks. In a paper I co-authored on model cascading, a cheap classifier handled the bulk of requests and only 4.4 percent needed the large model. That was a 96 percent cut in LLM calls with accuracy holding at 89.6 against 91.2 for the full model.

• Cut the token volume. API billing ties cost directly to tokens, so sending fewer is the fastest lever. Prompt caching reuses the precomputed state of stable instructions or large documents, taking 50 to 90 percent off input cost when you feed the same context repeatedly. Semantic caching goes further, serving near-duplicate queries straight from a cache and skipping the model entirely.

• Fix the serving layer. Self-hosted GPUs commonly run at 15 to 30 percent utilization, so there's real headroom here. Continuous batching with an engine like vLLM slots new requests in the moment capacity opens up, pushing utilization past 70 percent. Our token-aware batching showed the same idea, cutting padding waste from 54 percent to 0.19 percent by sorting requests by length.

There are a couple of things that standout for teams who have successfully integrated AI into their product.

They run AI as a function, not a project. Agents behave more like new employees than static software. They need ongoing ownership, context updates, and tuning. Winners assign business ownership to a model's performance long after launch and treat coaching it, refining prompts and updating retrieval, as daily operational work.

Secondly, build verification into the system. A model checking its own output against criteria it wrote can't catch what it can't see, so the gate has to live outside the loop. High performers run lightweight guardrail models alongside the main application, evaluating inputs and outputs in real time. That automated control is what lets them ship many autonomous agents instead of bottlenecking on manual review.

And last, feed data that explains itself, and keep the stack portable. Models have zero institutional intuition, so curated data products with clear ownership and versioning beat a vector store full of raw PDFs. On the infrastructure side, treat models and routers as pluggable components rather than hard-coding to one provider. The ecosystem moves fast, and portability is what lets you swap in something cheaper or faster without fracturing the stack.

I spent close to a decade at Amazon and Google before going early-stage, so I'll say up front that the transition is less a career move and more a full rewiring of how you work. Three things I'd pass on.

• Optimize for velocity of learning, not scale, at least until the company reaches a certain stage where you really start thinking about scaling. At a big company the job is robust, optimized, infinitely scalable. At a startup the enemy is time. Build modular enough to pivot next week, not bulletproof enough for a hundred million users you don't have yet. Shipping functional and unpolished today usually beats shipping flawless in a month.

• Become a problem finder, not just a problem solver. Big tech hands you a packaged ticket and measures how cleanly you close it. A startup has no map. The high-leverage engineers talk to customers, read the raw analytics, find where the product is bleeding users, and write the ticket themselves. Figuring out the right thing to build matters as much as building it, if not more.

• Make the leap for growth, not the lottery ticket. Early equity is illiquid and most startups fail, so go in with enough runway that financial stress doesn't cloud your product decisions. The real return is the compounding you get from running a lean stack end to end. One honest diagnostic before you jump is “if you put in two hard years and the company folds with your equity at zero, would you still call it a win?” If yes, stop waiting for perfect timing and go build.