Design-first software engineering: Craft – with Balint Orosz

0:00 so how do you find it being different being both a Founder with a lot more should I say design Focus user Focus mobile Focus true Engineers or hardcore Engineers didn't really find me to be one of them but then designers product managers or others they didn't find me to be one of them either so you end up in this in between period of you do a lot of engineering they respect what you do but somehow because my focus has never been on distributed system skillable algorithms a lot of The Innovation I bring to a team means that clicking on a button will take 2 milliseconds instead of 10 milliseconds backend Engineers will say they just save $2 million on infrastructure cost or scale to a billion users my love for creating user facing experiences kept me

0:45 going and going on this path many people who started next to me who ended up moving a lot more toward back and distributed system scaling you know engineering that's where they thought and they found hard problems to be craft is one of the most delightful text editors and an app that has previously received Apple's Mac app of the Year award I happen to know this app really well because it founder is my brother Bing toos bind is probably the exact opposite of me he's a designer at heart and is as good as someone can get him building amazing apps today we talk about why it's hard to fit in as a design first engineer or engineering leader at most companies unique engineering decisions behind craft like using custom components instead of the Native iOS and Mac ones and not using Auto layout how craft built an editor where everything animates but nothing is

1:32 jumpy and many more interesting topics like how most companies get Design Systems wrong and how to make local first software work well if you're interested in how beautiful and highly opined software is built with a small team this episode is for you if you enjoyed the show please subscribe to the podcast on any podcast platform and on YouTube thank you this really helps the show get to even more listeners and viewers this is a very rare and special episode especially that I only have one brother so so by first of all welcome to the podcast thanks for having me so one of the topics that one of the reasons you're here is recently I I I reflected on something interesting how most CTO that I know and even most Founders at at at tech companies they're

2:17 very backend oriented their their background typically you know they they've been in engineering for 10 plus years is usually very backend heavy and this leads to a lot of interest in things their approaches will prefer back and Engineering approaches for example they'll often Focus heavily on unit testing automated tesing and so on but what I've not really seen is a kind of more mobile ux design focused founder and special engineering executive and I have seen this uh with you because you're you're a lot more in this direction and the two of us are are pretty different if I had to put myself I'm I'm I'm for more of of this like backend preference and even when we did projects together

3:03 many many years ago I was writing the unit test and the business logic and and you were doing the front and side of things and and you still sa it here so how do you find it being different being both a Founder uh previously you were an executive at Skyscanner with a lot more should I say design Focus user Focus mobile Focus what what would a good way be to put it yeah so you know I've been writing code as you know since I've been 12 um but you know always when I've been writing code my main goal was to put something on the screen and to be able to interact with that so for many people it's we can we we can probably note your the first few programs that you wrote those were you know games

3:49 right yeah they were games and and visualization of graphs and and and I focused a lot on time on you know making sure the graph is is drawn in an animated fashion so those were always the the very very interesting parts for engineering for me uh and this also led me to a number of different techniques over the time uh for instance utilizing flash a lot I think flash was a a very interesting way of how code and design co- lived in the same tool and allowed a very strong creative expression and I always tended to look at computers as an opportunity to draw on a canvas right you know draw on your screen particularly as myself I've never never been able to draw by hand well I always looked at how computers can enable me

4:36 and I think this was a a very interesting because despite being an engineer for such a long time and writing so many code I always felt that true Engineers or hardcore Engineers didn't really find me to be you know one of them uh but then you know designers or you know product managers or others they didn't find me to be one of them either so so you end up in this in this in between period of you do a lot of engineering they respect what you do but somehow because my focus has never been on distributed system scalable algorithms you know a lot of the Innovation like for instance bring to a team means that clicking on a button will take two milliseconds instead of 10

5:22 milliseconds while backend Engineers will say they just save $2 million you know on infrastructure cost or you know scale to billion users and I think my love for for creating user-facing experiences kept me going and going on this path but I've seen many people who started next to me who who ended up moving a lot more toward wordss you know back in distributed system scaling you know engineering because that's where they thought and and they found hard problems to be and also it's it's a lot in big companies how competency Frameworks promotion you know structures are oriented towards those areas where it's a lot easier to validate the impact you've been doing because it's a lot more measurable this episode is brought

6:07 to you by work OS if you're building a SAS app at some point your customers will start asking for Enterprise features like s authenication skim provisioning and fine green authorization that's where work comes in making it fast and painless ad Enterprise features to your app their apis are easy to understand and you can ship quickly and get back to building other features work also provides a free user management solution called alkit for up to 1 million monthly active users it's a drop in replacement for Al zero and comes standard with useful features like domain verification role based Access Control bot protection and MFA it's powered by radic components which means zero compromises in design you get Limitless customizations as well as modular templates designed for quick Integrations today hundreds of fast growing startups are powered by workos

6:53 including ones you probably know like cursor versel and perplexity check it out at works.com to learn more more that is work.com before we jump back into the episode I want to let you know that the audiobook version of my bestselling book the software Engineers guide book is out now you can get it on all major audiobook platforms like Spotify audible liberal. FM Apple Books Google Play and also DRM free MP3 files I started writing this book after a decade of working as a software engineer when I was working as an engineering manager for a few years already at Uber here's a review from the book from senior principal engineer Tanya really who is the author of the staff Engineers path from performance reviews to P95 latency from Team Dynamics to testing G domestify all aspects of a software

