DEV Community: Mustafa ERBAY

How I Set Up My Digital Organization as an Engineer

Mustafa ERBAY — Wed, 08 Jul 2026 23:00:31 +0000

Last month, I needed an old system architecture document for a critical integration in a production ERP. I spent hours trying to find a file, written years ago, that contained both network diagrams and API endpoints in a single document. The reason? It was buried deep within a disorganized docs folder, saved with meaningless names. Such time losses have taught me, since the beginning of my career, that digital organization is not just an aesthetic preference, but an operational necessity.

As an engineer, I will explain in this post how I set up my digital organization to reduce my mental load and focus on my work, and what benefits this process has provided me. For me, digital organization is a constantly evolving system; it's not perfect, but it's good enough to get my work done.

Why is Digital Organization Indispensable for an Engineer?

Digital organization provides a mental foundation for an engineer to focus on complex problems. Often, the first step when starting a task is asking questions like "where did I save it?" or "which project was this?", which unnecessarily consumes our already limited cognitive capacity. This situation is a major source of inefficiency, especially for those managing multiple projects or working with legacy systems.

In my experience, a cluttered digital environment not only increases the time spent finding files but also elevates my stress levels. When working on an API integration, not being able to quickly find the relevant document or having to recreate an old configuration file slows down project progress and distracts me from the core problem. Digital organization removes these obstacles, making my workflow smoother.

What Principles Do I Apply in File and Folder Management?

Over the years, I've developed some fundamental principles for file and folder management. What's important to me is that everything is in a predictable place and that I can understand what something is just by looking at the file name. This is the digital equivalent of the principle "a place for everything, and everything in its place."

First, every project has its own main folder. Under this folder, I use standard subfolders like src, docs, config, tests, deploy. This structure gives both me and other engineers working with me a quick idea of the project's content.

💡 Simple and Consistent Naming

For file naming, I prefer the YYYYMMDD-topic-short-description.ext format. For example, 20260708-erp-integration-api-document.pdf. This allows me to understand when the file was created and its content at a glance. Date-based naming is especially useful for revision tracking.

I always have a _tmp folder for temporary files and I regularly empty this folder. Additionally, I use a separate archive folder for old or archived projects. This keeps my active workspace clean and prevents unnecessary clutter.

How Do I Manage My Notes and Tasks?

Note-taking and task management form the backbone of my digital organization. Often, I need to quickly record important information or a task to prevent it from slipping my mind. For this, I use different tools for different needs.

For quick notes and ideas, I use a simple Markdown-based note application. This allows me to quickly create a TODO list or save a server configuration. For more structured and long-term notes, I have a task management application I developed as a side product. This application allows me to gather all my personal and professional tasks, projects, and ideas in one place.

Regarding prioritizing my tasks, I have a simple rule: "If a task takes less than 2 minutes, I do it immediately." Longer tasks are managed by breaking them down into projects and sprints. This approach prevents small tasks from accumulating and helps me focus on larger projects.

How Do I Keep Email and Communication Channels Disciplined?

One of the biggest sources of digital clutter is email inboxes and communication channels. Hundreds of unread emails in the inbox or endless notifications in Slack/Teams channels create mental noise. I have strict rules in this area too.

I check my emails at specific times each day and try to keep my inbox as empty as possible (the "Inbox Zero" philosophy). I move important emails to relevant project folders or add action-required ones to my task list. Automatic filters and rules help me filter out spam and unimportant notifications.

In communication channels, I turn off unnecessary notifications and only keep channels that are truly critical for me active. If I see an irrelevant discussion happening in a Slack channel, I don't hesitate to mute it. Because every notification is an interruption, and for an engineer, interruptions mean breaking out of a flow state, which leads to significant productivity loss.

How Do I Support My Digital Organization with Automation and Tools?

One of my biggest helpers in maintaining my digital organization is automation. Everything that needs to be done manually is bound to fall apart eventually. That's why I automate processes as much as possible.

For example, I use systemd timers to run simple scripts that clean up old log files in specific folders or delete temporary files. On my own servers, I use Python scripts that periodically clean up old backups or check disk usage. These scripts monitor disk fill rates and inform me about potential issues.

#!/usr/bin/env python3
import os
import datetime

# Clean up files older than N days in a specific directory
def cleanup_old_files(directory, days_old):
    now = datetime.datetime.now()
    for filename in os.listdir(directory):
        filepath = os.path.join(directory, filename)
        if os.path.isfile(filepath):
            file_mod_time = datetime.datetime.fromtimestamp(os.path.getmtime(filepath))
            if (now - file_mod_time).days > days_old:
                print(f"Deleting old file: {filepath}")
                os.remove(filepath)

if __name__ == "__main__":
    cleanup_old_files("/var/log/my_app/", 30)
    cleanup_old_files("/tmp/my_temp_files/", 7)

Such simple automations take the burden of manual cleanup off me, allowing me to focus on more important tasks. Additionally, I properly configure .gitignore files in my Git repositories to prevent unnecessary files from entering version control.

Beyond Reducing Mental Load: Why Is It So Important?

Digital organization, for me, is not just about making it easier to find files. It also provides mental clarity and nurtures my creativity. Working in a cluttered environment creates constant "background noise." No matter how much we don't notice it, that disorganization causes our brain to constantly maintain a "to-do" list in a corner.

When I eliminate this disorganization, I have more mental space for more complex architectural decisions, writing better code, and producing more innovative solutions. When working on an AI-powered planning module in a production ERP, having every detail in its place helped me think more clearly about the module's architecture. Digital organization is a kind of meditation; it reduces external chaos and increases internal focus.

Conclusion: A Continuous Improvement Process

Setting up and maintaining my digital organization is not a one-time job; it's a continuous improvement process. I try new tools, optimize my existing workflows, and sometimes let go of old habits. One of the biggest challenges I've faced in this process has been to settle for "good enough" rather than striving for "perfect" organization. Because perfectionism often leads to inaction.

For me, digital organization is one of the keys to living a more productive and calmer life, not just as an engineer, but as an individual. So, how do you set up your own digital organization? What habits or tools are indispensable for you? I'd love for you to share them in the comments.

The Untold Side of Working Remotely for International Companies

Mustafa ERBAY — Wed, 08 Jul 2026 22:51:34 +0000

A few years ago, when considering a remote job offer from a European startup, all I could think about was a better salary and the freedom to "work from anywhere." At that moment, I never imagined this decision could be one of the most expensive "yeses" of my life. Working remotely for international companies often goes far beyond that perfect, tropical beach photo of someone working on a laptop shared on social media, revealing untold and often overlooked realities.

This post aims to share, through my own experiences, not only the allure of working remotely for international companies but also the challenges and overlooked details it brings. I want to address not just the financial gains, but also cultural differences, career impacts, and mental fatigue.

Working Remotely for International Companies: A Dream or Reality?

Working remotely for international companies stands as an appealing option for many of us, promising higher income potential and geographical flexibility. However, this picture often reflects only a part of the reality, with the true challenges remaining behind the curtain. In my own experiences, I've seen that turning this dream into reality requires significant adaptation and expectation management.

The direct and fast communication I was accustomed to while working with a production ERP system was replaced, at times, by delayed and more formal written communication in international remote projects. This directly impacted my ability to solve problems on the fly and the pace of progress on projects.

What's the Difference Between Salary Expectation and Reality?

The first thing that stands out in international remote job offers is usually the gross salaries, which are above Turkish standards. This naturally becomes a great source of motivation. However, the erosion these gross figures experience when converting to net can often dampen the initial excitement.

Factors like taxes, social security contributions, and currency fluctuations significantly affected the net amount that landed in my pocket. On one occasion, due to a new tax agreement, I experienced a noticeable drop in my monthly net income, which disrupted my budget plans. Embarking on this journey without thoroughly researching this topic can lead to a serious financial surprise.

ℹ️ Tax and Social Security

How your salary from abroad will be taxed in Turkey and the status of social security contributions vary depending on the double taxation avoidance agreements between Turkey and the country you work for, and your residency status. It is critical not to make a decision on this matter without consulting an expert.

What's the Reality Behind the "Flexibility" Curtain?

While "flexibility" is one of the biggest promises of remote work, especially in international remote jobs, this concept can have its limits. The time zone of your team directly affects your working hours. Even a few hours' time difference can mean attending meetings very early in the morning or late at night, Turkish time.

While developing the backend for my own side product, I was used to working according to my own schedule. However, at an international company, during a critical phase of a project, I repeatedly had to attend an "emergency" meeting that started at 11:00 PM Turkish time. This taught me that flexibility is not unilateral and is shaped by the company's needs.

What are the Cultural Adaptation and Communication Challenges?

Working with a different country's culture doesn't just involve overcoming a language barrier; it also creates significant differences in communication styles, work ethic, and expectations. Receiving direct criticism in a meeting, or conversely, understanding indirect expressions, can sometimes be confusing.

In a client project, while working with a development team, my constructive feedback, "this part could be more efficient," was perceived by the other side as "I don't like your work." Such misunderstandings can sometimes lead to team friction and loss of motivation.

How is Long-Term Career Development Affected?

Remote work, especially for international companies, can affect career development in different ways. Not being physically present in the office can lead to you being disconnected from the company's internal network and decrease your visibility. This can create a disadvantage when it comes to promotions or being assigned to larger projects.

In a friend's experience, he found that because he worked remotely, he couldn't participate in internal mentoring programs and was always excluded from informal conversations where important decisions were made. This is an important factor we need to consider when planning our career path in the long run.

Conclusion

Working remotely for international companies is undoubtedly a model that opens many doors and offers significant opportunities. However, alongside the advantages this model offers, there are also serious challenges and trade-offs that should not be overlooked. What I've seen in my 20 years of experience is that before embarking on this journey, it's crucial to manage expectations very well and plan financial and cultural adaptation processes in detail.

A high salary offer alone may not always be the "best" option. So, what surprised or challenged you the most in your experiences working remotely for international companies? Please share in the comments!

Why Senior Developer Experience Can Sometimes Be a Hindrance

Mustafa ERBAY — Wed, 08 Jul 2026 21:47:17 +0000

Why does senior experience sometimes become a bottleneck?

When adding a new reporting module to a production ERP, a two-week sprint was delayed by a week because a senior developer insisted "this code must conform to the architecture"; this showed how their experience became an obstacle rather than an advantage. The accumulated knowledge of senior developers increases the weight of decisions, and often the search for the "best way" slows down the current flow.

At the core of this slowdown is the focus on high-level abstractions while overlooking details. For example, when adding a microservice, a senior engineer's insistence that "all services must share the same data model" might prevent data consistency issues, but it also extends the dependency chain, slowing down the CI/CD pipeline. Such decisions can reduce short-term technical debt but extend long-term delivery time.

Furthermore, senior developers' reliance on "past experience" can make it difficult to adopt new technologies. In many cases, a team resists a suggestion like "Go instead of Node.js"; this resistance creates a culture within the team of "we already work with this language" and stifles innovation. At this point, the authority that comes with experience restricts internal team discussion processes, centralizing decisions around a single person.

What kind of delays occur in the code review process?

During the code review phase, a senior developer's request to "expand the boundaries of this function" can triple the PR (pull request) duration. For example, in a PR I opened to add a feature, a senior team member made a comment like this:

$ git diff HEAD~1 HEAD
--- a/app/api/production.py
+++ b/app/api/production.py
@@ -42,7 +42,12 @@
-    return db.query(...)
+    # TODO: Refactor to use generic repository pattern
+    # This function needs to be common across all services.
+    # Please also add transaction management.

This comment requested not only code changes but also an architectural revision. As a result, an additional sprint was planned to revise the changes.

Another example: during the review of journalctl -u myservice -n 20 output, a senior developer suggested "change the log level from DEBUG to INFO," ignoring the risk of increasing log volume. This decision raised log storage costs in the production environment and created unnecessary noise in the monitoring system. Such a suggestion affected not only code quality but also operational costs.

The root cause of code review delays is often the pursuit of "perfect perfection." This pursuit requires continuous revision of an "completed" piece of code within the team and prolongs the delivery process.

⚠️ Code Review Tips

Implement time-boxed reviews within the team; for example, provide feedback for each PR within a maximum of 2 hours. This ensures rapid progress without getting stuck on perfection.

How does the weight of architectural decisions create a problem?

In a large e-commerce project, a senior developer's decision that "all services should share a single data schema" extended the data migration process from 6 to 9 months, causing the project to miss a critical deadline. Behind this decision was a long-standing "single point of management" philosophy regarding data consistency; however, in a modern microservice architecture, this approach reduces service independence and scalability.

An example systemd unit file used in the decision process:

[Unit]
Description=ERP Production Service
After=network.target postgresql.service

[Service]
Type=exec
ExecStart=/usr/local/bin/erp-prod
Restart=on-failure
# Senior suggestion: Manual intervention on every error, instead of Restart=always

