Building great software always involves technical problem solving, but the best software goes beyond function. It feels fluid, coherent, and genuinely fun to use. This quality lives at the intersection of engineering and design, and very few teams know how to reliably produce it. Metalab is an engineering and design studio that has worked with some of the most successful companies in tech, including Apple, Slack, Uber, and Instacart. This studio is known for bringing together software engineering and design craft in a way that BU studios can match.
Wesley Yu is the VP of engineering at Metalab, where he leads the teams that design and build digital products for early stage companies. In this episode, Wesley joins Josh Goldberg to discuss how Metalab approaches tech stack selection for client projects, why agency worked a man's bias towards boring and stable technology, how iterative development and deliberately ugly apps lead to better final products, and how AI tools are changing the boundary between design and engineering. This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript-ESLint, a powerful static analysis toolset for JavaScript and TypeScript.
He is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling, find Josh on Blue Sky, Flostodon, and .com as Joshua K Goldberg. With me today is Wesley Yu, VP of engineering at Metalab. Wesley, welcome to Software Engineering Daily. Thanks, Josh. Really happy to be here.
Well, we're happy to have you. Just to start us off, how did you get into coding? How did I get into coding? This is, I have very humble beginnings in coding. You know, in 1999 or early 2000 or something like that, there was this browser game called Neo Pass, I don't know if you remember NeoPads, but essentially you care for these like virtual pets called NeoPads, and you have this virtual currency called NeoPoints, and you can create store funds and sell items and stuff like this during this currency, and they allowed you to edit HTML and CSS, and so as a kid, I just kind of copy and paste stuff, change the text around.
It's a great little custom store for my NeoPads, so that's how I got started, very trial and error. I'm just a kid at this point, of course, so I'm not reading like W3C documentation or anything like that, but that's how I got started. That's lovely. We have a lot of guests who played NeoPads and went there. Do you remember how your store looked? Was it good?
Yeah, I mean, it looked very kind of early 2000s, CSS styling, a lot of sparkles, a lot of banners and things like this, text moving around. Yeah, that's good time. Good time. Let's move forward a little bit. So you know how to code shoutout, NeoPads. What comes next? How did you get into professional software development?
Yeah, I think in high school, I created some static websites for me and my friends, and we built little sites for things that we were interested in. We built like a little fandom page for Neon Genesis Evangelion, which is a very formative anime for me, but it wasn't really till college that I started putting some of these skills to work to pay my way for schooling. Like many people that came from Non-Dricional Pass into software engineering, I built WordPress sites for small businesses essentially. And for whatever reason, I didn't really make the connection between coding websites and my path in college and university. So I didn't actually study software engineering, I studied business and media studies in university.
You've done quite a few things. You were a talk show producer. Did that mom and sort of check in? What was that? Yeah, yeah. That was my first job at a university. It was a radio news producer.
So essentially, that's finding interesting stories and guests for AM news talk shows for people's morning commutes. And around this time, I think it's kind of around 2010 or something like this. Lots of startups and tech were hiring people from media and journalism to become content marketers. So that's what I did. I got out of radio and then I landed this job as a content marketer for a tech startup.
And that's kind of how I got my start in tech. I was immediately thrust into Y Combinator with this startup. And this was around 2013. And so we went down to Sunnyvale, California. And I was just surrounded by this ambition and energy of tech in Silicon Valley at the time.
Do you feel fond of memories about the way things were back in the day, 10 plus years ago? Oh, yeah, of course. I don't think I'd be able to do it today, but we all shared a house down in Sunnyvale. I slept on the floor, like in the hallway somewhere. We had our living room, which is just set up with a bunch of computers that people were building things.
And I was writing a big blog post at the time and things like this. So a very fun time, lots of ambition, lots of excitement. We really felt like we're building this tech utopia for the future. That's lovely. That really is idyllic. It sounds nice.
Yeah. But moving forward, you are now a VP of engineering. So somehow you switched from content marketing to engineering and leading engineers. How did that happen? Yeah, yeah. So working for this company a little later, I think I decided, man, these programmers in tech, they seem to be having a really good time building stuff.
And so maybe I want to do that too. Maybe I can try to put some of this HTML and CSS knowledge to work. And so I enrolled in coding bootcamp and I learned for gun rails and then I'm really got my start in Metalab as an intern. And Metalab being the company that is, I think you've spent long enough there, you get a pretty good education from some of what I think are some of the most influential companies in tech, like the slacks and coin bases and Instacars and Ubers of the world, was kind of how I learned my ropes in the industry. Do you remember that being particularly difficult or easy to switch over that kind of mental model and set a communicating through words and communicating through code?
Yeah, I took the coding pretty easily. I think my brain just works that way. But I think I specifically found some more success in agency and specifically in Metalab, just because of the background that I have in communication, breaking down these complex topics and processes and trying to communicate them to a lay audience is a very valuable skill, I think just in general for software engineering, but especially in agency when you may be working with people that are not so focused on the tech but more focused on the business of the part that you're building. That's really interesting. We should focus a little bit on Metalab and agency work. What is Metalab and what is the difference between agency work and let's say a startup or traditional established company?
What is Metalab? Well, Metalab, I think the way that I put it is we design and build digital products for very ambitious companies. I think we come in to help really early stage teams to find their product DNA and then they later become household names or we hope that they do. But our strength is very small cross functional teams in design and product engineering solving kind of problems for a small business. I think I've worked in houses well and I think the difference there is that you're less defining the business and trying to find a market in some sense, but you're trying to optimize some part of it.
We've already gained traction in this business and now we're breaking it down into its component parts and then making the whole workflow more fluid, more scalable. Let's take an example. You've already had quite a few notable names like Slack, Uber and so on. Let's take Slack because I quite like Slack. What would you do for a company like Slack? Why would they come to you and what is the kind of service that you would provide for them?
Yeah, I mean for Slack specifically, they had already built this communication system. I think everybody kind of in the industry at the time was using a tool called HipChat. When I was at the startup and where the concept marketing, that's what we use for internal communication, HipChat. And when Slack came to us, it was positioning and branding to differentiate themselves in the market from these stock standard chat applications. And to revitalize this tool with some joy. And so it was less engineering when we were working on Slack. It was more, well, what does it look like?
What does it feel like in terms of UI and UX because the functionality of Slack was already baked in there. You're talking about things that not a lot of engineers can go to, like look and feel. What do you mean by feel? How does someone approach that for a product? What do I mean by feel? From an engineering perspective, like feel is how responsive does the application feel?
How much intention can you draw from the user and actions, how they're moving the mouse to the screen? I think a specific example of that is like if you're hovering over a channel, we may send an event to the backend and say, let's preload that channel so that when you move over to that channel, all the content is already there and it's lightning fast. That's what we think about feel when we're talking about the engine inside of it. But when we're talking about the design, the experience side, it is Slack still has this, but we kind of have the ideation for this in the early days. It's this idea of the Slack bot, but you're loading a screen. Slack will have some sort of funny message that it says and you can customize those messages.
That very little business value to that type of feature, but it brings you a lot of joy when you're using a tool like that. Another example is like if you type something into Slack, Slack will do some sort of Redjacks and then it will automatically post a message. So we might say nothing to see here and then Slack bot will respond with that GIF of Aimsimson, Homer, Simson, and I kind of like walking in and out of most bar. Like these types of fun things. We just didn't see another application spec then.
And now they're not Slack standard, but they're a lot more common. Why aren't they common? How are companies justifying spending the time to make these lovely little things? Yeah, I think we have this benefit of people coming to the middle app that really care about the design and experience of the thing, they care about the joy of using the tool and not so much just a function of the tool. And so we can self-select into the companies and these people that care about these little experiences, these little surprises and the touches of the product that are not just functional aspects of it, but aesthetic aspects.
Let's say that I'm a company, I have a product and I don't have a lot of delight or joy in the product. Let's say you really wanted to work with me. How would you try to convince me that it is worth it for my business, for my users, for my bottom line to employ metal app to add more Simpsons GIFs and such into my product? How do we convince you to add delight into your project? You know what? I think that when people come to us just because of our reputation, they don't really take a bunch of convincing.
In fact, we need to convince them out of some of these moments of the light in order to get the core functionality in place. It's like, okay, the trade-off of adding this delightful feature is the omission of some functional feature. And so we sometimes have to argue for the functional thing over the delightful thing. But yeah, we're in this great position where people come to us and by default, they want this type of experience for their applications. Let's be nice having people come to you because they want to enjoy what you're able to provide an advocate for.
Yeah. Yeah. All right. So we talked about the high level what is. I want to dive in a little bit more into the tech stack side of things.
You're an agency, which means you might not be controlling your project for a full decade the way the client company might be. So how do you make decisions around engineering knowing that you are more of a short-term player in a long-term kind of game product? Yeah. I think the longer that you work in agency, the faster you settle into choosing the most boring, stable technologies for your clients. When we were a much smaller, much younger shop, many of our clients were people that had a business idea, but they didn't necessarily have strong opinions about technology.
So a lot of the technology choices back then were driven by what we want to learn, what we want to try in production. So in like 2010s, we're still largely a rail shop and we were using the hottest JS frameworks to ship more and more client side codes. So I think we tried everything under the sun back then. I think we were very hipster and using coffee scraps and we were trying to knock out JS and hember and backbone and things like this. And very early adopters of React and GraphQL using Facebook's relay project.
Anyway, it was this type of experimentation that I think actually landed some of our biggest clients. So we worked with Walmart for 10 years doing design development across their whole digital footprint. And that contract actually started because someone at Walmart was using backbone and our CTO at the time, Jason Webster, was an active contributor to the project. And so they're like, hey, we're using this technology, you're contributing to this project, can you help consult for us? And that became a 10 year long relationship.
People say open source doesn't really pay, but in our case, this partnership gave us some pretty reliable revenue to take risks on smaller projects and startups in the early days. And some of those clients became run away successes. Do you have a favorite fun hipster JavaScript thing that isn't around anymore that you wish were kind of more prevalent? That's a good question. I was a big fan of Meteor back in the day.
Like I was just, I thought it was like the JavaScript version of Rails is how we put it. Like you could just build something super fast. That's not around anymore, but I wish it something like that was. Let's say that I'm a client and I have a business idea and not much. What would be the framework for decision making around tech stack that you would give to me?
Or how would you help me find the right tech stack for my project? Right. Yeah, we have it down to a pretty straightforward decision tree. I would say one of our team members actually just turned this into a CLI tool that you have a little conversation with. Like you answer a bunch of questions and then it fits you out of tech stack and it does a bunch of boilerplate stuff for you.
But we typically select tech stacks based on the needs and capabilities of the client and the product. And really in that order, it's like what is the client capable of maintaining and then what does the product actually need? So for the client, we ask the question of what technology does their team already have scales in? And then what technology can they reasonably hire for in their geography? And I think this geography piece is kind of important.
This is more anecdotal. But when we work with companies that are European based, they typically want backends that are written in Java based frameworks. So like spring and more commonly spring foods, just because that's what their universities produce. And so this is kind of part of our decision making as well. And we care a lot about what technologies actually energize the technical leads of our client team when we're choosing these things.
Because I think a staff decision is not just a technical exercise. It's also a hiring plan and an onboarding plan. And what does it mean to support this thing at 2am in the morning? That all goes into selecting the technology that we want to use. And then when we're evaluating on the product lens, we think about speed to market.
We're building iOS and Android applications. We look at cross platform tools if speed to market is a big concern and understanding what the performance requirements of the application are using cross platform buys you a bunch of calendar time. But I think that native still wins when the product's performance is still a core to the product. Does this mean that you hate to expo or hate an extra yes or any of these other tool chains? No, I actually love them.
And they're like a core part of our technology stack. I think expo has come a really, really long way in its time. And yeah, it's made things far easier to develop and react native. Hopefully that will have been the closest to a gosh or question you get during this video. I really like how you're phrasing not just the technical values of different areas or text acts, but the longevity of them and the way that they interact with the people and the organization around them.
Like the 2am tradeoff is different than your garage at 4pm. Do you have sort of a decision tree subtree for when you might prefer something new and shiny and maybe better suited to a problem rather than the tried and true and more well-known approach? Yeah, it is, I think, more rare that we would choose something that is unproven unless the client is really advocating for something like that. I think we build a lot of MVPs that I love. And so our preference for building these kind of first versions of products is a modular monolith.
And I think when we're trying something new, specifically on the back end, we like to build little side cars and we may use new technologies for those side cars. So if we need really fast, real-time, WebSocket behavior, we might use something like a Lexer or Phoenix in this side car and it's more isolated as something that you can change around. And it's not so integrated into the entire stack that it would be challenging to replace. And so we like to limit risk, consolidate risk into these isolated areas. Let's move up in scope a little bit.
You were previously a grand level engineer. Now you're VP of engineering. What does that mean at an agency or doing design agency work when you are leading engineers? How do you lead a group of people who are pulled between such different projects? Yeah, it is at the level that I am right now, especially for an agency.
We look at a lot at the pipeline of clients that are coming in and we try to find efficiency with the pipeline, trying to match the skill sets and capabilities that we have available expertise and industries that we have available with the clients that are coming in. And so we may be doing a lot in dating or in healthcare. It's like, OK, well, we want to leverage that experience that we have on current projects and future projects. So it is that coordination sometimes. So we may think about industry in that way.
We also think about tech stacks. So our team works across lots of different tech stacks. You may be working in React Native, or you may be working in Swift or React. We kind of like to chain projects so that you've built a ton of expertise in React Native. You've built all these efficiencies.
We're going to try to put you on a React Native project as your next project. Maybe in the same industry as well. And so we can do lots of issues that way. So this type of organizational efficiency is a lot of my concern. See, that's interesting.
I would have expected the if you've done React, continue to do and react. But within the same industry, why is, for example, dating or healthcare as an area of projects nice for people to say working in these apps, not very different? It's nice because specifically with healthcare, there are a limited number of EHRs electronic health records systems. And we have our preferred EHRs that we like to use when we're building healthcare applications and things like this. And the analogy that I like to use when I used to develop a lot is that I would work on a Rubeun Riles project.
Rubeun Riles has all these magic methods and functions and get it, and then you move away and go to work on a node project. You come back and you just forget a little bit about all the intricacies of this framework that you're working in. I think it's the same when you're working in different industries as well with platforms that we commonly use implement things, specifically EHRs. You just have a sense of where the edges are and what all the different solutions are. And when you come back to this type of industry in a year, you do kind of lose some of that reflex.
And so that's why we kind of like a chain of these types of projects together. That makes sense. I might imagine that some industries have very important specific gotchas like healthcare with HIPAA laws and privacy and whatnot that you really want to make sure you don't forget between projects. Totally. I want to ask you a two-part question here.
There are some skills that tend to be better for certain kinds of work. Like let's say there are skills that may be better for short-term or external projects versus skills that perhaps are even opposite of those that are better for long-term or internal projects. Do you see anything in particular that someone might want to understand being better for one type of project versus the other for let's say a ground-level engineer? Yeah, I think unlike the individual or contributor front, people have different defaults. I think that metal I'd be working on a lot of initial builds, MVPs.
And that process is a process of iteration. And so I think a really great skill is being okay delivering an ugly app. An ugly app is you build out the full flow from start to end and the screens that you build in between. Sometimes they just render JSON and a button and you're able to move through. And you iterate that process.
You work with design to say, okay, this screen is JSON. What is the best user experience to present this data that we have on the screen? And I think that can be a hard thing to overcome for some developers because they are more focused on perfection. They want to know how is it going to feel? They want to present the best version of themselves in the screens that they build.
And I think that's a hump that you have to get over when you're working very iteratively for these startups. And you need to be okay with delivering ugly applications as opposed to something that is more refined. How do you know when an ugly app is okay? Are there types of clients that will react negatively even though it might be the technically right strategy at the moment? Yeah, I do think that clients appreciate the ugly app, but you do need to prepare them for it.
Like we do a sprint demo and they're like, okay, what is this text on the screen that I've seen that has all of these weekly brackets and things like this. But what they appreciate is being able to move through the whole experience and then being able to reorder some of those screens. And you do start to see the project comes to life. The screens start to be refined. We go from JSON to wireframes to some sort of mid-fidelity that doesn't really have brand applied to something that is high fidelity.
And I think what is valuable showing that process is they get a sense of the speed and complexity of each of those features. But when you show just the final product, clients, they don't get that education. They don't understand all the work that led up to this beautiful thing that you're seeing at the end. But we like to open up the curtain when we're working with the people that we work with to show them the process because it is also part of the value of working with Menelab. We want to help build the DNA of this process that we have of building applications.
And it must be nice to be able to see the iterations that make adjustments to the DNA in progress, right? You're not just giving them one final thing and calling it a day. Yeah, exactly. And I think you get to see the gaps or the shortcomings of the initial idea or approach when you're able to see something end to end. Right? But there you start. You just have to think, okay, well, what if we change this?
I feel like it could have a feel better because it's easier to see the next step ahead of you once you've done the first step. But when you're trying to get to the end and you haven't accomplished any of the steps, building one chunk in a perfect way, one after the other gives you less room at the end to make adjustments. So that's why I like to build these ugly apps. More ugly apps. This kind of matches a large trend over the last decade or two in history, though, right?
That we aren't doing waterfall style development. We're doing agile with some sort of iterative strategy to allow ourselves to see these gaps and learn as things are coming along. Yeah, that's right. And I'm a big fashion and textile nerd. And I think the analogy that I like to use is it's like drape tailoring.
Like you hang a piece of fabric over a body and you start to tailor based on how the fabric hangs. And that is like a far less repeatable process. Then creating a pattern and then cutting that out and then putting it out a body. You really are pushing pull things as you're building it out to kind of perfectly tailor it to the solution to the body that you're working. And I would describe that as the iterative approach, whereas when you are cutting on a pattern that is very much the waterfall approach.
That's a beautiful analogy. Everybody is different. Every person's preferences and experiences and even year to year, their needs are different. It's kind of a beautiful way to think about software. Speaking of beauty, I've heard other people describe projects that they take from inception to completion as their babies.
You know, that's the common phrase. This feature is my baby or this app is my baby. A lot of people feel a sense of sometimes approaching what they think is parental instinct or affiliation or love for their projects. Do you think that in the agency world you have that or is it harder to develop that when you're working on so many different projects? No, we definitely develop this parental instinct.
You know, and maybe different from other agencies, we made a decision that if you are working as a developer on a project, you are working on one project at a time. So that your full attention is on this thing that you're building because of the iteration that we're doing, because we're defining a business for a client. It's hard to split your time across lots of different things between lots of different contexts. So you do very quickly become very attached to the thing that you build. And when it comes time to hand that project off, slowly back to the client's team or maybe we help them hire a team to maintain this application and rebuild the V2 or build the V3.
That can be quite hard. You're interviewing this person and you just want to make sure you're finding the best foster parent for this thing that you build. You want to make sure that your values are aligned. And then sometimes they're not and they'll look at the application and say, you know, I'm going to change this to that in the other. And it's a little heartbreaking sometimes because it's not always easy to convey all the steps of the process that got us to where we are today to this person that's going to take it over in the future.
Because everyone has their biases, everyone has the ergonomics and which they like to work in the code. And so I'm very much becoming these parents for these children that we build. This might be relevant for many different areas of engineering. Do you have tips for handoffs to make sure people understand why things were made the way they were? My biggest tip for handoff is to work with the person that is going to be working on this project as early as possible.
And so we don't like a cold handoff. A cold handoff is we have no idea who's going to maintain this thing in the future. And so we need a lot of comments in the code. We record a lot of video walkthroughs of the code base and leave a lot of documentation and readme's and lots of little directories and stuff like that. That's like the worst case scenario. I think you can only convey so much through documentation.
What we like to do is we like to run three or four sprints with this person so that they understand the way they work. They're in the P.R. reviews with us. They're making some technical decisions with us. And then this kind of gradual, what I would call like a hot handoff or warm handoff to projects.
So my biggest tip is, yeah, as much as possible, work with a person that is going to be maintaining this thing. That's not always something that we can do, but that is our preference. And we always kind of advise our clients to make those hires early. So that's the decisions that we're making are aligned with the decisions that better than faults, kind of the biases of the person that we're going to be working with in the future. That's an interesting use of terminology.
You just said the word biases, which much like tech that is often kind of a negative word or a bad thing in the industry, but you assigned it seems no negativity to it. It's just a fact of life biases in tech. I think so. Like, you know, everyone has kind of ergonomics to the way that they like to set up their desk or even their desktop on their computer, what types of terminal commands they like to use, how they like to navigate it. You know, those biases are either good or bad, but when you start to ingrain these types of things into a code base that you need to see every single day, it can be a little bit grating when you're looking at something that doesn't feel ergonomic to you.
And so that's how we like to involve the person that is maintaining this thing. We want to include their biases in this process because, you know, we know we're not the ones that are going to be meeting this long term. We want to set this up in a way that it's well with them. This is kind of part of draping a cloth over a body. That body is not just the business or the product, but also the people that are going to be working on this in the future.
That makes a lot of sense. So far, we've talked a lot about the engineering and the tech stack side of things and then the kind of clients to everyone handoffs in and the way all work together. I want to switch topics a little bit for a little bit to talk about the design side of things. You are particularly integrated between design and engineering. How does that look for you folks and how do you integrate designs so heavily into your process that it comes out really beautiful and delightful?
It is something that we are figuring out still. I think, you know, we found a way to do it through like very specific artifacts. And I think that the most important artifact for us for collaboration between design and development is, I guess what we described as a service blueprint. So service blueprints is all the different user actions, all the different back and actions, all the kind of back office things that need to happen from the start of the application when a user first authenticates a creates their account to the end of the value chain of this thing. And that's the thing that we align on first.
Okay. What are the core experience where the big beats of this application and how are they supported by technology and what are the user behaviors and tensions that are driving those things. And we come up with that process really, really early in our projects. Sometimes we make an estimation of what that might be when we're estimating or scoping something before a client is even come to the door and sign a contract with us. Just so that we have a really good sense of how we're going to hang different behavior, how we're going to hang different interactions onto this product once we have something that we can collaborate on together in this artifact.
It makes collaboration far easier. One of the analogies that I like to use is the analogy of producing a season of television. And so when you're producing a season of television, the writers come together and they think about the big beats of the story that they want to tell over the season. And there's no dialogue happening right now. There's kind of characters that are going through different arcs.
You just know, okay, this event is going to happen and then this event is going to happen. We're going to tie that through the story. And then you start to write the episodes. You go, okay, now we're going to do episode one, cold open, act one, go. And the design teams, they know where they're going and the engineering teams, they know where they're going because this structure has been put in place.
And so that's, we follow similar structure when we're building applications in that level. The second very good analogy you've given, do you personally find yourself jumping to analogies as a form of explanation when you have a really good one at Thready? I think it's like an instinct or reflex from, you know, my AM news, radio production days is like, you need to be able to translate complex ideas and complex topics and like processes into things that people, they already understand or they're already internalized. And I think analogies are good. They're not always one to one.
Like sometimes you can just completely butcher an analogy like you try to take it too far. But I think they're really helpful tool for getting people into the space of thinking about things in the right way. How do you manage the internal handoff then from the early stage folks to the later stage? Like in your analogy, the folks writing the beats of the story to the folks writing the dialogue, even for the same person, there's kind of a different way of thinking about those two areas, right? How do they inform each other?
Yeah, our teams that start projects, you know, we do, you know, a phase of discovery, understanding the industry and then we do a phase of what we call product definition, which is creating the beat to the story. That team is usually pretty small, but then we grow that team. And so, you know, we're not changing out those folks. We have a very kind of clear through line from the start of the project to the end of the project in these leaders that conceive of the idea. They're the ones taking the idea through execution as well.
So they're rolling the boulder up the hill in these first two phases of discovery and product definition, and then they're rolling the boulder down the hill when they get a larger team's implement thing. Just how to personal level do you prefer at either side of that hill or particular areas of Boulder, Pershing? I mean, rolling the boulder up the hill is always the hardest part. And I think it is hard, but it is also the most rewarding in my mind, because, you know, you have to be very comfortable with being in, you know, very messy ambiguous parts of a project of a business, not really understanding your users. You have to try to understand those.
You want to understand, you know, what their problems are. You don't really understand the dynamics of the business yet. And so that's not really hard. But it's also where you learn the most about an industry about people. And so it can be hard, but it's very rewarding.
The other side is also fun. I, of course, have gotten away from the actual implementation of things for a little while. You know, there's a joy to any of code and solving very technical problems. And so, you know, my preference, of course, is rolling the boulder up, but rolling the boulder down has its own choice. You get into the flow of things a lot more when you're rolling a boulder down the hill, kind of like skiing downhill or something like this.
Yeah, yeah, momentum behind it. Exactly. Yeah. Not to say that rolling down the hill is a straight path either. I think like sometimes you get little bumps and sometimes you have to roll a boulder up a hill to get down the other side and things like this.
To quilt, pull, and ski every comparison lips. Yeah. All right. Sometimes in product development, there is a beautiful design that has incredible value. This is really a lovely thing for the client or user.
And then the cost of it is obscene. Do you have particular strategies for dealing with incredibly beautiful design that would take three years to implement? Absolutely. We see this all the time. I think one example of this behavior is that we're building an application for collectibles.
And one of our designers is a big magic thing gathering collector. As my love mentioned gathering, he's like, I want to build this experience where it feels like you're flipping through this binder of cards. You know, want to create that experience with an application and then we show it to our reactative developer. And he's like, I don't know how we're going to do that. And so the process there is very collaborative.
They're sitting right next to each other and our developers are like, okay, these are the constraints. This is what I think that I can do. And then the designers poking through the application and this prototyping is like, well, you know, I like this, but could we do it like this? And then it's thinking about really pushing the bounds of creativity on the engineering side. And it's through this process of iteration that we land on something that is in between this crazy binder experience that the designer has in their mind.
And then, you know, what is easy or what is kind of the default for, you know, a reactative developer to implement? And you find somewhere in the middle and they really challenge each other in their respective disciplines. Training card games like magic are so interesting from a product and design standpoint, right? Because they're a thing that inherently is tactile that you, as the player, derive a lot of joy from, you know, flipping the shuffling index that, you know, saving draw at the end of a long match. But then you have to turn an electronic.
How do you just from a designer product standpoint, how do you capture that joy and magic of a tactile thing in the electronic form? Yeah. Yeah. Every interaction needs to have some sort of physical reaction tapping on something produces some sparks or something like that, like, kind of have to build the physicality back into those experiences. I think you provide some examples about when you play the game and things like this and shuffling deck.
But I get great joy from opening a booster pack and like revealing the cards and things like this. And so we have to try to make that kind of as pleasurable experience as also like a visually stimulating experience because that's kind of what you have to work with. We tried some stuff like with haptics and things like that. But I've always found that when you're like opening a pack and your phone vibrates and things like this or the lights go off and they feel a little bit out of place. They feel like, you know, my phone is vibrating. I'm like, what is going on? Can't have anything to do with this application.
But that's why we kind of rely more on visual aspects of things. There's a lovely period of time with apps when people discovered that haptics and that every app interaction was vibrating. You know? Yeah. Just shake it.
Yeah. You also brought up an interesting point that I think is a very good segue to one of our last areas, which is designers and prototypes. A lot of designers nowadays are slowly starting to, in a sense, code with AI or other tools, you know, low code, no code, code generation. Do you see there being a kind of direction that you like or don't like with having designers create their own prototypes? I like it.
I think the canvas of Big Mac can only get you so far. It's not until you really start to click or tap on the interface that you understand the ergonomics of the thing that you're building. And so I really like the idea of designers prototyping things in code. I think we're getting to this place where we are trying to create the scaffolding of an application enough so that a designer can commit real code, reduction code to an application. And when it's a commit to production, you know, there is still the review process of a developer to ensure that it works.
There maybe is a complete re-implementation of what the designer has prompted into Cloud Code to produce the PR. But we're thinking about, you know, what is the scaffolding that we need to build? What is the baseline that we need to build in an application such that designers can get to a point where they're also prompting Cloud Code to create PRs. And some of that is understanding what primitives exist in the application. What does the database look like?
What functionality do we need to build in that a designer might not be able to prompt into existence? So that's until the application still functions end to end and they're able to add their touches to it on the UI UI level. Wesley, I'm a content developer. Can you please expound on that and help me feel comfortable that my job will exist in two years? I think that the important thing is, you know, not just prompting things and desistencing things into production, but when there is an issue with something, when you need to make a small change to things, you still need to have a code base that is suitable, that is inspectable, that you can go in and actually make changes to.
And so setting up that foundation, setting up that directory structure, creating clear boundaries between things, that is still very much relies on years and years of experience from a developer. And so I personally don't think that there is a risk to losing jobs and things like this. We just kind of, we have a new medium in which we're collaborating in. The canvas of Figma becomes a little bit less important. You may be drawing things on paper and figuring things out, but now the material that you're working in is less than Figma.
The delivery is less than Figma is more than code and I like that a lot. Suppose I'm a client and I'm thinking, well, yeah, everything you said is true, but also I could just use AI to figure out what are the delighters and figure out my new designs. So I guess from another perspective, say I'm a designer, how do you make me feel comfortable that my job will exist in two, five years? Yeah, we have recently been using Cloud Design and these design tools and Figma and NCP to get things from Figma and into code. You know, I think when you start to use these tools, you start to see the sameness that these tools produce.
And very quickly, you're able to spot, you know, as a human pattern recognition machines what was generated by AI. I think we're getting less good at determining kind of photography that was generated by AI, like we're full quite a bit. But we don't need to see too many examples of AI generative to understand that this was generated by AI. And once you're able to see that as a consumer, the value of that thing decreases a lot. And so I think there's still this human touch of this was created by a human and I can tell because like, nah, we would ever do this or there's this blemish to this thing or that's never seen something like this before.
That I think is going to be increasingly important. What we often see is that when something can be newly produced at scale or in a particular way, a lot of the time you get this counter or reaction area aesthetic right afterwards where instead of, let's say, large sheets of glass or saying this and buildings, you have these intentionally different or almost user word blemished things that bring joy because they are not the same as everything else. Do you see any examples of that in the wild with design or even code that you've come across? I don't have any specific examples to point to it. It does feel intuitively true that things that take higher effort to produce things that are not mass produced have greater value.
And so, you know, the blemish that I talked about are a bit of a marker that something was done by hand or conceived by hand and not purely conceived by some sort of AI machine. Love that very much. So what is your role? Kind of moving forward the next five, 10 years, either you or metal app in general? How do you see the world of design and product, perhaps even agency versions of that moving forward?
Now that we're able to kind of shift and make the act of designing or writing code to this sort of new AI enabled agent. My role is a little bit split. I think part of it is understanding what trends we should pursue, what we should build expertise in. And I think my biggest learning so far in the last year or two is that building on the frontiers is really hard and risky. You spend a lot of time building like the spoke things that you end up needing to throw away because the industry standardizes around some sort of tooling.
So, you know, some things that we have sunk like an massive amount of time into is you doffering works for LLMs. We'd probably use something like Langchain or Langfuse. You know, if we were to do it again, we wouldn't build something for spoke. But, you know, when we were starting on this journey, we didn't have those tools or those tools were more nascent. We experimented a time with MCP for, you know, when that specification first dropped.
And we created lots of custom MCPs like for Notion and Figma and things like this. And then of course these companies released their own MCPs later and they're better and we largely kind of discard our own solutions. But yeah, like that's kind of what it's like to build on the frontier. And so part of my job is understanding what should we invest in and then what should we just wait for the industry to figure out for us. On the other side of things, like, you know, on the non-tech side of things, it's kind of figuring out how to optimize our organization around tools that we have available.
And I think the analogy that I like to use is it comes from like a Japanese bakery. So, you know, you walk into a Japanese bakery, they've got dozens and dozens of different types of pastries and baked goods. And Japanese people don't like cellophane or anything around these baked goods when you're buying things. Like it's more joyous to kind of like walk through this thing and like pick off baked goods and put them on tray. But the problem with that is that you bring it to a register and you have this what you need as a very skilled person and then register to understand what all these baked goods look like to punch them into a castersster for you to check out.
And so what this bakery in Japan did was they built a vision model and they said, okay, well, you know, you're going to put a tray in front of a camera and it's going to calculate all the different types of baked goods and give you the cost you need to pay. And the job of the person at the register is service between, you know, human interaction between you and the customer. And that's the kind of experience that I want to build at Metalab over the next few years is, okay, what are the kind of non-human things that we can automate away so that we can provide a service and experience that is fun, that preserves the human aspects of working with other people? Well, we can leave the specification writing the documentation and the meeting notes to services that can summarize that can turn it into material that then turns into things that we want to build.
We want to kind of optimize for this conversation, this interaction between humans. That's where my focus is right now is, you know, using tools kind of like granola and turning that into tickets and linear and pushing and pulling things but having more human interaction is my goal. That's so interesting. By rolling out all these elements and agents and such tools, you're not increasing the amount of roboticness in our lives. You're actually decreasing it by getting rid of the existing stuff so you can focus on what's important. Am I interpreting that right?
Yeah, yeah, exactly. You know, there's a lot of busy work that you need to do to run a business and we want to do away with that. We can serve as the thing that are really fun. The really fun things for us is working with people. You might have already answered this second to last question, but what are you excited about in this new world within the fun stuff? What's particularly fun for you?
I love the old things. I love kind of, you know, lots of big lists of side projects and things like that I want to do. And so I think it's been incredibly fun to use these tools to bring some of those ideas to life. And also very quickly see where all these great ideas that have in the list are actually all bad ideas. I think that's kind of fun too.
So I think it's awesome that you can go to a tool just kind of at 2am on your computer. Nothing is quite as joyous as having a side project idea, getting to prototype it, learning why it's bad and realizing you're no longer beholden to that idea. You don't have to spend your time on it. Exactly. Exactly. Lovely. Well, Leslie, we've talked about a lot of really cool stuff.
I'd like to have an interview with one or two questions that are kind of palate cleansers, especially non-technical. I actually have two for you. First, and please explain this for people who don't know anything about Magic the Gathering. If you are a commander and you had to choose a set of colors, why are you these particular colors and what would they be? Okay, I am just all blue. I like to play Magic, but I like to be the only one that has fun.
So blue is this color that's each player and Magic gathering performs actions and try to whittle away someone's life. Blue's color is all about preventing people from doing things. And so you prevent people from doing things enough that you get a little bit of an advantage and you win the game in that way. And I kind of like that. Why are you like this? That's the worst option. The worst answer to that question.
I know, I know. I'm sorry. I don't know why I'm like this. It just gives me joy. Great. Let's move on to the actual last question. We talked about this before. I love people to hear about this.
What is Magic to you? And can you tell us about the art of performing Magic for people in front of you? Yeah, sure. Like one of my actual first jobs was my friend and I started a business performing Magic at Children's Birthday Parties. And this was right around the Harry Potter boom. And so we really rode that way. People were really interested in Magic back then.
And so yeah, we would really interested in buying tricks and we would perform Magic at Birthday Parties and then we would use that money immediately to buy tricks. And what is Magic to me? Magic is creating something that is seemingly impossible. But by doing it through means that no one would expect that you would put that much effort into. I think like a really good example is a type of trick called a book test. A book test is that someone chooses a phrase or a passage in a book.
And you are able to predict kind of what they have in their minds. And some of the solutions to the strict involve you marking up every single page of this book. So that you're able to look at a corner of a page and predict kind of what word they might choose or producing your own book that only has certain words. Like, no one would ever think that you would put so much effort into creating this gimmick. That's the magic to me.
The magic to me is all the effort behind this tiny interaction, this tiny moment of delight. And I think that's very much the same as coding is that you put all this effort into a single moment that they're like someone. But you don't see any of that stuff. You don't see the production of this thing. And that's what I love about Magic.
That's a lovely way to end an interview. We've talked about product and engineering and design, how it works collaborating across those in general and with the agency world of Metalab. Leslie, if folks were interested in you and wanted to find out more about you and your work at Metalab, where do you direct them on the internet? I would direct them mostly to Metalab.com. If you're looking for Metalab, you can find me on LinkedIn and search my name, Wesley U.
And you can find me on Twitter, just creep in and scroll in, do and scroll in on Twitter at WesleyCYU. Well, excellent. Leslie, thank you again for hopping on top of your day. This has been an absolute blast. Cheers.
Thanks, Josh.