7:39 career this book is well named it really does feel like the missing guide book for the whole industry you can get the book at Eng guidebook.com or search for the software engineered guide book on your favorite audiobook platform I hope you'll enjoy it can we talk about this for a second because you know your path like our path could have not been more different you know just uh to recap like you both of us went to University right like we actually went to the same University I'm the older brother so I was two years basically ahead and then both of us did some side projects on the side we actually did some side projects together which was kind of fun SL interesting we built some some apps and then when it came to graduation I went into a Workforce I kind of you know went as an employee as a new grat to a consultancy then a larger company and

8:25 then you know like even even bigger companies in the Indi at Uber and you started off as an entrepreneur to start with you started off your startup it was a small startup then a mid-size startup and then it got acquired by a Skyscanner and then you became a a director of engineering when it was head of app product essentially had of app product so you had like a you went from like a two person startup or three person startup to a 30 person startup Acquired and boom you're inside a thousand person company so you said that it was kind of hard to get recognition and I'm interested in what happened you know this was clearly at Skyscanner you came in as you know you went from a running your your startup to an executive you know you were now so some very important funny enough we later both worked there

9:11 and you know I was like levels below you but what what what did it what did this mean in terms of you know like having to a little bit struggle to you know get recognized the same way as as you're kind of back and pierc did so it was very interesting on that side of things because there were two phases you know being at skyscreen I think the first part was our acquisition was mainly driven by the frustration or you know the desire to build a really amazing mobile experience so this was 2014 mobile was on the rise and the leadership at Skyscanner which was a Founder driven leadership you know clearly said we need to be very very good at mobile at the same time there was an understanding couple there that

9:56 they are a web firste company you know the entire generation of leadership was born in web and they need a different perspective who can propel them in that mobile first future so this meant kind of in the first year it was a lot about just do whatever you want to do uh and in the second year I think things a little bit changed because there was a new wave of leadership coming in from Amazon Microsoft Facebook other you know larger institutions and the primary goal of that leadership was to help scale the organizational structure of Skyscanner you you know to make it a world-class engineering team and I think this was where where very interesting things you know started to happen in terms of agreements disagreements you know what is important what is not important

10:42 senior achs coming in uh you know setting up metrics and and you know trying to measure output and performance in ways that that I didn't feel are the right way uh to measure those things it was interesting because I've been pushing back a lot and I think the moment I start having deeper discussions with the engineering leaders again you know very very senior ones coming from big companies I think there was a realization of oh my God this is an area I am completely unequipped to to deal with so for now I won't go super deep inside of that but eventually I think a lot of the behaviors through again competency Frameworks uh you know measurement of trer uh you know General

11:27 engineering principles and treating the engineering organization as which needs to work along the same set of principles every engineer propagated into you know the app team uh and and the organization as well which led to a lot of different things on how we viewed uh you know performance how we looked at through put and who who was seen as someone worthy of a promotion yeah so in indan you learned the big company ways yes yes and and I learned tons uh and and for me it was an amazing educational experience because I've seen a lot of things and I think I could really build up because of this a lot more solid understanding of what I believe is right more likely what I believe is right should always be

12:13 dependent on the context so I got a lot more graner understanding of there's no right way of doing things there are certain problems which have certain ways of solving them yeah Al although I remember when you know earlier before you joined SC and you were a lot more straight you're like no this this is this is the only way this is the only way that that we can do that course but you you never lost that you know you mentioned you know one thing that both of us were a Skyscanner for a short time uh a different organization uh made made sure I I didn't report to your organization and indirectly to you but I I remember that there there was always a focus when whenever I went over about like you know when when we talked about like mobile development like with with you or or

12:58 people on your team it wasn't really about the usual stuff you know like uh code quality unit test coverage uh cic deuil times it was about user experience how smooth does it feel how fast is it how many Taps do you need so you kind of kept this this Focus even as you started your next startup right that was a mobile I iOS first startup craft craft docs how and by that time you've seen them both you've seen the back end you've seen the front end what did you decide to bring in from day one from engineering on how you've built this this startup from scratch yes so I think the the biggest takeaway I had there

13:45 is there if you want to create a really amazing product you cannot really have one engineering culture inside of the company uh and this is very interesting right because when we look at for instance companies like apple they are a very you know UI first uring culture if you'd like and but their backends and their web services and you know all of those are terrible and then you look at Amazon and Google who are you know very strong you know system design and you know back and inuring principle driven companies they cannot seem to create you know meaningfully good or fluent you know UI experiences of course you know by the measurements they are there but when you use them they still don't feel com and what I thought at the time specifically

14:31 as we've been creating a piece of software that was meant to be used hours a day uh like you know even today it's used you know our average users use it two three hours a day that you just cannot compromise right you need to make it feel very fluent but we are dealing with data important data in terms of you know what you're writing how you're thinking which needs to be synchronized seamlessly very fast you know local first so I think this was the first thing I set of we're going to have uring principles for areas that touch data right uh because we need to ensure there's zero data loss we need to ensure those are very fast super efficient you know anytime we can switch parts um and we don't really need to innovate there