This configuration prevented the service from restarting automatically, leading to prolonged production outages in case of an error. Here, the negative impact of the "manual intervention on every error" principle on operational continuity is clearly visible.

Another side effect of architectural decisions is the "single point of decision" risk that arises "when decisions are made by a single person." This risk, especially when an urgent security vulnerability (e.g., CVE-2026-31431) emerges, prevents a quick patch from being applied, waiting instead for the senior developer's approval process.

Communication and knowledge sharing barriers

In a fintech project, a senior engineer's statement "I already solved this issue a year ago" caused a new team member to rediscover the same problem; as a result, a two-week debugging session was unnecessarily repeated. This situation indicates the formation of knowledge silos and a lack of emphasis on knowledge sharing by an experienced individual.

In a similar scenario, while showing the systemctl status myservice output, a senior developer stated, "the logs for this service are not necessary for us," and set the log level to Warning. Real-time monitoring teams missed a critical error message due to this setting, and the problem went undetected in the production environment for 3 hours. This example demonstrates how miscommunication can directly lead to service outages.

Communication barriers are also fueled by "a senior's 'I know' attitude." This attitude prevents new team members from asking questions and thus prolongs the learning process. As a solution, establishing weekly "knowledge sharing" sessions and an open "wiki" culture can reduce these bottlenecks.

The cost of performance and scaling decisions

In a large data processing pipeline, a senior developer's suggestion to "completely disable the Redis cache" increased query time by 40% and doubled CPU usage. Immediately after this decision, the redis-cli INFO output was observed as follows:

# Server
redis_version:6.2.6
...
# Memory
used_memory:10485760
used_memory_peak:10485760

When the cache was disabled, the same queries were directed straight to PostgreSQL, and "waiting for lock" lines increased in the pg_stat_activity output. This shows that performance delays were directly caused by a decision error.

Another example is a senior engineer's strategy to "prevent OOM by keeping container limits high." This strategy, in the docker stats output:

CONTAINER ID   NAME          CPU %   MEM USAGE / LIMIT
a1b2c3d4e5f6   erp-prod      12.5%   1.2GiB / 2GiB

These limits led to disk thrashing (disk I/O bottleneck) when multiple pods needed to run simultaneously. Consequently, the I/O wait ratio in the iostat -dx report reached 25%, and the application's response time increased significantly.

The cost of performance decisions is measured by "translating experience-based assumptions into directly measurable results." At this point, validating decisions with real-time metrics is a critical step.

How do we overcome the bottleneck?

Instead of a senior developer saying, "I must approve it first," an approach of "let's only pass the code through tests and static analysis" can reduce review time by 60%. When implementing this strategy, the following flowchart visualizes the process:

In this flow, the senior developer's role is shifted to the final approval stage; other steps are automated. Thus, "senior approval" remains a gate, but it does not create delays.

Another solution is to share senior experience directly with juniors through the "pair programming" model. For example, by running the systemd-analyze blame command together, we can instantly identify bottlenecks in service startup times:

$ systemd-analyze blame
5min 30.123s postgresql.service
2min 12.456s myservice.service
30.789s network-online.target

This numerical data provides a concrete basis for decisions and transforms "experience" into shared knowledge.

ℹ️ Experienced and Agile Team

Using a senior developer's experience as a catalyst instead of an obstacle fosters a mentorship culture within the team; this, in the long run, increases delivery speed.

Conclusion

Senior developers' experience can be a power source for projects, but it can also create a bottleneck due to decision weight, code review delays, and communication silos. As I've seen in real scenarios, these bottlenecks result in measurable delays, performance losses, and increased costs. However, it is possible to overcome these obstacles by breaking down the decision-making process, increasing automation, and systematizing knowledge sharing.

My clear position is this: we should position senior experience as a strategic resource, but we must balance its weight in processes. This way, the team can operate at an optimal point in terms of both speed and quality.

The Forgotten Cost of Security in Indie Hacker Projects

Mustafa ERBAY — Wed, 08 Jul 2026 21:38:59 +0000

Last year, while developing the backend for a small side project of mine, I skipped some security steps, thinking, "it's just a small project, who would attack it?" As a result, a simple brute-force attempt briefly cut off my server access, costing me both time and morale. In indie hacker projects, security often takes a backseat to feature development, and its true costs only become apparent when a problem arises. This post, drawing from my own experiences, discusses why security should not be neglected in indie hacker projects and what this "forgotten cost" can lead to in the long run.

It's understandable that indie hackers focus on quickly launching products with limited resources. However, security is not just a luxury for large corporate structures; it's a fundamental necessity for projects of all sizes. Taking the right steps early on can prevent major crises in the future and ensure your project's sustainability.

Why Do Indie Hackers Overlook Security?

Indie hackers typically operate with limited time, budget, and human resources. This often forces them to make compromises when prioritizing, and unfortunately, security is frequently one of the first areas to be sacrificed. I've fallen into this trap many times. Adding a new feature or fixing an existing bug often seems to offer a more immediate and visible benefit than patching a potential security vulnerability.

The thought, "my project isn't that big, who would bother?" is actually a very common misconception. Attackers, regardless of your project's size, scan for easy targets with automated bots and act when they find weaknesses. Even a small vulnerability can jeopardize your entire project and user data. Therefore, security is not just a feature; it's an existential part of your project.

What is the True Cost of a Breach?

A security breach is not limited to direct financial losses; it can have much broader and more devastating effects. Issues like stolen user data, service outages, or reputational damage can spell the end of a project for an indie hacker. I recall facing a potential risk of user data exposure due to a faulty API authorization in an Android spam blocking app I quickly put together. This led me to a days-long process of fixing the issue and rebuilding trust.

⚠️ Invisible Costs

After a breach, not only are there direct financial losses, but also invisible costs such as permanent damage to the project's reputation, loss of user trust, potential legal proceedings (like GDPR non-compliance), and valuable time spent fixing the breach. These costs can create burdens that are very difficult to recover from, especially for small and independent projects.

The process of fixing a breach is also a cost in itself. It can require days of debug sessions, log analysis, security patches, and perhaps even architectural changes. During this process, time and energy that should be allocated to new feature development or marketing are spent managing the security crisis. Moreover, this can halt your project's progress, potentially causing you to lose your competitive edge.

What Are the Minimum Security Fundamentals?

Every indie hacker project, regardless of its size, should have certain minimum security fundamentals. These are "must-have" steps that will protect your project against basic threats. I always implement certain practices when managing my own servers. For instance, making SSH access key-based only and blocking failed login attempts with fail2ban forms the first line of defense for the system.

At the application layer, adhering to fundamental principles like input validation and parameterized queries prevents common attacks such as SQL injection. Additionally, ensuring that all libraries and dependencies I use are up-to-date plays a critical role in patching vulnerabilities that might arise from known CVEs. While these steps might initially seem like extra work, they have saved me headaches in the long run.

# Basic firewall rules (with ufw on Ubuntu)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

# fail2ban installation and basic configuration
sudo apt update
sudo apt install fail2ban
# Enable jails for SSH and Nginx in /etc/fail2ban/jail.local
# [sshd]
# enabled = true
# port = ssh
# filter = sshd
# logpath = %(sshd_log)s
# maxretry = 3
# bantime = 1h

How Should the Security Development Flow Be Structured?

Security is not a one-time task but an ongoing process that should be a natural part of your development flow. One of the most valuable lessons I learned while working on a production ERP was this: integrating security tests into the CI/CD pipeline. Automated static code analysis (SAST) and dynamic application security tests (DAST) helped me catch potential vulnerabilities before the code went live.

Establishing continuous monitoring and alert mechanisms is also of great importance. Regularly checking journald logs or auditd outputs allows me to detect unusual activities or failed login attempts early. Furthermore, performing regular backups and testing these backups with restoration scenarios is the only way to recover quickly in case of data loss.

Database Security: Often Overlooked Points

Databases are critical components that store the most valuable data for most applications, making them primary targets for attackers. In indie hacker projects, database security often remains at the level of "just set a username and password," but there are much deeper points that should not be overlooked. When using PostgreSQL in my own projects, I ensure that connection strings are stored securely and that database users have only the minimum necessary privileges.

For example, correctly configuring the pg_hba.conf file allows you to precisely define who can access the database, from which IP addresses, and by what methods. Additionally, encrypting data both at rest and in transit helps protect sensitive information from unauthorized access. While working on the backend of a performance-oriented ERP, I saw that slow queries caused by incorrect index usage could actually be a potential vector for a Denial of Service (DoS) attack. Therefore, correct indexing strategies indirectly affect not only performance but also security.

ℹ️ Basic Security Tips for PostgreSQL

pg_hba.conf Configuration: Restrict database access to specific IP addresses and users only. Use more restrictive rules instead of general permissions like host all all 0.0.0.0/0 md5.

Principle of Least Privilege: Grant your application's database user only the necessary privileges such as SELECT, INSERT, UPDATE, DELETE; never grant SUPERUSER privileges.

SSL Connections: Always encrypt database connections over SSL. This is critically important, especially if your application and database are on different servers.

Regular Backups: Take regular database backups and store them in a different location. Periodically test the restorability of these backups.

Even operational issues like WAL bloat can indirectly pose security risks. Excessively growing WAL files can consume disk space, leading to service outages, or potentially cause sensitive data to remain in logs longer than necessary. Therefore, database maintenance and optimization are an integral part of a security strategy.

Practical Steps in Network Security

Network security in indie hacker projects is often approached at the level of simply "open the firewall" or "forward ports." However, there are many more practical steps that can be taken at this layer where your server and application are exposed to the outside world. On my own VPS, I start by setting up basic firewall rules with tools like ufw or firewalld. This ensures that only necessary ports (like SSH, HTTP/S) are open, closing unnecessary access points.

If multiple services run on the same server, even a simple VLAN segmentation can logically increase isolation between services. However, for an indie hacker, this can often be unnecessary complexity. A more practical approach is to use a reverse proxy like Nginx to manage all traffic from a single point and establish the first line of defense against DDoS attacks with rate limiting at this point. Furthermore, we can add modules that provide a basic Web Application Firewall (WAF) feature to the Nginx configuration to provide additional protection against common web attacks.

# Example of basic rate limiting with Nginx
# Add to http block
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

server {
    listen 80;
    server_name example.com;

    location / {
        limit_req zone=mylimit burst=10 nodelay;
        proxy_pass http://localhost:8000; # The port your application runs on
        # Other proxy settings
    }
}

Instead of directly exposing the SSH port to the internet for remote access, using a VPN solution significantly enhances access security. Advanced concepts like Zero Trust architecture might be overkill for small projects, but applying their core principles (always verify, least privilege) is always beneficial. DNS security is also often overlooked; however, technologies like DNSSEC can help protect your domain name against spoofing.

How to Optimize Security with Time and Budget Constraints?

One of the biggest challenges for indie hackers is to ensure the best possible security with limited time and budget. In this situation, instead of striving for perfection, it's crucial to focus on addressing the most critical risks and taking steps that will yield the highest return. I always make this trade-off in my own projects: I think, "we would have done X, but since we didn't have Y resources, we chose Z."

First, identify your project's most sensitive data and most critical functions. Direct your security investment primarily to these areas. For example, user authentication and payment processing sections have a much higher priority than a comment section on a blog site. Second, leverage open-source and community-supported security tools to the maximum extent. Tools like fail2ban, ufw, Nginx are excellent options for providing strong security with minimal cost.

💡 Strategies to Reduce Security Costs

Prioritization: Focus on protecting your most critical assets and data flows. Not every vulnerability carries the same risk level.

Automation: Automate repetitive security tasks. Integrate security checks into your CI/CD pipeline.

Open Source Usage: Opt for powerful open-source tools like fail2ban, Nginx instead of paid solutions.

Continuous Learning: Stay updated with developments in the security field and educate yourself. Learning simple security practices can make a big difference.

Simplicity: Keeping architectures and codebases as simple as possible reduces security vulnerabilities. Complexity is the enemy of security.

Finally, don't compromise on simplicity. Complex systems tend to harbor more security vulnerabilities. Keeping your architecture and codebase lean not only increases your development speed but also reduces security risks. Remember, security is not a destination, but a continuous journey. By constantly educating myself on security topics and updating my practices, I strive to ensure the longevity of my projects.

Conclusion

In indie hacker projects, security is often an overlooked but critical area that can lead to catastrophic costs. While "quick and dirty" approaches might seem appealing initially, the reputational damage, financial losses, and operational disruptions caused by a security breach can often mean the end of a project. From my own experiences, I've seen that integrating fundamental security practices into the early stages of the development process is indispensable for the long-term health of your project.

