Ivan Burazin

The through-line

Almost everything Ivan Burazin says returns to one analogy: an agent is a digital knowledge worker, and knowledge workers need computers. Daytona exists to hand them one. "We essentially give AI agents computers to do their tasks" [1], and the test he applies to any new use case is deliberately crude: "if a human needs a computer to do something there's a high probability that an agent will need to do that as well" [2]. That framing is the product roadmap, the pitch, and the reason he resists the word the market settled on.

It is also the endpoint of a twenty-year arc he tells consistently: racking physical servers in Croatia in the mid-2000s, building one of the first browser-based IDEs in 2008 when there was no VS Code and no Kubernetes so you wrote your own editor and your own orchestrator, then dev environment automation for large enterprises, then the pivot to agents [2][4][5][12]. "My entire career has been servers, developers, dev environments, which are also servers, infrastructure" [4]. The second, quieter through-line is temperament: a decade of feeling like he failed every morning, and the conviction that persevering through that is the only mechanism he has ever seen work [3].

On giving agents computers

He is unhappy with the industry's vocabulary. Sandbox is the name of the primitive Daytona offers, the way EC2 is the VM AWS offers, and the market has consolidated on it, but "the sandbox I feel is quite a limiting name and also feels about like testing and not actually in production type thing" [1]. What he wants people to picture instead is a "composable computer for the agent": the agent decides on the fly that it needs this much CPU, this much RAM, this much disk, maybe a GPU, maybe Windows, maybe Mac, maybe Linux, the way you once assembled a PC from parts in a shop, except it arrives in "sub-100 milliseconds" [1]. On Linux it is roughly "60 milliseconds, which is half the time it takes you to blink"; Windows takes about a second [2]. The analogy extends to why humans own more than one machine, a MacBook Air for email and travel, a GPU box for 3D rendering, and GPUs at Daytona follow that same logic rather than inference: the reason you have a GPU in your computer, for Blender or rendering or games [2].

A fresh machine also comes with apps, and he treats that as the design brief. The "agent toolbox" ships a headless terminal, headless file explorer, headless LSP and headless Git client by default, because a laptop you unbox already has a file explorer and a terminal even if nobody calls those apps [1]. He pushes the metaphor further than most: he described spinning up a Mac sandbox with a phone and a SIM card attached so an agent has its own email and its own account, with privileges over what it can and cannot do, reachable by text, Slack or email [2]. The bigger prize is arithmetic. A human really works on one laptop; "an agent can work on like 36,000 in parallel at the same time" [4], and even on a conservative, linear view of AI adoption, serving agents is "orders of magnitude larger than serving all human developers" [4]. He has also framed the same thesis around everyone shipping agent computers [7][10].

On statefulness, speed and rejecting the off-the-shelf orchestrator

Three properties were the foundation from the start: long-running, stateful, fast [2]. Ephemeral sandboxes came second, as a flag, because the mental model was a human computer that runs as long as the agent wants and holds its state the way a laptop does when you open and close the lid [2]. Getting all three at once is why they wrote their own orchestrator: "we don't use Kubernetes or anything off the shelf," though Kubernetes still deploys the control plane [2].

That same judgement shapes how he reads the competitive landscape. "The number one quote-unquote competitor for us is like, you know, Kubernetes cluster" [1], and customers usually arrive after it has bent under them: pods were built for app deployments, not for agents grinding at a task for a long time, so the first conversion trigger is scale and breakage, and only then do people notice the tooling and the performance gains [1]. Costs are honest about this. Daytona is somewhat more expensive than running your own Kubernetes cluster, though it removes the DevOps burden, and it costs less than a lambda [1]. Usage patterns dominate: some customers spin up 300,000 or 400,000 short-lived sandboxes a day for under a hundred dollars, while others run 20,000 for hours each and pay orders of magnitude more [1].

On security once the agent is inside the box