15:17 if if you know what I mean I mean we need to refine a lot of things but but it's something that with the right approach we should be able to measure iterate and work on and then there's the using in part of the things where you know what we set out to do is essentially we start creating a hypertext editor for mobile right now A hypertext editor even on the desktop is fairly complicated uh you know there's no very strong established patterns it's not like you know a shopping cart where where kind of it's very trivial what you need to do so I knew it's going to require a lot of iteration and a lot of you know resets and figuring things out and and that's where I didn't feel that established engineering patterns in the

16:02 standard way of you know testing things code coverage uh you know com building you know even design components when you know tomorrow it might not be needed will be the right approach to that so so this was I think the the approach of it came out with is neither is better than the other right you know it's not I'm not saying that you know one type of engering is better than the other but these can actually very well complement each other it brings an organizational complexity of the question of okay but what is engineering then is engineering then one domain or two domains or do we call frontend Engineers design engineers and have them you know compensated differently but I felt very strongly about this coming out from there so so maybe let's start with the actual

16:48 architecture of of the app like when you started out I remember like you knew I want to build an IOS app which is going to be you know like you can take notes you can use it you can you can do what whatever you know it's like ever node Plus+ or or or you you know just a lot better than what existed and obviously you already knew at that point that there's going to be an iPad app at some point there's going to be Mac app maybe a web app what most teams would have done is you build an IOS app you then build a Mac app you build a web app okay the iPad I guess it might be the same code base so you now have three code bases and most teams would have just use you know existing native components what did you do uh and why yeah so I'm you know quite radical in terms of believing that actually everything we're

17:35 doing today and front-end engineering people could do maybe even better 20 years ago so you know when I when you look at the complexity tools of you know Photoshop or you know just you know even when I look at just visual studio right you know 20 years ago uh how complex it was and you know how well it worked um but sometimes I even go to these you know stores where they have these dos based you know blue screen windowing Management Solutions with all the keyboard shortcut UI so it's it's kind of a thing where I don't feel that there has been a significant Improvement in terms of our ability to produce you know user interfaces uh there somehow you know we still try to figure out how to

18:22 make them but there there hasn't been a significant complexity shift for me what was always though really really important is whenever I have an idea be able to execute on it uh and typically what happens is the closer you are to the core you know language pattern or the core you know framework elements the bigger control over you have what you want to do for instance if you can you know create Shader code you can create any type of you know very beautiful visual effects if you want to despite you know anything else for me and and just just clear shaders you know for those who are not listening this is what renders uh like 3D or even 2D things on on the screen

19:08 and it basically runs on your GPU right yep and for me I think this was a driving factor of I wanted to have that freedom and flexibility uh even if that comes with some sort of complexity later because that will allow me to find the right solutions for the problems I have rather than being constrained and there's another other important thing is the more high level abstractions and Frameworks you use the more time you spend figuring out the bugs and the things that those Frameworks are good at and allow or disallow versus actually building the things so it's almost like you know there's like Alo layout is a very good example which Apple introduced in 201 you know 13 14 I think you've been you know one of the early adopters

19:54 of Auto layout inside of Skyscanner which promised you no longer need to to think in rectangles right you no longer need to specify that this label goes in this rectangle you can just say it should be at the top the problem happens then is you know it's very easy for one label but when you keep adding more things the complexity increases so when you want to do something more sophisticated it can become very performance intensive or you change one thing and the other change starts to fall apart I guess so for those who don't know iOS and auto layout or how layouts work could we just explain like what this is and why Auto layout was a big deal for developers and then you know the tradeoffs yep so you know back in the days you know I an iOS generally

20:39 has this principle coming back from of it gives you a canvas which you can draw on which comes with a lot of advantages but disadv the other disadvantages is you don't think of components of a stack let's say where you just pack things in stack like in the web browser but you say I want this view to be on the XY z00 coordinate I want it to have a width of 200 pixels and a height of 100 pixels uh and this worked very well because early iPhones had all the same sizes right I think the iph same resolution right the same resolution and I think the iPhone four or five was which you know became bigger and that's where essentially you would have to start defining rectangles of I want this rectangle to be the width which is 20% less wide than the enclosing container and that's where

21:25 Apple said why don't we do something more elegant where you just spe ify you know this should snap in the middle and it can you know automatically magically grow and what happens here is the layout engine calculates all of these run times so you have a more abstract syntax that is easier you know to understand and Define but when it comes for instance to animations to edge cases you lose control because all of these dynamically calculated things will end up with something so it's a lot more implicit way of you know defining how you want things to look rather than being very explicit about this is exactly what I expect you to do as a layout element yeah so you're trading off a lot easier

22:12 to Define and work with as a developer and more complexity on the device and just less control when you want to do like more advanced of as you mentioned animations and in the early days it could feel jerky laggy sometimes it would like go up and down up and down up and down but they fix that part right well they didn't they didn't because still when I run you know simulators you know Apple error messages coming from their internal components of you know the compiler couldn't figure out the layout so it's just you know falling back to something else so there's always the more complexity you add in your slave of what that engine can do you're a slave of what it can resolve and you know the more complex it gets the less likely it can resolve it in a in a reasonable set of time it got better but I still think it's it has you know