Establishing minimum security fundamentals, paying attention to database and network security, and automating security processes even with limited resources will protect your project from many common threats. Security is not a feature; it is the foundational pillar of your project. Keeping it strong will carry you further on the challenging yet rewarding journey of independent development. In my next post, perhaps I'll share an OOM issue I encountered while setting cgroup limits for systemd units and its security implications.

The Frenzy to Chase Every Technology: Pragmatic Engineering

Mustafa ERBAY — Wed, 08 Jul 2026 20:16:17 +0000

Last week, a message that landed in my inbox struck right at the heart of that big career dilemma I'd been grappling with for a long time, but couldn't quite name. The message read, "Mustafa abi, should I learn systems, focus on backend, or dive into these new AI agent architectures? When I try to look at all of them, my head spins, and I feel like I'm not specializing in anything by the end of the day." This question was the most concrete summary of the "know everything and jump on every train" hysteria that has descended upon our industry in recent years.

Throughout my nearly twenty years of field experience, I've seen similar confusion countless times, both in myself and in the teams I've worked with. The consumption rate of technology has increased so much that a new library or system is released before you can even fully learn the previous one. This situation creates a serious sense of inadequacy and a loss of direction, especially for engineers at the beginning and middle of their careers. In this post, drawing from this excellent topic suggestion, I will share my perspective on why trying to keep up with everything is a career suicide and how we, as pragmatic engineers, can stay afloat.

What Was the Suggestion and Why Is It So Familiar?

The core concern in the email I received was a natural consequence of the information bombardment we all face every morning when we open our browsers. The sender explained that while he wanted to delve into the depths of PostgreSQL, he was also drowning in the details of a new-generation frontend framework, all while juggling Docker and Linux system administration tasks at his company. Adding to this the pressure of "AI is coming, it will end coding, I must learn agent architectures immediately," it created a complete state of analysis paralysis.

This situation feels very familiar because I went through a similar path. Years ago, I was simultaneously trying to do VLAN segmentation and configure switches, writing systemd units on Linux servers, and struggling with the database performance issues of an enterprise ERP. At that time, I believed I had to know everything with the same depth, and it wore me out immensely. Over time, I realized that knowing everything is not only impossible but also an illusion that degrades engineering quality.

ℹ️ Pragmatic View

Engineering is not about knowing how to use all the tools; it's about the ability to choose the right tool to solve the given problem with the least cost and highest reliability. Tools change, fundamental principles remain.

The Illusion of Knowing Everything: Full-Stack Myth or Industry Pressure?

There's a "Full-Stack" myth that has been marketed in the industry for a long time. This concept arose from companies' desire to hire system administrators, database administrators, frontend developers, and backend developers all for a single salary. However, in practice, finding someone who is equally specialized in every area is almost impossible. Someone who is very good in one area will inevitably remain superficial in others. This is the biggest factor leading to systems crashing at critical moments.

For instance, you can't expect a developer who writes a fantastic interface to deeply understand the B-tree indexing logic of the PostgreSQL database behind it or the impact of VACUUM processes on disk. Conversely, it's unfair to ask a system administrator who meticulously calculates cgroup memory limits in the Linux kernel to solve the complexities of state management in modern browsers. Trying to load all these roles onto a single person will cause that person to have "a little" knowledge in every area and become unable to "produce solutions" in any.

The Practical Limits of Being a T-Shaped Person

So, what's the solution? The "T-Shaped" person model, often heard in the industry, comes into play here. This means having a general knowledge base in many areas (the horizontal bar of the T) and specializing deeply in one or at most two areas (the vertical bar of the T). While this model sounds great in theory, its practical application requires serious discipline. Because if you don't know where to draw that vertical bar, your T will eventually turn into a rake, and you won't be able to dig deeply anywhere.

My T model has evolved over time to look like this: horizontally, it includes network topologies, Linux services, and basic frontend knowledge; my vertical specialization areas are enterprise software architecture, PostgreSQL database management, and system security. If I encounter a switch loop or routing flap issue on the network side, I know enough network knowledge to understand and diagnose the problem. However, I wouldn't attempt to optimize the BGP routing decisions of a global telecom infrastructure; I'd leave that to the real expert. The important thing is to be able to draw your own boundaries.

Pragmatic Engineering: Which Technology to Discard, Which to Hold Onto?

Every day, a new library, a new database, or a new cloud tool is thrown at us. How do we understand which of these will last and which will be forgotten in two years? This is where the pragmatic engineering filter comes in. Before I adopt a technology into my life, I ask myself these questions:

Does this technology truly solve a real problem I am currently trying to solve?
Is there a strong, independent, and standards-based community behind it?
Does the abstraction layer introduced by this technology allow me to debug when errors occur, or does it turn the system into a black box?

If a tool is very popular but has nothing but a huge technology company's marketing budget behind it, I approach it with suspicion. For example, I wouldn't move an application that can be easily set up with Docker Compose and run for years without issues into a complex Kubernetes cluster just to be "modern." Or I wouldn't immediately try to build a complex distributed architecture for a data processing task that could be handled by a simple Python script. Pragmatism is choosing not the coolest, but the most boring yet most reliable option.

A Real-Life Example: A Decision Point in a Manufacturing ERP

While working on a manufacturing ERP, we needed to present real-time data for the factory's production planning and metrics from operator screens. The enthusiastic colleagues on the team immediately jumped in, saying, "We absolutely must set up an event-sourcing architecture here, every operator action should be an event pushed to Kafka, and then processed by microservices." It sounded like a very cool project, worthy of a CV.

However, considering the factory's physical conditions, the stability of the network infrastructure, and the team's maintenance capacity, I knew this decision would lead to disaster. Instead, we used standard mechanisms offered by PostgreSQL, optimized indexes, and a simple FastAPI backend with WebSocket connections. The result? The system ran flawlessly for years with practically zero maintenance cost, without losing any messages, and without dealing with complex distributed transaction management. This is the very essence of pragmatic engineering.

Approach	Complexity	Maintenance Cost	Ease of Debugging
Recommended (Kafka + Event Sourcing)	Very High	High (Requires separate teams)	Difficult (Distributed log tracing)
Implemented (FastAPI + PostgreSQL + WS)	Low	Very Low (Single database)	Easy (Standard SQL and logs)

The 20-Year Yogurt-Eating Habit: How My Career Filter Works

After all these years of running around in the industry, my greatest gain has been the ability to decide what I should not learn, rather than what I should learn. My personal career and technology filter is built on these three fundamental pillars:

Invest in Fundamentals: Learning how the Linux kernel works, the handshake stages of the TCP/IP protocol, and the transaction isolation levels of relational databases is an investment that will never become obsolete. A JavaScript framework you learn today might disappear in three years, but TCP/IP has been around for thirty years and will be around for thirty more.
Learn to Read Error Symptoms: Knowing what to look for in logs when a system crashes is the greatest indicator of expertise. Correctly filtering journald logs, understanding why a systemd service was OOM-killed, or being able to diagnose deadlocks in PostgreSQL will always make you the sought-after person.
Use AI as a Partner, Not a Crutch: I frequently use AI tools (LLMs, code assistants) when coding or researching complex system configurations. However, unless I have the fundamental knowledge to verify the output they produce line by line, I will never deploy those codes to a production environment. AI can increase your speed, but it doesn't reduce your responsibility.

Final Word: How to Build Your Own Filter?

If you also feel like you're drowning trying to keep up with everything, the first thing you should do is take a deep breath and close those fifty different tabs in your browser. Choose a main focus area for yourself. This could be backend, system administration, or data engineering. Deeply immerse yourself in this area; push the limits of those systems, make mistakes, and solve those mistakes yourself.

Don't completely ignore other areas, but keep them at a "general knowledge" level. It's enough for a system administrator to understand software architecture, and for a developer to be aware of the resource limits of the server their application runs on. There's no world where everyone knows everything; there are only people who pretend to know everything and are lost when the first serious crisis hits. Don't be one of them.

In my next post, I will explain how we practically configure cgroup limits to prevent unnecessary resource consumption on Linux servers and the impact of these limits on application stability.

3 Critical Steps When Choosing AI-Powered Developer Tools

Mustafa ERBAY — Wed, 08 Jul 2026 20:08:20 +0000

Recently, a teammate asked me, "Which AI code completion tool should we use?" when starting a new integration project. There are so many options on the market that instead of giving a direct answer, I thought a systematic approach to choosing the right tool would be more beneficial. Selecting AI-powered tools to boost developer productivity should go beyond simply trying what's popular; it requires a strategic process.

When choosing an AI-powered developer tool, especially if we're considering integration into production environments, it's essential to consider much more than personal preferences. To make the right decisions in this process, it's crucial to accurately analyze needs, compare available options, and validate with small pilot applications. In this post, I'll share the 3 critical steps I follow and my experiences when making this decision.

Why Do We Need AI-Powered Developer Tools?

Over the past few years, we've seen a significant transformation in software development processes. Many routine tasks we used to do manually can now be automated or significantly accelerated with AI-powered tools. I've seen the benefits of these tools countless times, whether developing the backends for my own side projects or working on complex modules of a production ERP.

These tools save time, especially in areas like writing boilerplate code, generating skeletons for simple functions, or refactoring existing code. Sometimes, I can get a draft of a complex SQL query in seconds just by writing a comment. This reduces context switching costs, allowing me to focus more on my main work.

ℹ️ Context Switching Cost

Developers carry a cognitive load when switching from one task to another. AI tools, especially in areas like code completion and documentation, can alleviate this load, helping developers stay in a "flow" state. This allows us to work more efficiently with fewer interruptions.

However, to fully leverage the potential of these tools, focusing solely on technological innovation isn't enough. We need to understand which tool is best suited for my and my team's workflow, how it will integrate with our existing infrastructure, and most importantly, what risks it poses in terms of data security. This is critical not only for productivity but also for operational security and compliance.

Step 1: Comprehensively Analyze Your Needs and Existing Infrastructure

As with any technology investment, the first step when choosing AI-powered developer tools is to clarify what we truly need. The "everyone else is using it, so should we" approach often leads to disappointment. In a production ERP, do we want to increase the development speed of new modules, or do we aim to optimize refactoring processes to reduce technical debt in the existing codebase? The answers to these questions play a fundamental role in selecting the right tool.

For example, in one of my projects, I observed that manual test writing was very time-consuming and couldn't keep up with continuous updates. In this case, an AI tool capable of generating automatic test scenarios becomes a priority. If the problem is keeping complex API documentation up-to-date, a tool that generates documentation or comments on existing code would be more valuable.

Compatibility with Existing Technology Stack

The AI tool we choose must seamlessly integrate with the programming languages, IDEs, version control systems (Git), and CI/CD pipelines we use. In a project where I use a FastAPI backend, a Vue/React frontend, and a PostgreSQL database, I would look for a tool that can natively integrate into this ecosystem. If the tool works as a plugin for our existing IDE (like VS Code or IntelliJ), it provides a significant advantage in terms of developer experience.

⚠️ Integration Should Not Be Overlooked

No matter how powerful an AI tool is, if it cannot seamlessly integrate into your existing development environment or constantly requires manual intervention, it will create more complexity than productivity in the long run. It's also important to consider installation and maintenance costs.

Furthermore, understanding the AI tool's operating principles is also important. Does it run on our own servers (on-premise), or does it offer a cloud-based service? With cloud-based solutions, sending our code or data to a third-party provider raises critical questions regarding data security and intellectual property. In a financial calculator project, I would prefer local or tightly controlled solutions to minimize the risk of sensitive business logic code leaking externally.

Step 2: Compare Various AI Tools and Understand Their Limitations

The market is flooded with AI-powered developer tools: code completion, test generation, refactoring suggestions, documentation assistants, and even debugging aids. Each has different capabilities and limitations. Therefore, comparing potential candidates against objective criteria is vital.

Here are the key criteria I consider when making comparisons:

Accuracy and Relevance: How accurate are the code snippets or solutions suggested by the tool, and how relevant are they to the context of my project? What is its tendency to produce "hallucinations," i.e., incorrect or fabricated outputs? This is critical, especially for complex algorithms or parts involving business logic.
Speed and Latency: If a code completion tool doesn't provide suggestions instantly, it disrupts the developer's flow. Latency can be a significant factor, especially with cloud-based solutions. This is why I consider speed-focused providers like Groq or local solutions like Cerebras for my own AI applications.
Integration and Supported Languages: How compatible is the tool with the IDEs and programming languages (Python, JavaScript, Go, C# etc.) we use? In projects using multiple languages (e.g., a FastAPI and Vue.js combination), supporting both sides is a huge advantage.
Cost Model: It's necessary to evaluate subscription fees, pay-per-use (token-based), or models offering different tiers. Whether we're working with a small team or a large corporate structure influences this choice.
Data Privacy and Security: How the tool processes our code, whether it stores it, and whether it uses it as a training dataset are very important. This can be a "deal-breaker," especially for projects dealing with sensitive data. It's essential to question its compliance with corporate security policies.

Underlying Models and Their Limitations

Most AI-powered developer tools are backed by large language models (LLMs). These models have their own limitations. For example, a limitation called "context window" determines how much information the model can process at once. If we are working on a very large code block, it's possible that the model may not understand the entire context and provide irrelevant suggestions.

In such cases, architectures like Retrieval-Augmented Generation (RAG) come into play. In my own AI applications, I frequently use the RAG pattern to ensure the model has access to more specific and up-to-date information. This is critical for getting accurate and relevant outputs, especially in complex and niche areas. It's important to remember that the model doesn't always know everything, and human oversight is indispensable.

Step 3: Conduct Pilot Applications and Measure Performance

No matter how good theoretical comparisons and feature lists are, the best way to understand the true value of an AI tool is to try it in a controlled environment. That's why I select the 1-2 most suitable candidates from the potential options and conduct trials on a small pilot project or a specific module.

During these pilot applications, I define clear metrics to understand if the tool truly delivers the promised benefits. For example:

Code writing speed: We can compare how long it takes to complete a specific task (e.g., creating a new API endpoint) with and without the AI tool. Qualitatively, we can use phrases like "significant acceleration" or "roughly half the time," as a precise, numerical metric may not always be achievable.
Error rate: The number of errors in AI-generated code that require manual correction or issues found by static analysis tools.
Developer satisfaction: Team members' experiences using the tool, challenges encountered, and overall satisfaction levels. Collecting this feedback through surveys or one-on-one interviews is very beneficial.
Code quality: The readability, maintainability, and adherence to best practices of AI-assisted code.

💡 Establish a Feedback Loop

Continuously gathering feedback from developers during the pilot application is critical for understanding the tool's strengths and weaknesses. This feedback allows you to evaluate not only technical performance but also user experience.

During the pilot phase, we also get the opportunity to closely observe integration challenges. Do IDE plugins work correctly? Is there automation that can be added to CI/CD pipelines? For example, when writing a new data integration for a module in a production ERP, I can track how much the AI tool helped in this process, in how many iterations it produced the correct code, and how many manual corrections were needed. This allows me to base my decision on more concrete data.

Challenges and Lessons Learned in AI Tool Integration

AI-powered developer tools can bring challenges as much as they promise benefits. I've learned some lessons from these integration processes in my own projects or in organizations I've consulted for:

"Hallucination" and Trust Issues: AI models can sometimes generate incorrect or fabricated information. This can lead to overconfidence, especially in new developers, and cause critical errors. Once, a recommendation I received from AI for an SQL query included a non-existent table name. Fortunately, I caught it in tests, but such situations reinforced the habit of always questioning model outputs.
Context Window Limitations: In large and complex codebases, the AI tool's inability to understand the entire context can lead to irrelevant or incomplete suggestions. Especially when navigating between long functions or modules, the model "forgetting" the previous code block can be frustrating. This is why I use RAG patterns in my own AI applications to give the model access to a wider context.
Data Privacy and Intellectual Property Concerns: Cloud-based AI tools can send our code or project data to external servers. In a client project, the security team identified this as a risk and restricted the use of certain AI tools in a project containing sensitive code. In such cases, on-premise solutions or providers offering stricter data protection policies come into play.
Over-reliance and Skill Degradation: Some developers can become overly dependent on AI tools. This can dull fundamental programming skills or problem-solving abilities. It's important to remember that the tool is just an assistant; the primary problem solver is still human. My observation is that these tools mostly increase the productivity of experienced developers because they can filter and optimize AI output faster.
Integration and Maintenance Burden: Integrating or keeping some AI tools up-to-date with existing development environments can require additional effort. Compatibility issues may arise with new IDE versions or framework updates. This is an additional operational burden that can overshadow the potential benefits of the tools.

Despite these challenges, I have experienced that correctly chosen and consciously used AI tools significantly increase developer productivity. The key is to evaluate these tools with a critical eye and always keep the "garbage in, garbage out" principle in mind.

Conclusion

AI-powered developer tools have the potential to transform our software development processes. However, instead of rushing when choosing these tools, we must adopt a strategic and systematic approach. Accurately analyzing our needs, comprehensively comparing available options, and validating with small pilot applications will increase our chances of success in this process.

In my practice, these 3 critical steps – needs analysis, detailed comparison, and pilot application – have always enabled me to make the most accurate decision. Let's not forget that these tools are merely assistants; the true creativity, problem-solving ability, and critical thinking will always remain with us developers. Equipped with the right tools, we can build the software of the future faster and more efficiently.

Authenticator Apps vs. SMS 2FA: 3 Key Differences in Security

Mustafa ERBAY — Wed, 08 Jul 2026 18:49:04 +0000

While designing the user management panel for one of my side projects recently, I was reviewing the two-factor authentication (2FA) options. Despite the easy setup of SMS-based 2FA, security vulnerabilities in critical systems, in particular, pushed me towards authenticator apps. These two common 2FA methods have three fundamental differences in terms of security mechanisms, attack resistance, and usage practices, and understanding these differences helps us decide which method to use and where.

While SMS 2FA offers an undeniable advantage in user-friendliness, its weaknesses against external threats like SIM swap attacks and phishing attempts make it risky for critical data. On the other hand, apps like Google Authenticator or Authy, with their offline functionality and stronger cryptographic foundations, provide a much more resilient layer for protecting financial or sensitive personal data. As a system architect, considering these nuances when designing security layers is not just a technical choice, but also part of our responsibility to protect our users' assets.

Why is Two-Factor Authentication (2FA) So Critical?

In a software development project, when the "my account was compromised" complaints from users increased, I observed that it was mostly due to weak or stolen passwords. It was precisely at this point that I clearly understood why passwords alone are insufficient and why a second layer of verification is vital. Two-factor authentication (2FA) is an additional security barrier designed to prevent unauthorized access, even if your username and password are compromised.

This second factor typically comes from the categories of "something you know" (password), "something you have" (phone, authenticator app), or "something you are" (fingerprint, facial recognition). Our goal is to minimize the probability of an attacker obtaining both factors simultaneously. Even on the backend of my own financial calculators, I've made 2FA mandatory to enhance password security; because I know users' password habits are often far from ideal.

ℹ️ Security Layers

2FA is an important part of the defense-in-depth principle. We aim to create multiple layers of security to prevent a single weak point from bringing down the entire system. Passwords are often the first line of defense, but due to the weaknesses of the human factor, we always need a secondary verification.

How Does SMS-Based 2FA Work and What Are Its Main Vulnerabilities?

SMS-based two-factor authentication is, I believe, the most widely used 2FA method, and its primary reason is its simplicity. When you try to log into a service, the system sends an SMS to your registered phone number containing a one-time password (OTP), and you are asked to enter this code on the login screen. Since it doesn't require any additional app downloads or complex setup from the user's perspective, it's a method I sometimes prefer for some less critical systems.

However, this simplicity also comes with serious security vulnerabilities. One of the most well-known risks is SIM swap attacks. Here, the attacker, through social engineering or phishing methods, tricks the telecommunications company into porting the victim's phone number to their own SIM card. Once the number is compromised, all SMS messages are redirected to the attacker's device, thus gaining access to sensitive information, including 2FA codes. A case I observed on a bank's internal platform painfully demonstrated how victims' accounts could be emptied within a few hours.

Furthermore, SMS messages are transmitted as unencrypted text by nature and can be intercepted through SMS forwarding, SS7 vulnerabilities, or malware. Malicious software on your phone can read incoming SMS messages and send them to the attacker. Additionally, phishing attacks pose a significant risk to SMS 2FA. An attacker redirects you to a fake login page, you enter your password, and then the fake page asks for the 2FA code. The moment you enter the code, the attacker instantly logs into the real site and compromises your account. These types of attacks can be quite effective, especially in scenarios that distract or rush users.

Authenticator Apps (TOTP/HOTP) and Their Security Mechanism

Authenticator apps offer a more advanced security layer than SMS 2FA and typically use Time-based One-Time Password (TOTP) or HMAC-based One-Time Password (HOTP) algorithms. Apps like Google Authenticator, Authy, and Microsoft Authenticator work on this principle. During setup, the service provides you with a unique "secret key," usually in the form of a QR code. When you add this key to your authenticator app, the app and the server use the same algorithm and key to continuously generate new one-time codes.

The TOTP algorithm generates a code valid within a specific time frame (usually 30 or 60 seconds). Both the server and the app independently generate these codes using the same time synchronization and secret key. This means codes can be generated even without an internet connection. HOTP, on the other hand, uses a counter that increments each time a code is used, independent of time. This counter remains synchronized on both the server and the app. In the custom login system I built for my own site, I opted for TOTP to enhance user security, knowing the weaknesses of SMS.

💡 The Importance of the Secret Key

The QR code or text-based secret key provided during the setup of an authenticator app is critical for your account's security. You should not share this key with anyone and should store it securely (e.g., in a password manager). If this key is compromised, the attacker can generate codes just like you.

Since authenticator apps generate codes directly on your device, these codes cannot be accessed through a SIM swap attack or SMS forwarding attempt. Furthermore, they are more resistant to phishing attacks. Even if you enter your password on a fake site, when you try to enter the code from the authenticator app, its validity can only be established with the real site. It's harder for an attacker to take a code from a fake site and immediately log into the real site, as the code needs to be valid within a specific time window and they are more resistant to MITM attacks.

Difference 1: Resistance to Phishing and Man-in-the-Middle (MITM) Attacks

One of the most significant differences between two-factor authentication methods is their resistance to phishing and Man-in-the-Middle (MITM) attacks. A key weakness of SMS-based 2FA is its vulnerability to such attacks. An attacker can redirect a user to a cloned website, tricking them into entering their password and then the SMS 2FA code. When the user enters the code, the attacker can immediately log in by relaying this code to the real site. This is a very common problem, especially when users don't habitually check URLs carefully or when it's hard to notice on small mobile screens.

Authenticator apps, in this scenario, are significantly more secure. Codes generated with TOTP or HOTP algorithms are created locally on your device and do not require an internet connection. This means that even if an attacker redirects you to a fake site, the code you enter there will not be valid for the real site (if the attacker cannot relay the code to the real site instantly or if it times out). More importantly, since authenticator apps typically operate via a shared secret key, the codes are not directly tied to the site; they are simply generated with the correct time synchronization and key. Hardware-based keys like WebAuthn (FIDO2) further enhance this resistance, providing near-complete protection against phishing by verifying which site you are logging into.

⚠️ The Insidious Nature of Phishing

Phishing attacks are not limited to email or SMS. Links shared on social media platforms, or even fake ads appearing in search engines, can redirect you to fraudulent websites. Always checking the URL in the address bar and certificate information is the first step to protect yourself from such traps.

Difference 2: Risk of SIM Swap and Phone Number Compromise

The second critical difference between authenticator apps and SMS 2FA is their resistance to SIM swap and phone number compromise attacks. SMS 2FA, as the name suggests, is tied to your phone number. This means that if an attacker manages to port the target phone number to a SIM card they control, they can access all 2FA codes. Unfortunately, such attacks are becoming increasingly common, exploiting weaknesses in the customer service processes of telecommunications companies. An attacker can convince the operator, using fake credentials or social engineering methods, to port the victim's number to their own SIM card. When this happens, the victim's phone goes offline, and the attacker starts receiving all calls and SMS messages.

Authenticator apps, however, completely eliminate this risk. The app is associated not with your phone number, but with the unique secret key provided during setup. This key is stored securely on the device where the app is installed and does not require an internet connection or SIM card to generate codes. Therefore, even if a SIM swap attack occurs, the attacker cannot access the codes generated by the authenticator app. This is a critical security advantage, especially for high-value accounts like banking, cryptocurrency exchanges, or cloud services. In my own Android spam app, I prioritized authenticator-based solutions over SMS for user authentication processes, considering the risk of SIM swaps.

The diagram above simply illustrates how a SIM swap attack occurs and how SMS 2FA is affected. Authenticator apps, on the other hand, remain outside this chain and are inherently more resistant to such attacks.

Difference 3: Connectivity and Accessibility Dependency

The third important difference is the connectivity and accessibility dependency of these two 2FA methods. SMS-based 2FA naturally requires an active phone network connection. If your phone has poor network reception, you're experiencing roaming issues, or you're using a local SIM card while traveling, you might have trouble receiving SMS codes. This was a problem I encountered, especially during international travel or in rural areas; when I needed to access a critical system, the SMS code not arriving could disrupt my work. Furthermore, in situations with heavy SMS traffic or due to operator-side delays, codes might take time to arrive.

Authenticator apps, however, are much more flexible in this regard. TOTP algorithms generate codes based on the secret key stored on your device and time synchronization. This means the authenticator app can work even without an internet connection. Whether you're on a plane, in a tunnel, or completely offline, you can generate the necessary code to log into your account. This feature provides a significant advantage in terms of business continuity and accessibility. When setting up 2FA for SSH access to my own VPSs, I always preferred authenticator apps because I needed to be able to access my servers even in case of a network outage.

Of course, there are also risks like losing the device on which the authenticator app is installed or its battery dying. However, most authenticator apps try to minimize these risks by offering features like backup codes or cloud synchronization. The important thing is to use these backup options securely and plan in advance what to do if the main device is lost.

When Should We Prefer Which?

The choice of which 2FA method to select depends on the sensitivity of the account you are trying to protect, the technical proficiency of the target audience, and the potential risks you might encounter. There isn't a single "best" solution; a trade-off analysis is always necessary. I generally use the following decision-making process:

Situations Where SMS 2FA Might Be Preferred:

Low Sensitivity Accounts: SMS 2FA might be sufficient for accounts that are not very critical, such as email newsletters, forums, or blog comment systems. Here, easy setup and broad user accessibility are more important.
Reaching a Wide Audience: SMS 2FA is a more practical solution when the user base has low technical proficiency or when serving individuals who do not use smartphones. Everyone has a phone and can receive SMS.
Temporary or One-Time Use: SMS 2FA's speed can be an advantage for short-term access or one-time verification processes.

Situations Where Authenticator Apps Should Be Preferred:

High Sensitivity Accounts: For accounts like banking, financial investment platforms, cloud services (AWS, Azure), email accounts (especially primary emails), cryptocurrency exchanges, and administrative panels, authenticator apps are indispensable. In my production ERP, we completely disabled SMS 2FA for operator screens and management panel logins and switched to TOTP.
Situations with High Risk of SIM Swap or Phishing: If your target audience or industry is vulnerable to SIM swap or sophisticated phishing attacks, authenticator apps are a much safer option.
Need for Offline Functionality: For those who travel or work in environments with limited internet access, the ability to generate codes offline is a major advantage.

ℹ️ Hardware Keys (WebAuthn/FIDO2)

For the highest level of security, hardware-based keys (like YubiKey, Google Titan Key) can be considered. These offer the strongest protection against phishing and MITM attacks and completely eliminate the risk of SIM swap. However, their setup is slightly more complex and requires additional hardware costs. For me, these keys are my primary choice, especially for critical infrastructure access.

Feature / Method	SMS-Based 2FA	Authenticator Apps (TOTP/HOTP)
Setup Ease	High (Phone number is sufficient)	Medium (App download, QR code scan)
Usage Ease	High (Enter the received code)	Medium (Open app, copy/type code)
Phishing Resistance	Low (Easily bypassed)	High (More resistant to MITM attacks)
SIM Swap Resistance	Low (Risky if phone number is compromised)	High (Independent of phone number)
Connectivity Dependency	High (Requires network connection)	Low (Can generate codes offline)
Cost	Generally Free (Depends on operator)	Generally Free (Apps are free)
Recovery Options	Phone number recovery, backup codes	Backup codes, cloud backup (app dependent)
For Sensitive Accounts	Not Recommended	Strongly Recommended

This table summarizes the advantages and disadvantages of both methods. In my own projects, I try to strike a delicate balance between user experience and security. While I always prefer authenticator apps for critical systems, I may offer SMS 2FA as a transition or additional option in less sensitive areas.

Conclusion

Understanding the fundamental differences between authenticator apps and SMS 2FA is at the forefront of the steps we take to protect our digital assets. While SMS 2FA's simplicity and widespread accessibility make it appealing, its weaknesses against SIM swap and advanced phishing attacks pose a significant risk, especially for accounts containing sensitive data. In my experience, ignoring these risks can lead to much larger problems in the long run.

On the other hand, authenticator apps offer a much stronger security layer with their offline functionality and attack resistance. Therefore, I strongly recommend using an authenticator app for all your financial, email, or business-critical accounts. Security is not just a technical feature of a product or service; it is also a responsibility you bear towards your users. Making the right choices by knowing the trade-offs of these two methods will strengthen the digital security of both you and your users.

6 Mistakes You're Making With Your Wi-Fi Router: Home Network Fixes

Mustafa ERBAY — Wed, 08 Jul 2026 17:12:42 +0000

A few weeks ago, a friend's home Wi-Fi network was constantly dropping, and their internet speed was quite low. When we looked for the cause, we found that the router was operating with its default password and its firmware hadn't been updated in five years. For most people, their home Wi-Fi network continues to run for years after setup, often untouched, which can lead to security vulnerabilities or performance issues. In reality, you can make your home network both more secure and faster with just a few simple adjustments.

I apply the experience I've gained over years in corporate networks, server infrastructure, and software development to my home network as well. These six critical error fixes you can make on your home router will protect you from potential security risks and improve your daily internet experience. These settings form the foundation for simplifying seemingly complex network management and enhancing your digital quality of life.

ℹ️ Why It Matters

The security of your home network means the protection of your personal data and devices. Performance optimization, on the other hand, provides an uninterrupted and fast internet experience. These simple steps will significantly improve both areas.

Why Should I Change My Default Router Password?

When we buy a new router or have a modem installed by our service provider, it usually comes with default username and password combinations like "admin/admin" or "root/toor" for the administrator panel. Many home users never change this password and continue to use the router as it came out of the box. This is one of the biggest security holes we unknowingly open.

Default passwords are found on easily accessible lists online and are one of the first methods malicious actors will try to access your network. If someone infiltrates your home network this way, they can access all your internal devices (computers, smart home appliances, NAS devices), monitor your internet traffic, and even change your DNS settings to redirect you to phishing sites. When I set up a new router in my own home, one of the first things I do is change this default password immediately, just like changing the default root password for SSH access to a server.

To change this password, you need to enter your router's IP address (usually 192.168.1.1 or 192.168.0.1) into your browser to access the administrator panel. You should set your password to a strong combination of at least 12-16 characters, including uppercase letters, lowercase letters, numbers, and special characters. Also, ensure you don't use this password anywhere else.

Why Should I Set My Wi-Fi Encryption to WPA2/WPA3?

The most fundamental way to ensure the security of data on your Wi-Fi network is to use the correct encryption protocol. In the past, protocols like WEP (Wired Equivalent Privacy) and WPA (Wi-Fi Protected Access) were used, but these protocols were found to have serious security vulnerabilities and are no longer secure. For example, WEP encryption can be cracked in just a few minutes, meaning all traffic on your network can be read by others.

My recommendation is always to use WPA2-PSK (AES) or the newer WPA3. WPA2-PSK (AES) is still considered a very secure standard for home networks today. The AES (Advanced Encryption Standard) algorithm encrypts your data much more strongly, making unauthorized access difficult. If your router and all your devices support WPA3, this is the most current and secure option. WPA3 offers improvements like stronger encryption, better password protection, and individual data encryption.

To check your settings, you'll need to log into your router's administrator panel again. In the Wireless Settings or Security Settings section, you'll find the encryption type (Security Mode/Encryption). Make sure you select WPA2-PSK (AES) or WPA3 here. If you are still using WEP or WPA, I strongly advise you to change it immediately.

What Does a Guest Network Do, and Why Should I Use It?

A guest network is a separate Wi-Fi network isolated from your main network. I apply the principle I learned from setting up VLAN segmentation in corporate networks to my home. When you want to provide internet access to guests visiting your home, using a guest network instead of giving out your main network password is a critical security step.

Your main network contains your computers, smart TV, NAS device, or other smart home appliances. These devices often communicate with each other and may contain sensitive data. If a guest device has malware or the guest is an internet user with low security awareness, all devices connected to your main network could be at risk. A guest network prevents guest devices from seeing and communicating with other devices on your main network. This acts as a "firewall" on your network.

In your router's administrator panel, you'll usually find an option like "Guest Network" or "Separate Network." By enabling this feature, you can set up a separate SSID (network name) and password for your guests. Some routers also offer additional features on the guest network, such as bandwidth limitations or timers. This way, you protect both the security and performance of your main network while guests access the internet.

Why Shouldn't I Neglect Firmware Updates?

Router firmware is like your device's operating system. Manufacturers regularly update this software to add new features, improve performance, and most importantly, patch discovered security vulnerabilities (CVEs). For someone like me who tracks CVEs as part of their job, I've seen how critical this issue is for home devices.

Outdated firmware leaves your router vulnerable to known security exploits. These exploits can allow malicious actors to remotely access your router, change its settings, or even infiltrate your network. For example, a remote code execution (RCE) vulnerability found in a router model can put millions of devices connected to the internet at risk, and if your firmware is not up-to-date, you become part of that risk. Furthermore, firmware updates often include improvements that enhance network performance and stability. In many cases I've seen, outdated firmware was the underlying cause of modem slowdown complaints.

By logging into your router's administrator panel, you can find the "Firmware Update" or "System Tools" section. While some modern routers have an automatic update feature, for others, you may need to download the latest firmware file from the manufacturer's website and install it manually. Don't forget to back up your current settings before updating. This gives you a way to revert in case of a problem.

⚠️ Important Note

Be careful not to disconnect your router's power during the firmware update process. Otherwise, your device may become unusable.

Why Should I Disable the WPS Feature?

WPS (Wi-Fi Protected Setup) is a feature designed to easily connect wireless devices to a router. It typically works by pressing a button on the router or entering an 8-digit PIN. While this feature is included on many routers for convenience, it actually harbors a significant security vulnerability.

WPS's PIN-based mechanism is very weak against brute-force attacks. The 8-digit PIN is actually split into two parts, and attackers can find the PIN by trying these two parts separately, rather than billions of possibilities, with far fewer attempts. This means that using automated tools, the WPS PIN can be cracked in just a few hours. Once the PIN is cracked, the attacker has obtained your network's Wi-Fi password and gains full access to your network. In my professional capacity performing network security audits, I've repeatedly seen how easily WPS can be exploited.

If you don't actively use WPS (which most users don't need), disabling this feature from your router's administrator panel is the safest approach. It's usually found as an option under the "Wireless" or "WPS" heading. Disabling WPS protects your network from potential brute-force attacks and significantly strengthens your overall security posture.