He splits the world by where the agent sits. Historically the agent ran elsewhere, on AWS or GCP, and called out to a sandbox for a specific job, the iframe in a vibe coding tool while the chat interface and the agent live outside [1]. If it is only ever calling out, security is a narrower problem; you do not need a computer to answer what the capital city is, you need one for a pile of CSVs [1]. The newer pattern is putting the agent inside, throwing Claude Code into a locked-down sandbox where it cannot break your laptop and where you can run many at once. "It's like it's not one agent. It's like, 'Oh, I can throw 50 of them, 100 of them.' It doesn't matter" [1]. Directionally he expects agents to live inside sandboxes, though the majority of customers are still on the old pattern [1].

That shift created the security surface. An agent inside a machine can see everything in it, so secrets and tokens have to be solved, by managing them or proxying API keys so the agent cannot go off and do malicious things, and the Git client already hides tokens from the agent [1]. Firewalls, inbound and outbound, were shipped recently in direct response to demand: where can the agent go on the internet, and who can see what it publishes [1]. His design choice is that everything is open by default and constraints are set at creation time by the human owner or integrator, who then binds every sandbox the system creates [1]. He is candid that this is a moving target, and treats it as a lesson in product timing: "firewalls and, you know, secrets management and things like this weren't really interesting a few months ago" because agents were outside, and that is why building at the start of a market trend requires keeping your ear to the ground [1]. For larger buyers he layers it: monthly pen tests, certifications, multi-tenant cloud, single-tenant cloud, and fully on-prem, plus the isolation of the sandboxes themselves [1].

On selling performance rather than fear

He resists the security-company label. "We mostly think of Daytona as a performance enhancer sort of company," on the argument that an agent using a Daytona sandbox is roughly double or orders of magnitude more performant than one on a Docker container or a Kubernetes pod, because speed, statefulness and built-in tools all save time, tokens and context window [1]. Security is nonetheless "at least a third of our product" [1], and he is explicit about the sequencing: the buyer wants their agent to do X, so raise the probability it does X, and being more secure on top of that is an extra win [1].

The go-to-market question he keeps returning to has three parts: "One is awareness. Do they know you exist? Two is preference and then the third is like is there some deterministic factor that you have that others don't?" [2]. Awareness is currently the binding constraint, and he says so plainly. The market does not yet know it needs this, most people still reach for a Kubernetes pod first and only convert after the pain, and the market itself is very new even where competitors exist [1]. Security out of the box is a real wedge with large companies, though smaller startups do not care yet [1].

On exponential growth and what it breaks

Growth arrives as a staircase, not a slope. A stretch of linear day-over-day movement, then a customer launches and volume jumps 5x or 10x and stays there, then compounds organically, then another customer does the same [1]. At around 1.8 million sandboxes a day, earlier milestones that felt enormous flatten into an invisible line on the chart [1]. He is straightforward that infrastructure businesses are power-law businesses, where a small set of customers drives most of the growth, and that as fast-growing consumer AI companies build on you, their curve becomes yours [1]. He is equally straightforward about the cost: every order of magnitude shakes or breaks something, a customer publicly felt one such episode, and "linear growth is sort of easy to predict what is going to happen, but exponential growth is really, really hard" [1]. Six months live and still accelerating, he calls the projected numbers exciting and scary in the same breath [1].

Underneath the growth sits a supply problem he flags bluntly: "CPUs are the new constraint because of people like us and sandboxes and RL environments and all these things and by October there will be no more CPUs like it's done like for this year" [2].

On dev environments, and why the pivot happened

Daytona did not begin as agent infrastructure. The original product automated development environments for large regulated enterprises, aviation, transport, defence, banking, on the observation that a developer joining Google clicks a button and starts working, while a developer at an equally large non-tech company can lose hours, days or weeks getting set up, repeatedly, for every project [4][5]. He put a number on it: engineers waste "anywhere from like 50 to 70% of their productive time" on environment issues, waiting for tests and builds [5]. The framing was levelling the playing field, giving companies with Google's problems Google's solution [4]. It was working, with two rounds raised in eighteen months and enterprise customers landing [4].