22:57 significant challenges in side of it so you you never opted into it right you always said like let me choose the complexity and just to keep control no it this is in the story so every time we hire an iOS engineer they're like you guys are ancient right why don't you use these new technologies for a while it was all to layout now with swift UI and what I always do is I you know show them one of our Transitions and say if you can do this with the same performance and auto layout we're switching to Auto layout and I've done this at least 10 times and you're always like yeah sure like hell I can some of them even succeed but then when you look at the code and I tell them okay but now change this to that and they're going away for two weeks and they still couldn't figure out how to change that I'm like you know here that was two minutes to do that's

23:42 when I say okay you know this technology is not for us so it's not about resisting things it's about what I said does it limit our capability to innovate and does it limit our capability to express things in a reasonable time frame versus does it you know feels simple at the start but actually when you're at the bleeding edge of what you want to do it's holding you back I think that is the main you know part of what I'm looking at one interesting thing that you also did on top of not necessarily on boarding to these system components is how you organize your code so you you you mentioned that you have one code base across mobile iPad desktop and even Vision Pro and

24:29 as I understand this is not normal even in the iOS world or in the in the kind of apple world right usually there's different code bases and they reuse some parts of it why why did you decide to do the same and U you know like what upsides and downsides it have yeah so it's very interesting so I think we are you know the only app of this complexity which actually has the same code bases not just reuse components it's like 99% the same code base uh with you know some you know native bindings of each platform which are required to do that and the reason we had that is you know when I started craft I said we want to do a hypertex mobile editor but we had this thing where mobile products shouldn't be just companion tools you know a big chunk of the world is mobile

25:14 only and if we build the right software like these mobile CPUs and gpus are now so fast there's no reason why you cannot have the full software there maybe except you need to you know think about it differently because what happens is most companies try to shrink that down their their desktop product into Mobile and try to cherry pick which functional you want to have there and which not so for this was a really important thing that our desktop app always does the same thing as the mobile app and of course what better way is to do it than having the itself a shared code base um but I think you know what originally when I started craft there wasn't this technology which enabled you to run UI kit code on the Mac uh so when people were asking me about a desktop appy we're like you know maybe sometime we

26:00 want to get it right on mobile first and then around in 2021 Apple introduced this thing called ma Catalyst which again essentially allows you to write Mac apps with iOS you know you know components and and code layouts because Mac used to have a different you know rendering engine and layout engine different API as well different apis and all sorts of things and you know with the introduction of the M1 processors made sense because suddenly instead of it running in a simulation as it had with the Intel based processors it kind of runs down natively so you get the same performance benefits now the big problem for us was of course is Mac apps tend to look and behave very differently than iOS apps right so technically we

26:45 couldn't really have any examples of what is the right way of doing all of these uh you know responsive designs at this Fidelity so with Fields native on energy platform so I think that's where our our you know belief and we treat everything as a canvas made a lot of sense because we could build a toolbar that looks on the Mac like a Mac toolbar and an iPhone like an iOS toolbar or we could build buttons that again you know adapt to those behaviors and I think we spent like a good two years of trying to understand how to structure our code our components to get the most reusability and and be able to truly fulfill this vision of let's say you know just building the feature for both

27:31 platforms will always take a little bit more time but I think for us it's just like 5% more time rather than saying 50% more time as we optimize for both can we actually look at what that means uh if if you if you could show you know just the the UI and just show us you know what some of your your own components are and then maybe how how it it connects with the code I think actually you know the toolbar is a good example so I'll just you know first show you visually what I'm going to talk about and then you know what are the benefits so right in applications this you know top area is called the tour bar where you have the tab bar uh you have buttons and all sorts of things like that and first of all you know we wanted to have a lot more flexible tabbing experience but also we wanted to have you know specific capabilities like Focus mode

28:17 where you have this you know immersive experience so you're hiding everything and then you know there was nice animation there right can you do it again yeah yeah I can do it again so everything you know moves in the same time and then you know everything comes back to the same time now for most native developers doing this is kind of what you would call impossible I think when I showed this to Apple Engineers they themselves asked how can you do this like it's it's not why why would they say that you know what makes it so challenging on most things it's you know like it's it's a nice animation right just saying as someone who's seen it it is really smooth but you know it's an animation right yeah the problem is if you use the default toolbar you cannot hide the default toolbar anim it you can definitely not say what curve it should hide with right so even if you hide the

29:03 sidebar you know the toolbar is going to animate in a different you know sense so you won't have this consistent feeling but again as I said we treat this as the canvas so everything you see here is kind of owned by us drawn by us we can just say hey toolbar move out in that perspective um so that is what enables this and a lot of people think that hey this must be you know super complex because you know recreating such a you know foundational thing as a toolbar you know is super complex so you know I'll just take things show a little bit about you know how the code looks like it's you know in this time frame it might be a little bit harder to you know understand but but I'll give my best to highlight the foundational parts so kind of a lot of our you know back in the

29:49 days craft was still called lokie so a lot of in the code we have still the old code names but this you always have code names right like every single company has code names yeah yeah so essentially you know here we have kind of the toolbar class and you can say that we needed to and we could Define you know some custom you know capabilities like in the toolbar we might want to show your profile you know display or we might want an iPhone specifically it's important to have a bottom separator but you know when you scroll we don't want to have that you know do we want to show let's say the title of the page or inside of that and you know there's you know some of these part of things and but but then when you you know run through the code itself it's fairly similar right we have a bottom separator we have a blur material so at the

