Commitment To Community
Dimitrie Stefanescu — CEO @ Speckle
About this masterclass
Open Source in AEC with Speckle by Dimitrie Stefanescu
Dimitrie Stefanescu is the founder and CEO of Speckle, an open source data platform for architecture, engineering, and construction. What started as a side project during a research fellowship at UCL London is now a venture-backed construction tech startup serving enterprise clients across the global built environment, from Jacobs to Foster + Partners.
What This Masterclass Covers
The AEC industry is locked into proprietary software, opaque file formats, and siloed workflows. Dimitrie's challenge: how do you build an open source construction software platform for a 12-trillion-dollar industry that has never operated that way, and turn it into a business?
In this masterclass, Dimitrie Stefanescu walks through the full journey from academic research to an open core business model, and shares the hard-won lessons along the way:
- Why making Speckle fully open source was the fastest path to trust, and enterprise adoption, in a closed-source industry
- How bottom-up community growth around Speckle turned into top-down enterprise deals, including a Discourse forum post that led to the CTO of Jacobs
- The shift from open source project to open core business model: what to keep open, what to commercialize, and how to bring your community along
- Why iterating on your business model matters more than iterating on your product
- The hiring mistake most early-stage construction tech startups make, and why "anti-selling" your company attracts better talent
- Where AI delivers real value in AEC today (parsing RFIs, scanning documents), and why 95% accuracy is a dealbreaker when buildings need to stand up
- How to move from consensus-driven to velocity-driven culture without breaking what made you special
You Might Also Like
Build Software For The Field: Florian Biller, CEO @ Capmo
Win As The Accidental CEO: David McGavran, CEO @ Maxon
The Infra.Market Story: Shubhankar Bhattacharya, General Partner @ Foundamental
Q&A
Question: What core problem in AEC does this masterclass tackle, and how does Speckle address it?
Short answer: The AEC industry is constrained by proprietary software, opaque file formats, and siloed workflows. Speckle’s approach is to build an open source data platform that creates trust through transparency, enabling interoperability and accelerating enterprise adoption in an industry that has historically been closed.
Question: How did community-led growth translate into enterprise deals for Speckle?
Short answer: Speckle grew bottom-up through an engaged open source community, which organically surfaced the platform inside large organizations. A notable example is a Discourse forum post that ultimately connected the team to the CTO of Jacobs, illustrating how grassroots interest can lead to top-down enterprise engagements.
Question: What does moving from open source to an open core business model involve?
Short answer: The masterclass explains how Speckle evolved from a fully open source project to an open core company—keeping the foundational technology open while commercializing select capabilities for enterprise needs. It also covers how to decide what remains open, what becomes paid, and how to bring the community along during that transition.
Question: Where does AI deliver real value in AEC today, and why isn’t 95% accuracy acceptable?
Short answer: Practical AI wins today include parsing RFIs and scanning documents—tasks where automation reduces manual effort and errors. However, in safety-critical contexts like buildings, 95% accuracy is a dealbreaker; the remaining 5% can have material consequences, so higher reliability is essential.
Question: What organizational lessons does the masterclass highlight beyond product development?
Short answer: It emphasizes that iterating on your business model can matter more than iterating on the product, warns about a common early-stage hiring mistake in construction tech, and explains why “anti-selling” your company can attract stronger talent. It also covers how to shift from a consensus-driven to a velocity-driven culture without losing what makes the team special.
Transcript
Introduction
Hello everybody. My name is Dimitrie. I describe myself as a recovering architect. Now I am founder and CEO at Speckle — Speckle being the data platform for AEC. I like coding a lot. I like building companies a lot. And I like the intersection of the digital and the built world.
Background: A European Union By-Product
I grew up in Bucharest. I consider myself a kind of European Union by-product, because I managed to move around quite a bit. I studied architecture in Bucharest for about four years, then moved to the Netherlands, spending time in Rotterdam and doing my master's at TU Delft. I was coding a lot and running workshops throughout Europe around computational design, architecture, and engineering — all powered by being able to move around.
Afterwards, I ended up working in Stuttgart as a visiting lecturer at the Academy, teaching computational design there. Then I ended up in Brussels working as an architect, and then finally I arrived here in London around 2015, where I was at UCL. Fun fact: about six months after I arrived, the Brexit referendum happened, which was a very encouraging development — but let's keep politics out of this conversation.
Why Architecture (Not New Media)
I studied architecture — and it's actually a funny story. In high school, I was coding a lot — doing eight hours of C++ a week, which did wonders for my social life, as you can imagine. I wanted to study new media and do interactive projections for live performances. But then came the classic conversation with the parents. This is Romania — that's not a proper job. Why don't you study architecture? Which is a nice technical mix between programming, analytical thinking, and creative thinking. That's how I ended up studying architecture. But I never stopped coding throughout that process. I was always driven to apply programming to various tasks, and over time I sharpened my thinking around what you can do with digital tools. That's maybe where my whole career started being defined.
Favourite Cities
Probably my favourite city — now that I have a kid and all that, history looks much better with distance — was Rotterdam, because of the student life and the opportunities and the vibrancy of the university there. I also really enjoyed Brussels because it had the right mix of Dutch and French culture: really good food, maybe too many EU bureaucrats around, but we weren't hanging out with them. London, though, has a special place in my heart. It's the city I've been in the longest — coming up to a decade or a bit more, which makes me feel old when I say it. London is great. It can be intense, but it can also be relaxing. It offers opportunities, but you choose when and how to take them.
The Key Insight: Buildings Are Data
While I was studying, I was always trying to blend the analytical parts of building things — buildings, infrastructure, roads, tunnels — with the creative side, and also with the data side. When I graduated, it was a rough moment — the 2008 boom and bust cycle meant there were essentially no jobs. That's why I ended up, somewhat luckily, at a very classic architectural studio in Brussels: a small shop, ten to fifteen people, growing to twenty in better times. There I was trying to apply computational design techniques to square buildings and very classical projects.
It was a period in which I learned that what's most important is not how things look — getting a fancy Zaha Hadid-style facade or a double-curved glass panel in — but rather, it's about interacting with various stakeholders. Stakeholders look at a building through very different lenses. As architects, we were not well equipped to create shared understandings between, say, someone who does economics and someone who does structural design.
The process was full of friction. My biggest moment came when we were working on a masterplan for Brussels Noord, for the north part of Brussels, next to the train station. There was an economist involved who was building an economic model of how that masterplan would function. A lot of data. That data was then supposed to be translated into architectural and urban decisions. And nothing in my training as an architect had prepared me for that moment. But that's when I realized: when we design masterplans or buildings, the data is already part of that design. There are a lot of heuristics that go into thinking about these things as an architect or urban designer — but it was very difficult to surface that back up in the language of an economist, or the language of the mayor, or the language of someone running a different feasibility study.
That was the biggest moment. I realized we're operating in a very diverse environment, and we are not empowered to speak to all of the stakeholders in it. As architects — and I fault us a lot here — one of the first ideas around Speckle came into play. I realized: it's not about how a building looks. It's much more about how that building translates into things that other stakeholders understand. I believe that all the essential qualities and quantities embedded in a floor plan, a building, a road — they can be surfaced up to different stakeholders so that they can make sense of them in their own calculations and their own domains.
The Marie Curie Fellowship & The Birth of Speckle
On the basis of that insight, I did this very unusual moonshot application for a Marie Curie Fellowship at UCL in London, which I received after a couple of interviews. That's how I transitioned to UCL, where I had the space to test these ideas and figure out if there was any worth to them.
At UCL, I had the space to actually do the thinking around the problems I'd been describing: how to take the data that's being generated while we design things and surface it up meaningfully. Initially there was no idea called Speckle — the name didn't exist in my head, nor the concept behind it. But as you do in every research project, there's a large body of literature to review, which was a very boring phase. So I started coding something on the side. The original Speckle was a very simple tool for Grasshopper — a computational design plugin — that just instantly shared your 3D model in seconds. That was all it did.
I started it as a side project, a way to get my head out of all the papers I was reading. I put it out there to see what the reaction would be. It got some traction, and some of the industry partners I had through the Marie Curie project started seeing things in it. I started refining it, and refining it more. Speckle went through many iterations — it's like the Ship of Theseus: all the parts have changed a hundred times already. The name is still the same. People ask me about the origin of the name — whenever I tell the story, it never gives them any satisfaction. So maybe I'll skip that part.
Growing the Community
When I first put Speckle out, I just launched it into the internet. There was already a vibrant community of computational designers and people who code in AEC. I seeded it into that corner of the internet and it started spreading organically. It wasn't open source at first, but then I did open up the repositories behind that original version of Speckle — and that's when it really took off.
People from McNeel — who make Rhino, the authoring tool that architects and engineers use a lot — started contributing. With their help in particular, we had by that point grown into a little community of Speckle enthusiasts — people excited about the project, using it in their day-to-day workflows. We created a Slack group, which was the go-to thing at the time. Nobody wanted to pay for it though, so we started hitting Slack's 10,000 message limit. Louise ended up setting up a Discourse forum where those limits wouldn't apply, and the community could gather meaningfully. And the advantages of a forum over a purely chat-based gathering started compounding: in a forum, people ask questions, those questions stay there, they're searchable. In a WhatsApp group or a Slack channel, things disappear. In the forum, they stay. That was a good place for the community to start gathering and coagulating — that's how the first seeds of Speckle's community started blossoming.
Industry Partners & Going Open Source
When the Speckle community started growing, I was slightly surprised — but also not that surprised. Within the Marie Curie research project at UCL, there was a large group of industry partners: Foster + Partners, Buro Happold, and a bunch of other large AEC companies, as well as service providers like McNeel. They helped seed that initial community through their enthusiasm and their work. This is also where I later met my co-founder. And it was where Louise started showing up — she came from McNeel. A group of people coagulated around what was, at the time, a novel and fairly rare approach in the industry.
I made Speckle fully open source — a decision I took while at UCL, partly to shortcut a bunch of political complications around who owned the Speckle IP. But also because I wanted to set an example: if we share things, there are a lot of positive externalities that help this grow bigger than any individual could make it. The AEC industry, for context, is rather boxed in by vendors who lock people into proprietary software and walled gardens, as well as opaque file formats that are very difficult to parse outside the authoring tools that produce them. It's a very closed place. Speckle, by being open source and transparent, was diametrically opposed to that.
I think that resonated with a lot of people. It also helped some architecture companies realize: our secret sauce is actually the designs we produce and how we engage with clients — not the magic little scripts we have in-house for generating facades or doing quantity takeoffs. It was wonderful to see. It was an amazing time.
From UCL to Arup to Independence
At one point, like all good things, the time at UCL had to come to an end. The research project ran for three years, and when it ended, so did the funding. I was on the market for a job. Luckily, Arup was already using Speckle, and they offered me a very generous position to go in there and keep developing Speckle as an open source project. Those were two more great years. It supported the project really well — and me as well. After a while, though, the limitations of developing an open source project inside a company, while that open source project was also being used by their competitors, started to show.
And that's why the company was born. In short: three years of intellectual and practical incubation at UCL, two more years of putting the project through its paces at Arup, and then we decided — we can go much faster and grow this thing much further if we go independent. There was already a good amount of people using it, a great community around it. We said: what's the fastest way to grow this project and capture all the data inside AEC? And we decided to establish a company around the open source project — one that would focus on developing and later commercializing it. That's where the journey of Speckle as a company started, with our pre-seed raised from Foundamental.
What Speckle Is
For those who don't know: Speckle is an open source data platform for AEC. That's a very abstract value proposition, so we've wrapped it into several productive experiences. They center around interoperability — being able to exchange data faster between authoring tools, saving people hours every week — as well as business intelligence, collaboration, and analytical access to that data.
This goes all the way from simply doing design reviews in a browser, issue tracking, and tracking design changes, to vacuuming up data from various APIs and actually training AI models on top of your company's historical data. All of this is geared towards helping companies deliver a better project the next time they do it. It's not just about helping design in the now — it's also about helping design in the future, keeping track of historical learnings, and making those available both to human beings and to our newfound partners: AI and agents.
Open Source Is Not Free Beer
Open source means a lot of things to many people, and understanding of it varies by industry depending on their digital maturity. In AEC, open source was initially perceived as free beer — whereas the closer or better definition is that open source is the free recipe for the beer itself. You still have to brew the beer yourself, and you bear the costs of setting up your brewery. But you have the recipe.
Together with community members, we continuously struggled to push this message across. To this day, there are still pockets of the internet that think Speckle is free, or should be free, and get confused when they see we have a pricing page. But the world has changed dramatically over the last four years. Where before people were asking "why is this open source software not free?", now they understand that open source is part of their infrastructure and has far more strategic potential for them than existing closed-source solutions. I like to believe we helped push that understanding along.
What open source means for Speckle specifically is that we're wearing our heart on our sleeve. As a customer, you can always hold us accountable: if you're unhappy with Speckle, you can take your toys, self-host Speckle, and never send a single dollar to the company. This creates a very good, trust-based relationship with our community and our customers. We understand that we need to be honest, that we need to create real value first, and then extract it in a meaningful way.
Open Core Model & Commercialization
Not all of Speckle is open source. Our model is an open core, around which we have built a proprietary layer of features. Historically, roughly 75% of our time has been invested into the open source core. About a year and a half ago, we started developing proprietary components of the Speckle platform that we are actively monetizing and leveraging for our enterprise clients.
Reactions to this were mixed, but we had set expectations from the beginning. We were transparent with our community from the start, saying that at some point this would happen, and adamant in pushing the message that open source is a free recipe, not a free product. When we started commercializing more intensively, most people's reaction was: of course you need to do this, you're a company, we totally understand, let's talk about how I can get access to these features.
Obviously there were also some angry reactions — why is this closed source now? But there's a funny phenomenon that happens here: when a primarily closed-source company like Google or Microsoft makes something open source, the crowd goes wild. But when a primarily open source company makes something closed, the reaction is: these guys are evil. We had a bit of that. The key to navigating it was being transparent with our community and setting expectations early. We took our community and advocates along with us on that journey of understanding. Honesty and trust do pay off.
Community as a Village
When you start an open source project and a community grows around it, the community becomes a bit like the village that helps you raise a child. And just like any village, it can be an annoying village or a helpful village — there will always be that difficult neighbor now and then. It comes with all the joys of a family, but also all the responsibilities of one. That needs to be handled carefully, articulated and shaped thoughtfully. It goes back to trust. Communication and transparency are key to having this village co-found the company with you, or help grow it into a serious adult.
I get asked a lot: what comes first — the open source project or the community that grows around it? I don't think there's a fixed starting point. You can start an open source project and the community will gather around it. Or you can start a community and, if motivated enough, that community will start an open source project. With Speckle, it was more the former — the open source project started first, and then the community assembled around it. That's a very fun dynamic to watch, and I wholeheartedly recommend anyone try it. You've got nothing to lose.
The Blender Problem & Platform Modularity
As Speckle is growing fast and signing up enterprise clients at a speed and pace we didn't fully anticipate, we've had to change how we respond to community needs. There's a funny phenomenon with open source projects — take Blender, the complex 3D modeling software mostly used in the games industry. It has so many buttons you can't begin to learn it — you need a whole month just to understand Blender's UI. There's a saying that pretty much all open source projects end up a bit like Blender: they accumulate exploding complexity because everybody wants a new button doing something else.
At Speckle, we suffered from that a bit. But actually, it prepared us for what's happening now. All those varied community requests — can Speckle do this, we want that, can you expose this API — helped us build a robust platform that we can now shape in very targeted ways for enterprise customers.
The way we think about it: we've built a set of Lego blocks. Those Lego blocks we've assembled into a bunch of Lego sets that you can pick up off the shelf. But AEC is very project-specific and very company-specific. When you're building an airport or a major capital project, it becomes its own micro-universe of standards, needs, and workflows that a single product usually can't fully serve. That's where being a modular platform really helps — we can shape it towards a commercial agenda. It's not easy to achieve and we're continuously iterating, but this is where community-driven development and commercial needs have converged in a rather surprising and productive way.
What Not to Do: Negative Advice
As a founder and as a person, I don't believe much in positive advice. I believe a lot more in negative advice. I have plenty of stories about what not to do.
One is codified into a kind of internet law — mostly a meme — but it's real: any surface area of an API that you expose, whether documented or not, is a feature and will be used by someone. If you take it away, you're going to annoy someone. This happened to us a lot and still happens as we try to balance continuously modernizing the platform while letting go of certain legacy things. It's quite difficult to manage technically.
The bigger lesson though is this: it's very easy to iterate on product. It's very easy to iterate on platform. The most difficult thing to iterate on — and where I feel most companies struggle, including us sometimes — is business model. This is where the most value is to be gained from iteration, rather than from pure product iteration. You don't want to trap yourself in local maxima. You need to make sure you're providing the right kind of value to your customers and charging for it in the right way. That's something I'm actually proud that Speckle, for better or worse and with all the internal grumbles it generates, excels at doing.
Trust, Community, and the Jacobs Story
Trust is really important to us — trust towards our community, trust towards our clients, and the trust we receive back. We don't build that trust alone; our community is a key engine for it.
Speckle being open source and having this bottom-up driven adoption really helped us infiltrate AEC enterprises, both large and small, in a way that a top-down approach would have made into a completely different game — much more difficult, and with the wrong incentives in how we developed the platform and the product. Speckle's aim was always to be valuable both for the individual architect working in a small team and for an organization at scale. Being open source and having a diverse community helped keep all those incentives aligned.
And there are some wild anecdotes along the way. One example is how Speckle got adopted at Jacobs. At one point, there was a random person on our forum asking: how do I self-host my server? We helped them out. Six months later it turned out that person was the CTO of Jacobs. We had no idea — it was just a random username with a number and a Gmail address. But that's exactly how the motion of having a strong community and being open source can be leveraged into commercial success further down the line. I like to believe these two things are not opposed to each other.
Lessons Learned & Taking the Leap
There are many things I would do differently if I were to start Speckle over again — codebase-wise, cultural-wise, company-building-wise. It's an endless list of negative lessons learned. But I think a lot of it comes down to having the courage to do something that may or may not work, and naively believing that it might actually work, and just taking the dive. That's really important.
As you progress from pre-seed to seed to Series A and beyond, those leaps of faith become more calculated. But the temperature of the water you're jumping into doesn't change much. That training is really important — especially for me, given that I don't come from an entrepreneurial family, I don't have a consulting background, and I'm also operating in Europe, which in some respects is diametrically opposed to Silicon Valley. London is a nice middle ground, but it also carries some of the old bones of the continent — a bit creaky and cautious.
This also connects to something else: it's important to be truthful to yourself — who you are as a person — and then to be explicit about that with others around you. Whether it's your work ethic, your endurance, what you expect from yourself and from others — all of these things need to be clarified from the start, especially when founding a company, open source or not.
Hiring Honestly: Anti-Selling
One very concrete mistake I can share: we always struggled with hiring in the early pre-seed and seed days. Who is Speckle? What is AEC? You don't attract talent easily. We are genuinely very nice people — quirky, friendly, culturally aware. But in interviews, we were overselling the company. We'd say things like: our work-life balance is amazing. It was not amazing. People were working days, nights, weekends — maybe because they wanted to, maybe because they were passionate. But we were selling ourselves as this beautiful, mature startup — which we were not.
That attracted the wrong kind of people. People who, in hindsight, didn't really fit — and that was our fault for misrepresenting ourselves. Now, there's a significant moment in every interview process where we do what I call anti-selling. Depending on the role, we just say: Speckle actually sucks from the following points of view. And then people self-select: either they decide they don't want to continue, or they say — this is exactly what I'm looking for, when can I start? Being truthful to yourself as a company and as an individual is really important. And communicating it well is key to having a good marathon. This is not a sprint — it's a series of sprints that keep coming every year, every quarter. You cannot last through them if you're not in tune with who you are.
The Future of AEC & AI
The future is really exciting for the AEC industry and the wider built environment. Infrastructure needs to grow — people need houses, cities are growing. It's a vibrant place to operate. And increasingly, there's an understanding that all the creativity and effort that goes into designing the future of the planet — which is essentially what construction does — is backed up by data, and that the importance of that data, catching decisions in real time and aligning stakeholders, is now being recognized.
People are understanding they can achieve much more — and be happier in general, rather than suing each other, which is a favourite pastime in AEC — by actually collaborating and reaching shared understandings. Providing them the data and the tools to do so is what gets me excited about the future. Some of the biggest highs in my life came from seeing something I helped design actually get built and cast a shadow on the earth. Speckle provides a much more scalable way for me to get that same feeling.
I'm also excited about the wealth of startups now attacking the authoring layer: tools like Giraffe, Snaptrude, TestFit — shout out to my best friend Clifton, they're doing incredible work there because authoring is really hard, it's a huge problem to tackle. At Speckle, we chickened out of it. We said: our main goal is capturing the data layer. We'll leave authoring to Revit and the others. But seeing this new generation of tools emerging is really exciting because my former architect self would genuinely love using them.
There has never been a time where so much energy, innovation, and dedication is being poured into the foundations of how AEC gets done. The digital revolution passed construction and associated industries by for a long time. But I feel we're finally catching up. And for me, deep down still an architect who wants to design better buildings, that's really exciting.
AI in AEC: Honest Assessment
AI triggers a lot of happy and sad feelings in me. Sad, because a lot of the generative AI potential currently used in AEC has been stuck in the 2D world of visualization. I've suffered through too many conference presentations where people talk about AI and the only thing you get out of it is: look at this new comfy UI workflow for producing renders. That's a great thing, but it feels like it's lacking the foundational research potential we could have. When you go beyond the superficiality of visualization and try to dive deeper into how AI can surface your data, it's still a bit of a solution in search of a problem. And there's a lot of caution coming from customers — and rightly so. Buildings need to stand up and not kill people. That's mantra number one. And using AI systems that are right 95% of the time is not feasible in that context, because the 5% of the time they're wrong will still skyrocket your insurance premiums. There's an impedance mismatch between how AI models currently operate and how they can be applied within AEC.
That said, AI is bringing a lot of value when it comes to parsing through large volumes of RFIs, scanning PDF documents — that's where it genuinely amplifies day-to-day work. The gap is that these models are not yet deeply domain-specific. They have context around AEC but don't really know the heart and soul of it yet — in the way they seem to have permeated other industries more thoroughly. I think as AEC itself digitizes more, it will open itself up more to these models and actually help them help us further down the line.
At Speckle, together with many of our customers, we're embarking on a journey of: what can I do with my data? How can I make this data available for AI? We're helping companies take all their historical projects and models, put them into Speckle, and then — with Speckle as a data platform — stream that data down and start training specific AI LLMs on top of their own data. That's the model we're helping the industry implement, because we believe a core asset of each of these companies is their designs and their data itself. We don't believe in centralizing those learnings and training our own AI models on top of everybody's data — that model doesn't work well for AEC given how things are currently set up.
Imposter Syndrome & Growing Into the Role
There's a significant component of imposter syndrome in pretty much my day-to-day life. My journey — from programming in high school, to architecture, to being this mixed breed of architect-who-codes-for-the-domain, to starting a company — now there are 27 team members working full time. It's amazing. At the same time, it brings a lot of what-the-fuck moments: what am I doing here? But it's also extremely interesting. Speckle never stood still — as a company, as a project — there was always something new to crack, a new challenge to solve, a new failure to de-risk or recover from. And that's what mostly keeps me going.
Growing into the role of CEO is a journey I'm still on. I like to believe I'm surrounded by great people and great partners — from investors to employees to the community. It's always, at least from my perspective, about curiosity in the day to day: making sure I define what I enjoy, satisfying that hunger, and asking what can I learn today, how can I do this better, what is the most important thing I can apply right now.
With Speckle, there was no ready recipe we could apply. Open source, weird niche, twelve-trillion-dollar industry that had no idea about open source at the time and was very low on the digitalization front — there were no playbooks. Everything had to be adapted. The speed of adoption is different in AEC. The stickiness is wildly different in AEC. These are variables you have to juggle every day when making decisions.
Velocity Over Consensus
The main lesson for me so far is that it's much more important to take a decision fast — even if it's wrong — than to agonize over it in circular discussions. Speckle as an open source project was a very democratic place, and the company took a lot of that on board. We were very consensus-based. That doesn't necessarily mean we moved slowly, but it also didn't mean we always moved fast. About a year and a half to two years ago, I needed to make a cultural shift inside the company: research is nice, being kind to each other is nice, taking decisions together is nice — but at a certain point, velocity matters more than consensus. That's still a cultural challenge we're working through.
Another complexity item is that we're a remote-first company. We started during COVID — there was literally no choice. And there were a lot of mistakes made there. No recipes to apply. A second-time founder probably wouldn't have made them. I'm a completely different person now from who I was four or five years ago.
Would I Do It Again?
Would I do this again? The answer is yes. How would I do it? I'd start even earlier and move even faster. With all the pain, blood, sweat and tears — it's a resounding yes. I wouldn't trade any of the decisions I've made for a different direction. They all assemble themselves into a very beautiful puzzle. None of the pain or the down moments actually takes away from the existential joy you get from creating a company, building an open source project, and building something that people use. That's where I stand. My partner might disagree with this statement — but I don't think so.
Managing the Dark Moments
As a founder, there are many things that frustrate me on a daily basis. I'm a very classic Eastern European — skeptical, hard to satisfy — the kind of person where even when the most amazing thing happens today, I'll still think: okay, this could have been done better in this way and that way. That's my default position. I've learned to live with it. I've also learned to channel some of that energy in a more nuanced way with the people I work with. Most of it stays internal.
The things that calm me down are mechanical: I love going back into product, I love to code. I'll carve out an hour, shut down my brain, and write some code that maybe goes nowhere. It's therapy. Other people do drugs, other people do sports. Since I have a kid, I don't have time for much else. Playing with a toddler is actually a surprisingly good therapy session too.
Balancing family and company is an ongoing challenge. I feel like I over-balance towards the company — but then again, that's probably something I took over from my parents. My earliest memories of them are sitting in front of their computers, working. So I don't understand the world any other way.
But fundamentally: find the things that shut your brain down. That's what will calm you down. For me, coding does that. The gym, on the other hand, amplifies the echo chamber of negative thoughts. But badminton — a sport I played for a long time when I was young — actually does shut my brain down, because it's just the endless chase for the shuttlecock. You're like a cat focused on a laser dot. It's essential to understand, as a founder, what gets you back into that happy place and what makes you calm again.
Watch the video on YouTube.
