# Panel - Building Dapps: How to Start and What It Takes

- Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup)
- Date: 2025-10-07
- Duration: 48:22
- Watch: https://streameth.org/watch/yt-pujD93QP1S4
- YouTube: https://www.youtube.com/watch?v=pujD93QP1S4

## Description

This panel gathers seasoned builders like Andrej Berlin, Elod Varga, Gabriel Stoica, Noah Jelich and Ovidiu Damian  to demystify dApp development on Ethereum. From selecting your tech stack and balancing decentralization with usability, to embedding privacy by design, leveraging open source tools, and harnessing community feedback, you’ll walk away with actionable strategies for launching and scaling modern, user friendly Ethereum applications.

## Transcript

Hello everyone. Hello. I hope you're ready. So, uh, next up we have, um, somewhat casual format, more casual format. We have some topics to go through, but more of a, you know, life experience, uh, building apps, DAPs, etc. And developer best best practices panel here. Um, I'll be the moderator and everyone will introduce themselves. Um, so, hi, I'm Noah. I'm uh I'm a security researcher and a software architect. Uh so yeah, I'll just be going through the questions sort of and providing minor feedback. Um let's go on Gabriel. >> Yeah. So, oh my name is Gabriel. I'm I'm working for a company called Emergentics. I'm leading the protocol development there. Um I'm doing a little bit of everything to be honest. I'm working on the smart contracts back end front end um heavy on the web3 side even though it's front end and back end and I would just add that I'm I'm I'm a true believer of bridging the web two and web3 gap >> nice thank you uh yeah agree with that um my name is Andre I've uh built out the uh product design collective called Deep Work been around since 2017 uh 2018 sorry and um worked with a lot of um web 3 teams, technical teams on their products, UX uh and user research and my personal experience is more in organizational design, product design and business management. And yeah, I I also really want to bridge the gap between web two and web 3. So this is this is the moment. Hey guys, uh my name is Alud and just for the context of it, I basically built a liquid staking dab on a small layer 1 EVM called Terraa from the ground up. So I'm really hopeful that I'm going to to provide you guys some very cool insights and then and then yeah, I work with a lot of layer ones and layer twos. So I'm really hopeful that yeah, this is going to be good one. Hello there. Um name name is Damian. I'm currently working for uh pi squared and basically uh working to bring verifiability in a much better state in web 3. But in terms of building in terms of building deps, I would say that what I'm bringing to the table is in terms of experience, I've pretty much whatever DAP you can think of, I've most likely tried building it at some point. Some I've actually built, some I've failed. But um Poly Market clone, done it. Um I don't know, liquid staking at some point done it. Normal staking at some point done it. NFT staking at some point done it. um NFD marketplace at some point done it different stuff like this I just like uh building stuff whether it's useful or not that's another talk that's for BD to decide for us it's to build >> okay okay thanks for the intros so yesterday we had a security panel and we talked about code smells and you know what can go wrong in the process and we were just you know criticizing developers right so um do do you guys use deodorant Right. Uh do you smell? What's what's the code smells? What are the pitfalls for uh for developers of the apps? Uh and uh what exactly let's say let's keep it split between actual code like solidity stuff and more like architectural like just try to make the distinction clear there as well. >> So hopefully we smell we smell good that's for sure. So um is that more a question like what we are actually doing on a daily basis or uh >> what what are some practices I mean at some point you were a junior and then you learned something. So what are the key learnings of the last x years that uh that you would like that you think can help people? So I think uh asking for for feedback from the early stages is like one of the most important uh advice I would get uh because we as developers somehow we tend to you know um hide all the complexities and and show that we know everything but it's not like that in reality and the fact that we are working in the you know web three space this is a totally new space it's evolving on a daily basis you need to be ready to learn new things and to admit that you know something that you know today might change tomorrow. So having this you know self-starter um appetite and be ready to change your mind and uh be ready to face failure and negative feedback because that's very hard to face. It's a critical thing. Um and from a non-developer perspective um and also agree with that maybe to add on it uh I think generally being open for collaboration is also pretty useful to think about because you because everything changes all the time and like kind of everything is possible. Competition doesn't really like make sense anymore. um being open to the opinion and feedback of other people in the context of creating something together I think is kind of a good starting point as well. So it's of course we get excited about cool new ideas but then also it makes them even stronger if we get to collaborate with others. >> Um I would say that you need to keep your files shorter than 300 lines. No, no, no. That's not it. That's not it. Um the like heaviest learning that I I really really basically want to take with my with me and I would do differently is if you as a team are not the user of what you're building that's already like a huge huge red flag. Um it's super super important to to just take a step back and uh we are seeing this especially in web 3 like all over the place. People who are actually building protocols they never used it. I swear like a lot of teams I I just had a talk with and they just they just don't touch their own product. It's impossible to build and to actually create something that the market requires without you actually being the the alpha tester and really the one that iterates and gets their like opinion built into the application itself. So one thing to not do which I've heard over the last few days quite a few times but I'll repeat it because it's very important is obviously don't expose your API keys. Um and in terms of in terms of good practices, I agree with what the others said, but in terms of in terms of good practices, um generally obviously use it as well for you. And when you are thinking about uh your user journey, where your user starts and where they want to end, try while your app is in beta, try giving try thinking who's your ideal user. And once you find that profile, find someone in real life that is that profile and give it to them. See and stay near them, kind of stalking them while they're using the app and see what they do. If you see they are having issues at a specific point, don't take it personal. Just rebuild that part or tweak it or whatever. But the point is they're going to be offering specific feedback that might be um that might be very useful in what you're in what you're building. >> Okay. Okay. Thank you for the answers. Uh okay. to sort of up the ante um let's move to more um sort of architecty questions. So uh when we're when we're looking at when we're designing apps right normally we just have this idea of we need to implement this business logic but with this whole blockchain thing now we have the question of which business logic is going to be in this public ledger system that is available to hackers and which business logic is going to be offchain which business logic is going to be bound by let's say legal contracts by by backend accounting etc. So where where do you guys you know draw the line? What is what is uh what is food and what is a pet? What is onchain? What is offchain to you guys? I mean someone else can uh start as well. You need to follow fixed order. Yeah. All right. So let me take this one first. Um, I think I I always start with a philosophy of drawing up the parts of data and the parts of business logic that really need to be on chain. And basically that's like a very very good starting point to actually iterate afterwards and see if there is any other critical aspect or any critical data that that would really be good for the user to to be added to that else how basically that that's what you roll with like this is warranted to be on chain keep it that like really uh onchain data and onchain tools are not there to be abused. Um, usually I'm seeing a lot of a lot of uh dabs just because they can they put things on chain. That's I think that's a very very bad design. And uh unfortunately with the with the like increased TPS that we are seeing this is a really really frequent and reoccurring thing that that is that is happening in the space right now. No, just keep it lean. Keep what needs to be on chain on chain. Everything else can go offchain. Now depending on what you actually do uh legal bindings etc etc that's up to the actual business logic itself. >> Okay. Okay. And like but this seems more of a let's say a hybrid app situation. What about pure DeFi apps? Like how do you do those? Do you treat those like fully onchain systems? Um yeah, I think when it comes to fully onchain systems, um the business logic and really the like the routing that you have implemented in the in the protocol itself defines like it gives you this this answer like the the moment that the moment that like you actually require that piece of building block for your business logic to make sense, you're there. Like you just can't get rid of it, right? Um and then and then yeah just keep it natural. >> Um I would maybe add to that that or like kind of remember that uh business logic is kind of about humans for the most part in terms of the uh result of it. So we're designing sociotechnical infrastructure and the socioeconomic behaviors co-evolve with the technology that we're creating. So, um it's a constant back and forth between understanding what is the value exchange and what are we um what are users paying for, what's the value that they're creating. Ultimately, they should feel like that exchange is fair and um how do we implement that in our um model? And and that's like if you're talking about like um legal frameworks uh or technical frameworks, it also depends on what you have access to. like sometimes you can't just um like you don't just don't have the resources to set up something that would um work in a specific stack or um in a specific framework. >> Okay. Anyone else wants to add? >> I I could add the fact that for example for the type of app where most of your uh most of your logic has to be on chain as you said like for DeFi apps. So for those even if most of it is um from my experience even if most of the logic itself is uh onchain most of the times you can add an off-chain layer that's helping with different things to scale the app like to for example sure you can have a DEX where everything is onchain but you can also add an off-chain layer that helps you speed things up like some index and some databases that back things up so you don't do as many RPC calls and so on And I feel like especially in the beginning when you start building stuff if you're a beginner it's tempting to put everything on chain because it's easy. But once you do that then going to the next level to actually build a scalable app you need to start thinking okay how do I how do I add a layer that's offchain so that things are scalable. So I don't have 1,00 RPC calls per second if users try to log in into my DEX at the same time. example. >> Okay. Okay. To sort of move on from this. So what what would be the ideal stack here now in 2025? What what is some of the ideal tooling for for that for you guys? So I think that everyone agrees that nowadays uh NexJS if if we were to take it from from the front end uh I would say NexJS for the front end side. For the back end I see a lot of you know projects building on NodeJS and NestJS. Um then for storage of course we see a lot of projects building using like legacy databases. We know that's like a hybrid approach and it's not a true decentralization. So for that we can use IPFS for example or even AR weave to store our data in a decentralized way. Of course for smart contracts I would add Foundry. Uh I think everyone agreed that agrees that right now is the most uh you know performant um development tool in terms of testing because we have uh built-in fuzzing support. Um and yeah we have things like indexers you know when Ovidu said we have uh tools like MVO the graph ponder which is uh full backend for web three apps that helps us indexing data and yeah I will leave uh the others for my panelists. Uh let me let me uh give you guys a bit of like a more radical approach to this because two weeks ago uh we had a talk with with the CEO of Adjust uh Paul Mueller and what you need to know about that like they're they're they're like a web two protocol but they are basically the providers that that enable any sort of ads on Facebook, Google, uh like whatever like when you when you get that uh popup with like that annoying ad on the on the bottom of of your phone that's coming from them. So imagine the amount of data that that they are processing. It's in in the range of pabytes on a month. Um and he had this this really really interesting uh concept for for tax text tax and I think it really really resonates well especially in the web3 world that if you're not working terabytes of au of data uh on a monthly basis then edge functions server functions uh microservices hosting different types of like back nodejs backends is just like unwarranted it everything like everything that I that I just explained to you in this enumeration could be served by a simple go backend on one machine and this is very it's like a very very powerful statement we have I think I think like you went through 10 different uh providers that are just enabling basically data rendering indexing and like of course frameworks for smart contract development but I feel like at least when I'm trying to build something uh I try to approach it in a minimalistic way because on the scalability side and if you really actually get the amount of users uh descaling this very very complicated stack on on web three is is like big big hurdle. >> Okay. Uh if I can add yeah I had this dilemma whether or not we should use you know multiple providers for you know doing different things because you know nowadays there are a lot of providers that provide actually everything like third web they have the connect SDK the in app uh even the indexing things they do have it but at the end I think it's more about decentralization and having multiple providers means that there is no single point a failure because if you create a system that's independent and it's inhouse, it's on prem, what happens when something goes down? That's that's a dilemma. Of course, I agree with you, but that's, you know, the reverse of the coin. Yeah. Okay. So we opened some tooling but uh this still seems like fairly I mean this is this is mature tooling for uh for the modern web but what how do you feel about like the bottom sort of dropping out of the whole actual DAPs element decentralized apps that run without any reliance on your own back end and stuff like that like is privacy in that way dead? is is are fully censorship resistant apps that don't even use a CDN dead. you said about privacy and you know the previous question um was was about so it it depends on what's your target audience right so if you aim if we aim to build for users I think right now at this very moment privacy is not so important but if we aim to build for institutional grade companies governments um you know everything like that they do need privacy first so um you know exposing my wallet balance and wallet address. We saw in the past, you know, vulnerabilities with MetaMask lacking IP which, you know, could track a wallet address to the user's location. And that's for sure something that keeps still is keeping you know uh institutionals away from from the ecosystem. And to add on that, I think we should emphasize more on ZK proofs for sure on fully homorphic encry encryption native blockchains where you know you can compute on encrypted data and in this way you can you can you know on board the masses you don't have to you know um leak any sensitive data. >> Okay. But that's that's just the let's say execution engine side. But how do you feel about all the infrastructure supporting it? like you mentioned decentralization through using two or maybe three RPCs but that's that's just two or three RPCs and at the end of the day it's barely censorship resistant right because you still use a major CDN to host your websites you said NexJS but uh it's actually fairly difficult to run some NexJS applications on anything but Verscell because Verscell does build a moat around itself like just as an example from my circle. Um, Sofascore is a major gambling company, like sports gambling company in Croatia. And they were like, "Okay, we're going to save a ton of money. We're going to shift our whole Nex.js app infrastructure from Verscell to Cloudflare." And it was insanely difficult because they found that there were all these little tidbits of configuration that Versell doesn't really document that they had to reverse engineer then. So we're we're talking about some privacy tooling. We're talking about these decentralized apps, but they run on a very corporate supported, very heavily infrastructure specific stack and they run on a very censorship possible stack where you use a major CDN or you use major DNS. and you couldn't it would be extremely hard to even compile this and put it up onto something like IPFS, >> right? >> I don't want to take on too much on the on the microphone. So, just to expand on on that and give you a short answer. It's true. We can't expect, you know, the blockchain world to take on the whole world like tomorrow. It's a progress. It's a it's a process first and we need to be aware of that. We need to try to shift the focus from having centralized providers to decentralized ones. But we know for sure that down the road we still need to depend on them until we reach a phase where we can discard everything. Um just to just to add on this um it would be at least from this perspective really good to finally have a like big enough catastrophic scenario that triggers people to think about it because right now quite honestly like privacy nobody cares, right? There was this like just last week there was like the biggest data leak ever and quite frankly who cares, right? You change your password and there's basically no consequence. People just don't care about their data and the privacy of their data. There are regulators that care because they are actually building the framework and maybe some people, but the masses they they don't. And that's kind of like the the harsh truth especially in web 3. Now consumer crypto is all the buzz. DeFi is basically the the main use case of everything. And yeah, the focus is shifting to the point that we want to make it easy, usable, and reachable so that like even your your dad can use it. Privacy is just doesn't it's not a high prior thing, right? It's not P 0 right now unfortunately. So the reality is really that we're not even building DAPs. We're just building apps, right? >> Exactly. But that actually use some sort of blockchain tech, but it's not zero. That's that's the truth. >> Okay. Okay. Anyone else got something to add? So at some point I I did try seeing how far I can go into reasonably keeping a let's say relatively mainstream stack but actually going as as close to decentralized app as possible and sadly it's kind of a mess to do that in the sense that many times you don't have the support you wish would have exactly because there are so few people that are going specifically for this sadly sadly I think the conclusion you got to that we're actually mostly building apps that have some sort of decentralized part is is correct. But I don't think it's uh such a depressive conclusion as it sounds because because for example, sure you have like you have let's say an an app that helps you trade your NFTs. Sure it's not decentralized. You're trading them through an app that has a front end and so on that's centralized, but in the end those NFTs are onchain. And if you if the app goes down or try censoring, you still have the assets and you can get them somewhere else. So I would say that while it's not perfect decentralization, it's a good step forward and it's not something that should make you say, "Okay, decentralized is dead and let's just leave the room and go for a beer." Okay. Okay. So we're about halfway through. Let's let's let's spend the other half on positive notes. So we we've gotten through this illusion. Now let's focus back on on what really matters and that's users. So okay, can we just have a short like show of hands? Who here knows what is hallway UIX testing? Like have you heard the term hallway UX testing? >> We should all have our ends our hands raised. >> Okay. So the next few things I'd like to open up are about actual user feedback, user testing and how how you in approach the process of actually designing your software because generally everyone's sort of just criticizing UX in crypto and it is horrible. It is cryptography. It it is horribly hard to manage for your average user. So between like pass keys as a new thing and those like easier security measures and general like process there is to signing and how it works and all the features like how do you approach it? Yeah. So um I think everyone in this room at least have heard about account abstraction which is trying to solve this your user experience problem for sure. um having you know embedded wallets just to address the login issue where an embedded wallet gives you the ability to use any login method like any web to legacy login method for example email pass key uh face ID even uh social login and you get uh uh a built-in uh EOA for your for your app and there are a lot of there there are a lot of providers out there right now uh as I said third web um prey We we just saw it was acquired a few days ago. Um so yeah trying to design apps for users uh you need to you need to understand first that we need to abstract all the complexities for sure. Um and we need to think workflows that looks like uh web two workflows. Yeah, agree to that. Um, I also I would zoom out a little bit. Um, and I think I still keep hearing like why do we not we have this sorry why don't we not have the next billion users on uh web 3 yet? And I think from a very top down perspective it's because we just ship incomplete experiments and um use technical jargon. And I think that's okay because we just test things out. And I think I would look at it as like we're still experimenting with things and seeing what comes back. And we're getting into a time where we can just run more of these experiments and more of them at the same time, more frequent ones, shorter ones. And um to me like the way to get to user adoption and create something that people really value and experience is just a culmination of a lot of these feedback loops and different experiments that you can set up, but that are also dependent on your personal skills and the technology that you're using and um your creativity and putting them together into something that's like very unique and very easy to understand. So you build something, put it out there and see what comes back and and don't ignore the feedback because it's sometimes painful to to listen to people like not you know not working through the journey that you've designed um and then go back to the drawing board and maybe like reduce something. I think one thing that I feel like is um also often overlooked is uh the um removal of of parts. like it's it's very easy for us to like create things and build them together and like be very excited about a big vision and want people to experience it, but um it's also useful to kind of go back and be like, well, what's that experience really about? Like what can what can I remove from it? Um what do I want people to experience? And then see if they do. Um, adding to your point, I think that because now we we got to the point like the the the web three market got to the point that like at at the beginning you had a small group of believers really adopters of of of the tech and anything you shipped really they picked it up. They they were those types of like mechanic users that just wanted to understand everything. So basically this burden is just what wasn't like a thing right you always found at least a couple of users now with the market being saturated and having some quality protocols out there we are getting forced into actually rethinking and that is what is actually going to to to make the market move forward. And the other thing with with legislation coming into hand um if you have an opportunity and you have interested parties take an institution with you pilot with them and they're going to give you a very very good feedback about like hey like this protocol works okay it works but like with this level of UX with this level of usability or unusability we're not going to ship this to our users and that is going to be very pivotal it's like super pivotal super good for you because you just have a lot of internal feedback and you're not actually like doing anything that is harming your your your brand. You're not shipping anything that at least a sub part of users are not okay with. And yeah, I think that is what is going to to open the floodgates. >> Just a a quick u a quick note and then we can go further. I'd say I so I've been through what you said and having an taking an institution with you and trying to pilot with them and I have to say it was so depressive when I was focusing on complex things and building efficiency and the people trying I saw that people trying it out would basically I would see them crash out in front of me and basically getting absolutely stunned or blocked because I don't know uh I've changed the default UI to dark mode or something and they they weren't them being pretty much techiterate. They weren't able to understand what's happening just because the UI was changed to dark mode and realistically we've got a long way to go until we can saturate that that market. But uh yeah, as you said it's very important to go through that as well. >> Okay. So continuing sort on this segue. So what are your like experiences with internal UIX testing workflows and like user experience, user journeys, etc. like maybe more practical examples, specific stories and things that you saw users doing, you know, or or like are you even participating as developers in the UX floor? Do you feel that that's something that usually gets um let's say put on the design team? Is there even a UIX testing team or is it just you know the designer just doing the design? How does it work for you guys? Uh sorry. So the question is more about process or more like specificity. >> How does the user interface design happen because there's many ways it could happen right? It could be the CEO's head or it could be based on feedback from real users trying to use a platform. >> I think one thing that's very important uh from this point is that you don't test internally but that you test with people who don't know your product yet. Um and um user researcher um Sasha Tanasi. Um yeah, I mean I think um I'm also a little bit biased because we're an external kind of like organizational external collective and we uh come in to um teams existing teams and actually facilitate sessions to align developers, business uh like business people, designers on the uh experience that they want people to have. so that you get um the ideas and the knowledge from all of these expertises and together design what is possible and then um make sure that you can actually implement it and test that. Um but yeah, I mean that's I guess like in a nutshell that would be the process. Just like take everybody from the whole team who has a um stake in the project, align them on exactly what the user journey should be like because everybody knows best what they can bring to the table from their expertise and um then prototype it before even building anything because otherwise you might just waste a lot of money. And um yeah and I I mean again I even even user research I think should be done um by an external person in order to stay unbiased because if you if if you do the user research as someone who's like building that thing then you'll be like kind of imagining that the person would do exa would say exactly what you want them to say and you might misinterpret their feedback. You might not pay attention to their like you know facial expressions. >> Yeah. Researcher bias. Research. >> Right. Right. Yeah. Exactly. Um, so I think it's it's very important to um or I I I would recommend to involve external parties to actually do that testing like you would with a security audit. >> Does that answer your question more or less? >> Yeah. Yeah. Very much very much. >> I can I can pitch into this. So uh at least at least in how it currently works in uh in my team is as follows. But to be not that we're mostly still building lots of demos, proof of proof of concepts or stuff like that. So we we generally try to ship fast. We're not fiddling too much with things. So generally we have a developer drawing up like a very crude design in of a flow they're thinking about of implementing that then goes to that then goes to our designer that will aim to actually make it pretty and usable. Once that is done, it's uh the changes are then implemented by by set designer. Then it goes to into another phase where people from the company that are not techy test it out uh basically throw dirt at it and then the developer will again do like a third version in which the non- tech uh opinions are taken into account and then we say okay it's kind of fine to ship. Then obviously some improvements if we see users struggle in different things but this is like a end to end workflow of what we're doing before actually going to real users. Um chiming in here for probably like the builders that that have been in the space for a long period of time especially in DeFi. Uh do you guys remember those times when we just built something, there was a community around, we shipped fast and then you know like it was it was this this this uh like hunt of like I shipped this but I I wanted that and then I ship it again and then the community wants something else and then I ship it again and then the community finds another problem there. Now, I still see that a lot of like small developer uh developer teams of small protocols are kind of like stuck in this and they're always complaining about the fact that they're actually never going to to find product market fit because the sample and the community that they're actually testing with is so biased and they know their tools, they know their application that simply the the the the input that they have they get is just so altered and so specific that Yeah, they just can't scale with that. And then to do another round on this, there are the other teams that uh actually strip away, they have a bigger communities and then strip away a small subset of OGs that basically get the opportunity to see the first pilot versions of next features or next versions of protocols and they basically do the user testing with these people. This is the the other very frequent uh type that that I can see in the in the space. Well, whether this is good or not good on institutional level, definitely not going to cut it. For small projects, it's pretty nice because like you get a lot of free feedback and potential really good improvements, but uh but it's definitely not a perfect flow. >> So just to give a real world example of how we are doing things at emergent. So um first thing first we allocate a small team on building a specific product a specific app. Um then once we have that app we get our CEO and CTO on board and you know to try and test the app because we are trying first to create apps that solves real world problems and we are trying to build apps that we would actually use and see if these flows make sense for us first and then put it out there. share the MVP and grab some some feedback. >> Okay. Okay. Thank you, Ron. So, we have about a minute left here. So, I was just thinking like really really short like 15 seconds each. Um like if you were starting from scratch today, you know, empty empty slate, right? Um what would be the one thing you would do differently? just like one sentence in order or whoever's ready first >> contributing to open source projects uh at the early stage because there's a lot of uh value in there and uh feedback for sure. >> Um I would definitely be more of a user than a builder. I feel like I spent a lot of time on designing and implementing things that made sense for us really and obviously getting negative feedback on that hurts. And then I slowly realized that when you get inside this loop of trying to please your users, you're basically getting so out of touch of what the market actually requires that it's very very hard to get back into it. So be a user, understand what the market market uh def facto standard is and then always have that in mind when you're actually building something. Probably one of the biggest issue I I had at the beginning of that I would avoid at all cost would be uh not would be so I would avoid testing on mainet. Yep. That was a very uh that was a very big issue for me in the beginning. >> I just one thought. Okay. Um I would probably experiment testing with money directly and try to um yeah I mean basically sell because it will refine your intuition and comfort with what's valuable and what people perceive as valuable and what you can create for people that's higher value that their um perceived investment and um use that sense of what people need to build technical infrastructure that creates value um rather than extracting. >> Okay. Okay. Uh thank you very much everyone. I'm just going to add one answer for myself as well. I would spend so much more on the requirements docs for every single client. My god. And yeah, now we can go into the Q&A hopefully. >> Questions. Does anyone That's loud. Does anyone have questions? Daniel, I know you >> or if a certain UX researcher from the audience would like to add her own word. [Music] >> You would like to Oh, you would like to make a point. >> Yeah. Okay. >> Uh so, first of all, excellent panel. I'm very happy to hear more and more about builders taking into account testing which is great. Uh it was really funny because I heard internal testing and I got shortcircuited and then Andre chimed in which is great. I think um all the builders should understand that it's much cheaper to test out the idea like just I have an idea go talk to 10 people who might be exactly like you said I imagine these are the people that might actually use my idea let me talk to them and see how it actually works. Maybe it's useful, maybe it's not. Maybe it's only for you. Um, and it's much much cheaper to do it like that. Internal testing is not amazing. It's good only for finding like visual issues and bugs and I would consider it more like dog footing which is again a very good thing but testing testing should be done with unbiased participants unbiased researchers. Um, yeah, the team is great to be there observing because it's easier to get it from the horse's mouth, but shouldn't be done by the designer who is already invested. And most of you said it's very um hurtful and painful to hear about feedback like negative feedback. I think we should reframe this because feedback is a gift and any bad feedback or negative feedback is actually an opportunity. So we need to break thing faster, learn faster that our product maybe is not yet perfect, but this is great. It means we're on the right track. And as a researcher, if you hear only good feedback >> that that's amazing. That's amazing. Sorry. Sorry to interrupt. Do you have a question? I love the point. It's just getting a bit long. >> Okay. Can I finish? >> Thank you. Uh, so as a researcher, the first thing if you hear that if you have too much good feedback, it means you're doing a poor job. Thank you. >> Thank you. So yeah in short uh you know not just the brun get the brains think about what you're doing get a security register and a UX register in the loop early we got some more questions. >> Yeah. Um okay so we're talking about DAPs and in the last time I'm I'm not sure exactly how I haven't seen a lot of new types of dabs coming up just copies of things that already exist on the chain. Do you feel like we've built everything that we could have built before or are there still things that we can create new things? I I think there's a lot of new going on. We can It is not obvious until it hits you in the face, you know. Uh but I see a massive raise in faster uh order books which have sometimes higher capital efficiency and stuff like that on DeFi side, new solutions for privacy etc. You know there's always more. you guys got some >> I would just encourage everybody to like go out and do a lot of non-monetary things and think about how we can solve social problems with blockchain tech. And one more point to this is that like back in the days when we didn't really have available solutions for for problems or for use cases, it was more obvious that ah okay now like ne next week we I have something that I can use for this. I have something that I can use for that. Before that I I didn't even think about something like this happening right. So now uh I I I again agree that there is a lot of new it's just it's incremental. it's better than something that was before. But then it might happen that a lot of like a lot of the market doesn't realize because there is a cost to switching that might not be basically like big like like yeah covered enough for the user base to actually drastically switch and then obviously like the news are not hitting because of this and there's not that big of an echo chamber effect. Any other questions from the audience? Yeah, that's loud. What do you think about uh sacrificing decentralization for user experience when building your app? Go first to the video if you want. >> So, I think it all depends on who's your target audience. Once again, like if your target audience is just, for example, a bunch of people that want to make a quick buck, absolutely go for it. If, for example, your target audience is someone that's a is like the ideal person that would use your app is someone of, I don't know, privacy freak, then absolutely don't do that. Everything is depending simply on who is going to be the user that you want your app to use. And you got to research the market for your app for that. after all. >> So, uh I think the question was about decentralizing right the user experience. Um I think to circle back it's it's more about um you know relying on multiple different parties at least nowadays to build your app. It's not just about having a single provider out there for your app for you know wallet connect um RPC indexing and so on. So just decentralized for now at least the tech stack and then we'll figure it out. Okay, we have time for one very very very short final question. >> Anyone up? >> I know Daniel had a question. >> Okay, thank you very much. >> Okay, perfect. Thank you. >> Thank you very much. Please put together for uh your hands for our wonderful B panelists here.