30:35 background of the toolbar has this nice little blurred feeling a done button we have this real-time cursor area where you know you see all those faces popping enough a who's editing it you know some other revews like the title the left and kind of then it's like you know some basic command handling we use of you know what happens when you know somebody does something uh but I go through this this is the layout code right so this is what I talked about of it's of we're saying it's kind of ugly because this would be more and this is when I'm saying of hey we're saying the right area should be you know in this rectangle and I'm doing the calculation of this rectangle but it's again you know it's drawing a rectangle so it's not super complicated I mean this is what what the code will probably be for a native component as well roughly if we

31:22 looked inside of it yeah and again it's like 600 lines but kind of none of of those lines are really cognitively you know challenging so we have Junior Engineers coming in and you know in the second day doing changes to this so it's it's a very interesting thing because again it's so this is where I come back to a backend engineer a season you know staff engineer will come look at this and say I mean where's the you know magic inside of here and I think the core part of is is you need to do a lot of iteration to get you know which components you build and how right uh but then you can reap a lot of the benefits without having a super complicated thing and the other really good thing is it's like having an open source Library you can actually modify

32:08 right because what I said we're not working with close Source compo components or even codebase that is just so big you know even let's say you're using a a complex you know framework even if it's open source you're afraid to modify it because there maybe so many side effects is everybody is free to go in and do the changes and they can understand the impact of those changes very easily and so when you're saying like open source you mean like open in terms of for the team to change because now you internal open source if you will y yeah because most of the components you end up using native components or whatever like if you use a native toolbar you cannot really modify that at all you get what's in there yeah but this is this is really interesting though because I feel there's a very big divide between backend and kind of

32:54 client sidef frontend Engineering in the sense of you know as a backend engineer it's kind of like obvious that a you choose an open source Library uh you might also just rebuild a lot of things from scratch it's it's there just this given thing that you go in and change you Fork the library and you might make changes or try to submit them Upstream whereas for I worked on both sides when I worked with mobile Engineers it was like oh you kind of you just take the component that comes from Apple uh or or or from Google or or you know jet brains and you look at the API what you can do you try to tweak it and and that's it uh I I I wonder why this is uh do you think Apple might have something to do with it you know they have a very strict way they they don't take contributions you can you know raise a even even if you

33:40 have an obvious bug it takes so long to resolve you have to raise in their ticketing system and they might or might not look at it but they're the only ones who can uh do it yeah I think this is a lot about you know a lot of the communication of and engineering companies who build tools for fronted Engineers are about we're going to simplify this for you because it is complex okay so a really good example is there are things which we call virtualized lists right so what's essentially means is you have a list of 10,000 items you cannot create the 10,000 views because that's going to be very slow so as you scroll you detect which views should be on the screen and you only have let's say 10 you know views on the screen at a time and every time one of it disappears you know kind

34:27 of you purpose it and and people are very afraid to create virtualized lists because they say oh it's so complicated and I'm like what is so complicated in understanding of which view is offscreen and then reusing it adding it to an object pool and putting it back and they're like yeah but you know Apple's you know UI collection view or whatever you know list view has so many things it can do I mean yeah it has so many things it can do but which of those things actually do you need right now and you know then why cannot you write that itself so I think frontend engineering is a little bit like you might have thousand things a you know control supports right it can support you know small text Big sext big text you know

35:12 this background cve that you know touch keyboard handling whatever that is and that is a lot of work um but assuming that you're going to need all of them isn't you know probably the right thing to do but also then because you never actually end up building lower level Cod you always just end up using these you kind of lose your capability to to create these uh very often front-end Engineers will become an expert in their own domain like you know react Engineers know how react works but they don't necessarily understand the underlying you know Solutions again in backend Engineering in the university and everywh people learn about how databases work at the core you know what do those mean and they can repurpose that we don't learn that about you know frontend

35:58 systems so there's a lot more I think fear of doing anything custom and what that might resoled in this episode is brought to you by augment code wish your AI copilot actually knew your code base augment code is different augment is built for professional engineering teams working on complex systems not hobbyists building to-do apps other AI assistants struggle with context augment understands your entire code base architecture pattern dependencies and all we're talking instant understanding of systems with millions of lines of code in under 200 milliseconds teams like webflow lemonade and Kong use augment to ship better code faster no more context switching no more generic suggestions just an AI that

36:44 works the way expert developers do fast and in flow plus with Enterprise great security and zero training on customer code you can trust augment with your systems start building with augment in your favorite IDE and see what it's like when an AI actually understands your code try it free at augment code.com pragmatic when we talk about front-end systems one of the things that most companies would do is they would uh if you're talking a mobile app or web app create a design system you know like this is i' I've seen this so many times that at Skype Skys scanner every company there's blog posts about it here's our new design system uh and this is usually a pretty big undertaking but it it might involve creating custom comp components you're using system components Etc uh

37:30 what is your design system if you even have one do you have one so we have systems but we we have a very different design system that most companies will do and so what most companies do is there is this called Atomic design system where you start with base colors as you know atoms and then you have buttons which combine you know colors and shapes as you know components and then you build you know bottom up from there and this has been very efficient and Design Systems started coming along when there was this saying that design needs to have a cxo seat at the table and kind of since you know most CX like a like a SE level so Chief design officer basically yeah Chief design officer or just kind of design starts saying we need a seat at the table yeah and they found this very

