January 28, 2026
Handling Money in Milliseconds: 12 Questions for AdTech Expert Damian Naglak (Appliscale)
AdTech is often misunderstood. To the outsider, it’s just pop-ups and tracking cookies. To the insider, it’s one of the most ruthless, high-performance engineering playgrounds on the planet—a place where a 20-millisecond delay costs real money and "scale" isn't a buzzword, it's a survival requirement.
We sat down with one of our team members Damian Naglak who's also a Head of Engineering at Bedrock Platform, to talk about what it actually takes to build the engine room of modern advertising. Damian isn't just managing Jira tickets; he's architecting systems that handle massive financial transactions in real-time, integrating AI agents into boring operational workflows, and rethinking what it means to be a software engineer in the age of LLMs.
From the reality of "coding" with AI to the hidden complexities of building a next-gen DSP, here is a look inside the mind of the guy keeping the servers running when the bid requests flood in.
- What was the very first piece of software you built that made you realize engineering wasn't just a hobby, but something you wanted to do for a living?
I am a very practical person, so the realization did not come from writing a specific piece of code. It happened when I understood that technology is one of the main drivers of innovation in recent years and that I could be part of that. I was fascinated by what technology makes possible, and software has always been just a tool for me to create real-world impact.
- You’ve been with Appliscale for 5 years – that’s a lifetime in tech. What was the company like when you joined as a Software Engineer versus the version you see now as Head of Engineering?
The company itself has remained quite consistent since I joined. What changed the most was my role and how I see things. When I started as a Software Engineer, Appliscale felt like a place of discovery for me. I was focused on understanding how things work and how software gets built. Over time, as I gained experience and took on more responsibility, my perspective shifted toward the why. I started thinking more about goals, outcomes, and what makes teams effective. As Head of Engineering today, I see the same company, but through a much broader lens, focused on impact, alignment, and long-term growth.
- You’ve worked in Gaming, Web3, and Video-as-a-Service. AdTech is notoriously 'heavy' and complex. What was the hardest thing to wrap your head around when you first jumped into the world of bid requests and SSPs?
The hardest part of working in AdTech is not the engineering itself, but the domain. AdTech is full of complexity, with many players and countless ways to achieve what is, at its core, a relatively simple goal. The heavy use of jargon and acronyms does not make it easier. Even for strong engineers, building this domain understanding is the biggest time investment. To propose good technical solutions, you need to understand the domain well enough to properly gauge effort and reason about the long-term impact of decisions. You cannot do this with technical knowledge alone.
- If you had to explain the engineering complexity of what you are building to a developer who has only ever built standard CRUD apps, how would you describe the scale and latency challenges you face every day?
The biggest difference compared to standard CRUD systems is that we are directly managing money in real time. Small mistakes can become extremely expensive very quickly. For example, an incorrect CPM calculation or a missed budget update after winning an auction can lead to significant overspend. Even a single minute of incorrect behavior can waste a large amount of money, which adds a real sense of responsibility and urgency to the work.
On top of that, everything operates under very tight latency constraints and at high scale. When you are handling thousands of requests per second, inefficient code or poor architectural decisions have an immediate and measurable financial impact. You do not need to work at a huge company to feel this pressure. It is a domain where good engineering, correctness, and performance truly matter every day.
- Tell us about Bedrock Platform from your perspective. Forget the marketing description: what is the actual technical beast you and your team are building behind the scenes?
Bedrock is a next-generation DSP. They have been around for a long time, but once you spend enough time in AdTech, you start to see how many workflows are still manual, fragmented, or based on outdated assumptions. What we are building is a buying platform where AI is used to simplify and improve those workflows rather than just optimize bids. Things like supply discovery, pacing control, budget allocation, and campaign monitoring are traditionally handled through a mix of dashboards, rules, and human judgment. We are turning these into AI-assisted systems that continuously observe what is happening and help operators make better decisions.
Technically, this means building AI systems on top of a real-time bidding and budget-aware core, with strict latency and correctness requirements.
- In most companies, 'Product' is something users can see and click. In AdTech, the 'Product' is often a high-speed bidding decision happening in 20 milliseconds on a server. From an engineering perspective, how does this change the way you work with Product Managers?
It definitely puts a strong emphasis on communication. Because the “product” is often an invisible, real-time decision rather than a UI, engineers need to be able to explain complex technical trade-offs in very simple terms. From an engineering perspective, this means speaking the language of Product Managers: pros and cons, risks, constraints, and expected outcomes, while deliberately hiding most of the technical jargon. Many people in AdTech are already aware of the underlying challenges though.
- In AdTech, it is very easy to over-engineer solutions because the data volume is so high. As a Head of Engineering, how do you stop your team from building 'cool tech' that doesn't actually drive business value? What is your mental model for saying 'no' to a new shiny tool?
My default bias is toward shipping early and operating on assumptions rather than building for a scale that does not yet exist. Having worked on multiple startup projects, I learned that over-engineering is often a bigger risk than under-engineering.
My mental model for saying no to shiny tools is simple: does this help us deliver value faster today, or is it an optimization for a hypothetical future? If a system eventually starts to suffer from latency or load because usage grows, that is a good problem to have. It means the product is delivering value. I encourage the team to start with the simplest solution that can work, measure real behavior, and only then invest in more complex technology when there is clear evidence that it is needed.
- If you had to be honest, what percentage of your 'coding' time is now spent actually typing syntax versus directing Cursor and AI agents to do it for you? Are we at 50/50 yet?
I was an early adopter of LLMs. I started using them back in November when they first launched, and I have been using them regularly ever since. Over time, I got quite good at prompting and at choosing the right way to apply them. I rarely write code by typing it myself. With proper guidance, AI is simply much faster. My role has shifted away from writing syntax toward planning, validating approaches, and navigating trade-offs. In practice, the engineer’s role today looks much more like an architect, reviewer, and decision-maker than a pure code producer.
- There is a massive debate about AI tools making the 'Junior Developer' role obsolete. Since you hire and lead teams, how do you see AI changing the way someone starts their career today?
AI has definitely changed the junior developer experience, but it does not make the role obsolete. The biggest shift is that outcomes now depend much more on the person than on the tools themselves. A motivated junior who is willing to put in the hours can learn and progress extremely fast with the help of AI. Many traditional junior tasks, especially writing small functions or methods, are now handled very well by AI. If I were starting my career today, I would spend less time focusing purely on syntax and more time learning how to think about architecture, trade-offs, and validation. Those are the skills that separate mid-level and senior engineers, and AI is still far from being good at them.
I think that juniors who will do best are the ones who learn how to work with AI effectively rather than compete with it.
- With the rise of AI agents that can code, the definition of a 'high-performing engineer' is changing rapidly. If you were hiring a Principal Engineer today for 2030, what skill would you prioritize that you wouldn't have cared about two years ago?
The skill I would prioritize most is strong product and business judgment. Today, with AI agents writing code so effectively, that is no longer the main differentiator. What matters now is the ability to understand the domain deeply, reason about business impact, and make good decisions under uncertainty.
A Principal Engineer in 2030 needs to understand business tradeoffs and know what is worth building, what is not, and why. They need to keep AI “on a leash” by defining what good looks like, validating outcomes, and iterating quickly. In short, I would hire someone who acts like a business player who can execute with technology, not only produces code. AI amplifies impact, but only for engineers who can connect technical decisions to real-world outcomes.
- If you were stranded on a desert island with only one LLM model to help you build a boat, which one are you picking and why?
I do not think the specific model matters that much. Most modern LLMs are close enough in capability. What really determines whether you sink or swim is how well you can prompt them, guide them, and validate the output.
- What is a 'modern' tech trend that you secretly think is a complete waste of time?
In my opinion, there is an overfocus on privacy in places where it does not matter.
People already give enormous amounts of first-party data to a few large tech companies every day. They share messages, locations, contacts, photos, and habits with platforms often without thinking twice. At the same time, the same people can be very hesitant to use a small third-party tool for something low-risk, like taking notes or listing ideas, just because it markets itself as “privacy-first”. This creates a strange imbalance. We accept deep data access from large platforms because they are familiar and convenient, but we over-scrutinize small tools where the actual risk is minimal.
Because of that, “privacy-first” often becomes a label that signals emotional safety rather than something that meaningfully changes real outcomes or risks. This imbalance also creates real problems for new players. Smaller companies are often forced to meet a long list of regulatory and compliance obligations from day one, even for low-risk products. That increases cost and slows innovation, while large incumbents benefit from scale, legal resources, and existing user trust. It is good to see that Europe is starting to acknowledge this and gradually reduce the burden in some areas.
If you want to pick Damian’s brain about high-frequency bidding, AI agents, or why your privacy-first note-taking app is over-engineered, you can find him on LinkedIn. Just be patient—he’s probably busy making sure a few thousand server requests don’t lose money in the next millisecond.