Why Should I Optimize My Router's Channel and Bandwidth Settings?

One of the key factors directly impacting your Wi-Fi network's performance is the wireless channel and bandwidth settings it uses. Most routers automatically select a channel, but this doesn't always yield the best results. Especially in densely populated areas, your neighbors' Wi-Fi networks might be using the same channel as yours. This situation leads to signal interference and a noticeable slowdown in your network's speed. While dealing with QoS and DSCP settings on the network side, I realized how much difference simple optimizations could make for home Wi-Fi.

Wi-Fi routers typically broadcast on two main frequency bands: 2.4 GHz and 5 GHz.

2.4 GHz band: Offers a wider coverage area and penetrates walls better, but the speed is lower and it's generally more crowded (as many devices use this band and there are only a limited number of non-overlapping channels like 1, 6, 11).
5 GHz band: Offers higher speeds and is less crowded, but has a narrower coverage area and weaker wall penetration.

For performance optimization, you can do the following:

Channel Selection: Use a Wi-Fi analyzer app (on your phone or computer) to identify nearby networks and the channels they are using. Manually select the least congested, non-overlapping channel (usually 1, 6, or 11 for 2.4 GHz).
Band Selection: If your devices support it, prefer the 5 GHz band for better performance. 5 GHz is more suitable for bandwidth-intensive tasks like streaming, gaming, or file transfers. By broadcasting both bands with different names (SSIDs) on your router, you can connect your devices to your desired band.
Channel Width: Using 20 MHz on the 2.4 GHz band and 40 MHz or 80 MHz (if your devices support it) on the 5 GHz band is generally a good balance. Wider bandwidth (e.g., 160 MHz) offers higher speeds but can mean more interference and shorter range.

You can find these settings in your router's "Wireless Settings" section. Finding the most suitable configuration for your home environment through trial and error will have a significant impact on your network's stability and speed.

Conclusion

Wi-Fi routers in our homes are the unsung heroes of modern life. Without them, connecting to the internet, using smart devices, or working remotely becomes impossible. However, most of the time, we use these critical devices with a "set it and forget it" mentality. Fixing the six mistakes I discussed today—changing default passwords, using secure encryption, setting up a guest network, updating firmware, disabling WPS, and optimizing channel settings—will significantly enhance both the security and performance of your home network.

Many of the security and optimization principles from corporate systems are also applicable to home networks, albeit on a smaller scale. These simple steps are the first steps in viewing your digital security as a personal responsibility and acting proactively. Remember, the weakest link is often the one that receives the least attention. To keep your home network secure and running at its best performance, review these settings today. In my upcoming posts, I will continue to delve into more in-depth network and system security topics.