38:17 common language of you know systems and components because engineers and again you know high level Executives and tech companies were often engers in the past rather than just saying like we feel this looks good right they could have this shared language of how this looks good and for companies which have a very established brand identities and guidelines which is very static this works well and also it works very well for scaling quality right now we all know that scaling quality versus improving quality or you know innovating are two very different systems so for instance you know I expect every front-end engineering craft in 2 minutes to be able to create the exact same button we have because what is the

39:02 button we have it's a rounded rectangle with a six pixel Corner radius eight on iPhone with you know this background color and this font size aign center now creating that doesn't require a PhD what we do have systems for is you know more sophisticated you know parts and these are for instance animation right so in animation we figured out that it's not about the I mean you need to tune some parameters but really what happens is you animate multiple things at the same time and the consistency of that experience so it feels as one movement and every movement is harmonized together it's like because it's this visual moving it's like a dance right so

39:48 when you look at a team Dance Competition if the dancers move in the same time it looks good but as each one of them move in the different time it feels terrible uh so for us you know having an animation engine an animation library that synchronizes everything across everyone and we enforce usage of that you cannot do anything else is something then I think there are other things which are you know quite important for us because you know we realize some things that I think I might just you know show my screen here share my screen for a minute and and then just to be care when you said like it's like a dance and multiple things need to move this is because do you animate like often everything on the screen like all your components right well you know when an area grows others need to shrink

40:35 right so it's kind of you have a fixed window size or when you change that window size everything needs to adaptively fill that and in craft everything is animated so I think this is also a very interesting thing of I think we're the only text editor where for instance when you enter a new line right or you know remove something the entire document animates it's not jumping you don't have this but rather everything you know flows down so animation and everything by default like the bottom bottom like uh the the bottom like document for example it also moves down like you know that's that's going to be right right in the next paragraph and you know everything like you know companies shy away from animating these because it's

41:21 harder because the built-in and also the built-in components don't allow to do this easily or or nicely right no they do not okay so I'm starting to see that you're like did you know you're going to get all this advantages by building your own stuff or did it just happen so what we knew is when you draw on a cus you decide what you want to do so I think this is the point of you know when you just think about something where you have full control over everything you know you can do whatever you do and five years ago I didn't know I want have this type of Animation or you know that type of thing but what I wanted is to set up the environment in a way where I can do it if I want it uh

42:07 and I think this is a lot about having control over the basic parts of the system which enables you to do these and then it enables you to often do it very cheaply because often you can hack it into existing systems but then those modifications if they go against the original design principle of that system it feels terrible it will be buggy hard to maintain and so on so then you said you don't have a designed system but you have systems like an animation system yep and we also have you know some behaviors or components that we identified are generally relatively hard to implement but we want to use them in multiple places like one of the things we realize is if you look at you know this part you can see that the this the you know the

42:55 question one doesn't fit what most you know front end systems will do is they crop the label and put an ellipsis now what we realize is yeah what we realize when you put three dots you lose two characters right so if this were an ellipsis I wouldn't see the O and the N I would only see up to the question and we found this both better aesthetic and you know more useful because in Mobile and Tiny spaces those few characters matter so we created a behavior which you can attach on any label and then instead of you know it cropping itself it will have this nice fading out experience uh and also it's it's a little bit more complicated because it needs to work against any background because craft uses these tinted backgrounds it takes over the document color and the likes of that so

43:41 it's um it has complexity to create on its own you have dark mode as well right yeah we have dark mode light mode you know transparent backgrounds it's you know color is quite complicated um and that's why we create this once and build it in a way where you can attach it to any label you have in the application which means again you know for engineers it's very easy to create these delightful experiences they because they can just take something and tweak it easily so what one one thing that's interesting about craft is it's it is as as you told me before it's personal software uh it's it's very kind of you know you work with your own documents with your own own stuff uh and how how what what difference does

44:29 this make in how you engineer the application what opportunities does it give you you mentioned things like like local first and you know like what how does it impact the architecture back and and front end yeah so this was something that I keep learning and relearning all the time so it's very clear I think that new technologies emerge on the server side and for a while it wasn't clear for me uh of you know how much of the things we do can be local versus how much of them need to implement it on the server side so we have you know quite strong teams on both parts and I think that's need in the long term what very important is is when you're dealing with personal software usually the amount of content

45:15 you're dealing with except for binary files like videos and media but you know raw content that can fit on the user's device uh which is very interesting because when you're looking at you know B2B software where there's you know a thousand you know individuals contributing to that is there's no way that's going to fit on your device um now this is something very interesting because then if you think about it a lot of the computes can be done locally which is also interesting because how your cost space you know will you know move across those things and also what I'm seeing right now for instance llms and AI is something that we're saying is like it's no way it's going to be on device but you know just in the recent weeks we're seeing signals actually in a couple of years that might be also available yeah so one of the things

46:02 we're building is we're building every service in a way and wrapping them in Architectural Components that we can replace them to Local or remote components anytime you know we feel uh now it's possible to do our not without significant infrastructural changes and this also has impact on how we architecture our backends right so for instance a very concrete example would be search now the traditional way of you know when you have you know let's say craft has you know more than two million users is you have a big let's say elastic search cluster right all of the you know users data is indexed in that elastic search cluster uh and you know you have logical separation but you don't have physical separation now the

