Scaling a developer conference to 5,000 attendees with Ivan Burazin of Daytona
GitHub Codespaces is doing the marketing Ivan Burazin's company doesn't have to. Daytona's bet, learned the hard way at his first attempt at this exact idea in 2009, is that dev environments only work top-down — so let Codespaces sell the bottom-up dream and go straight after the enterprise buyer instead.
Ivan Burazin is the co-founder of Daytona, a development environment management and orchestration platform, and previously ran developer experience and a 5,000-person conference called Shift as an executive at Infobip.
We get into what he learned from building basically the same product 15 years too early at Code Anywhere, what it's like negotiating for a bottom-up developer motion inside a top-down enterprise, and why Daytona is deliberately not competing with GitHub Codespaces for individual developers at all.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does Daytona actually do?
Daytona is a development environment management and orchestration platform, which is a lot of words for saying it enables any developer to clone their repository and instantly start coding. Everything you'd normally have to do beforehand — setting up dependencies, installing tools, all the stuff that usually doesn't work right out of the box — is done automatically. We do that with a specific focus on enterprise companies.
Why does that setup problem matter so much?
When I was writing code back in 1999 or 2000, you basically opened your editor, started coding, and deployed it somewhere or ran it on localhost — there was no underlying environment problem to solve before you could start working. For people trying to get into the industry today, it's a huge hurdle just to figure out whether their code isn't running because they made an error, or because the development environment underneath it isn't set up properly. And it's not just a beginner problem — we've seen engineers waste anywhere from 50 to 70% of their otherwise-productive time on development environment issues, waiting on tests and builds, rather than actually coding.
You tried something similar before, with Code Anywhere. What was that?
Code Anywhere — originally called PHP Anywhere — was a browser-based IDE we started in 2009. We were basically one of the first to try that; Heroku actually tried it first, killed it, and pivoted into what became Heroku, though we didn't know that when we started. We had a bit of success, but the technology was genuinely too early, and the market and people weren't ready for it. I think the awareness and technology have both caught up a lot since then, especially because of GitHub Codespaces.
What did you actually learn from that first attempt that you've carried into Daytona?
Mostly how not to do it — there's a quote from Edison about learning a thousand ways not to do something, and we pushed on Code Anywhere from 2009 to about 2016, so quite a chunk of time to learn a lot of those ways. I think we've incorporated that into the new product, and when I look at competitive products now, I see some of them making the same mistakes we made a long time ago, because they haven't been through it. Being old is genuinely our competitive advantage here.
Before Code Anywhere, you'd also built a totally different kind of company. What was that?
My first company wasn't really a startup — it was a systems integrator that sold and set up things like Cisco routers and WiFi networks for clients like hotels and office buildings. I started it almost by accident: I was running IT for another company, felt stuck and too scared to just quit, so I suggested to the owner that we spin it out into its own company so I could offer services to the rest of the market, half-expecting him to say no. He said yes, and I ended up founding a company with zero business knowledge — I didn't know the difference between EBITDA and cash flow. I learned everything the hard way, and eventually realized I couldn't build something truly impactful doing that, so I sold it to a local competitor. It wasn't a huge exit, but it got me started.
How did Shift, the conference, actually start?
It started as a way to give back to the community, but also somewhat by accident. While running Code Anywhere, we applied to pitch competitions everywhere — Tokyo, Beijing, London, Vienna, San Francisco, New York — as a way to get in front of investors. We got onto every one of those stages and never got a single check out of it. But I loved the energy at those conferences, and nothing like that existed back home in Croatia, so I decided to try organizing one myself, despite never having organized anything bigger than a birthday party. The first one was rough — I was the MC, fighting stage fright, literally setting up microphones myself because there was no budget. I said I'd never do it again, but people said it was great and offered to sponsor a second one. We actually lost money for the first three years, but attendance kept growing — 250, then 300, then 500 people — and once developers became a hot commodity, sponsors started coming in for access to them, and it really took off from there. We ended up running three conferences a year, and it became my full-time focus until Infobip acquired it in 2020.
What do you think actually makes Shift work, beyond just growing in size?
There are really three groups outside your direct control at any conference: the speakers, the attendees, and the sponsors who finance it. For speakers, we always try to treat them as a top tier even when we didn't have the budget — a driver picking them up, flights, a dinner so speakers get to know each other, even sailing trips for speakers the day after. Speakers notice that and become advocates who want to come back and bring other speakers with them. For attendees, the goal is to create serendipitous encounters, because for me a conference has always been about meeting people rather than watching talks. We repeat the same handful of songs throughout the event so the soundtrack sticks in people's memory, we have cocktail and mocktail stations that create natural icebreakers in line, and we've had Porsche as a sponsor for the last three years so people can drive a GT3 for the first time at our event, with a simulator competition where the winner gets a trip to race on an actual track in Istanbul. The venue itself is now a 360-degree stadium, which is disorienting for speakers at first, but it also means attendees genuinely can't get lost — just keep walking and you'll get where you're going.
What changed when Infobip, a much bigger company, acquired the conference?
Infobip is a Twilio competitor — one API for voice, email, SMS — bootstrapped from a village in Croatia to about two billion dollars in revenue with essentially no external funding, still private. They were a top-down, wholesale enterprise sales company, not bottom-up like Twilio, and their comparable competitors got 40-50% of revenue from bottom-up motion that Infobip had no access to. Acquiring the conference gave them access to around 5,000 developers a year. They brought me on as chief developer experience officer to run not just the conference but the DevRel team and a startup program. The useful thing was that Shift was already a bigger brand in the developer community than Infobip itself, so they left it largely alone — Infobip became more of a backstory sponsor, flags in the background, getting developer attention without pushing a specific product message.
What was it actually like pushing a bottom-up motion inside a top-down enterprise?
It's genuinely hard, and there's a lot written about how being the first-ever hire for something like this sets you up to fail, because a large company already has an entrenched way of working. Infobip was around 2,500 people when I joined and nearly 4,000 when I left — a very top-down, enterprise-focused culture. Suddenly you're saying we need to fly around the world doing meetups and conferences, and a lot of people internally assume you're just spending money and having fun rather than working. There were a lot of mental barriers inside the company we had to break down to be allowed to do what we wanted.
How did you actually navigate those internal politics successfully?
The key for us was that I'd been acquired directly by the founders, and I worked hard to maintain that relationship so they effectively sponsored what we were doing. Everyone in a company has their own OKRs and their own agenda for hitting them, and resources are finite — having a high-enough sponsor gives you the room to execute on a longer time horizon, because bottom-up isn't like sales, where you make a hundred calls today and close one tomorrow. It's general awareness that compounds over time. The upside of bottom-up, once it's working, is that it scales without adding headcount — everyone knows Twilio, and they don't need to keep scaling DevRel to maintain that, whereas a top-down company has to keep scaling sales and customer success as it adds customers. Without a sponsor high enough up, it's very hard — I've seen a lot of people in that position quit or get pushed out because it just doesn't work.
Is there a pattern to which initiatives survive that kind of internal friction?
If a company's founders or top leadership genuinely care about something, it's very hard for an initiative pushed by people lower down to succeed without that sponsorship — leadership sees the cost on the spreadsheet every month or year, but the inbound effect takes a long time to show up, and that's exactly when the friction arises. It really does come down to whether the people at the top care about it.
How is what you learned across Code Anywhere, Shift, and Infobip shaping the growth strategy for Daytona?
Shift was interesting because, as a conference, it genuinely ran both motions at once — sponsorships were a top-down enterprise sale, while ticket buyers were a bottom-up motion. Before that, at Code Anywhere, I only knew bottom-up. At Infobip, I was on the other side of the table for the first time — I was effectively the enterprise buyer, purchasing things top-down, which finally let me understand what that buyer actually needs. Looking at the market now, GitHub Codespaces is doing a great job, but they're a bottom-up SaaS product focused on individual developers. What we learned at Code Anywhere is that this specific type of product only really succeeds with a top-down motion — that's our thesis for Daytona.
So you're not trying to compete with Codespaces head-on?
Not at all — we're basically happy to let GitHub keep doing the bottom-up marketing and preaching that this category of product is great, and then we go sell to the enterprises with specific needs Codespaces doesn't serve: security, stability, on-prem deployment, that kind of thing. We're deliberately not launching an individual-developer SaaS product for the foreseeable future, though there will be a self-hosted version people can download and run on their own infrastructure.
Most dev tool advice says start bottom-up. Why is this specific category different?
It's counterintuitive, and for most dev tool companies bottom-up really is the right way to do it. What's specific to this category is that a bottom-up motion here requires a huge amount of compute, which comes at a very high cost — Replit, which is very similar to what Code Anywhere was a decade earlier and is now worth 1.2 billion dollars, has had to cut back on free hosting because of exactly that compute cost. A hyperscaler like Microsoft, which owns Codespaces, or AWS can absorb that because they own the underlying cloud. As a startup, that's not a cost fight I want to be in.
What's your one or two takeaways for other founders from all of this?
I think everyone on a team should be at least partially DevRel. Some engineers are shy about it or don't think it matters, but there are low-effort ways to involve them — we'll do a video or audio call with someone on the team and just transcribe it into a post. The people who actually built the product are the ones who can tell its story most believably; you can hire great dedicated DevRel people too, but the builders carry a credibility a hired storyteller can't fully replicate. If you build a culture early on, while you're small, where it's everyone's job to contribute a bit — not flying to conferences, just showing up in a Discord or doing a quick call — I think you get a much bigger, more believable impact with your audience. We're 11 people at Daytona right now, and that's the approach I'm trying.