What changed his mind was recognising that agents share the human problem and add needs humans do not have, which makes the same machinery more valuable, against a market that dwarfs human developers [4][12]. He is unsentimental about the turn, and connects it to an older lesson: at one point Daytona was doing pretty well and they decided this is not the thing, kill it, move on [2]. He also draws a sharp contrast between enterprise dev environment complexity and the simplicity people now experience in vibe coding [4]. The concrete demo he uses is the flower shop website: a model can write the code but cannot run it, whereas with a sandbox the code is injected, run, and returned as a URL you can send to someone [4].

On what Code Anywhere taught him

Code Anywhere ran from 2009 to roughly 2016, one of the first browser-based IDEs after Heroku's founders abandoned the idea, and he has a precise post-mortem [2][5]. The technology was not ready, the market was not ready, and awareness only came later with GitHub Codespaces [5]. They sold directly to the end developer, "which is not how you make money. You have to sell to businesses and developers have to bring it in" [2]. They had no on-prem offering when that was required [2]. DevTools was not yet seen as an investable category, and only after GitHub's acquisition did investors accept you could make money there [2]. Most painfully, they did not understand how to sell a story of vision, or how human network effects actually matter when raising [2]. They talked to close to a hundred VCs and were told no every time, and he now says he would not have given himself the money either [3]. They were stubborn and pushed it far too long: the deeper lesson is that a thing which does not look dead may in fact be dead, and you are better off moving on [2].

He treats the accumulated scar tissue as the moat. "I learned how not to do it," and watching competitors who never lived through it repeat the same mistakes, "that is our advantage that we've been here just we're just old" [5]. Daytona is explicitly a spiritual successor: nobody had solved the problem they started on a decade earlier, and the companies attempting it were making their old mistakes [3]. His open source thinking sits alongside this, from AGPL licensing and contribution paths at Daytona [2] to his broader argument that most founders do not understand what open source licensing commits them to [8].

On failure as a skill

His most personal argument is that failure has to be learned rather than avoided. Across roughly fifteen years he says that for at least the first decade "I'd wake up every morning feeling that I failed," through the Great Recession, a company nobody would invest in, and a conference that lost money for years [3]. He makes three claims. First, "failure is relative": we call it failure when we do not hit a target, but "being the worst in your class is still a success," and finishing a race last still leaves you further along than before you entered [3]. He tests this on his own history: the period he would have named as the worst of his life, four employees and customers cutting costs, was also the period the company was paying salaries and doing a couple hundred thousand in revenue, worlds away from the $2,000 he had borrowed against a 24% credit card to start it [3].

Second, failure is a stepping stone. The conference he swore after the first edition he would never repeat lost money for four consecutive years while outsiders saw a success, and ended up acquired by Croatia's largest company [3]. Third, failure is a skill you build like going to the gym, and the culture teaches the opposite, that failing is simply bad [3]. He blames the training montage for the damage: the hero acquires a superhuman skill in fifteen minutes while you eat popcorn, and "we've been programmed that it's super easy," when getting in shape or building a company takes years or decades [3]. The counter-example he keeps is a Techstars classmate in a worse position who spent two years calling and flying to every VC on the planet to raise two million, later sold for a life-changing sum, and invested in Daytona [3]. He closes on Edison: "I have not failed I have just found that 10 000 ways it doesn't work" [3].

On building conferences and community, and top-down versus bottom-up

Shift began because he and his co-founders entered pitch competitions in Tokyo, Beijing, London, Vienna, San Francisco and New York, got in everywhere, raised nothing, and he liked the energy of the conferences more than the pitching [5]. He had never organised anything bigger than a birthday party, MC'd the first one himself, and lost money for the first three years while attendance grew from 250 to 300 to 500 [5]. It only turned when developers became a hot commodity and sponsors wanted access to engineers [5]. It now draws around 5,000 developers and runs on a 360-degree stage in a stadium, chosen because no other venue was big enough, then turned into an advantage: sponsors, lounges and food on the outer ring, and you cannot get lost if you keep walking one way [5].

