Scaling a startup from idea to product market fit is one of the most challenging journeys in tech. For Stepan Arsentjev, Founding Engineer at Agora.xyz, it’s a challenge he knows firsthand. With a background spanning crypto, capital markets, and emerging AI, he’s built high-performance web applications, decentralized protocols, and scalable systems in some of the fastest-moving environments. At Agora, Stepan has worked directly with leading protocols, helping them tackle complex problems under intense pressure. In this conversation, he shares hard-won lessons on hiring, building for enterprise-grade customers, balancing speed with quality, and why culture is the true operating system of any engineering team.
When you’re scaling from zero to product market fit, what’s the very first engineering hire you prioritize and why?
The first engineering hire has to be a founding engineer type who is resilient, frugal, and hungry. In the early days, there are no processes, no safety nets, and no margin for bureaucracy. The ideal person is experienced enough to ship quickly under ambiguity, but humble enough to roll up their sleeves and work like they still have everything to prove.
I like Steven Schwarzman’s framework for hiring. 10s are LeBron James’s of the world — the best of the best at every part of the game. 9s are also great, but they’re not quite like 10s. They can deliver almost anything without coaching. 8s do what they’re told, but they won’t set the bar. For contractors, 8s can work well. But for your first hire, you want 9 or 10, someone who doesn’t need to be told what to do, who can own problems end to end.
That first hire doesn’t just write code; they define what “good” looks like. They set the bar for quality and culture. And that person needs to be both a hungry builder and a potential future leader. As Bill Walsh puts it, get the culture and people right and “the score takes care of itself”.
Working with enterprise customers and leading crypto protocols like Optimism, Uniswap, ENS, and Scroll brings unique pressures. How do you balance their high expectations with the need to iterate quickly toward PMF?
Product market fit is obvious when it happens, everyone is knocking on your door. The fastest way to get there is to work with the market leaders. They are leaders for a reason, they feel the pain first, and they have resources to solve it. The rest of the industry looks up to them for direction. If you can solve their problem, you can usually solve it for everyone else.
At Agora, we treated leading protocols like Optimism, Uniswap, ENS, and Scroll as partners. They were willing to pay for V0 solutions because their pain was urgent. For example, ENS needed a more sophisticated admin tool for proposal creation. We built it for them and then packaged it so that any customer could use it. That model allowed us to move fast, learn directly from the most demanding customers and apply those lessons to the broader market.
It is counterintuitive, but market leaders often don’t need polish. They need solutions now. Mass market customers, on the other hand, are pickier. They expect refinement. By working with the leaders first, we gained credibility and built the core functionality. Then we had the time and validation to refine it for everyone else. We used the pressures of the industry leaders as fuel to reach the PMF faster and then scaled the learnings across the market.
Many startups either drown in process or avoid it entirely. How do you “right-size” processes so that teams can move fast without losing product stability?
In a high-paced environment, the biggest mistake is over-processing. If you hire right, you don’t need heavy bureaucracy; you need principles, values, and clarity of ownership. People with agency will naturally create the lightweight processes they need to get work done.
At Agora, I’ve found that processes work best when they’re introduced reactively, not proactively. My early mentor drilled this into me: “You cross that bridge when you get there”. You don’t build for every hypothetical problem. You wait until the friction actually shows up. This can be in the form of missed handoffs, unclear ownership, or quality issues, and then you put in just enough process to solve that problem.
That’s why I think of it as principles over processes. Culture, autonomy, and accountability come first. The right people can adapt as the team grows from 5 to 20 to 100. Process is a tool, not the operating system. The operating system is the culture you set.
Over-engineering can be as dangerous as under-engineering in the early stages. What signals tell you it’s time to simplify rather than add more complexity?
When I think about great products, I think about Google at launch. It was a single text field and 10 blue links. Contrast this with Yahoo and AltaVista at the time, their display was cluttered with weather, news, and stock tickers. The winner chose to strip away everything non-essential. The same principle applies to engineering; progress comes from not piling up features but from cutting until only the core remains. SpaceX’s Raptor engine is another example. Their first iterations were overbuilt and messy, but through simplification and iteration, they converged to something elegant and powerful. And as Elon Musk says, the best part is no part.
Over-engineering and under-engineering often manifest themselves with the same symptoms: a product that feels awkward and brittle to use. I’ve seen many teams stall because they want perfection before launch. Product market fit doesn’t happen because the product is flawless. It happens because it solves a painful problem so well that people jump on it despite the rough edges.
In startups, shipping fast, even messy, is the only path to progress.
The hard lesson I’ve learned is that doing what’s required is more important than doing what you think is best. Especially with enterprise customers, good enough and working beats brilliant and unfinished any day. The way to avoid over-engineering is to ship, get real feedback, and iterate quickly. That’s how you converge on simplicity, by cutting back to essentials over time, in response to what the customers actually need.
Scaling isn’t just about code, it’s about people. How do you structure cross-functional collaboration so that engineering, product, and leadership teams stay aligned on priorities and trade-offs?
There are three pillars for making cross-functional collaboration work.
- Radical transparency. Bureaucracy kills information flow, especially in remote teams. At Agora, we set rules like: avoid DMs, make channels public by default, and keep information accessible. It’s simple, but it cuts through silos.
- Mastering async. Focus time matters, so we minimize meetings and rely heavily on documentation. Written collaboration in Notion or Jira lets people contribute on their own time and usually leads to clear, more thoughtful feedback than a rushed video call.
- Clear ownership. Collaboration doesn’t mean everyone is in the room for every decision. It means agency, people knowing exactly what they own, so that they can work fast and pull others when needed
I learned this first-hand while leading a forward-deployed team with Optimism. The team was spread across multiple time zones with minimal overlap. The async became the default. Thorough documentation, clear project tracking, and weekly progress updates kept engineers, product, and leadership aligned without slowing down.
Crypto and enterprise customers often require rigorous security, compliance, and reliability. How do you integrate these demands without slowing down innovation?
This is a very important question. In my experience, the teams that win in crypto and enterprise are the ones that take security and compliance seriously from day one.
Coinbase is a great example. It grew slowly and steadily through multiple bear markets, while hundreds of crypto exchanges were started and collapsed. They took compliance and security seriously from day one. Contrast that with FTX, which imploded because it ignored those fundamentals.
The challenge is timing. Early on, the risks are abstract, so it’s easy to ignore them. But once you start locking in the funds of real customers, security issues can appear from nowhere. If you’re not prepared, the outcome could be catastrophic. At the same time, overspending on security where the impact of a breach is low will burn resources and slow you down.
At Agora, we struck the balance by taking security seriously where it mattered most — the protocol layer. We were betting that our customers would eventually be locking their funds into our contracts, so this was essential to get right. Our strategy was to build on top of a proven open source foundation, OpenZeppelin Governor, which was already battle-tested and widely adopted in the DAO ecosystem. This gave us both technical confidence and reputational credibility while saving us a huge amount of time and money on audits.
As we scaled, this approach allowed us to partner directly with OpenZeppelin to further develop governor contracts. Having a strong partner not only reduced costs, but it also gave us an asset in sales conversions and let us move fast with confidence without breaking the bank.
From your own experience, can you share a specific scaling pitfall you’ve faced and how you navigated out of it?
One of the biggest pitfalls I’ve seen is building before selling. Startups often guess what customers might want, spend months engineering it, and then discover nobody cares enough to pay. At Agora, we flipped that. We secured financial commitment from customers first, then built.
That discipline carried through to engineering. Instead of piling on speculative features and ending up with a “Frankenstein”, we built with an assumption that if one customer wants it, others will too. It forced us to minimize waste, keep things simple, and maximize reuse.
To make that possible, we invested early in multi-tenant modular architecture. Every feature we shipped once could be customized and rolled out to others on demand. It kept the team lean while still scaling to new customers quickly.