46:47 problem is what if you just want to change you know the search algorithm for a few users or improve that and things like that it gets complicated so what we're looking at is could we you know have two million search indexes on a disk you know in the cloud and every time somebody does a search you know either they can download that search index locally and use it there to execute the search or if we cannot download it because it's too big maybe a you know Lambda or a serverless function can just read the search index and based on that execute the search for the client that's needs to do that specifically for API use cases or you know uh you know whatever headless you know capabilities we want to implement this might be very helpful but thinking about how we can replicate and use the

47:33 same infrastructure across client and backend is something you can only do when you're looking at personal scale data and it's kind of impossible to think about when you're looking at very deeply interconnected you know thousands of individuals in the same data set yeah and like it's interesting because like you mentioned local Computing until now the the traditional thinking was that yeah you should do every compute on the web because you have very thin clients it might just be a web page even it's if it's a mobile device it doesn't have much Computing capability but this is all changing isn't it I think it's always a ping pong right you know and this is what we realize when you're long enough in Tech it's you

48:18 have Cycles right we used to come from you know the Central Computer with terminals then we came on to with the pcer of local Computing then we went back with cloud of everything is computed in the cloud you know from websites being server side rendered and now we are seeing a think a new wave of personal Computing and I think it is powered by also processors getting a lot faster like I believe the M4 Pro is a faster processor than anything you can buy on an AWS Cloud so and and if you can use those resources for it to execute code only for you and you as a user have an option to upgrade your level of service because of local Computing that is interesting so I don't think it's ever going to be black and

49:04 white it's always great I think they're they eventually people get tired of their own computers holding them back and they enjoy you know server site components enabling them and then they start feeling bad about how much a server site project costs and they want to have that power on their own computer so it's a pendulum swing and I think now we're starting to see a lot of interest in moving that ownership of you know being able to decide the performance I want to have to my computer versus to the cloud and but I guess this this can also help with for example just pricing just you know right now we're in the end of zero interest rates have ended efficiency is a lot more important it's harder to raise money basically it's it's not really feasible to necessarily have lose money on on uh on services but

49:50 if you can do this and you you switch it you might be able to for example offer software where it's free or very cheap uh or like a one-off payment if use local and if you want to use the server okay well then you know it'll be a monthly fee of of this or that right like like that theoretically this could be an option but only with with local compute in the sense of not losing money on it well I think one of the big challenges is underlying operating systems are changing a lot faster than they were and consumers expect even free software to adopt to that so yes you're right on the on the on the hosting perspective our biggest challenge is every time Apple Rees a new iOS version it's like you know one and a half months of the full engineering team just to make it sure it's bug free and if we don't do that even free customers or one-time payment customers will be very upset that we're not updating the

50:37 software yeah I I I hear you one thing you noticed is one thing you mentioned is local first and now this is this is I I feel this this technology is making a comeback or a surge what is your honest thoughts on on it like does local first actually work for these uh you know like personal software categories or or is it still in its infancy so local first is a very interesting thing because for it to make sense you need to have a very high Reliance on the content you have there because really the value of local first is when you don't have 5G on your devices you can still access that information and I think local first is is now experiencing a comeback because

51:22 people are starting to travel again right when they're on their airplanes they're on the tubes uh and it gets very inconvenient when you need something badly and you don't have it um but I think it only makes sense for a very small subset of products out there right so it's very interesting because for instance craft is local first but um when adding comments we could do it in a local first manner but we figured the ux would be very weird of you see a Content you post a comment on it when you're on an airplane three hours later when you land you know the comments get added but at that there might be other comments added which make your comment feel super weird from a social perspective so I think for us it's very important because we store some of the information you

52:07 always want to have access to Independent of when that is uh but there aren't that many software categories which actually you know need to provide that with users for how opinionated is craft and and in generally personal software uh compared to you know one thing that strikes me about craft you know I've been using it since the alpha right like this the advantage of being there it just feels very kind of different you know you have these uh gestures I I don't know maybe you can show some some of them that it's just doesn't exist like and you know you're pretty opinionated and and craft seems pretty much I wonder if this is unique to to craft or or do you see you know more

52:54 more startups personal soft for potentially doing this and and actually you know it it being a good thing is it a good thing do do people like it you know cuz I I like it but I'm I'm never representative of you know the the broader audience so I think when it comes to personal buyers and personal software it's very much around you know when you think for instance pricing so businesses are do what they call Value based pricing right so they say that hey this problem cost me $1,000 if you can do it for 900 it's a win for me consumers are a lot more emotional or an ing around this uh so different mental model and also when looking at software to use since software is now mainstream it's not in early adopter phase everybody in the world or like most of the population of the world uses software

53:40 extensively a lot of the effect of consumerization in general I think taking place and I look a lot at inspiration of nons software categories of what that means and when you look at some of you know the success stories in shoes like you know I like to run so specifically I look at running shoes and there are new brands popping up and they are very opinionated about what they represent and you know what are the values and because the objective performance isn't that difference between shoes or it's very very hard to measure consumers choose a lot more on which one they feel resonates with them or which you know is around that and again software is becoming cheaper to create right we have a small team we

