Devs for Devs: Being a Good Developer Isn’t Enough to Build Your Own Product
Devs for Devs: Being a Good Developer Isn’t Enough to Build Your Own ProductFrom world-class developers, straight to you.
Hello! 👋 In today’s issue, Aliaksandra Asichka is sharing her knowledge behind indie development. She’s an AI Engineer and iOS Developer who combines artificial intelligence with mobile development to turn ideas into real products. Aliaksandra experiments with new technologies, builds her own projects, and shares practical discoveries from her journey with the developer community. Is it enough to be a good dev to ship a product? P.S. You can check out Aliaksandra’s work on LinkedIn.
Subscribe if you’re new here! 👋 As developers, we are used to thinking in terms of solutions. There is a problem. We understand the technology. We design the architecture, choose the tools, write the code, fix the bugs, ship the feature. So when a developer decides to build their own product, the natural assumption is that the hardest part will be building it. I thought so too. After working on my own iOS product, MirrorFit, I realised that writing the code was probably the most predictable part of the entire journey. The much harder questions were:
These are questions engineering skills don’t necessarily prepare you for. It Started With Technology — but Technology Wasn’t the ProductMirrorFit started with an idea between me and my co-founder. The original idea was technically interesting: use the camera and face tracking to recognise facial movements and turn them into exercises. I had been practising face fitness myself for a couple of years. So I didn’t just see a piece of technology that could track a face. I could see how it could actually be used. I started thinking about which exercises could realistically be tracked, how they could be performed in front of a camera, and how computer vision could turn something that was traditionally a set of instructions into an interactive experience. That was the moment when the technology became a product idea. And that experience taught me something I still consider important: Technology is rarely the product by itself. As technical people, we are naturally attracted to interesting technology. A new model, a difficult computer vision problem, an unusual architecture, a new framework — these things are fun to build. But the fact that something is technically interesting doesn’t mean that people need it. The first question shouldn’t always be:
Sometimes it should be:
The Technical Trap: Making the Product Better Instead of Getting It Into People’s HandsOur next mistake was much more familiar. We spent time improving the product before launch. The design wasn’t quite right. The content wasn’t quite ready. There were things we wanted to polish. We wanted the product to feel complete. Meanwhile, the market was moving. Someone released a similar product before we did. And, as if that wasn’t enough, the name we had chosen was taken by someone else for another fitness-related product. That was an unpleasant lesson in timing. While we were thinking about how to make our product better, someone else was already shipping. Looking back, I would launch the MVP much earlier. Not because the first version would have been better, but because it would have given us something much more valuable than another polished feature: real information. A product sitting in development gives you assumptions. A product in the hands of users gives you evidence. The Audience Became More Important Than the Feature SetOur first testers were friends, people from women’s communities, and readers from Threads. Eventually, I collected around 100 people in TestFlight. But I wasn’t just looking for people to click through the app. Even while we were developing it, I was asking questions:
These conversations taught me more than I expected. And surprisingly, the most useful research wasn’t a sophisticated framework or a spreadsheet. It was talking to people. Personal conversations helped me understand what people actually meant, rather than what I assumed they meant. I also became a very active user of my own product. I tested it after practically every deployment. At some point, I was completely immersed in it. That was useful because I could immediately feel when something was inconvenient or didn’t make sense. But it also created a danger. When you build something yourself, it is very easy to confuse your own understanding of the product with the market’s understanding of the product. Those are not the same thing. The Android Request Was More Than an Android RequestOne of the recurring pieces of feedback was surprisingly simple:
We had built an iOS application, and our audience kept reminding us that the market was bigger than the platform we had chosen. Another recurring request was localisation. These requests were uncomfortable because they were not really about features we could simply add to the backlog. They exposed a bigger question: Who are we actually building this for, and what prevents them from using it? That is an important distinction. User feedback doesn’t always mean that you should blindly implement whatever users request. But every repeated request is a signal. The job is to understand what is behind it. The Painful Part: Accepting who the Product Was Actually ForOne of the decisions that took the longest to accept was our target audience. Initially, we wanted MirrorFit to work for both women and men. It sounded reasonable. Why make a face fitness product specifically for women? Men can have the same interest in their appearance. Men can have wrinkles. Men can care about their skin and face. And men actually helped us during testing. Around 5% of our testers were men, and their feedback was useful. But testing also showed something else. Trying the product and having a reason to keep using it are two different things. The long-term motivation was much stronger among women. The problem wasn’t that our competitors had somehow forgotten that men existed. If almost every product in the category was positioning itself primarily toward women, perhaps there was a reason. We had been looking at the market through the lens of what we wanted the product to be. Eventually, we had to take off the rose-coloured glasses. We didn’t fundamentally change the concept. We changed our understanding of who was most likely to need it. And that distinction matters. Sometimes a pivot isn’t abandoning your original idea. Sometimes it is understanding your original idea more clearly. Changing the Design Hurt more than Changing the PositioningThere was another part of the process that was surprisingly difficult for me: the design. If you decide that you’re building a product primarily for women, the product needs to look and feel like something your audience actually wants to use. That sounds obvious. It wasn’t obvious while we were building it. As a developer, I naturally wanted the functionality to be right first. If the tracking worked, the exercises worked, the flow worked — that felt like progress. But users don’t experience your app as a technical achievement. They experience it as a product. They see the visual language, the content, the onboarding, the tone, the exercises, the value proposition. And then they decide whether they want to spend their time with it. Changing the design meant letting go of something we had already spent time creating. That was painful precisely because I liked the product we had. But liking what you’ve built is not the same as knowing that the market likes it. Then Came the App Store Reality CheckAt some point, I caught myself thinking: Why isn’t the App Store promoting us? We had built the product. We had testers. We had launched. Where was the growth? The number that eventually stood out to me was 91 downloads. On paper, 91 downloads is not an impressive App Store success story. But I started looking at it differently. Those 91 downloads didn’t appear because I wrote good Swift code. They happened because I had built something, launched it, talked about it, created content, found people, explained the product, fixed it, shipped it again and kept trying. And I realised: 91 downloads were actually my achievement. That sounds small when you compare it with successful apps. But when you build your first product, you quickly discover that every number has a story behind it. One download means someone noticed you. One tester means someone gave you their time. One piece of feedback means someone cared enough to tell you what they thought. And when the numbers are small, you don’t have the luxury of hiding behind dashboards. You have to understand where every user came from. Once It’s Your Product, You’re Not Just the DeveloperThis was probably the biggest mindset change for me. When you work as a developer, you can specialise. You can be responsible for iOS while someone else handles product. Someone else researches users. Someone else writes copy. Someone else runs marketing. Someone else looks at acquisition. Someone else worries about positioning. When it’s your own product, there is no “someone else”. You are the developer. But you’re also the product manager. You’re the marketer. You’re doing user research. You’re looking at analytics. You’re thinking about design. You’re answering users. You’re deciding what to build next. And sometimes you’re staring at the App Store wondering why nobody is downloading the thing you spent months building. What I Would Do DifferentlyIf I started MirrorFit again, I would do three things differently. 1. Launch the MVP EarlierNot when everything feels finished. Earlier. The market is a much better source of information than another month of internal polishing. 2. Start Marketing EarlierI used to think marketing was something that came after the product. Now I see it as part of product development. You need to know whether you can reach the people you’re building for. You need to understand what language makes them stop scrolling. You need to know what they think the product is before you can know whether your positioning works. 3. Get Comfortable Changing Your MindThis is probably the hardest one. When you’ve built something yourself, you’re emotionally attached to it. You’ve spent evenings on it. You’ve solved technical problems. You’ve made decisions. You’ve imagined what it could become. Then someone tells you they want something different. Your first reaction is often: But that’s not what we wanted to build. Sometimes that’s exactly when you need to listen. Should You Build Alone?Building your own product also taught me something that has nothing to do with technology. It is hard. Really hard. Not because there is always too much work, but because there are periods when nothing seems to happen. You can have a period where everything moves forward and you feel that the product is finally taking off. Then you can have a period where the numbers don’t move, marketing doesn’t work, and you start questioning whether any of it makes sense. I don’t think building alone is impossible. But I don’t think it’s for everyone either. Having a co-founder or even a friend who genuinely supports you can make a huge difference. The useful thing about having another person is not only dividing the workload. Sometimes you simply need someone who is having a good day when you’re having a bad one. If you’re building with someone, your periods of doubt may not happen at exactly the same time. And that can be enough to keep moving. The Lesson I Actually Took from Building a ProductI started this project because I wanted to experience both sides of the process: being a developer and being an entrepreneur. I wanted to release my first application, understand what happens beyond writing code, and see what it actually takes to put a product on the App Store. I got that experience. But I also learned that there isn’t a perfect formula for what to do first. You can’t only listen to yourself. You can’t only listen to the market. If you only listen to yourself, you can spend months building something technically impressive that nobody needs. If you only listen to the market, you can end up changing your product every time somebody asks for a new feature. The real skill is finding the balance. Listen to yourself enough to have a vision. And if you’re thinking about building your own product, I would start with something much less exciting than opening your IDE. Study your competitors. If you can’t find any, don’t automatically assume you’ve discovered an untouched opportunity. Ask yourself whether you’re solving a problem people actually have. If competitors do exist, don’t be discouraged by them. Ask yourself how you can create more value. Find a co-founder, a friend, or someone who can support you through the inevitable ups and downs. And most importantly: Don’t be afraid to change the idea. A pivot doesn’t necessarily mean that the original idea was bad. Sometimes it means you’ve finally learned enough about the market to build the version that has a chance to matter. Subscribe if you’re new here! 👋 Every Wednesday news, every Sunday tips from devs!
|
