Wrong Mansur

fuck, if you missed this, catch up https://youtu.be/pWwQmikOoqg?si=Bhd58wiI5TDgg8ht

I want to share a bit about what I’ve been working on outside of my main job. Over the past few months, I’ve been building an project called Concierge - a platform for residents and property management teams in residential complexes. The idea didn’t come from “let’s build another startup.” It came from my own experience of buying an apartment, going through renovation, and then living in a residential complex. I started noticing how many everyday processes around the building still live in Telegram chats, personal messages, and manual agreements like “just text the manager.” Want to book a shared space like a chaykhana or BBQ zone? You message someone. Need the security or technician’s contact? You search through old chats. Trying to find an important announcement? You scroll Telegram. Need to connect your apartment or solve a building-related issue? Again, personal messages. It works somehow, but as the number of residents, apartments, and shared spaces grows, it quickly turns into manual chaos. And it’s not only inconvenient for residents, it also puts a lot of pressure on the property manager, who has to deal with dozens of repetitive questions, requests, and small operational tasks every day. With Concierge, I want to bring these processes into one clear and convenient product. The first working version is already built: — a web app for residents inside Telegram Mini App; — an admin panel for residential complex managers; — a product landing page; — a backend service that powers both the app and the admin panel. In the first version, I focused on the core scenarios: authorization, apartment ownership verification, resident management, booking shared spaces, announcements from the management company, and important contacts in one place. For me, it was important not to build just a nice-looking app for residents, but to look at the process from both sides. On one side, residents want to solve everyday issues quickly, without endless messages and searching through chats. On the other side, managers need a proper tool where they can clearly see who lives in which apartment, who submitted an access request, which shared spaces are booked, what announcements are published, and what currently needs attention. The first pilot I want to launch is in my own residential complex. This is where I personally noticed the problem and decided to try turning it into a product. Right now, I’m polishing the product, talking to potential users, and preparing for the first pilot. I’d be happy to hear any feedback, especially from people who live in residential complexes, work with real estate, property management, or just enjoy discussing product and startup ideas. https://landing.concierge-service.uz/

Ребята, привет! Хочу показать вам проект, над которым я сейчас работаю в свободное время. Я делаю сервис «Консьерж» - это приложение для жителей ЖК и админка для менеджеров дома. Идея появилась после того, как я сам столкнулся с жизнью в ЖК: заявки, объявления, бронирование общих зон, контакты, вопросы к менеджеру - всё обычно разбросано по Telegram-чатам и ручным сообщениям. Я хочу собрать это в одном удобном месте. Сейчас уже есть рабочая версия: Telegram Mini App для жителей, админ-панель, backend и лендинг. Первый пилот хочу попробовать запустить в своем ЖК. Буду рад, если вы посмотрите концепт / скрины / демо и честно скажете, что думаете: понятно ли, полезно ли, что выглядит сильным, а что стоит улучшить. Мне сейчас очень важен живой фидбек, особенно от людей, которые сами живут в ЖК или сталкивались с такими бытовыми вопросами. https://landing.concierge-service.uz/

DevOpsDays Tashkent 2026 https://youtube.com/playlist?list=PLfxac9SJZ5QZfUnEkLscL6PbL3vs7HsgT&si=ZXajIe7lzKdXC63I

the second concept i liked is Tracer Bullets. most LLMs tend to code horizontally. they build layer by layer: first models, then services, then UI, and only at the end you see if everything actually works. it can feel productive, but the problem is that feedback comes too late. tracer bullets push you to do the opposite: build a small vertical slice that goes through the whole flow. not the final version. not the perfect architecture. just one thin path that works end to end. for example: one screen, one API call, one database operation, one result back on the screen. what i like about this idea is that planning becomes more grounded. you are not trying to guess everything in advance. you quickly see the real problems: missing requirements, unclear data, wrong assumptions, integration issues. after that, it is much easier to plan the next steps. i think this is especially useful when working with AI coding agents. instead of asking an agent to build a big feature at once, i prefer to start with a tracer bullet first. small working flow → feedback → improve. it keeps the agent on track, and keeps me in control of the direction. here is promt example by Matt:

## Tracer Bullets

When building features, build a tiny, end-to-end slice of the feature first, seek feedback, then expand out from there.

Tracer bullets comes from the Pragmatic Programmer. When building systems, you want to write code that gets you feedback as quickly as possible. Tracer bullets are small slices of functionality that go through all layers of the system, allowing you to test and validate your approach early. This helps in identifying potential issues and ensures that the overall architecture is sound before investing significant time in development.

recently, I started taking Matt Pocock’s course “Claude Code for Real Engineers”. one idea I liked is that when working with coding agents, engineering fundamentals become even more important. It’s less about writing every line of code yourself, and more about clearly defining the task, guiding the process, and checking the result. I want to start a small series of posts about engineering concepts that I like and use in my work and life. the first one is Red-Green-Refactor. Red-Green-Refactor comes from TDD — Test-Driven Development. It is a simple cycle: first, you write a failing test (Red), then you write the minimum code to make it pass (Green), and after that you improve the code without changing its behavior (Refactor). what I like about this idea is that it makes you think about the expected behavior before implementation. You first define what the code should do, what cases it should cover, and how you will know that it works. Only after that you start writing the solution. I found this useful in many cases: at work, in pet projects, and also during interviews. For example, when you have a live coding session, it’s often better to start with test cases. It shows the interviewer that you care about quality and edge cases, and the session goes smoother because you already have a clear picture of the problem in your head. You are not randomly trying to solve something, you are moving step by step: define the behavior, make it work, then improve it. I think this approach becomes even more important when working with AI coding agents.