Remove Your Personal Information from the Internet: Data Broker Sites

Mustafa ERBAY — Wed, 08 Jul 2026 16:50:51 +0000

Recently, when I searched my own name on Google, I saw my address and phone number listed on a data broker site, all because of an irrelevant form I filled out years ago. This situation showed me once again how vast and sometimes uncontrollable our digital footprint on the internet can be. Having our personal information publicly accessible on such platforms poses serious risks to both privacy and security.

In this post, I will provide a practical, step-by-step guide on how to get your personal information removed from data broker sites on the internet. Although this process requires some time and patience, it is an important step to reclaim your digital privacy and prevent potential unwanted situations. My goal is to make this complex-looking process understandable and help you take control back into your own hands.

Why Do Data Broker Sites Exist and How Do They Work?

Data broker sites, as the name suggests, are platforms that aggregate personal information from various corners of the internet and generally use it for commercial purposes. These sites obtain information from public records, social media profiles, old websites, leaked databases, and even other data brokers. The data they collect can include details such as first name, last name, address, phone number, email address, family members, occupation, and even past addresses.

These platforms usually sell the information they collect for marketing, fraud detection, background checks, or simply to offer "people search" services. The need to pull data from open-source channels for supplier integrations, which we once encountered in a production ERP, showed me how easy this kind of harvesting has become. With the right tools and APIs, collecting and processing this data is technically not very difficult.

ℹ️ Information Sources

Data brokers obtain information not only through illegal means but also from public and legal sources. Data such as land registry records, court decisions, and voter lists become feeding sources for these sites as they get digitized.

So why is this a problem? At the very least, you receive unwanted calls and spam emails. In more serious cases, you could become a target for identity theft or fraud attempts. The less personal information you have in the digital world, the less of a target you become. Therefore, managing our presence on these sites is an important part of our digital security.

Identifying Your Digital Footprint: Where to Start?

The first step in removing your personal data from the internet is to identify where your data is located. This requires a bit of digital detective work and a highly systematic approach. Usually, people are surprised by the results that appear when they search for their own names.

First, search your first and last name in different variations (e.g., "Mustafa Erbay", "M. Erbay") on popular search engines (Google, Bing, DuckDuckGo). You can make more specific searches by adding your city, profession, or old addresses next to it. This is usually the easiest starting point, and you can find most data broker sites this way. While doing SEO work for my own website, I had the opportunity to deeply examine Google's indexing mechanisms, which helped me better understand how this kind of information surfaces.

Next, search your email addresses and phone numbers in search engines as well. This information consists of key identifiers that data broker sites usually use to build profiles. If you have them, don't forget to check your old email addresses too; because these sites often keep data dating back years. Similarly, you can search with information like an old work address or an association membership.

💡 Research Tips

You can get more targeted results by using keywords like "[Your Name Your Surname]" + "address" or "[Your Phone Number]" + "public records" in search engines. Additionally, some dedicated "people search" sites may list your data for free; looking directly at these sites will also be useful.

When you identify these sites, it is very important to record the URL of each one and what information they list about you in a document. These records will serve as reference points for your removal requests and make it easier to track the process.

The Personal Information Removal Process: General Steps

After identifying your personal information on data broker sites, we can move on to the process of removing this information. Although this process involves some bureaucracy and repetition, you can succeed when you proceed with the right steps. The important thing is to be systematic and patient.

The first and most important step is to find the "opt-out" or "information removal" policy of each data broker site. These links are usually located in the footer of the sites under names like "Privacy Policy", "Do Not Sell My Info", "Remove My Data", or "Contact Us". These pages explain step-by-step how to get your information removed. If you can't find it, you can look at the site's help or FAQ section.

⚠️ Be Patient

This process usually does not happen instantly. It may take time for data broker sites to process requests, sometimes weeks. For this reason, noting down the date and reference number (if any) of each request will make it easier to follow up.

When requesting removal, you are usually asked to provide information such as your first name, last name, address, and sometimes your email address. Make sure you enter this information accurately and completely, as incorrect information may cause your request to be rejected. Some sites may ask for additional steps to verify your identity, such as an email confirmation or even an ID document. In these cases, take care to share only the minimum necessary information and do not risk your personal security.

Keeping a record of each removal request is vital. In such transactions, I always note down the date I sent the request, the name of the site, what information I wanted to remove, and the request ID number if available. These records will serve as a reference to check whether your request has been processed in the future and to request again if necessary. Regularly following up on the process is the key to success.

How to Opt-Out of Data Broker Sites?

Although the process of removing your information (opt-out) from data broker sites may differ slightly for each site, it generally involves similar steps. By following these steps systematically, you can increase your chances of removing your information from most sites.

First, go to the homepage of the target data broker site and look for the "opt-out" or "remove my data" link. This is usually located at the bottom of the page or in the privacy policy section. After clicking the link, you are usually greeted with a search form to find your information. Search for yourself by entering your first name, last name, and if possible, your city or state.

Once you find your profile, you are usually asked to fill out a removal request form. In this form, you state that you want to remove your information and sometimes you may need to explain why. In this step, take care to share only the information that is absolutely necessary. Then, sites usually request an email or SMS confirmation to verify that your request is made by a real person. Complete these verification steps carefully.

# Example: Searching for yourself on a data broker site
# This is not a command, but pseudo-code to explain the concept
# It is usually done via a web interface

# Step 1: Search for your profile on the site
# Enter in the website's search box: "Mustafa Erbay"
# Or: "Mustafa Erbay" "Istanbul"

# Step 2: Find your profile and look for the "opt-out" option
# Usually, there is a link like "Remove my data" on the profile page or footer.

# Step 3: Fill out the opt-out form
# First Name: Mustafa
# Last Name: Erbay
# Email: mustafa.erbay@example.com (to be used for verification)
# Checkbox: "I am the subject of this record and wish to opt-out."

# Step 4: Verification via email
# Check your email inbox and confirm your request by clicking the link provided.

After submitting your request, you will usually receive a confirmation message or email. It is important to keep these messages. Later, after waiting for a certain period (usually 7-14 days), check again by searching for your information in search engines and on the relevant data broker site. If your information is still there, do not hesitate to contact the site again using the request number or contact details you saved. Sometimes the first request can be overlooked or a technical issue might occur.

Automated Opt-Out Services: Should We Use Them?

In the process of managing your digital footprint, you will see that there are many third-party tools on the market offering "automated opt-out" services. These services promise to scan data broker sites on your behalf, find your personal information, and automate the removal process. At first glance, they can look very attractive because dealing with each site manually is both time-consuming and tedious.

The biggest advantage of such services is undoubtedly time savings. Instead of visiting hundreds of different data broker sites one by one, filling out forms, and following up, you delegate this task to a software. It seems like a practical solution, especially for people who have a busy schedule or do not want to deal with such details. Additionally, these services can usually detect sites you didn't know about or missed before.

However, this convenience also has some significant disadvantages. First of all, most of these services are paid and work on a subscription model. You need to make regular payments for continuous protection. More importantly, to use these services, you must share your personal information (such as your first name, last name, email address, physical address) with them. In other words, in the name of protecting your privacy, you entrust your information to another third party. Personally, I prefer not to give my sensitive data to another third-party service. I find it safer to be in control.

⚠️ Privacy Risks

Automated opt-out services may collect more personal data while acting on your behalf. Do not use such a service without carefully reading the provider's privacy policy. It is critical to understand to whom you are giving your information and how they will process it.

The effectiveness of these services is also debatable. Some sites may recognize and reject automated requests, or block automation due to complex verification steps. Therefore, there is no guarantee that a service will remove one hundred percent of your information. When making a decision, you need to weigh the time and effort you will spend against the risk and cost of giving your personal data to a third party. My preference is to put in more effort and keep the control entirely in my own hands.

Tips for Permanently Protecting Your Digital Privacy

While getting your personal information removed from data broker sites is an important step, permanently protecting your digital privacy requires ongoing effort. This involves taking proactive steps, not just reactive ones. Acting more carefully and consciously in the digital world will help prevent potential future data leaks and unwanted situations.

First of all, always be cautious when sharing your information on online platforms. When registering for any new site or application, try to provide only the minimum information that is truly necessary. Regularly review the privacy settings of your social media profiles and allow only people you trust to access your information. While developing an Android spam blocker for one of my side products, I saw once again how easily personal data can be leaked and how important these proactive steps are.

💡 Email Address Management

While using your primary email address for your important transactions, you might consider using temporary or disposable email addresses for online registrations or services that look suspicious. This reduces the amount of spam and lowers the risk of your primary email address being harvested by data brokers.

Using strong and unique passwords, enabling two-factor authentication (2FA), and storing these passwords in a secure password manager are also fundamental security steps. A large portion of data breaches occur due to weak or reused passwords. Also, make sure to use a VPN when using public Wi-Fi networks, as these networks are generally not secure and can be open to data theft.

Finally, make it a habit to regularly check your digital footprint. At certain intervals, search your name, email addresses, and phone numbers in search engines to check if your information has appeared on a new data broker site. This can be thought of as a continuous "cleanup" process. Digital privacy is not a one-time transaction, but an area that requires regular maintenance.

Conclusion: Reclaiming Your Privacy Is in Your Hands

The process of removing your personal information from the internet may seem daunting at first, but every step you take will strengthen your digital privacy. By following the steps I mentioned in this guide, you can reduce your presence on data broker sites and take control back. Although this process requires some time and patience, it will provide you with peace of mind and security in the long run.

Privacy in the digital world is an area that requires constant attention and effort. Every small step you take today will help you prevent potential problems in the future. Remember, the less your information spreads on the internet, the less risk you carry. Therefore, taking responsibility for protecting your information is an inseparable part of modern digital life.

Everything you do in this regard will be a learning experience for you and will increase your digital literacy. In the next post, I will discuss the nuances of VLAN segmentation in corporate networks and how to implement it correctly.

The Current State of the Passkey Ecosystem: Convenience or Lock-in?

Mustafa ERBAY — Wed, 08 Jul 2026 15:40:25 +0000

The promise of passwords disappearing from our lives when logging into internet services has been a topic of discussion for many years, and Passkeys finally seem to be making that promise a reality. When I switched to using Passkeys on several different platforms in recent months, I initially experienced the tremendous convenience of passwordless login; however, I didn't want to overlook the potential "lock-in" risks of this new ecosystem. In this post, I will explain how Passkeys work, the conveniences they offer us, and also the risks like platform dependency that we need to be aware of, all based on my own experiences.

Passkeys are essentially digital credentials based on the WebAuthn standard developed by the FIDO (Fast IDentity Online) Alliance, enabling secure login without the need for a username and password. This technology offers a much more secure and user-friendly authentication method by eliminating the security vulnerabilities created by traditional passwords (phishing, weak passwords, reused passwords). For someone like me, who works in both system administration and software development, this balance between security and user experience has always been critical.

What is a Passkey and Why Did It Enter Our Lives?

A Passkey, in its simplest definition, is a device-specific digital key created for a website or application that replaces traditional passwords. Instead of a classic password, you authenticate your identity with your device's biometric sensors (fingerprint, facial recognition) or PIN. This can be thought of as an evolution of the second-factor authentication (2FA) we've been using for years, but now it has become the first factor.

The problems passwords create in our lives are endless: remembering them, keeping them secure, creating different and strong passwords for each service, and changing them regularly. This situation creates a huge burden for end-users and also creates easy targets for cyber attackers. Phishing attacks, weak password breaches, and credential theft were risks I frequently encountered in both my own operations and client projects. Passkeys emerged with the goal of providing a radical solution to these fundamental problems.

ℹ️ The Core Advantage of Passkeys

Passkeys eliminate the need to store passwords on the server side. This means there is no password database to be stolen in data breaches, significantly enhancing user security.

Passkeys offer both security and ease of use, helping users better protect their digital identities. As someone who has been involved with system and network security for many years, I know very well that passwords are the weakest link. I have repeatedly observed employees struggling to remember complex passwords and using simple ones in a production ERP system. Passwordless solutions like Passkeys both increase the security level in such scenarios and reduce friction in users' workflows. Therefore, I personally support the widespread adoption of this technology.

What are the Passkey Architecture and Core Components?

The architecture behind Passkeys relies on asymmetric cryptography and standards set by the FIDO Alliance. This system consists of three main components: the authenticator, the relying party, and the user. The process works quite differently from traditional password-based systems, and this difference forms the basis of the security advantage it provides.

When a user creates a Passkey, their device (authenticator) generates a private-public key pair. The private key is securely stored on the user's device and never leaves it. The public key, on the other hand, is stored by the service provider (relying party). When the user logs in next, they grant access to the private key via biometric verification (fingerprint or facial recognition) or PIN on their device. The device uses this private key to sign a login challenge and sends the signed response to the service provider. The service provider verifies this signature with the previously stored public key and confirms the user's identity.