54:26 create a complex software other companies out there can do the same independent from the technology I build something in three months you know anybody can probably build it uh so it comes back to a lot around what you choose to put in front and you know what you choose to emphasize in you know your way of doing so with shoes that might be shapes and forms and colors and in productivity tools it might be certain features or the way you access those features or the way you store your data which are going to be very important for consumers so I do see this thing yes of in personal software you need to be a lot more opinionated in B2B I think a lot less or or big buyers will tell you what they need because they know what they need and you need to be able to

55:11 fulfill that that's why B2B softwares tend to become complicated because everybody needs something and you add 50 buttons and it keeps working because they have what they need in consumer I think it's it's personal software it's it's it's different than that and how is what what is crafts kind of opinionated or or or or values or how does it come across in in the the app you can also share if you want to if you want to like show some visual examples because it is pretty visual as well right it is visual but you need to touch the product so I think this is kind of when we talk about our values it's a lot about how craft makes you feel and I think all of the animation and the custom Solutions all are built so we can fine tune how the software makes you feel because again

55:58 like we believe a lot that the software use every day will influence you know you uh you know I think for this audience a very good example could be we're trying to build what Visual Studio code is for engineers but for you know knowledge workers in the sense of Visual Studio code feels lightweight after all of those super heavy IDs which were you know non-expandable and slow and and everything Visual Studio code was a fresher breath air which you are just happy to be in because it's responsive it's fast it you know does everything you need integrated and of course for you know non-technical people there are slightly different angles that's where animation fluidness you know visual customization you know makes a lot of sense but that's how I could you know

56:43 you know bring uh our type of positioning closer to this more engineering focused audience so you you built craft with a pretty small team can you tell me how what what the size of of the the team is and and then also how many people built for example the the the iPhone the Mac apps yep so we have our product engineering team is around 20 people uh this Ines you know product engineering design and uh and QA and we don't really have product so it's mainly design engineering in QA well you you are product no well kind of design I I think you know design has an overweight in product and and of course I do product as well um but kind of then then we have but just to confirm you do not have a a

57:29 dedicated product manager role no we do not have a dedicated product manager role no uh and and we're split now on platform teams so this means we have a web team a native app team and a backend team and each of those teams are like three four people uh so and that's kind of it uh we tried to scale up um but it didn't work out I think uh you know one of our parts problems of scaling up is we try to be a lot more systematic and a lot less flexible and at the iteration speed we want to grow I think our decision would have been either to grow you know fivefold and then we can reap the skillability benefits but we ended up in this interim situation where we were neither flexible and fast enough nor structured enough and it was a kind

58:16 of a bad place to be so we find this you know around four up to five people platform teams understand the context are resilient you know they can step in for each other but can iterate very fast and it also puts a constraint on us on how complicated infrastructure we're willing to build because of course if you build complicated stuff maintaining that requires a lot of effort and we we don't really we only want to do that if if the trade-offs are very attractive like it's something truly special that our users will really love so like you're saying there's like three or four people building the I the IOS app and then sorry the the whole code base all all four code bases I iOS Mac iPhone and iPad and even Vision Pro yes yes so on the native appside people

59:03 who are writing Swift Code it's only kind of three four people that's surprising to hear but also I guess encouraging that it it does work and and can work and you're saying that in your experience the smaller team worked better than the somewhat larger team because of was it Communications overhead iteration disagreements what what made it more challenging so what happened s is when you have a team over five people right the communication starts to break down so then you ideally want to split it to two teams and what we did at the time is we had you know more than five people in each platform so we said let's move to feature teams you know typically what companies refer to it so each team has a specific goal they work on a specific feature they execute on that but we lost those

59:50 holistic capabilities of everybody having full access to the full codebase if you if you get what I mean of you know what I showed if you want to create a focus mode it's super easy because you just go down to the root and you know change that and it works um and also these teams being you know not having sufficient team members from the same platform while you're working on that slowed it down a lot so we notice that a fellow iOS engineer can help a fellow iOS engineer better than a fellow web engineer or backend engineer and that is what creates these very clever Solutions when multiple people from the same domain have different ideas and they do understand the business context we're providing a lot of context and we really

1:00:36 focus on every team fully understanding that but then they can really understand their technological limitations and how they can come through that which for us increases velocity a lot and the composition of of the team is is mostly so if I understand mostly it will be of those you know like 15ish Engineers about like four or five backend and the rest will be mobile front end Focus yes yes which is interesting because it's usually again for most companies just even even mobile focused companies it's usually the other way around at Uber there were more backend Engineers than the mobile Engineers so an interesting interesting twist but I'm I'm glad that it's working it clearly is now what

1:01:21 advice would you give to front-end or mobile Engineers who are really passionate about about what they do they love the craft they you know they they love building these things but they do feel a bit stuck uh both professionally they're just not getting ahead the next promotion will not be them they they will unlikely to be the team lead or or U if if they want to go into engine leadership it looks really hard what could they do to be taken potentially more seriously and to be able to take this this frontend and and use her focus into a bigger organization have a larger impact yeah so you know it's very hard for us front and danger to talk about if I do this project we're going to save a million dollars right it's it's it's just not possible to

1:02:08 articulate in that sense uh so it's a lot about how you know it makes people feel now what the thing I do I still do this as CEO today a lot is what I call building prototype apps and I put it in the hand of decision makers right when I

…