база от Влада https://www.youtube.com/watch?v=i-FFVM4cIXQ&t=568s

Interviewing at Bloomberg (Prep Doc) https://drive.google.com/file/d/1UoL6q5egwXLpinWqivmSPG_YstfGLBur/view?pli=1

I intently follow and read posts by Diyorbek. Recently, he released a podcast on Frontend System Design, covering all the important aspects and providing clear, concise insights on each topic. https://www.youtube.com/live/Pcxs07g-xVU

I intently follow and read posts by Diyorbek. Recently, he released a podcast on Frontend System Design, covering all the important aspects and providing clear, concise insights on each topic. https://www.youtube.com/live/Pcxs07g-xVU

Working with WebView looks easy — until you're deep in edge cases, routing issues, and native-web sync problems. At payme, I dealt with all of that while building avia & tickets. I recently wrote a post breaking it down: – When WebView makes sense (and when it doesn’t) – Problems we faced in production – Communication between native and web – UX nuances, routing, and lifecycle quirks Wrote it in two versions: 📎 Habr (RU): https://habr.com/ru/articles/919856/ 📎 Medium (EN): https://medium.com/@mansurisakov.dev/from-browser-to-app-the-inner-workings-of-webview-10aea73dcf86 Might save someone a few hours of debugging — or help decide if WebView is even the right call. Happy to hear your take too.

I recently wrote an article on a topic that often seems simple but can become a real performance challenge: working with lists in web development. It covers key concepts like virtual scrolling, infinite scroll, and how proper keying can make a difference — with practical examples for both React and Angular. Would love to hear your thoughts or experiences around this too https://medium.com/@mansurisakov.dev/working-with-lists-in-web-development-performance-patterns-and-examples-0ccdaaea34d5

Trying despite disbelief I am very good at finding reasons why something will NOT work out, and pessimistically hyper-focusing on them. In my past they were enough to immediately give up on an idea. One thing that my wife taught me is what I call trying despite disbelief. I think the first time it happened was ~9y ago. The company I worked for made me a H1B work visa and offered $56k/year salary. I took the deal without negotiations and moved to the US. When my wife, girlfriend at the time, heard that my salary is just $56k, she was like "WTF, they low-balled you, go and ask for 20% more". I laughed because nobody gets 20% raises, but she convinced me to TRY. I went to my boss and asked for 20% raise with zero belief that I will get it. The funny thing is, when I try I appear like I know what I am doing, smiling and such, and what do you know, to my surprise I got ~15% increase. Another time I left my backpack with a laptop in a coffee shop. I called them up and they said they don't see one. Past me would give up, because I got a pretty strong signal that it isn't there. By that time I already had a few experiences where trying helped, so I simply drove there and there it was, on the floor. I don't know how they couldn't notice it. There were many other examples. Some still required encouragements by my wife and others, like trying for L7, and asking for more money. Another example is me accepting the L7 high-risk high-reward offer -- I'll do my best and hopefully survive. Even publishing this post is an example -- the reason not to post it is that this is possibly bullshit. --- I am not saying that it will help everyone, but it might certainly help those competent but not confident. Quoting Wikipedia "The Dunning–Kruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their own ability, and that people with high ability at a task underestimate their own ability" (I encourage to read the rest of article). If you believe you belong to the second group, or sometimes you find yourself thinking "if even he/she did it, then I should be able too!", then it might help. Or if you are a woman, because the ever-present patriarchy makes you feel small. A part of this is accepting a possibility of failure. In fact, I usually go with low expectations and just do my best. If you fail, that's OK. It isn't the end of the world. Another thing is, you might luck out. An interviewer might not ask you topics that you are weak at (I am weak at parsers). In my Google interview I wasn't prepared for system design. I failed one; the other was quite algorithmic (=easier) and the interviewer was from Android (not working distributed systems themselves), so I got lucky. You cannot get lucky if don't even try 😉. Like I said, I tend to hyper-focus on reasons why something will NOT work out, in a pessimistic way. While it is discouraging, it also guides me to work on the weakest parts. If you think about chances of success as a confidence interval, then working on the weakest parts maximizes the lower bound. You can see an example of this in my obsessive preparation for the behavioral interview which I never did before and which isn't very technical. This attitude also poses the question "What am I missing?" and you can see an example of this in researching my Microsoft interviewers and discovering new topics to learn. Thinking how a system might fail (failure modes, unhappy cases) is one difference between L4 and L5. Overall I can say that this simple technique made a big difference in my life. The first step is the hardest.

digging into Leetcode lately — thought I'd share this resource in case you need it https://leetcodetherapy.com/

Excited to share — I’m now a Senior Frontend Developer at payme.uz!

TBC x payme Office Tour 🚀 Our office tour is live! Check out TBC x Payme Office Tour to see where your everyday-use products come to life

Great Black Friday Deals! 🔥 LeetCode Yearly Premium — Just $129! 💎 Course Hunter Premium — 2 Years for $40!