One of the most important points in this architecture is that the private key is never sent to the server. This means that even if a data breach occurs on the server side, attackers cannot access users' private keys or, consequently, their Passkeys. While traditional passwords can lead directly to the theft of user passwords in server breaches, Passkeys eliminate this risk. Furthermore, Passkeys can often be synchronized across devices. For example, Apple's iCloud Keychain or Google Password Manager securely sync Passkeys across your different devices, allowing access from multiple devices with a single Passkey. This feature significantly improves the user experience and reduces the necessity of using a password manager.

What are the Real Conveniences Provided by Passkeys?

The conveniences brought by Passkeys are not limited to increased security; they also significantly simplify our daily digital lives. For someone like me, who is active on multiple platforms and projects, these practical benefits are quite valuable. In particular, the elimination of the need to remember and enter passwords provides a noticeable acceleration in my workflows.

First and foremost, the passwordless login experience is the biggest convenience. I no longer bother typing a username and password to access a website or application. I can log in within seconds using the fingerprint reader or facial recognition on my phone or computer. This is much faster and more accurate than typing passwords on a keyboard, especially on mobile devices. When accessing the backend of my own side product or connecting to the administration panels of client projects, this one-click login capability truly saves a lot of time. This speed also proved very useful in processes like logging into the Play Store or managing updates while developing an Android spam application.

Secondly, Passkeys offer natural protection against phishing attacks. In traditional password systems, users can be tricked into entering their passwords on fake websites, which forms the basis of phishing attacks. Passkeys, however, check the actual URL of the website during the authentication process. If the site you are trying to log into is different from the site where you registered the Passkey, the Passkey will not engage. This prevents users from accidentally providing their credentials to a malicious site. This is a reassuring feature, especially in my work where I constantly need to be vigilant about information security.

Thirdly, cross-device synchronization and ease of access are also significant advantages. Passkeys can be securely synchronized within the platforms' own ecosystems. For example, when you create a Passkey in the Apple ecosystem, thanks to iCloud Keychain, this Passkey automatically becomes available on all your iPhone, iPad, and Mac devices logged in with the same Apple ID. Google and Microsoft also offer similar synchronization services. This eliminates the hassle of setting up new credentials or remembering passwords every time you access the same services from different devices. As a software developer, when I have to access different test environments or my own development servers from various devices, this synchronization feature makes my life easier.

What are the Potential Passkey Ecosystem Lock-in Risks (Vendor Lock-in)?

While the conveniences brought by Passkeys are undeniable, the other side of the coin presents potential vendor lock-in risks. These risks can be significant, especially for users who use multiple ecosystems or plan to switch platforms in the future. For a professional like me, who works with different technologies and values flexibility, this is a matter that needs to be handled carefully.

The most prominent lock-in risk is that Passkeys are largely tied to the ecosystems of platform providers. Currently, Passkeys are generally managed through Passkey managers offered by major tech companies like Apple (iCloud Keychain), Google (Google Password Manager), and Microsoft. When you create a Passkey, it is usually saved to the Passkey manager of the operating system or browser of the device you are using. For example, a Passkey created on an Apple device is saved to iCloud Keychain and synchronized within the Apple ecosystem. If you later switch to a completely Android or Windows-based system, seamlessly migrating these Passkeys to your new platform may not always be possible.

⚠️ Passkey Migration Challenges

Currently, cross-platform Passkey migration and export mechanisms are not yet fully mature. This means that users might have to recreate all their Passkeys when switching from one platform to another.

There are still significant shortcomings in cross-platform Passkey compatibility and portability. Although the FIDO Alliance continues to develop standards in this area, a direct "export" or "import" feature between different Passkey managers is not yet common in practice. This situation carries the risk of a user leaving all their digital identities under the control of a single platform. Let's say you've been using the Apple ecosystem for years and have hundreds of Passkeys. If you decide to switch to Android one day, you might need to manually recreate all those Passkeys on your new platform. This creates significant friction and a "lock-in" effect.

Furthermore, Passkey recovery mechanisms can also be another source of concern. If you lose all your devices or lose access, you have to rely on the platform provider's own recovery methods to recover your Passkeys. This again increases dependence on the platform. As a system administrator, I know how critical backup and recovery scenarios are. In the Passkey ecosystem, this issue also needs to be more transparent and flexible. I still have reservations about fully trusting Passkeys for logging into critical services on my own VPS, as the recovery scenario is still a bit hazy.

Transition Process and User Experience Challenges: Is the Transition Painless?

While the transition to Passkeys seems smooth and painless in theory, in practice it brings some challenges for users and service providers. A seamless transition is critically important for the widespread adoption of the technology. In my own experiences, I've seen that how well a technology is adopted and how users adapt to it is just as important as how good the technology itself is.

One of the biggest challenges is the hybrid nature of the transition from existing password-based systems to Passkeys. Most service providers offer Passkeys as an option alongside passwords, rather than making them immediately mandatory. This creates a transition period for users to abandon old habits and get used to a new authentication method. However, this hybrid situation can also lead to confusion for some users. They may struggle to understand when to use a password and when to use a Passkey. I've seen how difficult it is to change user habits even when deploying a new module in a production ERP. Passkeys are going through a similar adaptation process.

💡 Importance of User Education

For Passkeys to become widespread, users need to clearly understand what Passkeys are, how they work, and the benefits they provide. It is critical for service providers to offer simple and understandable educational materials on this topic.

From a user experience perspective, the processes for creating and managing Passkeys can still be somewhat complex. A first-time Passkey user might struggle when following the steps provided by the browser or operating system. Furthermore, for users with multiple devices, issues like where Passkeys are stored, how they are synchronized, or how to recover them if a device is lost are still not fully clarified. For example, I considered Passkey integration to simplify the user authentication process in one of my mobile applications, but due to recovery scenarios and potential user confusion, I opted to stick with traditional JWT/OAuth2-based methods for now.

From the perspective of service providers, there are also integration and management challenges. Making existing authentication systems compatible with Passkeys requires additional development and testing processes. Furthermore, ensuring the compatibility of Passkey-supporting systems with older browsers or operating systems is another challenge. For the future success of Passkeys, it is vital that this transition process becomes smoother by overcoming both technical and user-centric difficulties. As an infrastructure and software architect, I know that such transitions always take longer and require more resources than expected.

What are My Expectations for the Future of Passkeys?

Although Passkey technology is still in its early stages of development, it has the potential to form the foundation of digital authentication in the future. With the continuous development of standards by the FIDO Alliance and the support of major tech companies, I believe the Passkey ecosystem will further mature and become more widespread. My expectations on this topic are shaped by both technical details and the overall user experience.

First, I expect increased cross-platform interoperability. To reduce current vendor lock-in risks, easier Passkey transfer and synchronization between different Passkey managers should be possible. For example, we should be able to seamlessly move Passkeys from a Google Passkey Manager to iCloud Keychain or vice versa. This will give users more freedom in platform choice and increase competition. The FIDO Alliance's efforts in this direction are promising, but practical implementations need to accelerate. As a system architect, I believe that open standards and interoperability always win in the long run.

Second, I believe corporate and enterprise-level Passkey adoption will accelerate. Large companies and public institutions will want to benefit from the enhanced security and simplified user experience that Passkeys offer. Especially in environments where multi-factor authentication is mandatory, Passkeys will both increase the security level and reduce the workload for employees. In a production ERP, Passkeys can provide great convenience in scenarios such as operators logging into the system quickly and securely during shift changes. However, issues such as how Passkey management will be centralized in corporate environments (e.g., how Passkeys will be revoked when an employee leaves) also need to be resolved.

Third, I expect Passkey recovery mechanisms to become more transparent and user-friendly. It is vital for a user to be able to securely verify their identity and recover their Passkeys if they lose all their devices or lose access to their Passkeys. These processes need to be supported by platform-independent and standardized methods. For example, Passkeys could be recreated with a recovery code or another trusted authentication method.

Finally, with the widespread adoption of Passkeys, I hope for a more resilient ecosystem against cyber threats other than phishing. While Passkeys provide strong protection against phishing, risks such as device theft or malware will continue. Therefore, device security and operating system-level protections also need to evolve alongside Passkeys. Overall, I believe Passkeys will fundamentally change the digital authentication paradigm and bring us closer to the end of the password era, but there is still a way to go for this transition to be painless.

Passkeys' Scope and Reach: Will They Stay Only on the Web?

While Passkeys were initially designed for web-based authentication, their potential application areas are not limited to websites. I believe that in the future, the scope of Passkeys will expand and we will encounter them on many different platforms and scenarios. This expansion could affect many more aspects of our digital lives and offer new integration opportunities for those of us working in various technology fields.

Currently, Passkeys are generally used through web browsers and mobile applications. However, I expect this technology to be integrated more deeply into desktop applications and at the operating system level. For example, the ability to use a Passkey instead of a password when logging into your computer or launching specific software could significantly simplify the user experience. This could especially facilitate the implementation of security policies in corporate environments and speed up employee workflows. As a Linux system administrator, I know how practical authentication with SSH keys is; Passkeys could offer similar convenience for general use.

Secondly, it is also possible for Passkeys to be used for authentication in IoT (Internet of Things) devices and smart home systems. Using biometric authentication with a Passkey instead of complex passwords to access smart locks, security cameras, or other smart devices could both increase the security level and simplify device management. This could help alleviate security concerns in home automation and IoT. When managing some smart devices in my own home, being able to log in with a single Passkey instead of remembering different passwords would be a great convenience.

ℹ️ Passkeys' Expansion Potential

Passkeys will not be limited to just websites and mobile applications; they can offer an authentication solution across a wider range, including desktop operating systems, IoT devices, and even physical access control systems.

Thirdly, we may also see Passkey-like technologies being used in physical access control systems. While RFID cards or biometric systems are currently used, the security and platform independence brought by Passkey standards could be integrated into these areas as well. For example, using the Passkey on your phone to open an office door or enter a data center could eliminate the need to carry keys or cards. This offers new opportunities in terms of both security and management.

Finally, I believe Passkeys will play a greater role in digital identity management and e-government services. Passkeys can be a powerful tool for citizens to access e-government platforms or other public services more securely and easily. This can improve the digital citizenship experience and help public services reach wider audiences. For someone like me, who has been involved with authentication and authorization systems for many years, the expansion potential of Passkeys is quite exciting. However, the new security and privacy challenges that this expansion will bring must also be carefully addressed.

My Own Experiences with Passkeys and My Vision for the Future

My personal experiences with Passkeys have been both exciting and thought-provoking. I started actively using Passkeys for several different online services, and the initial ease I experienced truly showed how unnecessary a burden passwords were. Especially for logins from mobile devices, instant access with a single fingerprint scan or facial recognition quickly changed my habits.

For one of my own side products, I evaluated Passkey integration to simplify the user authentication process. While the idea of enhancing my existing JWT/OAuth2-based system with Passkeys was appealing, I decided to adopt a more conservative approach for now due to the user adaptation process for Passkeys and especially the cross-platform transition scenarios (vendor lock-in). I don't yet believe that the entire user base is ready for this new technology, and I saw that such a transition could create more support burden for me without a well-planned transition strategy and comprehensive user training.

🔥 Transition Strategies and User Support

Service providers considering Passkey integration must carefully plan how to seamlessly migrate their existing users to Passkeys and how to provide support for potential issues. A hybrid approach may be the safest route for the beginning.

However, my vision for the future of Passkeys is quite positive. I envision a world where passwords are completely eliminated and digital authentication becomes much more secure and convenient. This will be a great relief not only for users but also for cybersecurity professionals and system administrators. A significant portion of the effort we spend combating phishing attacks or closing security vulnerabilities caused by weak passwords will be eliminated.

In the coming period, I expect Passkeys to become more widespread in more services, cross-platform compatibility to increase, and recovery mechanisms to become more user-friendly. With these developments, I believe Passkeys will become the undisputed standard for digital authentication. For me, this is not just a technological innovation, but a paradigm shift that will fundamentally change the balance of security and convenience in the digital world. Being a part of this change and following it closely will continue to be an important part of my work and personal curiosity.

Conclusion

Passkeys represent a long-awaited revolution in digital identity authentication, offering a powerful solution to the myriad problems caused by passwords. The convenience of passwordless login, the natural protection against phishing, and cross-device synchronization are all advantages that clearly demonstrate why Passkeys are being rapidly adopted. In my own experiences, I have personally lived this convenience and seen how it has simplified my digital life.

However, the potential lock-in risks and transition challenges brought by this new ecosystem should not be ignored. Issues such as platform dependency, incompatibility between different Passkey managers, and the immaturity of recovery scenarios raise the question of whether Passkeys are about "convenience or lock-in." Resolving these issues is critical for Passkeys to reach their true potential.