His theory of what makes an event work is that three of the four components sit outside your control, so you invest in the ones you can influence [5]. Treat speakers extremely well, drivers with name cards, dinners, sailing days, even when the budget only stretches to economy flights, and they become advocates who recruit both attendees and other speakers [5]. And engineer serendipity, because he attends conferences to meet people rather than to hear talks: a repeating soundtrack that recalls the event months later, free cocktails and mocktails with queues that function as icebreakers, Porsches to drive and simulators with a racetrack trip as the prize [5]. He considered writing a book on the subject because so few exist [5].

The acquisition by InfoBip was a top-down company buying a bottom-up capability, wanting developer reach because comparable companies earn 40 to 50% of revenue that way [5]. He warns that being an acquirer's first hire in a new function is usually not set up for success, and describes real internal resistance, colleagues assuming travel and meetups were spending money and having fun [5]. The teams he ran did around 30 conferences a year and later won awards for best DevRel program and best community DevRel program [5]. The brand strategy was deliberate: Shift was bigger among developers than InfoBip, so InfoBip stayed a background sponsor rather than branding over it [5]. He has continued arguing for bottom-up adoption as where the strongest agent companies are forming [9][11].

On teams, and on Croatia

Daytona's founding team has been together for around two decades, and most of the wider team has worked with one of the founders before, giving an average tenure together of roughly six years, which he calls a "high context, high throughput organization" where people argue freely and move faster for it [2]. They work from three offices, Zagreb, Split and San Francisco, and he moved to San Francisco because being away from where AI companies are built is too large an opportunity cost [2]. He is a persistent advocate for the Croatian ecosystem: a country of 3.8 million with three billion-dollar companies, InfoBip built from a village to multiple billions in revenue while staying private, Rimac Automobili now owning Bugatti, Verne, and Google's acquisition of Photomath [2][5]. His own first business, racking Dell boxes and VMware for banks and telcos from around 2004, was CPU-box infrastructure, which he notes is essentially what sandboxes are today [2].

On adapting, or being passed by

The thing he says should worry developers is not a specific technology but the compression of adaptation cycles. Historically an engineer who stopped learning got overtaken slowly, and usually near the end of their career anyway [4]. What he says he has never seen before is 28, 29 and 30 year olds who, when shown what AI augmentation makes possible, visibly do not understand what is happening, and he is blunt that "you cannot work with these people" [4]. His standard is competitive: if you want to compete with the best you have to use the best tools, and everyone on the team has to run at that pace [4]. AI will not solve every problem, but it makes things faster, and for those who refuse, "time will pass you by" [4].

Takeaways

• Design for agents by asking what a human would need: "if a human needs a computer to do something there's a high probability that an agent will need to do that as well" [2].
• Daytona's three founding requirements were long-running, stateful and fast, which is why they wrote their own orchestrator rather than using Kubernetes for sandboxes [2].
• Sell the performance gain and let security be the extra win; security is still at least a third of the product [1].
• Security became urgent only when agents moved inside the sandbox, forcing secrets management, token hiding and inbound and outbound firewalls set at creation time by the human owner [1].
• Infrastructure growth is a power law and a staircase: a few launches drive 5x to 10x steps, and every order of magnitude breaks something, because "exponential growth is really, really hard" [1].
• The main competitor is a Kubernetes cluster, and customers convert after it breaks at scale, so awareness is the real go-to-market constraint [1].
• Selling DevTools direct to individual developers does not make money; you sell to businesses and let developers bring it in [2].
• Failure is relative and learnable: "being the worst in your class is still a success," and the training montage has convinced people that hard things should take fifteen minutes [3].
• Treat conference speakers exceptionally well and engineer serendipity for attendees; both compound over years [5].
• CPUs, not GPUs, are the emerging constraint for sandbox and RL workloads [2].