Balint Orosz is a designer-first engineer and founder of Craft, a note-taking app that won Apple’s Mac App of the Year. He sits in an unusual space between hardcore backend engineers and pure designers, having spent his career focused on user-facing experiences, animations, and mobile-first product design rather than distributed systems or infrastructure scaling. This episode explores how he built Craft with a tiny team, why he rejects common engineering conventions like Auto Layout and design systems, and how he thinks about local-first software, opinionated product design, and the role of AI in frontend engineering.
What it’s like being a UX-focused founder in a backend-dominated world
Most CTOs and tech founders come from backend backgrounds, which shapes company culture toward measurable engineering outputs like unit test coverage, CI/CD times, and infrastructure cost savings.
Balint’s engineering focus has always been on the user-facing side: making a button respond in 2 milliseconds instead of 10, creating smooth animations, and crafting mobile experiences.
This made him an awkward fit in both directions: backend engineers didn’t see him as one of them, and designers/product managers didn’t fully claim him either.
At Skyscanner, where he became Director of Engineering after his startup was acquired, incoming senior leadership from Amazon, Microsoft, and Facebook introduced competency frameworks and metrics that favored measurable backend impact, making it harder for design-focused engineering leaders to get recognition.
He pushed back on these frameworks, which led to deeper discussions with senior leaders who realized they were unequipped to evaluate design-centric engineering contributions.
The experience taught him that there’s no single “right” engineering culture, but that context matters enormously, and he became more nuanced in his views while retaining his core convictions.
How Craft was built: architecture and engineering philosophy
Single codebase across all platforms: Craft runs on iOS, iPadOS, macOS, and Vision Pro with a ~99% shared codebase. This was a deliberate choice to ensure the mobile app is never a “companion” to the desktop app but a full-featured product in its own right.
Apple’s Mac Catalyst (introduced around 2021) made this technically feasible, but Craft still had to build custom components to make the app feel native on each platform (e.g., a toolbar that looks like a Mac toolbar on macOS and an iOS toolbar on iPhone).
The team spent about two years figuring out how to structure components for maximum reusability across platforms, eventually reaching a point where building a feature for both platforms takes only ~5% more time rather than 50% more.
Why Craft doesn’t use Auto Layout or native components
Auto Layout trade-offs: Apple introduced Auto Layout to let developers define constraints (e.g., “snap to center”) instead of hardcoding rectangles. While easier to define, it calculates layouts at runtime, making it harder to control animations and edge cases. Balint argues it’s gotten better but still has significant challenges, and Apple’s own error messages show the layout engine failing to resolve constraints.
The test he gives new hires: When iOS engineers join and question why Craft doesn’t use Auto Layout or SwiftUI, Balint shows them a smooth transition animation and asks them to replicate it with the same performance. Some succeed, but when asked to modify it, they struggle for weeks, whereas the same change takes minutes in Craft’s codebase.
Custom toolbar example: Craft’s toolbar can animate in sync with the rest of the UI (e.g., hiding everything for a Focus Mode), which is impossible with Apple’s native toolbar because you can’t control its animation curve or timing. Because Craft draws everything on a canvas it owns, it has full control over every pixel and animation.
The toolbar implementation is ~600 lines of code but is straightforward enough that junior engineers can modify it on their second day.
Why frontend engineers are afraid of building custom components
Frontend engineers tend to rely on closed-source system components (from Apple, Google, etc.) and are discouraged from modifying them because they can’t contribute upstream and fear side effects.
Backend engineers, by contrast, are accustomed to forking open-source libraries, reading source code, and modifying internals.
Balint argues that many “complex” components (like virtualized lists) are simpler than people think, and that frontend engineers lose the ability to build low-level solutions because they always work through high-level abstractions.
He sees a knowledge gap: backend engineers learn how databases and systems work at a fundamental level in university, but frontend engineers rarely learn how rendering and layout systems work underneath.
Craft’s approach to design systems
Most companies use atomic design systems (atoms → molecules → organisms) with base colors, reusable buttons, and bottom-up component libraries. This works well for scaling quality and maintaining brand consistency.
Craft doesn’t use this approach. Instead, it has systems for specific hard problems:
Animation engine: A custom library that synchronizes all animations across the app so everything moves in harmony, like a dance team. Engineers are required to use it and nothing else.
Fading labels instead of ellipsis: Rather than cropping text with ”…” (which loses 2 characters), Craft built a behavior that fades text out, which looks better and preserves readability in tight mobile spaces. This works against any background, including dark mode and tinted backgrounds.
The philosophy is to identify behaviors that are hard to implement but needed in multiple places, build them once, and make them easy for any engineer to attach to any component.
How Craft makes everything animate without feeling jumpy
Craft is a hypertext editor where every change (adding a line, removing content) animates smoothly rather than jumping. This is extremely rare in text editors.
The animation system coordinates multiple simultaneous movements: when a line is added, everything below it flows down in sync. This requires owning the entire rendering pipeline rather than relying on native components.
Native components don’t support this kind of fine-grained animation control, which is why most apps avoid it.
Local-first architecture and personal software
Craft is local-first: all data lives on the user’s device and syncs seamlessly. This matters for users who work offline (on airplanes, tubes, etc.).
Personal software has a key advantage over B2B software: the data volume per user (excluding media files) fits on a device, enabling local computation and reducing server costs.
Search example: Instead of a centralized Elasticsearch cluster for 2+ million users, Craft is exploring per-user search indexes stored in the cloud. A user can either download their index locally or a serverless function can query it, making it easy to iterate on search algorithms for individual users.
Balint sees a pendulum swing back toward local computing as devices get faster (M4 Pro is faster than most AWS instances) and as companies look to reduce cloud costs in a post-zero-interest-rate environment.
However, local-first has limits: social features like comments don’t work well with local-first because of weird UX when syncing after being offline for hours.
The value of opinionated software for consumers
B2B software tends to accumulate features because enterprise buyers know what they need and demand it. Consumer/personal software succeeds by being opinionated about what it represents and how it feels.
Balint draws an analogy to running shoes: performance differences between brands are minimal and hard to measure, so consumers choose based on emotional resonance, values, and aesthetics.
Craft’s values are expressed through how it makes you feel: the animations, the fluidity, the visual customization, the responsiveness. He describes the goal as “what Visual Studio Code is for engineers, but for knowledge workers” — lightweight, fast, integrated, and a joy to be in.
He believes personal software needs to be more opinionated than B2B software because consumers choose emotionally, not rationally.
Team structure and why small teams work better for Craft
Craft’s product engineering team is ~20 people (engineering, design, QA), with no dedicated product manager role. Balint and the design team share product responsibilities.
The team is split into platform teams: web, native apps, and backend, each with 3-4 people.
The native app team (3-4 Swift engineers) builds for iOS, iPadOS, macOS, and Vision Pro from the single shared codebase.
They tried scaling up to feature teams (cross-functional teams focused on specific features) but it didn’t work: communication broke down, engineers lost holistic understanding of the codebase, and velocity decreased because iOS engineers help iOS engineers more effectively than cross-functional teammates.
Teams of 4-5 people who share a platform domain understand the full context, can step in for each other, and iterate fastest. This also constrains infrastructure complexity, since small teams can’t maintain overly complex systems.
Advice for frontend engineers who want more impact and recognition
Show, don’t tell: Build prototype apps and put them in the hands of decision-makers. Let them touch and feel the experience rather than trying to objectively describe the value. Senior leaders are good at recognizing patterns when they experience them directly.
Prototype example: At Skyscanner, Balint would build a prototype, put it in the CEO’s hand, and say “this is what we could have — do we want this?” This was far more effective than slides or descriptions.
Use AI to speed up prototyping: AI tools (especially reasoning models like GPT-o1) can help frontend engineers explore complex problems much faster. Balint used AI to solve shape recognition for Apple Pencil input (detecting circles, rectangles, triangles from hand-drawn strokes) in 3 hours instead of the 1-2 weeks he had originally estimated. The AI gave him an algorithm he didn’t know existed, and he iterated on it by describing failures in plain language.
AI is also opening up shader programming (mathematical GPU code) for engineers who don’t have deep math backgrounds, enabling new visual possibilities.
Why Balint still writes code as a CEO
He gets intuition and positive reinforcement from being close to the product: seeing user feedback and acting on it directly.
He believes he has rare skills at the intersection of product, engineering, and design that would be very hard to hire for, and that being able to connect deeply across all three domains helps him steer the team toward more efficient and pragmatic solutions.
He acknowledges this is unconventional for a CEO but says the team is fine with it, and it makes both the product and himself more satisfied.
Rapid fire
Favorite programming language: Swift, though he has a soft spot for Objective-C because of its fast compilation speed (several times faster than Swift due to fewer type checks).
Best design tool: He doesn’t use design tools at all. He sketches at a very high level (basic rectangles) and then goes directly to code. For web prototyping, he loves Tailwind CSS with hot reload in VS Code as the fastest prototyping tool he’s found.
Book recommendation: The Hard Thing About Hard Things by Ben Horowitz. He found the concept of “management depth” (comparing managing underperforming employees to technical debt) particularly insightful for translating engineering mental models to human systems.