In the future, with the efforts of the FIDO Alliance and the collaboration of tech giants, I believe Passkeys will become more interoperable, secure, and user-friendly. This will enable them to replace passwords and become the new standard for digital authentication for both individual users and corporate structures. For me, this is an important step in the right direction for technology, and I am excited to be a part of this change.

30 Days Without Google: Is It Possible, Is It Worth It?

Mustafa ERBAY — Wed, 08 Jul 2026 14:37:33 +0000

A few months ago, while trying to solve a critical server issue, I found myself typing three different queries into Google within seconds. This realization hit me with how deeply ingrained my reliance on information access had become, and it prompted me to start the "30 Days Without Google" experiment. While completely ditching Google initially seemed impossible, it's actually feasible and can offer unexpected benefits, though it comes with significant challenges.

This experiment wasn't just a digital detox; it was also an attempt to see how I could exist in the tech world, which I've been a part of for 20 years, outside of mainstream tools. For me personally, this challenge gave me the opportunity to question my habits and rethink my digital footprint.

How I Started My 30 Days Without Google

Before embarking on this adventure, I listed all the Google services I used and their place in my life. Gmail, Google Search, Chrome, YouTube, Google Maps, the core Android services, and even some Google APIs I used in my side projects were all part of this list. My goal was to completely break away from this ecosystem and find alternative solutions.

As a first step, I migrated my personal and work emails to ProtonMail. I made DuckDuckGo and Brave Search my primary search engines. On my Android phone, I tried to manage apps by disabling Google Play Services and using F-Droid and Aurora Store.

ℹ️ Starting Note

Completely separating from the Google ecosystem, especially on Android devices and with some web services, meant a lot more integration than I initially thought. So, when I say "Google-free," I'm referring to the main Google services (search, maps, email, browser synchronization), not unavoidable dependencies like basic internet connectivity or Google fonts used by some sites.

Unexpected Obstacles and the Search for Alternatives

One of the biggest challenges I faced during a month without Google was quick access to technical information. Especially when I needed to quickly search for an error I encountered in a production ERP or in the backend of my own side product, DuckDuckGo sometimes didn't offer sufficient depth. This led me to read more documentation, delve into man pages, and directly search for specific topics on platforms like Stack Overflow.

For maps, OpenStreetMap-based OsmAnd and Maps.me apps more than sufficed. I could even navigate without using mobile data thanks to their offline map features. However, it was clear they lagged behind Google Maps in terms of traffic information and real-time updates. I turned to platforms like Vimeo and PeerTube instead of YouTube, but the content variety and algorithm recommendations couldn't come close to the experience Google offered.

# An example I used when searching for a PostgreSQL WAL bloat issue:
# On DuckDuckGo, I usually got more general results.
# On Google, typing "PostgreSQL WAL bloat troubleshooting" directly
# brought up more specific blog posts and forum discussions.
# This situation forced me to change my search strategy:
# On DuckDuckGo, I had to use more specific queries like:
# "PostgreSQL WAL bloat" site:dba.stackexchange.com

Impact on Productivity and Gains

In the first week of this experiment, my productivity noticeably dropped. Breaking my habits and adapting to new tools took time. Not being able to instantly search for every question that came to mind while managing a system or developing software was initially frustrating. However, over time, this situation pushed me to think more deeply and approach problems from different angles.

My biggest gain was an increased ability to focus. There were fewer distractions, and having to put a little more effort into accessing information helped me internalize that information better. Additionally, the feeling of taking control of my personal data made me more conscious about digital privacy. I discovered new tools and platforms; while some weren't necessarily better than their Google alternatives, they at least reinforced the idea that "there are other ways."

⚠️ Productivity Warning

Initially, you might experience a slowdown in accessing information, especially on technical topics. This will require a learning curve to break habits and develop new search strategies. If you're in a critical period in your professional workflow, you might consider postponing this experiment.

Is a Google-Free Life Sustainable?

The conclusion I reached after 30 days is that a Google-free life is theoretically possible but practically quite difficult. Especially for someone like me, who constantly deals with new technologies and works in system architecture and software development, completely disconnecting from Google's information pool can create a professional disadvantage. Quick problem-solving and instant access to information are inherent to my job.

However, this experience helped me take significant steps to reduce my Google dependency. DuckDuckGo is now my default search engine, I only use Gmail for specific tasks, and I try to minimize Google Play Services integration on Android. Even for the financial calculators in one of my side products, I've turned to self-hosted solutions instead of Google's analytical tools. This experiment showed that making conscious choices and managing dependency is more realistic than completely giving up for an ideal.

This experience helped me understand how "free" we are in the digital world and how our habits shape us. Do you think it's possible to completely move away from Google, or is it just an ideal? If you have your own experiences, I'd love to hear them.

The Anatomy of Evaluating AI Tools: From Marketing Hype to Reality

Mustafa ERBAY — Wed, 08 Jul 2026 13:15:04 +0000

While researching AI tools for next-generation production planning modules in a manufacturing ERP, all the products I encountered in marketing materials were "revolutionary" and "autonomous." However, in reality, many of these tools struggled to integrate into our existing workflows or failed to deliver the promised performance. When evaluating AI tools, it's critical to look beyond glossy presentations and understand their true capabilities to make informed decisions. In this post, I want to share this "anatomical" evaluation process and the experiences I've gained over the years.

In this process, focusing solely on technical features is not enough; factors such as workflow compatibility, cost-effectiveness, and long-term sustainability must also be considered. For me, it has always been more decisive not just how "smart" an AI tool is, but how practically it can solve real-world problems.

Where Should We Start When Evaluating an AI Tool?

When starting to evaluate an AI tool, the first step has always been to understand which specific problem it solves and how well it aligns with my workflow. While marketing materials often talk about general benefits, my focus is always on concrete questions like "how will this tool reduce my current manual workload?" or "how much will it improve my decision-making processes?" For example, when examining an AI-powered inventory optimization system for a manufacturing ERP, I first clarified which stages of our current inventory management process were experiencing bottlenecks.

At this stage, I also consider how easy or difficult it will be to integrate the solution offered by the tool into my existing systems. While some AI tools may appear "plug-and-play," they can actually have hidden costs such as incompatibility with existing data structures, API limitations, or complex data transformation requirements. When trying to integrate an AI service with natural language processing (NLP) capabilities into an Android spam blocker application I developed for a side product, I realized that the API only accepted data in a specific format, and converting my data to that format created additional workload. Such incompatibilities can significantly increase the Total Cost of Ownership (TCO) of a solution that initially seemed attractive.

ℹ️ Starting Point for Evaluation

Focus on which specific business problem an AI tool solves for you and how compatible it is with your existing infrastructure, rather than just its promises. Identifying potential integration difficulties and additional workloads upfront will prevent disappointments.

How Do We Understand the Gap Between "Marketing Promises" and "Real Capabilities"?

Marketing materials for AI tools often promise high success rates, incredible speeds, and "human-like" capabilities. However, in-depth testing is essential to understand how well these promises align with real-world performance. In my experience, an AI tool working flawlessly in a demo environment does not mean it will perform the same with my own data. Therefore, a Proof of Concept (PoC) or Minimum Viable Product (MVP) phase is vital to bridge this gap. It's difficult to understand the true value of a tool without testing it with your own data, in your own workflow, and under real load.

For example, when evaluating a potential fraud detection AI for a bank's internal platform, we found that the vendor's claimed 99% accuracy rate was only 85% on our own customer data. The difference here stemmed from the vendor's model being trained on a dataset that was more homogeneous or had different characteristics than ours. In such scenarios, it's necessary to question whether the tool has the ability to retrain or fine-tune the model with your own data. Additionally, the model's ability to explain its "decision-making" processes (explainability) can be a critical factor. A black-box model makes it difficult to understand why it made a mistake when it does, reducing its reliability.

Why Are Technical Depth and Infrastructure Compatibility Critical?

The technical depth of an AI tool and its compatibility with your existing infrastructure are indispensable for long-term success. For me, this means not just looking at API documentation, but understanding how the tool will be deployed, monitored, and integrated with my existing systems. For example, if I plan to host an AI tool on my own VPS, I check whether it works seamlessly with Docker Compose or SystemD units. If it's provided as a container image, I test whether it experiences OOM (Out Of Memory) issues during the build process or if its disk I/O performance meets my expectations.

Another important point is security. Most AI tools work with sensitive data, and how this data is processed, stored, and protected is a critical issue. In a customer project, when using an AI service, data privacy policies required that data not be processed on third-party servers. In this case, we either had to find a tool that offered an on-premise deployment option or ensure that the data was processed encrypted and never leaked in plain text. For such situations, integration capabilities with system security tools like kernel module blacklists, fail2ban patterns, or the audit subsystem also become part of my evaluation criteria.

How Should We Evaluate Cost and Scalability Factors?

The cost of an AI tool is not just about the initial subscription fees or the price per API call; it also includes operational costs, scaling potential, and hidden expenses. In my side product, which includes financial calculators, when I started using an AI service, I saw that each API call, which initially seemed like a small cost, quickly led to a rapidly increasing bill as my user count grew. Therefore, it is very important to examine the pricing model in detail and calculate potential costs by estimating future usage scenarios.

Scalability is also directly related to cost. It's necessary to understand how an AI tool performs under heavy load, how much latency increases, and how much it consumes system resources (CPU, RAM, network bandwidth). For example, when integrating an AI-powered reporting engine into a manufacturing ERP running on PostgreSQL, if the engine opens too many connections or creates unnecessary query load on the database, it can degrade the performance of the existing system. In such cases, it may be necessary to prevent the AI service from harming other critical services by using connection pool tuning, read replica routing, or Linux resource limitations like cgroup memory.high.

⚠️ Hidden Costs and Performance

When evaluating the cost of AI tools, focus not only on direct service fees but also on hidden costs arising from integration, operation, data transfer, infrastructure resource consumption, and potential performance bottlenecks.

How Important Are Ecosystem and Community Support?

When choosing an AI tool, I look not only at its technical capabilities but also at the ecosystem and community support behind it. In my 20 years of experience, no matter how good a software or service is, it's difficult for it to survive long-term without quality documentation, an active community, and a responsive support team. Especially in a rapidly evolving field like AI, receiving quick updates and patches for new issues or security vulnerabilities is vital. Once, I encountered a critical bug in an AI library I integrated into my own site; however, thanks to an active GitHub community, I was able to quickly identify the problem and find a temporary solution.

It's important that documentation is not only present but also up-to-date and understandable. Rich documentation that includes API references, usage examples, troubleshooting guides, and Best Practices accelerates the integration process and reduces operational burden. Furthermore, the vendor's product roadmap and future plans are also important. As AI technologies constantly evolve, the tool you use must also keep pace with this development and offer new capabilities. If the vendor is not actively developing its product and does not value community feedback, you may find yourself stuck with an outdated technology in the future.

A Proposed Evaluation Framework for AI Tools

I can summarize the framework I use for evaluating AI tools with a simple flowchart. This framework aims to help you find the most suitable solution for your real-world needs, going beyond marketing promises. At each step, you need to ask yourself specific questions and proceed based on the data you obtain.

Each step in this diagram requires a critical thought process:

Problem Definition and Needs Analysis: First, clearly define which business problem you want to solve. An AI tool is a solution tool, not an end in itself.
Are Marketing Promises Realistic?: Approach promotional materials with a degree of skepticism. Question how well the claimed capabilities align with your concrete use cases.
Can I Test with My Own Data (PoC/MVP)?: If possible, test the tool's real performance on your own data and workflow with a small-scale pilot project or PoC. This is the most decisive step.
Is Technical Integration Easy?: Evaluate the tool's APIs, SDKs, deployment options (on-prem, cloud), security protocols (JWT/OAuth2), and compatibility with your existing infrastructure (Linux services, containers, Nginx).
Do Cost and Scalability Meet Expectations?: Focus not only on immediate costs but also on future costs and performance degradations that will arise with usage growth. Will it require optimizations like cgroup limits or PostgreSQL connection tuning?
Is Ecosystem and Support Sufficient?: Documentation quality, an active community (Stack Overflow, GitHub), the vendor's support processes, and product roadmap are important for long-term sustainability.

Diligently following these steps helps even someone with 20 years of field experience like me avoid the "shiny marketing trap" that can sometimes befall us.

Conclusion

The process of evaluating AI tools requires a pragmatic and detailed approach, looking beyond marketing promises. In my experience, an AI tool being the "smartest" or "newest" does not always mean it's the best solution. What matters is how effectively it solves your specific problem, how compatible it is with your existing infrastructure, and how sustainable it is in the long run.

Remember that AI is a tool, and like any tool, it creates value when used correctly for the right problem. It's natural to be excited when a new AI tool comes out, but filtering this excitement through a realistic evaluation is the best way to prevent wasting both time and resources.