Coder Legion - Recent posts tagged development

10 STO Development Companies for Digital Securities and Asset Tokenization

Fri, 30 Oct 2026 12:16:01 +0000

Security Token Offerings (STOs) allow businesses to issue blockchain-based tokens that represent securities or rights linked to underlying assets. These assets may include real estate, company equity, debt instruments, and investment funds.

Building an STO platform requires more than token creation. Businesses must consider how tokens represent ownership rights, how transfers are restricted, how investors are verified, and how transactions are recorded. Smart contracts, identity verification, investor management, and secondary-market integrations also play important roles.

Choosing an experienced STO development company can help businesses build the technology needed to issue and manage security tokens. However, not every blockchain development provider offers the same capabilities. Some specialize in custom software development, while others provide dedicated tokenization platforms or security token infrastructure.

This article compares 10 companies worth evaluating for STO development in 2027, highlighting their service focus and the types of projects they may suit.

1. Debut Infotech

Debut Infotech provides stablecoin development services, including custom stablecoin creation, smart contract development, blockchain integration, wallet development, and payment solutions. Among stablecoin development companies, it offers businesses technical support for building, deploying, and managing stablecoin projects based on their requirements.

2. Antier Solutions

Antier offers dedicated security token offering development services. Its solutions cover equity tokens, debt tokens, asset-backed tokens, and security token exchange platforms.
The company also describes tokenization use cases involving real estate, art, venture capital funds, and other assets. Its STO services include smart contract development and exchange-related infrastructure.

3. SoluLab

SoluLab is a blockchain development company listed in GoodFirms' STO development category. Its broader blockchain portfolio includes Ethereum tokens, decentralized applications, DeFi platforms, and Web3 products.

For an STO project, businesses should discuss its experience with security token standards, transfer restrictions, investor verification, and regulated token issuance rather than assuming that general token development covers every STO requirement.

4. Nadcab Labs

Nadcab Labs provides blockchain and Web3 development services, including smart contracts, cryptocurrency exchanges, token creation, wallets, and DeFi applications. Its work covers several components that may be required when building a security token platform.
The company is also listed in GoodFirms' STO development category. Businesses should confirm its experience with permissioned security tokens, investor eligibility controls, and compliance-related transfer rules.

5. Crypton Studio

Crypton Studio develops custom blockchain products, smart contracts, tokenization platforms, crypto exchanges, and Web3 applications. Its technical services cover blockchain architecture, tokenomics, development, and security-related work.

Its tokenization and custom blockchain capabilities may be relevant to STO projects that need tailored infrastructure. However, businesses should verify its specific experience with regulated security token issuance.

6. Solicy

Solicy offers blockchain development services covering smart contracts, decentralized applications, wallets, DeFi applications, and Web3 integrations. GoodFirms also lists the company in its STO development category.

For an STO project, its smart contract and blockchain engineering capabilities are worth evaluating. The key question is whether its team can implement security token standards, transfer restrictions, and investor verification requirements.

7. Vegavid Technology

Vegavid Technology provides blockchain and digital product development services. Its broader technology portfolio includes blockchain applications and solutions for businesses across several industries.

The company appears in GoodFirms' STO development category. Businesses considering it should request examples of security token projects and clarify whether the proposed engagement covers token issuance, compliance-related functionality, and investor management.

8. ScalaCode

ScalaCode is a software development company with experience in custom applications and digital platforms. GoodFirms includes it in its STO development category, with its listed blockchain capabilities covering smart contracts, digital asset tokenization, cryptocurrency wallets, and decentralized applications.

Businesses should confirm the availability of a dedicated security token development team and relevant regulated tokenization experience before proceeding.

9. CLARISCO

CLARISCO offers dedicated STO development and security token exchange services. Its published offerings include security token smart contracts, investor dashboards, KYC/AML integrations, token issuance, and secondary-market connectivity.
The company also describes support for token standards such as ERC-3643 and ERC-1400. These are relevant technical considerations for projects that require permissioned token transfers and investor eligibility controls.

10. Blockchain Technologies

Blockchain Technologies is an Australian blockchain development company offering decentralized technology solutions. Its published company profile describes blockchain and Web3 development work, including enterprise-oriented blockchain applications.
GoodFirms lists the company in its STO development category. Businesses should independently verify its current security token services, particularly experience with regulated issuance and asset-backed tokens.

Conclusion

Choosing an STO development partner requires a clear understanding of both blockchain technology and the requirements of digital securities. Businesses should compare providers based on their experience with security token issuance, smart contracts, investor management, asset tokenization, and relevant integrations.

The 10 companies discussed above offer different capabilities. Debut Infotech and Antier have dedicated STO service offerings, while other providers bring broader blockchain development and tokenization experience. CLARISCO also publishes specific STO platform and exchange services.
Before making a final decision, review actual project examples, request technical proposals, and establish which legal, compliance, and development responsibilities each provider will handle.

When DSA Solved Our AWS Scaling Problem

Fri, 30 Oct 2026 08:39:12 +0000

When DSA Solved Our AWS Scaling Problem

In the age of AI, it feels like DSA is slowly disappearing from day-to-day development.

You can ask an AI to generate a queue, configure an AWS service, or write a retry mechanism in seconds.

But there is one thing AI cannot remove from engineering:

Constraints.

And when constraints appear, DSA suddenly becomes relevant again.

At our startup, we often solve problems in a scalable way. But scalability doesn't always mean adding another AWS service. Sometimes, the solution is simply using the existing components differently.

You usually don't recognize a DSA concept in a real-world system until someone asks:

"Why are we doing it this way?"

That question led us to a surprisingly simple solution to an AWS scheduling problem.

The Problem: We Were Running Out of Schedules

Imagine we have a large number of jobs.

Each job can fail and needs to be retried on subsequent days:

Parent Job
   │
   ├── Retry 1 → +1 day
   ├── Retry 2 → +2 days
   └── Retry 3 → +3 days

Initially, this seems straightforward.

We can simply create an EventBridge schedule for every retry.

But then scale enters the picture.

We encountered a situation where, for every 6,000 jobs, we needed to create 3 separate EventBridge schedules.

That means:

6,000 jobs
   ×
3 retry schedules
   =
18,000 schedules

Now imagine increasing the workload.

What happens if we have 10,000 jobs?

10,000 jobs
    ×
3 retries
    =
30,000 schedules

And what if this keeps growing?

We eventually run into EventBridge scheduling limits.

The obvious solution might be:

"Let's add another AWS component."

But our senior asked a different question:

"Can we solve this using a sliding window?"

That was the interesting part.

First, What Is a Sliding Window?

A sliding window is a technique where we don't process the entire dataset at once.

Instead, we maintain a smaller active window and continuously move it forward.

For example, imagine these jobs:

Day 1   Day 2   Day 3   Day 4   Day 5   Day 6   Day 7
 ├───────┼───────┼───────┼───────┼───────┼───────┼───────┤
         [──────────── Window ────────────]

As time moves forward:

Before:

Day 1   Day 2   Day 3   Day 4   Day 5   Day 6   Day 7
         [──────── Window ────────]


After:

Day 1   Day 2   Day 3   Day 4   Day 5   Day 6   Day 7
                 [──────── Window ────────]

The important idea is:

We don't need to keep scheduling everything forever.

We only care about jobs relevant to the current time window.

That observation changes how we think about the EventBridge problem.

What If We Don't Schedule Every Retry?

This was the key idea.

Instead of asking:

"When should this retry happen?"

and creating an EventBridge schedule for that future date...

we ask:

"Which retries are supposed to happen today?"

That small change removes the need to schedule every future retry individually.

The Original Approach

Let's say today is August 18.

A parent job runs today.

Its retries are:

August 18
   │
   ├── Retry 1 → August 19
   ├── Retry 2 → August 20
   └── Retry 3 → August 21

The traditional approach is:

              EventBridge
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Aug 19     Aug 20     Aug 21
    Retry 1    Retry 2    Retry 3

For every parent job, we create future schedules.

This is where the number of schedules grows rapidly.

The Sliding Window Approach

Now let's change the perspective.

Instead of scheduling:

Retry 1 → tomorrow
Retry 2 → day after tomorrow
Retry 3 → three days later

we maintain a daily execution window.

Every day, we ask:

"Which existing parent jobs have a retry due today?"

Then we execute those retries.

                    TODAY
                      │
                      ▼
             ┌─────────────────┐
             │   Sliding       │
             │    Window       │
             └────────┬────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     Retry 1       Retry 2       Retry 3
      due today     due today     due today

EventBridge no longer needs to know about every individual retry.

It only needs to trigger the parent job.

But What About Jobs From Previous Days?

This is where the idea becomes interesting.

Suppose a parent job ran 3 days ago.

Let's say:

Parent Job
August 15
   │
   ├── Retry 1 → August 16
   ├── Retry 2 → August 17
   └── Retry 3 → August 18

Today is August 18.

The third retry is due today.

Under the traditional approach, we would have created a schedule on August 15 for the retry that should execute on August 18.

But we don't need to do that anymore.

Instead, today's sliding window discovers it.

August 15        August 16        August 17        August 18
Parent Job       Retry 1          Retry 2          Retry 3
    │                │                │                │
    └────────────────┴────────────────┴────────────────┘
                                                     ▲
                                                     │
                                                   TODAY

The system simply asks:

"What retries are due on August 18?"

And finds:

Parent Job: August 15
Retry:      3
Due:        August 18

Then it executes it.

The Trick

This is the entire trick:

Don't schedule the future retries.

Instead Conceptually:

                 ┌─────────────────────┐
                 │   Daily Trigger     │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │  Current Time      │
                 │     Window         │
                 └──────────┬──────────┘
                            │
                            ▼
              ┌──────────────────────────┐
              │ Find retries due today   │
              └────────────┬─────────────┘
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
            Retry due             Not due
                 │                   │
                 ▼                   ▼
              Execute              Ignore

Why This Scales Better

The important difference is what we are scheduling.

Number of schedules grows
with the number of jobs

Now the number of EventBridge schedules is no longer directly proportional to:

Number of Jobs × Number of Retries

Instead, EventBridge becomes the mechanism that wakes up the scheduler/processor, while the application determines which work actually needs to happen.

The Bigger Lesson

The interesting part of this problem wasn't really EventBridge.

It was recognizing that we were using EventBridge to solve a problem that didn't necessarily belong there.

We initially thought:

"We need to schedule millions of future events."

The better question was:

"Do we actually need to schedule millions of future events?"

And the answer was no.

We only needed to know:

"What needs to happen today?"

That is where a simple DSA concept like sliding window becomes a practical system-design technique.

DSA Is Not Dead

This is why I don't think DSA is disappearing from software engineering.
Sometimes the answer is a sophisticated distributed system.

And sometimes...

it's a sliding window.

The important skill isn't memorizing DSA patterns.

MCP Protocol Engineer vs. MCP Tooling Developer: Why "Vibe Coding" Works for One but Fails the Other

Tue, 20 Oct 2026 07:23:48 +0000

Hey everyone,

With the widespread adoption of the Model Context Protocol (MCP) across Claude Code, Cursor, and autonomous agent frameworks, there is a lot of discussion around using AI-assisted workflows ("vibe coding") to build out agent infrastructure.

We wrote an in-depth systems analysis dissecting the boundary between foundational protocol engineering and application-layer tooling:

The Tooling Developer Layer:
MCP tool authoring is largely declarative (JSON Schema Draft-07, REST/GraphQL fetch wrappers, and response payload formatting). LLMs are exceptionally good at this. An experienced engineer who knows how to tune semantic descriptions (to avoid tool selection hallucinations) and sanitize inputs can build reliable tools with AI assistance in a fraction of the time.
The Protocol Engineer Layer:
Implementing the underlying protocol (JSON-RPC 2.0 framing, stdio process pipe backpressure, Server-Sent Events, and zero-allocation memory buffers in Rust/Go/C++) requires strict, deterministic systems programming. Probabilistic models frequently introduce subtle multi-threading bugs, unhandled partial reads, and stream deadlocks that only manifest under high concurrent load.

The core conclusion: Vibe coding provides massive velocity when bridging APIs and tools to models, but relying on probabilistic synthesis for low-level protocol primitives introduces dangerous cognitive debt and production instability.

Full technical write-up with comparison matrix and architecture breakdown:
https://www.seosiri.com/2026/10/mcp-protocol-engineer-vs-tooling-developer-vibe-coding.html

Curious to hear how other teams are structuring the boundary between core protocol maintenance and rapid tool authoring in their agent stacks.

💬 Developers: Would you ship AI-generated code without reviewing it first?

Mon, 19 Oct 2026 03:21:00 +0000

Vibe coding can turn an idea into a working prototype in minutes. But a successful demo doesn't guarantee reliable, secure, production-ready software. 🚀

Here's the real challenge: How do you know the code is actually correct?

🧪 Automated tests
🔍 Code review
🔐 Security and dependency checks
⚙️ Real-world validation

💡 The developer takeaway: Don't measure AI coding success by how quickly code is generated. Measure it by how reliably that code works, how safely it runs, and how confidently you can maintain it.

AI can accelerate development. Engineering discipline makes the result dependable.

👇 Let's discuss:

Which AI coding tool has earned your trust?
What's your must-have check before merging AI-generated code?

Share your real-world experience. Let's exchange practical insights—not just tool hype.

📖 SEOSiri's guide to vibe coding tools and code accuracy:
https://www.seosiri.com/2026/10/vibe-coding-tools-accuracy-guide.html

VibeCoding #SoftwareEngineering

Interconnected Growth: A Community Begins with Each of Us

Fri, 16 Oct 2026 19:17:32 +0000

There is a quiet vulnerability in sharing our work. Whether we publish an article, offer an idea, or describe something we have created, we put a small part of ourselves in front of others. Behind that contribution may be hours of effort, years of experience, or the courage to be visible for the first time.

Naturally, we hope someone will respond. A thoughtful comment, a reaction, or a simple acknowledgment can reassure us that our contribution has reached another person.

Within a growing community, however, that hope carries a shared responsibility. If we all publish and then wait for others to begin the conversation, even a website filled with valuable contributions can feel remarkably quiet.

Participation Makes Belonging Possible

A developing platform needs more than a steady flow of new content. It needs people who take an interest in what others bring to it.

It is understandable to focus on our own work. Time is limited, responsibilities compete for our attention, and many of us are trying to build something meaningful alongside other commitments. Still, when we hope for engagement, it is worth considering whether we are making room to offer it ourselves.

Reading another person’s article, acknowledging a useful observation, or asking a sincere question helps establish the culture we would like to experience. These small actions make participation feel worthwhile, particularly for people who are still finding their confidence.

For someone wondering whether their work belongs, a few considerate words may carry more weight than we realize.

Mutual Support Without Keeping Score

Supporting one another should never become an obligation to exchange praise. A reaction does not create a debt, and leaving a comment should not come with an expectation of repayment.

The value lies in sincere attention.

We can recognize effort without agreeing with every conclusion. We can offer a different perspective respectfully, share an experience that adds to the discussion, or explain what we found useful. Meaningful engagement gives someone evidence that their contribution has been considered.

Over time, that attention builds familiarity and trust. People become more comfortable sharing unfinished ideas, asking questions, and offering their own knowledge. The community gains depth because its members feel there is someone on the other side of the conversation.

Our Growth Is Connected

On a website that is still developing its community, each interaction helps shape what the platform becomes.

When we respond thoughtfully to someone’s work, we give them a reason to return and contribute again. Their continued participation may help another person learn, connect, or feel encouraged. What begins as a small gesture can gradually strengthen the experience for everyone.

No individual can create an active community alone, and nobody should feel responsible for responding to everything. But we can each contribute to an environment where attention moves in more than one direction.

Before leaving after our next post, perhaps we can spend a little time with someone else’s. Read beyond the headline. Acknowledge an idea that deserves consideration. Leave the kind of thoughtful response we would appreciate receiving.

Every contribution represents a person hoping to be heard. A growing community becomes stronger when we make space to hear one another.

Vericore: AI Can Write the Code. But Who Verifies the Change?

Wed, 14 Oct 2026 10:42:51 +0000

AI coding agents are changing how we build software. They can generate features, fix bugs, write tests, and help developers move faster.

But there's a question I keep thinking about:

How do we know an AI coding agent changed what we intended it to change?

An agent might implement a feature correctly but also modify unrelated files. It might produce code that looks convincing while leaving some requirements unverified.

Passing tests is important, but it doesn't automatically prove that every intended constraint was respected.

That's the problem I'm exploring with VeriCore.

GitHub: Vericore

What is VeriCore?

VeriCore is an open-source, local-first verification layer for AI coding agents, currently focused on Java and Kotlin repositories.

Its core idea is simple:

Prepare the change boundary before editing. Verify against it afterward.

Instead of relying only on reviewing the final diff, VeriCore establishes a repository-bound change contract before the developer or AI agent starts making changes.

The workflow looks like this:

Analyze the repository and gather engineering evidence.
Prepare a change contract describing the intended change and planned files.
Let your usual AI coding agent implement the change.
Verify the repository against the original contract.
Produce a verification result with supporting information.

The coding agent can continue using its normal workflow. VeriCore adds a separate verification layer around it.

Why is this useful?

Imagine asking an AI agent to add input validation to a payment service.

The agent implements the validation, but it also changes an unrelated configuration file.

Your tests might still pass.

However, you asked for a specific change, and the agent made a broader one.

VeriCore's change-safety workflow is designed to detect changes outside the prepared scope and identify problems such as a missing, stale, or mismatched verification contract.

The goal isn't to prevent AI agents from changing code. It's to make the boundaries of those changes explicit and checkable.

Three principles behind VeriCore

Deterministic evidence first

Repository facts should come from inspecting the repository, not from a language model guessing what the code contains.

VeriCore builds deterministic engineering evidence before optional AI-assisted interpretation.

Verify against the original contract

VeriCore persists the change contract before editing begins.

Verification should use that original contract rather than silently creating a new one from the already-modified repository.

Be honest about what has been verified

A tool shouldn't claim that a requirement has been satisfied when it lacks the evidence to evaluate it.

VeriCore distinguishes successful checks from failures and criteria that remain inconclusive or unevaluated.

It is not a replacement for tests, code review, or engineering judgment. A successful verification result does not prove that arbitrary software is semantically correct.

How can you try it?

VeriCore is open source, and the repository includes installation instructions, a CLI, local MCP integration, a REST interface, and a reusable GitHub Action.

Start with the repository:

Repository

The basic workflow is:

vericore init vericore scan --path . vericore inspect --path .

Before making a change:

vericore prepare "add payment validation" \ --path . \ --planned-path src/main/kotlin/com/example/PaymentService.kt

After the coding agent finishes:

vericore verify --path .

Replace the example file path and change description with the paths and task in your own project. Run your normal tests and review the diff as well.

For installation details and the complete workflow, see the project's documentation.

What I'd love feedback on

I'm interested in feedback from developers who use AI coding agents in real projects.

How do you detect changes outside an agent's intended scope?
Would you use a separate verification step in your local workflow or CI pipeline?
What evidence would you need before trusting a verification result?
Which integrations would make a tool like this useful in your development environment?

I'm building VeriCore in the open and would appreciate honest feedback, bug reports, and contributions.

The broader idea is simple: as AI agents become more capable of writing software, we also need better ways to verify the changes they make.

AI can write the code. Let's make its changes easier to verify.

GitHub

Opus Core 1.2 já está disponível

Sun, 11 Oct 2026 03:07:27 +0000

Uma nova versão do sistema de gerenciamento web que venho desenvolvendo para aqueles que acreditam que construir para a web não deve significar carregar complexidade desnecessária.

O Opus Core nasceu de uma necessidade real: ter uma base própria, com controle sobre o código, liberdade para desenvolver e uma arquitetura que possibilitasse a criação de soluções sem impor ferramentas e convenções desnecessárias.

A versão 1.2 representa mais um passo nessa evolução.

O objetivo não é fazer tudo por você. É fornecer uma base sobre a qual você possa construir o que realmente precisa.

Seu próprio código. Liberdade para desenvolver. Menos restrições e limitações, mais controle.

Opus Core 1.2 ‿︵ Sua próxima ideia começa com a base.

Explore o projeto:
https://github.com/wellingtonpragidi/opuscore
https://opuscore.dev

Employee Response Ratio to our workflow dashboard alongside TAT and timestamps

Sat, 10 Oct 2026 17:02:05 +0000

Hi team—I'm proposing we add an Employee Response Ratio to our workflow dashboard alongside TAT and timestamps as a new performance recognition trigger.

I believe this will:
• Boost productivity by actively recognizing consistent employee engagement.
• Smooth out tasks by removing handoff friction.
• Optimize overall operations through better process visibility.

DevOps and Operations leads, what are your thoughts on this?

SoftwareEngineering #UiUx

the evolution of software development since the emergence of AI

Fri, 09 Oct 2026 09:51:04 +0000

It would be interesting to promote discussions on the evolution of software development since the emergence of AI, and how it has been transforming the sector and the jobs of many developers. In my experience, it's not advisable to swim against the current, so it would also be valuable to create a dedicated section to discuss and build technical AI applications that can boost our productivity and allow us to create more complex, useful developments that non-technical users cannot achieve.

Do you think the emergence of AI is a positive or negative event for software developers?

How to Prevent Algorithmic Bias When Using AI Tools as MCP Connectors

Wed, 07 Oct 2026 03:44:35 +0000

As developers shift toward agentic AI architectures, the Model Context Protocol (MCP) has emerged as a groundbreaking standard for connecting LLMs to local data sources, APIs, and development environments. However, hooking a powerful LLM directly into your workflows via an MCP connector introduces a major risk: amplifying algorithmic bias.

If your underlying model suffers from data skew, or if your context-retrieval pipeline lacks guardrails, your AI assistant will generate biased code, flawed evaluations, or skewed data summaries.

Here is a practical guide on how to design and configure your MCP connectors to actively mitigate algorithmic bias.

Enforce Structured Input & Output Schemas
Bias thrives in ambiguity. When building an MCP connector tool, do not rely on open-ended text blobs. Instead, establish strict JSON schemas for both incoming requests and outgoing tool results.
• The Fix: Filter out demographic markers or unneeded metadata at the connector layer before transmitting payload data to the model.
Implement Counter-Stereotypical Context Prompting
When your MCP server injects localized data into the LLM's context window, it can trigger hidden biases within the foundation model.
• The Fix: Hardcode robust system instructions directly into the prompt templates wrapped by your MCP server. Instruct the model to evaluate the context purely on functional logic, ignoring patterns that mimic historical biases.
Establish Multi-Source Data Diversity (Diversified RAG)

If your MCP server queries an internal database or local codebase to feed context to the LLM, a homogenous data source will lead to narrow, biased code recommendations.
• The Fix: Program your MCP connector to pull context from multiple, distinct nodes or repositories. Introduce diverse code repositories or documentation libraries into your retrieval pipeline to ensure varied training references.

Implement Human-in-the-Loop Validation Layers
Never allow an MCP tool to execute high-impact mutations (like direct git commits to production or automated user permission alterations) without manual validation.
• The Fix: Design your MCP connector tools with a strict approval phase. Use intermediate state flags (status: pending_review) so a human operator can review the generated code or decision for bias before deployment.
Audit MCP Interaction Logs Regularly
Bias mitigation is an ongoing process. You must log inputs, prompt context windows, and output generation samples traversing your MCP server.
• The Fix: Regularly analyze logs using semantic search scripts to flag repeating anomalies, unfair decision patterns, or toxic code constructs generated during model interactions.
Get Started with MCP

Building unbiased, highly deterministic AI workflows starts with choosing the right protocol framework. Explore open-source implementations, tools, and integration guides on the official SEOSiri Model Context Protocol Suite to secure your developer ecosystem today.

🚀 Architecture Shift: Why Cryptographic Tokens Beat Path-Based Routing

Tue, 06 Oct 2026 15:13:56 +0000

Learnt this during a recent pre-strategic development phase. I initially planned to build path-based URLs (/company-a, /company-b) for individual tenant portals, but the pivot to a Cryptographic Token Model (CTM) completely outclasses traditional path routing.

Here is the breakdown of why CTM is the superior choice for multi-tenant systems:

• URL Security: Path models leak sensitive tenant/company names in browser histories and HTTP referrers. CTM delivers 100% clean URLs (tasks.seosiri.com/v1/...), masking tenant footprints entirely.
• Spoofing Resistance: Path routing invites users to manually manipulate paths (/alpha ➡️ /beta). CTM makes tampering impossible by enforcing token signature verification right at the edge.
• Storage Isolation: Sharing origins on path models introduces severe LocalStorage XSS bleeding risks. CTM ensures hard isolation via parametrized database queries (WHERE tenant_id = ?).
• Agent Sync: Replaces brittle, complex URL path switching with clean, native background header passes (X-Employee-ID).
• The Best Part? You can deploy this entire robust security posture on Cloudflare Workers + D1 free tier for $0.00.

Stop relying on path hacks for multi-tenancy. Secure your boundary at the edge.

ForgeZero and Gloria: A Honest Look at a New Systems Language

Mon, 05 Oct 2026 19:59:23 +0000

Hi everyone. In this article I want to talk about ForgeZero and their own programming language, Gloria. I'll keep the review honest, with no exaggeration in either direction.
Before getting into it, I want to say a separate thank you to my mentor and teacher, Alex Voste, who introduced me to platforms like CoderLegion and has given me an enormous amount of knowledge along the way. It's largely thanks to him that I learned Linux properly and finally settled on my path in IT.
Why this project stands out
If you assumed that building your own systems language in 2026 is either a romantic exercise or a waste of time, ForgeZero is worth a second look. Gloria isn't another toy DSL bolted on top of Python. It's a serious, fully self-hosted compiler that emits native AMD64 binaries only a few hundred bytes in size, with no dependency on a Go runtime or libc.
What actually caught my attention

Zero-allocation by default.
There's no bloated heap sitting behind the scenes. Gloria talks to the kernel directly through syscalls (mmap, sys_open, write), which gives you tight, explicit control over memory from the very first line.
Deliberate architectural choices.
A few design decisions here show real engineering taste: >> chaining with register passing, built-in |? guard operators for safe short-circuiting, native vectors implemented with REP MOVSQ, and hash tables built on open addressing. None of this feels bolted on — it reads like a language designed around how the hardware actually works.
Coroutines written in pure assembly.
The project natively supports cooperative green threads (fibers), complete with its own register-level context switching and 4KB mmap-backed stacks. That's not a small feat to get right, and it shows a level of commitment most "systems-adjacent" languages don't bother with.
My verdict
ForgeZero and Gloria represent a genuinely substantial piece of work for anyone who still cares about true bare-metal systems programming. The language addresses a real pain point for engineers: it offers a clean, readable syntax while preserving full hardware predictability and extremely compact binaries. You don't often get both at once.
This is a project worth following for anyone who misses the days when code was written for speed, not for how many gigabytes of RAM it could comfortably consume.

Software Development Is More Than Just Writing Code

Tue, 29 Sep 2026 12:04:13 +0000

Being a software developer is not just about writing code or learning new programming languages. For me, it's about solving problems, exploring new ideas, and finding practical ways to turn those ideas into something useful.

Every project brings a different challenge. Sometimes the solution works exactly as expected, while other times a small mistake can take hours to find. These moments are a normal part of development, and they often teach me more than simply following a tutorial or reading documentation.

I believe the real growth of a developer comes from experimenting, making mistakes, and learning how to solve problems independently.

Learning Through Real Projects

One thing I enjoy most about software development is that there is always something new to learn. Technology changes quickly, development tools continue to improve, and new approaches make it possible to solve old problems in different ways.

Working on projects helps me understand how things work beyond the surface. Writing code is only one part of the process. Understanding requirements, planning a solution, debugging unexpected behavior, and improving existing code are equally important.

I've learned that a solution doesn't have to be complicated to be effective. Sometimes, a simple and well-organized approach is much easier to maintain than a complex implementation.

The Challenges That Make Developers Better

Every developer encounters bugs, confusing errors, unexpected results, and situations where the first solution doesn't work.

Instead of seeing these moments as failures, I see them as opportunities to understand the problem more deeply. Debugging teaches patience, problem-solving develops logical thinking, and reviewing old code helps identify better ways to approach future projects.

Good developers don't know every answer. They keep learning, ask questions, and know how to work toward finding the answer.

I also believe that writing code that works is only the beginning. Writing code that other developers can understand, maintain, and improve is an important part of building reliable software.

Sharing Knowledge and Learning Together

Software development is a field where learning from others can make a real difference. A problem that takes hours to solve alone might become much easier after reading another developer's experience or discovering a different approach.

That's one reason I enjoy connecting with other developers, sharing useful tips, discussing technical challenges, and learning from different perspectives.

Everyone has a different journey. Some developers enjoy backend architecture, others focus on frontend experiences, and many explore databases, automation, cloud technologies, or artificial intelligence. Each perspective brings something valuable to the community.

Looking Ahead

My goal is to keep improving my skills, build useful projects, explore new technologies, and become better at solving real-world problems.

I don't believe learning ever truly ends in software development. There will always be a new tool to explore, an existing skill to improve, or a different way to approach a challenge.

For me, progress isn't only about how much code I write. It's also about how much I understand, how effectively I solve problems, and how much value I can create through the things I build.

Keep learning, keep experimenting, and keep building. Every small improvement is a step forward.

I'd love to hear from other developers: What's one important lesson you've learned from a project that didn't go as planned?

Let's share our experiences and learn from each other.

Where Should Developers Write? A Practical Comparison of LinkedIn, Medium, Dev.to, and CoderLegion

Sun, 27 Sep 2026 17:55:21 +0000

I've published on all four platforms and get asked which one to use. The honest answer: it depends on what you're trying to accomplish. Here's how I think about each one.

LinkedIn - Entry Point, Not Destination

LinkedIn is best used as a conversation starter. Put a provocative question, a key takeaway, or a short observation in the post, then include the link to the full article on Dev.to, CoderLegion, or Medium in the first comment. This utilizes LinkedIn's strengths (professional reach, cross-border visibility) without asking it to do what it's bad at: hosting deep technical content. Think of it as the top of a funnel, not where the real discussion takes place.

Medium - for Storytelling and Long-Form Thought Leadership

Medium is ideal for writing enduring works such as career reflections, architectural post-mortems, and in-depth essays. The Partner Program adds a monetisation path. The main downside is discoverability: new posts get buried quickly and are difficult to find unless you are already in a publication or have an existing audience driving traffic there. Medium rewards writers who bring in their own readers, but it does little to surface new voices on its own.

Dev.to - for Tutorials and the Learning Community

Dev.to is the most beginner-friendly of the four. It's open, free, and the tag system makes technical tutorials easy to find. It's a good home for "how I built X" posts, quick tips, and beginner content. The weakness is that high posting volume makes it easy for solid posts to get buried quickly, and platform support can be slow. A post indexing issue I reported took over a month to be addressed. The community is welcoming but responses can be sparse unless your post gets picked up early.

CoderLegion - for Community Feedback and Visibility Without an Existing Audience

What I appreciate most about CoderLegion is the community responsiveness, people actually read and comment, rather than just scroll. The Trending and Promotion tags give newer posts and newer members a real shot at visibility from the home page, which the other platforms largely don't offer.

One feature worth highlighting is the Developer's Journey sharing group, which is designed specifically for developers (both senior and junior) to share their progress and learn from each other's experiences. It creates a supportive space where growth is visible and celebrated, and it gives newer members additional exposure beyond their own posts. In my opinion, this is a significant differentiator if you are early in your career and seeking a community that actively helps you grow and not just consume content.

If you're just starting out or want genuine peer feedback rather than chasing an algorithm, this is where I'd start. Platform issues I've reported have been addressed far faster than my experience with Medium or Dev.to.

My Rough Rule of Thumb

Role	Platform
Entry point / professional amplifier	LinkedIn
Community discussion + early visibility and growth	CoderLegion
Technical tutorials, how-tos	Dev.to
Long-form essays, thought leadership	Medium

Most experienced developers end up cross-posting to two or three. Write once, adapt the framing, post everywhere that fits.

A Note on CoderLegion

Having the Trending/Promotion visibility model is a real differentiator for newer voices - most platforms bury new posts the moment something more popular is posted. Community and team responsiveness is something worth mentioning out loud: it indicates that the platform is still in a phase where the people building it care about individual members.

Discussion

How would you leverage different platforms to accelerate the development of your projects?

🚀 Open-source developers: what are you building next?

Sat, 26 Sep 2026 21:57:32 +0000

SEOSiri is opening up more of its developer ecosystem through developers.seosiri.com — a developer-focused hub for open-source projects, MCP tooling, AI infrastructure, APIs, security, automation, and experimental engineering.

The goal isn't just to publish another collection of repositories.

It's to make useful developer infrastructure discoverable, inspectable, forkable, and buildable.

🔓 Explore the open-source projects

The SEOSiri GitHub organization currently includes public projects across areas such as:

🧩 MCP & AI tooling
• Search governance
• Semantic entity processing
• Keyword clustering
• Content/schema automation
• Database & infrastructure tooling
• Enterprise operations

🤖 Robotics & Industrial AI
• Bio-Robotics MCP
• Industrial AI Gateway
• Multimodal sensing
• IoT and cyber-physical systems

🛠️ Developer & DevOps tooling
• API validation
• DevOps intelligence
• DNS/security auditing
• Developer infrastructure

Several projects are explicitly released as open-source, including MIT-licensed repositories. ([GitHub][1])

👩💻 Built for developers

If you're interested in:

Open Source • MCP • AI Agents • DevOps • Python • TypeScript • APIs • Cloud Infrastructure • Robotics • Developer Tools

take a look at the code, README files, issues, and contribution opportunities.

👉 Developer Hub:
https://developers.seosiri.com/

👉 Open-source repositories:
https://github.com/SEOSiri-Official

Don't just consume AI tooling.

Read the code. Fork it. Test it. Break it. Improve it. Build something new.

If you're a developer, which area would you like to contribute to or see more open-source projects in?

OpenSource #MCP #Developers #AIEngineering #DevOps

I kept the post community-first rather than promotional: the public GitHub organization confirms multiple public repositories, including MCP, developer tooling, industrial AI, and open-source projects. ([GitHub][1])

[1]: https://github.com/SEOSiri-Official? SEOSiri · GitHub

How Much Does It Cost to Develop a Pokémon-Style App?

Fri, 25 Sep 2026 06:03:18 +0000

Mobile gaming has changed significantly in recent years, with augmented reality, location-based features, and interactive experiences becoming increasingly popular. Games inspired by Pokémon combine entertainment with exploration, allowing players to interact with virtual characters and game elements in the real world. If you are planning to create a similar mobile experience, one of the first questions to consider is the development budget.

Before starting such a project, it is also important to understand what makes this type of application different from a standard mobile game. A concept discussed across platforms such as pokemon electronmagazine highlights how Pokémon-inspired experiences can combine gaming, digital characters, exploration, and community interaction. Building these features requires careful planning, the right development team, and a suitable technology stack.

What Is a Pokémon-Style App?

A Pokémon-style app can refer to a mobile game that uses collectible characters, missions, battles, rewards, maps, and interactive gameplay. Depending on the concept, developers can also add augmented reality (AR), GPS tracking, multiplayer functionality, social features, and in-app purchases.

The final cost depends heavily on how many of these features you want to include. A simple character-collection game can be much cheaper than a large location-based AR game with real-time multiplayer functionality.

How Much Does It Cost to Develop a Pokémon-Style App?

The development cost can generally range from $50,000 to $300,000 or more, depending on the application's complexity.

A basic version with limited characters, simple gameplay, and standard mobile features may cost around $50,000 to $90,000. A medium-complexity application with GPS, advanced animations, online accounts, payments, and social features may cost approximately $90,000 to $180,000.

A highly advanced Pokémon-style app with AR, multiplayer gaming, sophisticated maps, real-time interactions, custom 3D assets, and backend infrastructure can exceed $200,000 to $300,000.

These are estimated development ranges rather than fixed prices. The actual budget depends on the project scope, development location, design requirements, technology, and team experience.

Key Features That Affect Development Cost

The features included in your application have one of the biggest effects on the final budget.

User Registration and Profiles

Users need a convenient way to create accounts and manage their profiles. Developers can include email registration, social login, profile customization, achievements, and account settings.

A basic login system is relatively inexpensive, while advanced profiles with player statistics and social connections require additional development.

Character Collection

Character collection can become one of the core parts of a Pokémon-style application. Players may discover, collect, upgrade, and customize digital characters.

Creating unique characters requires graphic designers, illustrators, and potentially 3D artists. The number and complexity of characters can therefore have a major impact on the budget.

GPS and Location-Based Features

If your game allows users to discover virtual content based on their physical location, GPS functionality becomes essential.

Developers need to integrate mapping services, location tracking, geofencing, and location-based events. These features can increase both development time and ongoing service costs.

Augmented Reality

AR is one of the most technically demanding features you can add to this type of application. It allows digital characters or objects to appear within the user's real-world environment through a smartphone camera.

AR development may require specialized developers and additional testing across different devices. More advanced AR interactions can significantly increase the overall development cost.

Battles and Multiplayer

If players can compete with one another, the application needs additional backend infrastructure. Real-time multiplayer features require synchronization between users, game servers, player matchmaking, and security measures.

A simple turn-based battle system may be easier to develop than a real-time multiplayer environment.

In-App Purchases

Many mobile games generate revenue through virtual items, character upgrades, premium content, or subscriptions.

Developers need to integrate payment systems and comply with Apple and Google app-store requirements. The complexity of your monetization model will influence both development and maintenance costs.

Technology Stack

The technology used to build the application can also affect the budget. Developers may use frameworks such as Unity or Unreal Engine for game development, while native Android and iOS technologies can be used for platform-specific functionality.

For AR capabilities, developers may work with technologies such as ARKit for Apple devices and ARCore for Android. Backend services can be built using technologies such as Node.js, Python, Java, or other suitable frameworks.

Cloud infrastructure is also important for storing user accounts, game progress, digital assets, and multiplayer information.

Development Team Required

A Pokémon-style app usually requires more than one developer. A typical team may include:

Project manager
UI/UX designer
Mobile developers
Game developer
Backend developer
AR developer
2D or 3D artist
QA tester
DevOps specialist

For a smaller project, some team members can handle multiple responsibilities. Larger games generally require specialists for each major area.

Development Time

The development timeline depends on the complexity of the project. A basic Pokémon-inspired application might take approximately 4 to 7 months to develop.

A medium-complexity game with maps, online accounts, character systems, and social features may require 7 to 12 months. An advanced AR and multiplayer application can take 12 months or longer, particularly when it includes extensive testing and custom content.

Creating characters, animations, maps, and other game assets can also extend the timeline.

Other Costs to Consider

Development is only part of the overall investment. After launch, you may need to budget for server hosting, cloud services, security, bug fixes, technical support, content updates, marketing, and app-store fees.

Games also need regular updates to keep users interested. New characters, missions, seasonal events, and improvements can become ongoing expenses.

How to Reduce Development Costs

You do not necessarily need to launch with every possible feature. Starting with a Minimum Viable Product (MVP) can help control the initial budget.

For example, you could launch with a limited number of characters, basic gameplay, and a simple progression system. Once users provide feedback, additional features such as AR, multiplayer battles, and advanced social functions can be introduced gradually.

Cross-platform development can also reduce costs when compared with building completely separate applications for Android and iOS.

Final Thoughts

Developing a Pokémon-style app can require a significant investment, especially when the project includes AR, GPS, multiplayer gaming, custom characters, and real-time services. A basic version may start around $50,000, while a sophisticated platform can cost several hundred thousand dollars.

Before development begins, define your target audience, core gameplay, monetization strategy, technical requirements, and launch platform. This will make it easier to create an accurate development estimate and avoid unnecessary expenses.

Whether you are researching gaming trends through pokemon electronmagazine or planning your own mobile gaming product, the most practical approach is to start with a clear feature list and scalable development plan. A well-designed MVP can help you test the concept before making a larger investment.

White Label WordPress Development Scale Your Agency Without Hiring

Tue, 22 Sep 2026 13:37:23 +0000

Your agency can win more WordPress projects without hiring another developer, but the real challenge is delivering that extra work without stretching your existing team too thin. When client requests pile up, deadlines tighten, and your developers are already committed to other projects, white-label WordPress development can offer a practical way to increase delivery capacity while keeping your agency client-facing.

The model is straightforward: an external WordPress development team handles the technical work, while your agency manages the client relationship and presents the finished work under its own brand. The key question isn't whether outsourcing is possible, but whether the setup gives you enough control over quality, communication, timelines, and client experience to scale without creating another operational headache.

What Is White Label WordPress Development?

White-label WordPress development is a service model where a third-party WordPress team develops websites, custom features, fixes, or maintenance work on behalf of another agency. The agency then delivers that work to its own clients under its brand.

The client may never interact directly with the development partner. From the client’s perspective, the agency remains responsible for the project.

This makes white labeling different from simply referring a client to another company. The development partner works behind the scenes, allowing the agency to expand its technical capacity without building a larger in-house team.

Typical white-label WordPress work includes:

Custom WordPress website development
Theme customization
Plugin development and integration
WooCommerce development
Website migrations
WordPress maintenance and updates
Performance optimization
Bug fixing and technical support
Landing page development
API and third-party integrations

For agencies, the biggest benefit is capacity. Instead of turning down projects because your internal team is busy, you can outsource specific development work.

Why Agencies Use White Label Development to Scale

Hiring full-time developers is not always the right answer to increased demand.

A new employee brings salary costs, recruitment time, onboarding, management, equipment, benefits, and ongoing workload considerations. More importantly, agencies do not always have a consistent amount of development work throughout the year.

White-label development changes the equation.

For agencies with tight project budgets, affordable white-label WordPress development can help manage costs while leaving room for design, strategy, project management, and client support.

You can add external development capacity when project volume increases and scale back when demand slows. This creates a more flexible delivery model.

For example, imagine a small digital agency has three active WordPress projects. Its designers and account managers can handle the client-facing work, but the development team is already at capacity.

A new project arrives with a tight deadline.

Instead of hiring someone immediately, the agency can outsource the development portion while keeping strategy, design direction, communication, and project management internally.

That means the agency can potentially take on more work without increasing its permanent headcount at the same rate.

What Work Should You Keep In-House?

Not every part of a WordPress project needs outsourcing.

A practical approach is to keep activities that directly influence the client relationship in-house and delegate specialized production work when appropriate.

Usually worth keeping in-house:

Client communication
Discovery calls
Project strategy
Brand direction
UX decisions
Creative approvals
Account management
Final quality review

Often suitable for white-label delivery:

WordPress development
Theme implementation
Plugin configuration
Custom functionality
WooCommerce development
Technical troubleshooting
Website migration
Routine maintenance

This division gives your agency control over the parts clients value most, while letting an external team handle repetitive or specialized technical execution.

How White Label WordPress Development Works

The workflow does not need to be complicated.

1. Your agency wins the project

The client signs an agreement with your agency. Your team establishes the scope, requirements, timeline, and expected deliverables.

2. You prepare the development brief

The development partner receives everything required to start work. This can include designs, content, functionality requirements, technical specifications, hosting information, and acceptance criteria.

A detailed brief matters because vague instructions create unnecessary revisions.

3. The WordPress team builds the project

External developers work to your specifications and development standards.

Depending on the arrangement, they may work in a staging environment, Git repository, development server, or directly through your project management workflow.

4. Your agency reviews the work

Before the client sees anything, your team should test the website.

Check responsive layouts, forms, links, performance, browser behavior, content, integrations, and any functionality included in the original scope.

5. You deliver the project

Once the work meets your internal standards, your agency presents it to the client through your normal delivery process.

This final review is important. white-label does not mean removing your agency from quality control.

How to Choose a White Label WordPress Partner

The cheapest development partner isn't automatically the most useful.

Your priority should be predictable delivery.

Before starting a long-term relationship, look at several practical factors.

WordPress expertise: Make sure the developers understand WordPress beyond basic page building. Ask about custom WordPress themes, plugins, WooCommerce, security, performance, and integrations when relevant to your projects.
Communication: Delayed replies can quickly become client-facing delays. Establish communication expectations before work begins.
Development process: Ask how requirements, revisions, testing, staging, and handoffs are handled.
Code quality: A website that looks correct today can still create problems later if the underlying implementation is poor.
Confidentiality: Since the partner operates behind your agency, agreements covering confidentiality and client information should be clear.
Scalability: If your project volume doubles, can the partner handle additional work without sacrificing delivery quality?
Revision policy: Define how bugs, scope changes, and revision rounds are handled before the first project starts.

White Label vs. Hiring an In-House WordPress Developer

These two approaches solve different problems.

An in-house developer gives you direct control over daily work, internal processes, and team collaboration. It can make sense when development demand is consistently high and predictable.

White-label development provides flexibility. You can add technical capacity without immediately committing to another permanent employee.

The choice often depends on workload, not ideology.

If your agency has steady development work every month, building internal capacity may be worth considering. If demand fluctuates or you need specialist support for certain projects, a white-label arrangement can scale more easily.

Some agencies also use both models. An internal developer handles core projects while a white-label partner provides overflow capacity during busy periods.

Common Mistakes Agencies Should Avoid

white-label development can create problems when agencies treat it as a simple handoff instead of a delivery system.

One common mistake is sending incomplete project requirements. Developers cannot reliably deliver against a brief that keeps changing.

Another is skipping internal testing. Even if the development partner has its own QA process, your agency should perform a final review before the client receives the work.

Pricing can also be confusing. Agencies should understand development costs, project scope, revision limits, and their own margin before quoting clients.

Finally, avoid depending entirely on one external developer without documenting processes. If that person becomes unavailable, your agency should still have enough project information to continue the work.

How to Make White Label WordPress Development Work Long Term

The strongest setups usually have repeatable processes. If you are managing multiple projects, following practical WordPress web development tips such as using staging environments, documenting requirements, testing responsive layouts, and keeping development workflows consistent can help reduce avoidable issues.

Create a standard development brief for every project. Include design files, page requirements, functionality, integrations, content status, technical constraints, deadlines, and acceptance criteria.

Use a consistent staging and review process.

Keep communication centralized rather than sending scattered instructions across multiple channels.

Most importantly, document recurring tasks. When you repeat the same WordPress development process across projects, documentation reduces mistakes and makes onboarding easier.

The goal is not simply to outsource work. The goal is to create a reliable extension of your agency’s delivery team.

Conclusion

White-label WordPress development gives agencies another way to increase delivery capacity without immediately increasing permanent headcount. It works particularly well when project demand fluctuates, specialist WordPress skills are needed, or an internal team is already operating near capacity.

The model works best when responsibilities are clearly divided. Your agency controls strategy, client communication, project direction, and final quality, while the development partner handles agreed technical execution. With a clear, brief, reliable workflow, testing process, and well-defined expectations, white-label development can become a practical part of an agency’s operating model rather than a last-minute outsourcing solution.

Frequently Asked Questions

1. What is white-label WordPress development?

White-label WordPress development is when an external WordPress development team builds websites or technical features for an agency. The agency then delivers the completed work to its client under its own brand.

2. Can agencies use white-label WordPress development without hiring developers?

Yes. Agencies can use an external WordPress development team to increase technical delivery capacity without immediately adding full-time developers to their internal staff.

3. What WordPress services can be white-labeled?

Common services include custom WordPress development, theme customization, plugin development, WooCommerce, website migration, maintenance, performance optimization, bug fixing, and third-party integrations.

4. Is white-label WordPress development cheaper than hiring an in-house developer?

It can reduce fixed staffing costs when development demand is inconsistent, but total costs depend on project volume, scope, partner rates, revisions, and the agency’s internal management requirements.

5. How do agencies maintain quality with white label WordPress development?

Agencies can maintain quality by using detailed project briefs, defined development standards, staging environments, structured testing, clear revision rules, and an internal quality review before delivering the project to the client.

What an AI-Ready ERP Could Mean for the Future of Solar Operations

Tue, 22 Sep 2026 10:46:00 +0000

The solar industry has changed dramatically over the past decade. What once looked like a relatively straightforward business of selling and installing panels has become a complex operation involving lead management, site surveys, system design, procurement, inventory, financing, installation teams, customer communication, maintenance, and performance tracking.

As solar companies grow, managing all these moving parts becomes increasingly difficult. Teams often rely on spreadsheets, separate applications, emails, messaging platforms, and accounting tools to keep operations running. While these tools can work at a smaller scale, they can create disconnected information and repetitive manual work as the business expands.

Artificial intelligence is now adding another dimension to this transformation. AI can analyze large amounts of business data, identify patterns, automate repetitive activities, and support faster decision-making. But AI works best when it has access to organized, reliable, and connected information.

That is where the next generation of ERP systems could make a difference.

Why Solar Operations Are Becoming More Complex

Solar businesses operate across several interconnected stages. A customer may begin by submitting an inquiry, followed by qualification, consultation, site assessment, system design, quotation, financing, procurement, installation, inspection, and after-sales service.

Each stage generates information.

For example, the sales team needs customer and project details, the design team needs technical information, procurement needs equipment requirements, installation teams need schedules and site instructions, and finance teams need accurate project costs and payment information.

When these details are stored in separate systems, employees may spend considerable time moving information from one place to another.

This creates several operational challenges:

Duplicate data entry
Delays between departments
Difficulty tracking project status
Limited visibility into inventory
Manual reporting
Communication gaps
Inconsistent customer information
Challenges forecasting demand and costs

An integrated system can bring these processes into a more connected workflow.

Understanding ERP for Solar Industry

ERP for solar industry refers to enterprise resource planning software designed or configured to manage the business processes involved in solar operations.

Instead of treating sales, inventory, finance, projects, procurement, and customer management as isolated functions, an ERP system can connect them through a shared operational environment.

For a growing solar company, this can mean that information entered during the sales process can become useful later during project planning and installation.

For example, when a customer approves a solar project, the system could connect the project with required equipment, expected costs, installation schedules, invoices, and other operational information.

The value isn't simply having another software platform. The larger benefit is creating a consistent flow of information across the organization.

Where AI Fits Into Modern ERP

Traditional ERP systems primarily focus on organizing and managing business processes. AI can add an intelligence layer on top of that foundation.

Instead of simply storing information, an AI-enabled system could analyze it and help teams understand what is happening.

For example, AI could potentially identify unusual project delays, detect changes in purchasing patterns, highlight inventory risks, or help predict which projects may require additional attention.

This creates an important distinction.

Traditional ERP asks:
“What happened?”

AI-enabled ERP can help ask:
“What is happening, why might it be happening, and what could happen next?”

The quality of those insights, however, depends heavily on the quality of the underlying business data.

Predictive Planning for Solar Projects

Solar projects involve multiple variables. Equipment availability, weather conditions, workforce capacity, site requirements, customer approvals, and supplier timelines can all influence project schedules.

An AI-ready ERP could use historical and current operational data to support more informed planning.

For example, the system could analyze previous projects and identify patterns related to:

Installation duration
Equipment consumption
Project delays
Procurement timelines
Labor requirements
Regional demand
Customer conversion rates

Managers could then use these insights when planning future projects.

AI would not replace human decision-making. Instead, it could provide additional information that helps teams make decisions with greater context.

Smarter Inventory Management

Inventory management is another area where AI-enabled ERP systems could become valuable.

Solar companies may need to manage panels, inverters, mounting structures, cables, batteries, connectors, and other components. Holding too much inventory can tie up capital, while insufficient stock can delay installations.

An intelligent ERP system could analyze historical usage, current projects, purchasing patterns, and expected demand to help businesses identify potential inventory shortages or excess stock.

For instance, if several upcoming projects require a particular inverter model, the system could flag the projected requirement before installation teams reach the procurement stage.

This type of visibility can help procurement teams move from reactive purchasing toward more proactive planning.

Software for Solar Installers: Moving Beyond Scheduling

Software for Solar Installers is increasingly becoming more than a tool for managing installation schedules.

Installation teams need access to project information, customer details, site requirements, equipment specifications, documentation, and task updates.

When this information is connected to an ERP environment, field teams can potentially work with the same project information used by office-based teams.

An AI-enabled system could further assist by identifying scheduling conflicts, prioritizing tasks, or highlighting projects that need additional preparation.

For example, if a project requires a specific component that has not yet arrived, the system could flag the issue before the installation date approaches.

This creates an opportunity to identify problems earlier rather than discovering them when crews are already ready to begin work.

AI-Powered Customer Insights

Customer information is another valuable source of data for solar companies.

Sales teams may track inquiries, consultations, quotations, follow-ups, conversion rates, financing preferences, and project outcomes.

An AI-enabled ERP could analyze these patterns to help businesses understand customer behavior.

Possible applications include:

Identifying common reasons for lost sales
Finding patterns in customer inquiries
Forecasting potential demand
Supporting lead prioritization
Analyzing sales cycle duration
Identifying frequently requested system configurations

These insights could help sales managers refine their processes while giving leadership a clearer view of business performance.

Connecting Finance With Project Operations

Solar project profitability depends on more than revenue.

Companies need to understand equipment costs, labor expenses, procurement costs, installation expenses, financing, customer payments, and other project-related expenditures.

When financial information remains disconnected from project operations, understanding actual project performance can take additional effort.

An integrated ERP system can connect project and financial information, making it easier to monitor costs throughout the project lifecycle.

AI could eventually help identify cost anomalies or changes in project profitability by analyzing historical financial and operational patterns.

For example, if certain project types consistently exceed their estimated installation costs, the system could highlight that trend for management review.

Predictive Maintenance and After-Sales Service

The relationship between a solar company and its customer does not necessarily end when installation is complete.

Solar systems require monitoring, maintenance, troubleshooting, and customer support over time.

AI-enabled ERP systems could combine installation records, service history, equipment information, and performance data to support more proactive maintenance processes.

Rather than waiting for every issue to be reported manually, businesses could use data-driven alerts to identify systems that may require attention.

This could help service teams organize their workloads and potentially address issues before they become larger customer problems.

What an AI-Ready ERP Needs

Not every ERP system is automatically ready for AI. Businesses considering this direction should look beyond simply adding an AI feature.

An AI-ready ERP should ideally provide a strong foundation for connected data and automation.

1. Centralized Data

Customer, project, inventory, financial, and operational information should be accessible through a connected environment.

2. Automation

Routine workflows should be capable of being automated where appropriate, reducing unnecessary manual work.

3. Real-Time Visibility

Teams should be able to access current project and business information rather than relying on outdated reports.

4. Integration Capabilities

The ERP should be capable of connecting with other systems used by the organization, including accounting, CRM, field-service, and communication platforms.

5. Data Quality

AI-generated insights are only as reliable as the information behind them. Clean and consistent data is therefore essential.

6. Flexible Reporting

Managers should be able to analyze information across projects, regions, teams, products, and financial categories.

The Human Role Still Matters

AI-enabled ERP should not be viewed as a replacement for experienced solar professionals.

A system can identify patterns, generate forecasts, automate repetitive workflows, and surface potential problems. But business leaders still need to understand their market, customers, teams, suppliers, and operational realities.

Human judgment remains particularly important when circumstances do not match historical data.

For example, an unexpected regulatory change, supplier disruption, weather event, or local market shift may require decisions that cannot be made purely from historical patterns.

The most useful approach is therefore likely to be collaboration between people and intelligent software.

How Solar Companies Can Prepare for the AI Shift

Companies do not necessarily need to transform their entire operation overnight.

A practical approach can begin with identifying processes where disconnected information creates the most friction.

Businesses can start by asking:

Where is our team entering the same information multiple times?
Which reports require significant manual preparation?
Where do project delays commonly occur?
How accurately can we track inventory?
Can sales, operations, and finance access the same project information?
Which decisions currently depend on spreadsheets?
What data would be useful for future forecasting?

These questions can help identify areas where an integrated ERP system could provide the greatest operational value.

The next step is ensuring that business data is structured consistently. Once the foundation is in place, automation and AI capabilities can be introduced more effectively.

The Future of Solar Operations Is Connected

The future of solar technology is often discussed in terms of more efficient panels, improved batteries, smarter inverters, and advanced energy systems.

But the business infrastructure supporting those technologies matters too.

As solar companies manage larger customer bases and increasingly complex project pipelines, disconnected systems can become a significant operational challenge.

An AI-ready ERP could provide a centralized foundation where business data, workflows, automation, and intelligent analysis work together.

The goal isn't simply to make software more sophisticated. It is to help solar businesses build operations that can respond to growth, identify problems earlier, and make better use of the information they already generate.

Companies such as Triple Minds are part of the broader software development ecosystem helping businesses explore customized digital solutions for evolving industry requirements. For solar businesses considering their next technology investment, the important question may no longer be whether they need more software, but whether their existing systems can work together intelligently.

Final Thoughts

AI has the potential to change how solar companies plan projects, manage inventory, support customers, monitor finances, and organize field operations. But AI alone is not the complete solution.

It needs a reliable operational foundation.

An ERP system can provide that foundation by connecting the different parts of a solar business. When combined with AI, automation, real-time data, and predictive analytics, it could move solar operations from simply recording what happened toward understanding what may happen next.

For solar companies preparing for the next stage of growth, building an interconnected and AI-ready operational environment could become an important part of staying organized in an increasingly digital industry.

What If the Compiler Is Lying to You?

Sat, 12 Sep 2026 10:01:46 +0000

What If the Compiler Is Lying to You?

Ken Thompson imagined the impossible in 1984. Forty-two years later, AI code, npm, and software supply chains are making the same question uncomfortable again.

By Mahan Tavakoli — MahanKenway
Tehran, Iran
GitHub: github.com/MahanKenway

Imagine you inspect a program.

You read the source code.

You review the repository.

You compile it.

You compare the resulting binary.

Everything looks clean.

No backdoor.

No suspicious function.

No hidden payload.

You ship it.

And the backdoor is still there.

Not because you missed a line of code.

Because the compiler itself was taught to insert the backdoor.

That sounds like science fiction.

In 1984, Ken Thompson explained how to do it.

He didn't publish a hypothetical security bug.

He demonstrated a way of thinking about software trust that still sits underneath modern supply-chain security.

His ACM Turing Award lecture, “Reflections on Trusting Trust,” appeared in Communications of the ACM in August 1984, volume 27, issue 8, pages 761–763. Its central question was brutally simple: to what extent can we trust a statement that a program is free of Trojan horses?

Thompson's answer was essentially:

You may be trusting the wrong layer.

And that becomes weirdly relevant in 2026.

Because the software we build today increasingly has another thing sitting between a human and executable code:

AI.

1. The terrifying idea hidden inside a tiny compiler

Ken Thompson's famous demonstration starts with a C compiler.

The basic situation looks like this:

C source code
     |
     v
  compiler
     |
     v
 executable

Most developers intuitively trust the relationship:

source code
   ↓
compiler
   ↓
binary

We inspect the source.

We inspect the compiler.

We inspect the resulting program.

Therefore the resulting executable should be trustworthy.

Thompson showed why that conclusion does not necessarily follow.

His attack can be understood as a chain of self-reproducing trust.

A malicious compiler could recognize when it is compiling:

1. the login program

and secretly insert a backdoor.

But that is only the first trick.

The more interesting version recognizes when it is compiling:

2. the compiler itself

and secretly inserts the malicious compiler behavior into the new compiler binary.

Now the source code can be completely clean.

You can remove the malicious code from the compiler's source.

You can recompile.

And the compiled compiler can simply put the malicious behavior back.

The source looks innocent.

The binary is not.

Thompson's original lecture develops this idea in stages, beginning with a self-reproducing program and then applying the technique to a compiler so that the malicious behavior can persist without appearing in the source.

This is the important conceptual jump:

The thing producing your software can become part of the trusted computing base.

And once you understand that, “is the source code clean?” is no longer enough.

2. The trust problem is recursive

Let's draw the problem differently.

A normal developer may think:

I trust my source code.
        ↓
I trust my compiler.
        ↓
I trust my binary.

Thompson asks:

Why do you trust the compiler?
        ↓
Because you inspected its source.
        ↓
Who compiled that compiler?
        ↓
With what compiler?
        ↓
Who built that compiler?
        ↓
With what environment?

Eventually:

software
  ↓
compiler
  ↓
compiler compiler
  ↓
build system
  ↓
operating system
  ↓
hardware

You have reached a philosophical problem disguised as a technical one.

Trust has to terminate somewhere.

And wherever it terminates becomes part of your trusted base.

Thompson's paper is often summarized as a compiler backdoor story.

That's true.

But the deeper lesson is more general:

A system can be compromised at a layer that verifies the layers above it.

That is why this 1984 paper is still taught.

Not because everyone is worried about somebody secretly modifying GCC tomorrow.

Because the architecture of trust it describes is still real.

3. Supply-chain security is basically this problem with more boxes

Modern software rarely goes directly from:

my source

to:

my executable

Instead:

source
  ↓
dependencies
  ↓
package manager
  ↓
build scripts
  ↓
compiler
  ↓
libraries
  ↓
CI
  ↓
container
  ↓
registry
  ↓
deployment

And often:

dependency
    ↓
dependency
    ↓
dependency
    ↓
dependency

This is the software supply chain.

CISA's documentation on the 2020 SolarWinds compromise is a useful illustration of how consequential that chain can become: attackers compromised the SolarWinds Orion software supply chain, and malicious software was distributed through affected Orion products. CISA described the campaign as affecting government, critical-infrastructure, and private-sector organizations.

Notice what made SolarWinds so powerful.

Victims were not necessarily downloading an obviously malicious executable from an obviously malicious website.

They were receiving software through a trusted vendor's normal distribution mechanism.

That is the basic supply-chain attack:

you trust A
A depends on B
B is compromised
therefore
you indirectly trust B

Trust propagates.

So does compromise.

4. npm already gave developers a preview of this nightmare

Node developers don't need a theoretical lecture about transitive trust.

They have seen it happen.

In 2018, the npm package event-stream was compromised after a new maintainer added the malicious flatmap-stream dependency. npm's incident report says the malicious dependency targeted Copay, a cryptocurrency wallet application, and that malicious code was eventually deployed in Copay versions 5.0.2 through 5.1.0.

The critical detail is not the cryptocurrency angle.

It is the dependency relationship:

Copay
   ↓
event-stream
   ↓
flatmap-stream
   ↓
malicious code

The application did not necessarily contain:

// hello, I am malware

at the level where the developer expected to find it.

It inherited trust.

And inherited code.

Snyk reported that the malicious dependency had been downloaded millions of times during the incident, illustrating how a popular dependency could become a distribution mechanism for malicious code.

The interesting thing is that the source repository could still look respectable.

The package name could look legitimate.

The dependency tree could look normal.

The package manager could be doing exactly what it was designed to do.

And yet the final application was compromised.

That is Thompson's question in a modern costume.

5. Then there was SolarWinds

The SolarWinds incident took the same general idea to enterprise scale.

CISA reported that the campaign involved a compromise of the SolarWinds Orion software supply chain, with affected Orion versions distributed between March and June 2020.

Again, the fascinating thing is where the attacker stood.

They did not need to convince every final victim to execute a random malicious file.

They needed to compromise a trusted point in the production chain.

That turns:

one compromised developer environment

into:

thousands of potentially trusting customers

This is why supply-chain security can be asymmetric.

An attacker may only need to compromise one high-leverage component.

The defenders have to verify everything downstream.

6. The xz incident made Thompson's old argument feel almost physical

Then came xz Utils.

In March 2024, malicious code was discovered in xz versions 5.6.0 and 5.6.1. The Open Source Security Foundation described the backdoor as intentionally obfuscated and specifically designed to affect particular distribution builds.

MITRE's CVE entry describes a particularly striking mechanism: the malicious build process extracted a prebuilt object from a disguised test file and used it to modify functions in liblzma; the resulting library could then alter data interactions for software linked against it.

This is exactly the sort of thing that makes old software-security papers suddenly feel contemporary.

The code did not simply say:

if evil:
    backdoor()

and call it a day.

The attack was embedded in a chain involving:

source tarball
   ↓
build process
   ↓
test artifacts
   ↓
object extraction
   ↓
library modification
   ↓
downstream software

That is a trust-chain attack.

And it is extremely close to the conceptual territory Thompson was talking about.

But there is an important distinction.

xz was not Thompson's self-reproducing compiler attack.

The historical mechanism and threat model were different.

The similarity is structural:

something you trust to produce or transform software becomes the place where malicious behavior enters.

That distinction matters.

Good security writing should not turn every supply-chain incident into “Ken Thompson predicted exactly this attack.”

He didn't.

He predicted the deeper trust problem.

7. Now add AI to the chain

Here is where things get really interesting.

A modern AI coding workflow might look like:

human idea
    ↓
AI coding assistant
    ↓
generated source
    ↓
package manager
    ↓
dependencies
    ↓
build system
    ↓
compiler
    ↓
binary
    ↓
production

The AI is now another transformation layer.

That means:

human
  ↓
AI
  ↓
code

The developer is not necessarily reading every line.

The developer is increasingly trusting a system to produce code.

This is not identical to trusting a compiler.

A compiler transforms already-defined source according to deterministic rules.

An LLM generates source probabilistically from context.

That difference is enormous.

But the trust question is eerily similar:

Can the thing producing the software be trusted to produce only what you intended?

8. AI doesn't need to be malicious to create a supply-chain problem

This is a crucial distinction.

Imagine an AI coding assistant invents a package:

import magical-auth-helper

There is no package named magical-auth-helper.

The AI believes there is.

A developer doesn't check.

They run:

npm install magical-auth-helper

Somebody else registered the name.

Now the innocent hallucination created the attack path.

This class of concern has become known as slopsquatting: an attacker registers package names hallucinated by AI systems and hopes developers or coding agents will install them.

Recent research and datasets are beginning to study exactly this problem. One 2025 GitHub research project surveyed AI-invented package names and found many hallucinated names, while its registration census found that the specific names in its sampled corpus had not been claimed at the time of re-check; importantly, the authors present the threat as real in principle rather than claiming every hallucinated package becomes malicious.

That caveat is important.

The scary story is not:

“AI hallucinated packages therefore attackers are already everywhere.”

The defensible story is:

AI adds a new mechanism by which developers may be encouraged to trust dependencies they did not independently identify or verify.

That is enough to matter.

9. AI can manufacture the appearance of authority

This might be more dangerous than hallucinated package names.

A human developer sees:

beautifully formatted code

The code has:

types
comments
tests
error handling
clean naming

It looks authoritative.

The model can explain it.

The model can defend it.

The model can generate documentation for it.

The model can even generate tests for it.

Now you have something that feels like a reviewed engineering artifact.

But its appearance tells you almost nothing about whether its assumptions are correct.

That creates a new security problem:

synthetic credibility

A malicious dependency traditionally has to look legitimate.

AI-generated code can accidentally produce the same psychological effect.

It looks legitimate because a language model can imitate what legitimate software usually looks like.

10. The numbers are uncomfortable

Veracode's 2025 GenAI Code Security Report tested more than 100 LLMs across Java, JavaScript, Python and C# on security-focused coding tasks.

Its published results reported that 45% of generated code samples failed security tests, with particularly weak performance on some classes such as XSS. Veracode's 2026 update reported that its later testing still found security pass rates around 55%, despite improvements in syntax and functional correctness.

These results come from one vendor's methodology, so they should not be treated as a universal measurement of every AI coding system.

But they establish something important:

Better at producing working code does not automatically mean better at producing secure code.

That is exactly where Thompson's argument becomes useful again.

The question is not:

“Can the system generate code?”

Obviously it can.

The question is:

“What do you trust to tell you that the generated code is safe?”

And now we have another recursive problem.

11. What if the AI reviews the AI-generated code?

This sounds like a solution.

You ask one model to write the code.

Then another model checks it.

Great.

Except:

AI generates
      ↓
AI reviews
      ↓
AI approves

Where does trust terminate?

If both models share similar blind spots, a vulnerability can survive both stages.

A 2025 study evaluating GitHub Copilot's code-review functionality against curated vulnerable examples found that the system frequently failed to identify critical issues such as SQL injection, XSS, and insecure deserialization, instead often focusing on lower-severity concerns.

A 2026 empirical study using real-world GPT-generated code from the DevGPT dataset likewise found vulnerabilities in real developer code and investigated whether current LLMs could detect and repair them.

The lesson isn't:

“Never use AI to review AI.”

It is:

AI review is another control, not the final foundation of trust.

That distinction becomes increasingly important as organizations automate more of the software pipeline.

12. Thompson's attack was recursive.

AI pipelines are recursive too.

Think about a modern AI coding agent.

It can:

read repository
      ↓
write code
      ↓
install package
      ↓
run tests
      ↓
inspect error
      ↓
edit code
      ↓
run tests again
      ↓
modify configuration
      ↓
commit changes

The agent is not merely generating a function.

It may be operating the software-development environment.

That means the trust boundary has moved.

The system that writes code may also:

select dependencies
invoke tools
modify files
run commands
create configuration
interpret test failures
make architectural decisions

This makes the old Thompson question more relevant:

What exactly are we trusting?

Not:

“Is the model intelligent?”

But:

“Which actions are we allowing an uncertain component to take without independent verification?”

13. There is another supply chain hiding inside AI

Here is a layer people often overlook.

An AI coding system itself depends on infrastructure.

AI assistant
    ↓
model
    ↓
training data
    ↓
libraries
    ↓
inference runtime
    ↓
GPU software
    ↓
operating system
    ↓
cloud infrastructure

So when a developer says:

“I trust my AI coding assistant.”

that statement is incomplete.

Which version?

Which model?

Which deployment?

Which tools?

Which plugins?

Which context?

Which package-resolution behavior?

Which external integrations?

Which runtime?

Which generated code?

Which dependencies?

The trust surface is much larger than a chat window suggests.

14. The AI equivalent of Thompson's compiler trick

We should be careful here.

An LLM is not a compiler.

And an ordinary AI coding assistant does not secretly rewrite its own binary the way Thompson's hypothetical compiler can.

So what would a structurally similar attack look like?

Imagine a future development agent that has:

repository access
+
package installation
+
terminal access
+
network access
+
write access

Suppose its instructions or context are compromised.

The agent could potentially generate malicious code while presenting it as normal implementation.

Or it could introduce an untrusted dependency.

Or modify a build script.

Or make a seemingly harmless configuration change.

The human then reviews the output.

But if the review process itself relies heavily on the same AI-generated explanation, the system can become self-reinforcing.

The chain becomes:

AI decides
   ↓
AI implements
   ↓
AI explains
   ↓
Human trusts explanation

That is not Thompson's exact attack.

But it has the same philosophical weakness:

The producer is also influencing the mechanism by which its output is judged.

15. The most dangerous sentence in AI-assisted development

It might be:

“The AI checked it.”

Because checked how?

Against what?

With what assumptions?

Using what tools?

And who checked the tools?

A static analyzer is different from an LLM.

A reproducible build is different from an LLM explanation.

A signed artifact is different from “the model says this is safe.”

A dependency lockfile is different from autocomplete.

Security controls become meaningful when they are independent enough from the thing they're supposed to verify.

This is one of the deepest lessons hiding inside Thompson's paper.

16. Reproducible builds are basically a response to this class of problem

Modern software-security engineering has developed mechanisms intended to reduce uncertainty in build pipelines.

Reproducible builds aim for the property that independently rebuilding the same source under controlled conditions produces the same output.

That doesn't magically prove the source is benevolent.

But it can detect some kinds of build-environment manipulation.

The conceptual difference is important:

“Trust me, this binary came from this source.”

versus:

“Here is the source and environment.
Rebuild it yourself.
Compare the result.”

The second reduces the number of things you have to trust.

It doesn't reduce them to zero.

But security is often about reducing trust assumptions.

17. Modern provenance is another attempt to answer Thompson

Software Bills of Materials, signed artifacts, provenance metadata, trusted build systems and isolated CI pipelines all address pieces of the same fundamental problem:

Where did this artifact come from?

and:

What happened to it before I received it?

Those are provenance questions.

A binary is not just:

bytes

It is:

bytes
+
origin
+
build process
+
dependencies
+
identity
+
history

The more complex the chain becomes, the more provenance matters.

And AI makes that chain more complicated again.

18. “Who wrote this code?” is becoming a strangely difficult question

In 2026, a commit may be:

idea: human
prompt: human
implementation: AI
review: human
tests: AI
dependency selection: AI
final approval: human

So who is the author?

That's a social question.

Security needs a different one:

Who is accountable for the correctness of the resulting artifact?

The answer cannot simply be:

“The AI.”

A model has no legal or operational responsibility.

The repository owner does.

The engineering team does.

The release system does.

The organization does.

And therefore verification has to remain human-accountable even if generation is automated.

19. AI generated code can multiply supply-chain mistakes

Suppose one developer traditionally adds:

3 dependencies

during a project.

Now an AI coding agent can rapidly scaffold:

17 dependencies

because it finds convenient libraries for:

authentication
validation
parsing
formatting
logging
HTTP
file handling
database access
image processing
caching
testing

None of those dependencies are necessarily malicious.

But every dependency expands the trust graph.

That creates a simple equation:

more dependencies
      ↓
more external code
      ↓
more trust relationships
      ↓
more possible compromise points

AI can therefore amplify the size of the supply chain, even when every individual generation is benign.

That is a more interesting risk than “AI writes insecure code.”

20. The package name problem is especially weird

A human developer usually installs a dependency for a reason.

They search.

They read the documentation.

They look at GitHub.

They check downloads.

They inspect versions.

An AI might simply output:

npm install xyz-helper

because the name statistically looks like something that should exist.

That changes the economics for attackers.

Instead of creating a convincing package name completely at random, an attacker can monitor which package names coding models tend to hallucinate.

Then:

AI hallucinates package
         ↓
attacker registers name
         ↓
developer follows AI suggestion
         ↓
package executes

Again:

the model does not have to be malicious.

The attacker can exploit the model's mistakes.

That is a fundamentally different threat model.

21. The uncomfortable part: smarter models are not automatically the solution

It is tempting to assume:

better model
=
safer code

Evidence so far does not justify that equation.

Veracode's 2025 analysis reported little improvement in security performance over time despite improving functional capabilities, and its 2026 update continued to report a substantial gap between functional correctness and security.

A 2026 ACL benchmark similarly found that current LLMs still struggle with secure coding in repository-level scenarios, with larger reasoning budgets not necessarily translating into better security outcomes.

That suggests security is not simply an intelligence problem.

It is a system-design problem.

22. This is why “trusting trust” is such a perfect title

Thompson didn't call his lecture:

“How to Write Better Compilers.”

He called it:

Reflections on Trusting Trust

That's the important word.

trust.

Because security failures often happen when something is accepted not because it was independently proven safe, but because it came from somewhere we already trusted.

That pattern appears everywhere.

trusted maintainer
trusted package
trusted vendor
trusted build
trusted compiler
trusted AI
trusted reviewer

Eventually:

trusted thing

becomes a proxy for:

safe thing

Those are not equivalent.

23. The supply chain is basically a graph of borrowed trust

Think of modern software as:

                YOU
                 |
             YOUR APP
                 |
        +--------+--------+
        |        |        |
      npm      PyPI     GitHub
        |        |        |
      deps     deps     actions
        |        |        |
     maint.   maint.   workflow
        |        |        |
      tools    tools    runners
        \        |       /
         \       |      /
             BUILD
               |
             BINARY
               |
           PRODUCTION

Now insert AI:

                  YOU
                   |
                AI AGENT
                   |
          +--------+--------+
          |        |        |
        CODE     DEPS     CONFIG
          |        |        |
        npm      PyPI     CI/CD
          |        |        |
        build    build    runner
           \       |       /
                  BUILD
                    |
                  BINARY

You have added another decision-making system before compilation even begins.

That is a new trust boundary.

24. The right response is not “ban AI”

This is where the discussion usually goes wrong.

A reasonable response to supply-chain risk is not:

“Never use open-source packages.”

That would be absurd.

Likewise:

“Never use AI-generated code.”

would miss the point.

The useful question is:

Which parts of the AI-assisted pipeline should be trusted automatically, and which should be independently verified?

For example:

AI suggestion
      ↓
human review
      ↓
static analysis
      ↓
dependency verification
      ↓
tests
      ↓
reproducible build
      ↓
artifact signing
      ↓
deployment

Each layer reduces dependence on the previous layer.

That's the important part.

25. AI should be treated as an untrusted producer

This sounds harsh.

It is actually liberating.

Your compiler is trusted within a defined threat model.

Your package registry is trusted within a defined threat model.

Your AI model should be treated similarly:

Useful, powerful, and not inherently authoritative.

The AI can propose:

architecture
implementation
dependency
configuration
migration
refactor
security fix

But proposals are not facts.

They are inputs into a verification pipeline.

That distinction becomes increasingly important as models become capable of editing entire repositories rather than merely completing individual lines.

26. The irony is that AI may make the Thompson problem easier to hide

A malicious line of code can look suspicious.

A malicious architectural decision may not.

For example:

“Let's add package X because it simplifies token parsing.”

Perfectly reasonable.

Except package X has:

postinstall script

that executes code.

Or perhaps the AI chooses an outdated dependency.

Or enables:

unsafe mode

because it makes the tests pass.

Nothing looks like a classic backdoor.

The attack surface is now partially semantic.

You are not necessarily searching for:

malware

You are searching for:

a decision that shouldn't have been made.

That is much harder to detect automatically.

27. The most important difference from Thompson's original attack

This deserves its own section because comparisons can become intellectually lazy.

Thompson's 1984 attack depends on a malicious compiler carrying hidden behavior forward when compiling future compilers and target programs.

Modern AI-generated-code risks are generally different:

hallucinated dependencies
insecure implementation
unsafe configuration
supply-chain compromise
malicious packages
prompt/context manipulation
tool misuse

These are not the same exploit.

So the claim should not be:

“Ken Thompson predicted ChatGPT.”

That is clickbait.

The better claim is:

Ken Thompson identified a general class of trust failure: the machinery responsible for producing or validating software can itself become a source of compromise. AI-assisted development adds another powerful, fallible producer to that machinery.

That's the historically defensible connection.

And honestly, it's much more interesting.

28. The future problem may not be “AI writes malware”

It might be quieter.

Imagine an enterprise with:

20,000 developers
+
AI coding agents
+
millions of generated lines
+
thousands of dependencies

Suppose the probability of one AI-generated component introducing a serious security problem is low.

The organization still has an enormous number of attempts.

Scale changes probability.

More generated code means:

more code
+
more dependencies
+
more configuration
+
more integration

And therefore more opportunities for something to go wrong.

That is why AI security cannot be separated from software supply-chain security.

They are increasingly connected systems problems.

29. What Thompson would probably recognize

Not the chat interface.

Not the transformer.

Not the token.

Not the GPU.

He would recognize this:

You trust one layer
because
another layer told you it was safe.

That is the whole game.

And it still works.

30. So what should a serious AI development pipeline look like?

Not:

prompt
↓
AI
↓
deploy

That is a prototype.

A serious pipeline should look more like:

                HUMAN SPEC
                    |
                    v
               AI PROPOSAL
                    |
          +---------+---------+
          |                   |
          v                   v
      CODE REVIEW        DEPENDENCY CHECK
          |                   |
          +---------+---------+
                    |
                    v
              STATIC ANALYSIS
                    |
                    v
                  TESTS
                    |
                    v
            REPRODUCIBLE BUILD
                    |
                    v
          SIGNED / VERIFIED ARTIFACT
                    |
                    v
               DEPLOYMENT
                    |
                    v
               MONITORING

The important thing is not the exact tools.

It is independence between trust layers.

Don't ask the generator to certify itself.

Don't rely on one model to provide the entire verification chain.

Don't treat package names suggested by an AI as trustworthy merely because they look real.

Don't confuse compilation success with security.

And don't confuse a passing test suite with proof of absence of malicious behavior.

31. There is a larger philosophical lesson here

Software has always been a strange form of trust.

You trust:

the source
the compiler
the dependencies
the operating system
the hardware
the distribution channel
the developer

AI adds another:

the model

But the important thing is not that AI is uniquely untrustworthy.

Humans weren't uniquely trustworthy either.

That's why security engineering invented:

signatures
checksums
reproducible builds
code review
auditing
sandboxing
least privilege
dependency verification
provenance

The purpose of security engineering is not:

“Find something trustworthy.”

It is:

“Reduce how much trust any one component is allowed to demand.”

That is a much better philosophy.

32. Forty-two years later, the question has changed slightly

In 1984, Thompson asked us to question whether a compiler could be trusted.

In 2026, we have to ask something broader:

Can I trust the model
that writes the code
that chooses the dependency
that modifies the build
that gets compiled
by the tool
that produces the artifact
that enters production?

That sentence is ridiculous.

It is also increasingly close to the architecture of real AI-assisted development.

And somewhere inside that chain is still the same old problem:

Who watches the thing doing the watching?

33. The uncomfortable conclusion

Ken Thompson's warning did not become obsolete.

We simply kept adding layers.

First:

source → compiler → binary

Then:

source → compiler → libraries → binary

Then:

source → dependencies → CI → compiler → container → cloud

And now:

human
  ↓
AI
  ↓
code
  ↓
dependencies
  ↓
CI
  ↓
compiler
  ↓
container
  ↓
cloud

Every layer promises convenience.

Every layer also creates another trust relationship.

The answer is not paranoia.

It is verification.

Because the central lesson of “Reflections on Trusting Trust” was never:

“Trust nothing.”

It was something more subtle:

Know exactly what you are trusting.

And perhaps that's the hardest part of programming in the AI era.

Not making software.

Not even making secure software.

But knowing which parts of the machine you have quietly decided to believe.

The Thompson Test

Here's a thought experiment for AI-assisted development.

Before shipping code generated by an AI system, ask:

1. What did the AI actually change?

2. Which dependencies did it introduce?

3. Where did those dependencies come from?

4. Which build scripts can execute code?

5. Which generated decisions were independently verified?

6. Could the artifact be reproduced independently?

7. Is the security review independent from the generator?

8. What happens if the AI is confidently wrong?

If the answer to every question eventually becomes:

“Because the AI said so.”

you don't have a secure pipeline.

You have a trust loop.

And trust loops are exactly what Thompson taught us to be suspicious of.

Frequently Asked Questions

What is “Reflections on Trusting Trust”?

It is Ken Thompson's 1984 Turing Award lecture, published in Communications of the ACM. Thompson demonstrated how a malicious compiler could preserve hidden behavior in subsequently compiled compilers and programs even after the malicious source code had been removed.

Is Thompson's attack the same as an AI coding attack?

No. The mechanisms are different. Thompson's demonstration specifically involved malicious compiler behavior reproducing itself through compilation. AI coding risks include insecure generated code, malicious or hallucinated dependencies, unsafe configurations, and new trust boundaries around AI agents. The useful connection is the underlying trust architecture, not an identical exploit.

What is a software supply-chain attack?

It is an attack in which an adversary compromises software or a component trusted by downstream users, allowing malicious behavior to propagate through the legitimate distribution or development chain. SolarWinds and the npm event-stream incident are well-known examples.

What happened with xz Utils?

Malicious code was discovered in xz versions 5.6.0 and 5.6.1 in 2024. OpenSSF described an intentionally obfuscated backdoor affecting specific build conditions, while MITRE's CVE description documents how the build process used disguised material to modify the resulting library.

Can AI-generated code contain security vulnerabilities?

Yes. Multiple studies and security evaluations have found vulnerabilities in AI-generated code. Veracode's 2025 and 2026 evaluations reported substantial failure rates on security-focused tasks, while academic studies have independently examined vulnerabilities in Copilot- and GPT-generated code.

What is slopsquatting?

Slopsquatting refers to the idea of registering package names hallucinated by AI systems and waiting for a developer or coding agent to install them. Research has established the mechanism as a plausible supply-chain threat, although the rate at which hallucinated package names are actually registered and malicious varies across datasets and studies.

Does using AI automatically make software insecure?

No. AI is a tool, and risk depends on how it is integrated into the engineering and security process. DORA's 2025 research characterizes AI as an amplifier of existing organizational strengths and weaknesses rather than an automatic source of either success or failure.

SEO / GEO PACKAGE

SEO Title

What If the Compiler Is Lying to You? Ken Thompson's 1984 Warning in the Age of AI Code

Meta Description

Ken Thompson's “Reflections on Trusting Trust” explained a terrifying software supply-chain problem in 1984. Today, AI-generated code, npm, xz, SolarWinds and coding agents are creating new versions of the same trust problem.

Suggested Slug

ken-thompson-trusting-trust-ai-code-supply-chain

Primary Keywords

Ken Thompson trusting trust, Reflections on Trusting Trust, AI generated code security, AI coding security, software supply chain attacks, compiler backdoor, npm supply chain attack, xz backdoor, SolarWinds supply chain, AI coding agents, slopsquatting

GEO Questions

What is Ken Thompson's trusting trust attack?

What does Reflections on Trusting Trust mean?

Can a compiler contain a backdoor?

How does AI-generated code create security risks?

What is the connection between AI coding and software supply chain attacks?

What is slopsquatting?

Why can't source code alone prove software is trustworthy?

Sources

Ken Thompson — “Reflections on Trusting Trust”
Communications of the ACM, Vol. 27, No. 8, August 1984, pp. 761–763. DOI: 10.1145/358198.358210.
ACM Classic / HPI archival reproduction — “Reflections on Trusting Trust”
Accessible reproduction and contextual material for Thompson's 1984 lecture.
CISA — Active Exploitation of SolarWinds Software
Official U.S. government alert describing the SolarWinds Orion supply-chain compromise.
CISA — Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure and Private Sector Organizations
Official detailed alert on the SolarWinds-related campaign.
npm — Details about the event-stream incident
Official npm incident report describing the malicious dependency and its downstream impact.
Open Source Security Foundation — xz Backdoor CVE-2024-3094
Analysis of the malicious xz/liblzma code and affected versions.
MITRE — CVE-2024-3094
Technical vulnerability description of the malicious build process and modified liblzma behavior.
Veracode — 2025 GenAI Code Security Report
Evaluation of security weaknesses across more than 100 LLMs and multiple programming languages.
Veracode — Spring 2026 GenAI Code Security Update
Follow-up evaluation reporting continued disparity between functional correctness and security performance.
Lian et al. — A.S.E.: A Repository-Level Benchmark for Evaluating Security in AI-Generated Code
Findings from ACL 2026 on secure code generation in repository-level scenarios.
“Security Weaknesses of Copilot-Generated Code in GitHub Projects”
Empirical research on security weaknesses associated with Copilot-generated code.
“GitHub's Copilot Code Review: Can AI Spot Security Flaws Before You Commit?”
2025 evaluation of AI-assisted security review effectiveness.
“Secure coding with AI – from detection to repair”
2026 study of vulnerabilities in real-world GPT-generated code and LLM-based detection and remediation.
Slopsquatting census research / dataset
Research into hallucinated package names and their potential use in software supply-chain attacks.

9 Steps to Build an IPTV Player With React and HLS.js: A Complete Developer Guide

Mon, 07 Sep 2026 16:52:25 +0000

Building an IPTV player for the web is an interesting frontend engineering project because it sits at the intersection of React development, HTML5 video, HTTP streaming, playlist management, browser APIs, and user experience.

At first glance, an IPTV player may appear to be nothing more than a <video> element with a stream URL. In reality, a reliable player needs to handle several layers of complexity: HLS manifests, M3U or M3U8 playlists, adaptive bitrate streams, browser compatibility, buffering, playback errors, channel switching, and lifecycle management.

In this guide, we will build the foundation of a React-based IPTV player using HLS.js. The goal is not to create a commercial IPTV application or connect to unauthorized streams. Instead, we will focus on the engineering concepts behind a modern web video player and use legally accessible HLS test streams as examples.

HLS.js is an open-source JavaScript library designed to play HTTP Live Streaming content in browsers that support Media Source Extensions. The library provides APIs for attaching an HLS instance to an HTML video element, loading a manifest, handling events, and recovering from certain media errors.

Why Build an IPTV Player With React and HLS.js?

React is a natural choice for a modern IPTV web player because the interface usually contains much more than a video element.

A typical IPTV-style application may include a channel list, categories, search, favorites, an electronic program guide, playback controls, quality selection, subtitles, loading indicators, error messages, and responsive layouts.

React makes these interface components easier to organize into reusable pieces.

A possible architecture might look like this:

React Application
│
├── ChannelList
│   ├── Categories
│   ├── Search
│   └── Favorites
│
├── VideoPlayer
│   ├── HTML5 Video
│   └── HLS.js
│
├── PlayerControls
│
├── ProgramGuide
│
└── ErrorHandler

The important distinction is that React manages the application interface, while HLS.js manages HLS playback.

That separation is useful because it prevents the player component from becoming responsible for the entire application.

What Is HLS Streaming?

HTTP Live Streaming, commonly called HLS, is a streaming protocol that delivers media over standard HTTP infrastructure.

Instead of downloading one large video file, an HLS presentation is typically divided into media segments. A playlist, commonly identified by an .m3u8 URL, tells the player where those segments can be found.

An HLS stream can also provide multiple quality levels. The player can then select an appropriate representation based on network conditions and other playback factors.

This is one of the reasons HLS is widely used for live and on-demand video applications.

For developers, the important pieces are:

HLS manifest
Media segments
Video element
Media Source Extensions
JavaScript player logic
Network connection
Optional adaptive bitrate representations

HLS.js sits between the web application and the browser's media pipeline.

HLS.js vs Native HLS Playback

One of the first things developers need to understand is that browsers do not all handle HLS in exactly the same way.

HLS.js uses Media Source Extensions when the browser supports the required APIs. Some browsers and platforms also provide native HLS support directly through the HTML5 video element.

The official HLS.js documentation specifically recommends feature detection rather than assuming that every browser requires HLS.js. Safari, for example, has built-in HLS support through the standard video element.

That means a robust React IPTV player should consider both approaches:

Does the browser support HLS.js?
        │
        ├── Yes → Use HLS.js + MediaSource
        │
        └── No → Check native HLS support
                     │
                     ├── Yes → Use video.src
                     │
                     └── No → Display compatibility message

This small piece of browser detection can make the difference between a player that works on one machine and a player that works reliably across multiple environments.

Step 1: Create the React Project

You can start with a standard React project.

For example, using a modern Vite-based setup:

npm create vite@latest react-iptv-player
cd react-iptv-player
npm install

Then install HLS.js:

npm install hls.js

HLS.js is distributed as an npm package and also provides browser-ready builds. The official project documentation provides installation instructions and API documentation for current releases.

The project structure could initially be:

src/
├── App.jsx
├── components/
│   └── HlsPlayer.jsx
├── data/
│   └── channels.js
└── styles/
    └── player.css

Keeping the HLS logic inside its own component will make the application easier to maintain.

Step 2: Create a Reusable React HLS Player

The core player can be surprisingly small.

Here is a basic implementation:

import { useEffect, useRef } from "react";
import Hls from "hls.js";

export default function HlsPlayer({ src }) {
  const videoRef = useRef(null);

  useEffect(() => {
    const video = videoRef.current;

    if (!video || !src) {
      return;
    }

    let hls;

    if (Hls.isSupported()) {
      hls = new Hls();

      hls.loadSource(src);
      hls.attachMedia(video);
    } else if (video.canPlayType("application/vnd.apple.mpegurl")) {
      video.src = src;
    }

    return () => {
      if (hls) {
        hls.destroy();
      }
    };
  }, [src]);

  return (
    <video
      ref={videoRef}
      controls
      playsInline
      style={{ width: "100%" }}
    />
  );
}

There are several important ideas here.

First, useRef() gives React access to the underlying HTML video element.

Second, Hls.isSupported() checks whether HLS.js can use the browser's Media Source Extensions environment.

Third, loadSource() tells HLS.js which HLS manifest to load.

Fourth, attachMedia() connects the HLS.js instance to the video element.

Finally, destroy() is called when the component is removed or when the stream source changes.

The HLS.js API documentation describes this general lifecycle: check support, instantiate the HLS object, attach it to the media element, load the manifest, and clean up the instance when it is no longer needed.

Step 3: Understand the M3U8 Playlist

An IPTV player often receives a playlist containing multiple channels.

It is important to distinguish between an M3U channel playlist and an HLS M3U8 media playlist.

An M3U file may contain entries such as:

#EXTM3U

#EXTINF:-1,Example News
https://example.com/live/news/index.m3u8

#EXTINF:-1,Example Sports
https://example.com/live/sports/index.m3u8

The metadata describes the channel, while the URL points to a media resource.

The player application can convert that information into JavaScript objects:

const channels = [
  {
    id: 1,
    name: "Example News",
    streamUrl: "https://example.com/live/news/index.m3u8"
  },
  {
    id: 2,
    name: "Example Sports",
    streamUrl: "https://example.com/live/sports/index.m3u8"
  }
];

The important engineering principle is to keep playlist parsing separate from playback.

Do not make the video component responsible for understanding the entire playlist format.

Instead:

M3U Parser
     ↓
Channel Objects
     ↓
React State
     ↓
Selected Channel
     ↓
HLS Player

This architecture becomes particularly useful when you later add search, favorites, categories, or an electronic program guide.

Step 4: Build the IPTV Channel List in React

Once the channel data is available, React can render a channel list.

A simple component might look like this:

export default function ChannelList({ channels, onSelect }) {
  return (
    <div>
      {channels.map((channel) => (
        <button
          key={channel.id}
          onClick={() => onSelect(channel)}
        >
          {channel.name}
        </button>
      ))}
    </div>
  );
}

The parent component can store the currently selected channel:

import { useState } from "react";
import HlsPlayer from "./components/HlsPlayer";
import ChannelList from "./components/ChannelList";

export default function App() {
  const [selectedChannel, setSelectedChannel] = useState(null);

  return (
    <main>
      {selectedChannel && (
        <HlsPlayer src={selectedChannel.streamUrl} />
      )}

      <ChannelList
        channels={channels}
        onSelect={setSelectedChannel}
      />
    </main>
  );
}

This is where React becomes especially useful.

The player itself does not need to know how the channel list works. It receives a URL and focuses on playback.

That separation keeps the component reusable.

Step 5: Handle IPTV Stream Errors Properly

A production-quality IPTV web player needs much better error handling than a basic example.

Streaming errors can happen for many reasons:

The manifest is unavailable
A segment cannot be downloaded
The server returns an HTTP error
The stream has ended
The media format is unsupported
The browser encounters a media decoding problem
The network connection disappears
CORS prevents browser access
The source URL expires

HLS.js exposes events and error information that can be used to identify these problems.

A basic listener could look like:

hls.on(Hls.Events.ERROR, (event, data) => {
  console.error("HLS error:", data);
});

For production applications, it is useful to distinguish between fatal and recoverable errors.

For example:

hls.on(Hls.Events.ERROR, (event, data) => {
  if (!data.fatal) {
    return;
  }

  switch (data.type) {
    case Hls.ErrorTypes.NETWORK_ERROR:
      hls.startLoad();
      break;

    case Hls.ErrorTypes.MEDIA_ERROR:
      hls.recoverMediaError();
      break;

    default:
      hls.destroy();
      break;
  }
});

The exact recovery strategy should depend on the application. Automatically retrying everything can actually make an outage worse.

The HLS.js API includes methods such as startLoad() and recoverMediaError() for specific recovery scenarios.

A useful production player should also show the user a meaningful message rather than exposing raw JavaScript errors.

For example:

Unable to play this channel.

Please try another channel or check the stream source.

That is much better than simply showing a blank video element.

Step 6: Improve Channel Switching Performance

One of the most important features in an IPTV-style player is fast channel switching.

Users generally expect a new channel to start playing quickly after clicking it.

A poor implementation may destroy and recreate the entire application unnecessarily.

A better approach is to keep the React interface stable and only update the stream source.

For example:

const selectChannel = (channel) => {
  setSelectedChannel(channel);
};

The player receives a new src and updates its HLS instance.

However, channel switching also depends heavily on the stream architecture itself.

Even a perfectly optimized React component cannot eliminate latency caused by:

Large media segments
Slow origin servers
Poor CDN performance
High network latency
Excessive player buffering
Slow manifest retrieval
Encoding delays

Frontend optimization is only one part of the streaming pipeline.

Step 7: Add Adaptive Bitrate Streaming

Modern HLS streams can contain multiple quality levels.

For example:

1080p → 5 Mbps
720p  → 3 Mbps
480p  → 1.5 Mbps
360p  → 800 Kbps

The player can switch between representations depending on available bandwidth and playback conditions.

This is known as adaptive bitrate streaming.

It is one of the most important technologies for maintaining playback quality across different network conditions.

A viewer on a fast fiber connection may receive a higher-quality representation, while a user on a congested mobile network may temporarily receive a lower-quality stream.

The goal is not simply to maximize resolution.

The real goal is to provide a stable playback experience.

That means a 720p stream that plays continuously can provide a better experience than 1080p playback that repeatedly buffers.

HLS.js includes configuration and APIs related to quality selection and adaptive streaming, allowing developers to tune playback behavior for their applications.

Step 8: Add Loading States and Playback UX

Technical correctness is not enough for a good IPTV web player.

The interface should clearly communicate what is happening.

For example, when the user selects a channel:

Channel selected
      ↓
Loading stream
      ↓
Manifest loaded
      ↓
Buffering
      ↓
Playback started

React state can represent these stages:

const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

You can then display:

{loading && <p>Loading stream...</p>}
{error && <p>{error}</p>}

This seems simple, but it makes the application feel considerably more reliable.

You should also consider:

Responsive video dimensions
Mobile layouts
Keyboard controls
Fullscreen playback
Captions and subtitles
Audio tracks
Poster images
Accessible buttons
Clear error messages
Dark-mode interfaces
Channel search
Favorites

React's component model is particularly useful for separating these concerns into small reusable components.

Step 9: Add CORS and Security Considerations

One of the most common problems developers encounter when building an HLS player is CORS.

A browser may successfully access a URL from the address bar while preventing JavaScript from fetching the same resource because of cross-origin restrictions.

This is not an HLS.js bug.

It is a browser security mechanism.

If your application is hosted on:

https://player.example.com

and the stream is served from:

https://stream.example.net

the stream server must be configured correctly for cross-origin browser access.

For a legitimate streaming service that you control, this generally means configuring the server or CDN with the appropriate Access-Control-Allow-Origin policy.

Do not try to bypass browser security restrictions from frontend code.

If you control the streaming infrastructure, configure CORS at the correct layer.

React IPTV Player Architecture for Production

Once the basic player works, the application can evolve into a much more structured system.

A production architecture might look like this:

                    ┌──────────────────┐
                    │  React Frontend  │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
        Channel API      EPG API       User API
              │              │              │
              └──────────────┼──────────────┘
                             │
                     Channel Selection
                             │
                     React Player
                             │
                         HLS.js
                             │
                    HLS Master Playlist
                             │
                          CDN
                             │
                     Origin Streaming

This architecture makes the application easier to scale.

The frontend should not contain sensitive infrastructure credentials or private server configuration.

Instead, the backend can provide the information the frontend needs.

For example:

{
  "id": "channel-001",
  "name": "Example Channel",
  "logo": "https://example.com/logo.png",
  "stream": "https://example.com/live/channel.m3u8"
}

The React application consumes the API and renders the interface.

How to Optimize an IPTV Player for Better Performance

Once playback works, performance becomes the next major challenge.

One useful rule is to measure before changing configuration.

Developers sometimes increase buffer sizes, disable features, or force quality levels without knowing what problem they are trying to solve.

That can make the player worse.

Instead, monitor:

Time to first frame
Manifest loading time
Segment download time
Rebuffering events
Playback interruptions
Selected quality
Download bandwidth
Buffer duration
Channel switching time

These metrics provide much more useful information than simply asking whether a stream "feels slow."

Reduce unnecessary React re-renders

The video player should not be recreated every time an unrelated UI component changes.

Keep the HLS instance inside a dedicated component and avoid creating unnecessary objects on every render.

For example, configuration objects can be memoized when necessary.

Clean up HLS instances

If a user changes channels repeatedly, old HLS instances must be destroyed.

Otherwise, the browser can accumulate unnecessary event listeners and network activity.

The cleanup pattern is essential:

return () => {
  hls?.destroy();
};

Avoid forcing a fixed quality

For most users, adaptive bitrate is preferable to forcing the highest available resolution.

The best quality is not necessarily the best experience.

A player should adapt to real network conditions.

Common Mistakes When Building a React IPTV Player

Mistake 1: Treating HLS as a normal MP4 file

An .m3u8 URL is not equivalent to an .mp4 URL.

The HLS manifest describes a streaming presentation and may reference many media segments.

Mistake 2: Ignoring browser compatibility

Not every browser uses the same HLS playback mechanism.

Feature detection should be part of the player architecture.

Mistake 3: Putting everything inside App.jsx

A large component containing playlist parsing, API calls, playback logic, error handling, channel search, and UI rendering quickly becomes difficult to maintain.

Separate responsibilities.

Mistake 4: Ignoring CORS

If the stream server is not configured for browser access, no amount of React code will fix the problem.

Mistake 5: Retrying every error

Automatic retries are useful for transient network failures, but endless retries can create unnecessary traffic and hide real infrastructure problems.

Mistake 6: Testing only one stream

A player should be tested with different:

Bitrates
Resolutions
Segment durations
Network speeds
Browsers
Devices
Live and VOD streams

Mistake 7: Forgetting cleanup

HLS instances, timers, event listeners, and subscriptions should be cleaned up when components unmount.

IPTV Player vs Generic HLS Player

From a technical perspective, there is not necessarily a separate "IPTV protocol" that a React player must implement.

An IPTV application can simply be a user interface around standard streaming technologies.

For example:

IPTV Application
      │
      ├── Channel metadata
      ├── Playlist management
      ├── EPG
      ├── Search
      ├── Favorites
      │
      └── Video Playback
             │
             └── HLS.js
                    │
                    └── HLS

This is an important distinction for developers.

The IPTV part is often the application layer, while HLS is the media delivery technology.

Once you understand this architecture, the same knowledge can be applied to many other streaming applications.

Testing Your React HLS Player

A good development workflow should include multiple testing scenarios.

Start with a known-good HLS test stream rather than immediately testing a large playlist.

Then test:

Valid HLS stream
      ↓
Invalid URL
      ↓
Slow network
      ↓
Temporary network interruption
      ↓
Channel switching
      ↓
Unsupported browser
      ↓
Mobile browser

Browser developer tools are extremely useful during this process.

The Network tab can reveal:

Manifest requests
Segment requests
HTTP status codes
Request duration
Failed resources
CORS errors

The Console can reveal application and HLS.js errors.

Together, these tools provide a much clearer picture of what is happening inside the player.

How to Extend the IPTV React Player

Once the core player is stable, you can add more advanced functionality.

Electronic Program Guide

An EPG can provide program metadata such as:

20:00 — Movie
21:45 — News
22:30 — Documentary

The React application can display this information next to the channel list.

Favorites

Users can save frequently watched channels locally:

localStorage.setItem(
  "favoriteChannels",
  JSON.stringify(favorites)
);

For authenticated applications, favorites can instead be stored on the backend.

Search

A channel search field can filter the React state without affecting video playback.

Multiple Audio Tracks

Where the HLS stream provides multiple audio tracks, the player can expose a language selector.

Subtitles

Subtitles can be integrated using browser-supported text tracks when the media workflow provides them.

These features turn a simple HLS player into a complete streaming interface.

A Practical React IPTV Player Roadmap

If you are building this project from scratch, do not attempt to implement everything at once.

A practical development roadmap is:

Phase 1 — Basic playback

Build:

React application
HTML5 video element
HLS.js integration
HLS manifest loading
Basic controls

Phase 2 — Channel management

Add:

Channel objects
M3U parsing
Search
Categories
Channel switching

Phase 3 — Reliability

Add:

Error handling
Loading states
Retry logic
Browser compatibility
CORS configuration
Cleanup

Phase 4 — User experience

Add:

Responsive layout
Favorites
Fullscreen
Keyboard controls
EPG
Subtitles

Phase 5 — Performance

Measure:

Startup time
Channel switching time
Rebuffering
Buffer duration
Bandwidth
Quality changes

This incremental approach is much easier to debug than building a massive IPTV application in one step.

Where HLS.js Fits in the Modern Streaming Stack

It is useful to think about HLS.js as one layer in a larger system.

Content
   ↓
Encoder
   ↓
Packager
   ↓
HLS Manifest + Segments
   ↓
Origin / CDN
   ↓
Internet
   ↓
Browser
   ↓
HLS.js
   ↓
HTML5 Video
   ↓
React UI

React is responsible primarily for the application experience.

HLS.js handles the HLS playback layer.

The CDN and origin infrastructure handle media delivery.

The encoder and packaging system generate the actual streaming assets.

Understanding these boundaries helps developers troubleshoot problems much faster.

If playback fails, you can ask:

Is this a React problem?

Maybe not.

Is HLS.js receiving the manifest?

Check the network requests.

Are the media segments available?

Inspect the segment requests.

Is the browser capable of decoding the media?

Check the media errors.

Is the CDN returning the correct headers?

Inspect HTTP responses and CORS headers.

This systematic approach is much more effective than randomly changing player settings.

Final Thoughts

Building an IPTV player with React and HLS.js is a useful project for learning modern web video development because it combines several important concepts in one application.

You learn how React manages state and components, how browsers handle HTML5 video, how HLS manifests and segments work, how Media Source Extensions fit into browser playback, and how adaptive streaming responds to changing network conditions.

The first version of the player can be very small. A React component, a video element, an HLS manifest, and a few lines of HLS.js code are enough to get a basic stream playing.

The difficult part comes afterward.

A production-quality player needs proper lifecycle management, error recovery, browser compatibility, CORS configuration, responsive UI, channel management, performance monitoring, and thoughtful handling of network conditions.

That is also where the project becomes genuinely interesting from a software engineering perspective.

If you are building streaming-related applications, experimenting with legitimate HLS test streams and your own media infrastructure is a good way to understand the complete pipeline before adding more advanced features.

For developers interested in the wider IPTV and streaming ecosystem, resources and real-world service examples can also be explored through IPTV FOX PRO, VAST IPTV, and FOX IPTV Premium. These links should remain supplementary rather than becoming the focus of the technical article.

The most important takeaway is simple: a good IPTV web player is not just a video element. It is a combination of frontend architecture, streaming protocols, network delivery, browser capabilities, and careful performance engineering.

Once you understand how those pieces interact, you can use the same principles to build many other types of modern live-video applications.

The Web Works Until It Doesn't: What Developers Should Really Be Building

Mon, 07 Sep 2026 13:26:22 +0000

The Web Works Until It Doesn't: What Developers Should Really Be Building

There is something strange about modern web development.

We can build more than ever.

A single developer can create a dashboard, connect an API, add authentication, deploy a database, integrate payments, generate content, monitor traffic, and put the whole application online without needing a large engineering department.

Frameworks are faster. Cloud platforms are easier. AI assistants can generate code in seconds. Libraries exist for almost everything.

And yet, many applications are still fragile.

A small change breaks something that worked yesterday.

A dependency update creates an unexpected error.

A database query becomes slow after the number of users increases.

A form works perfectly on a developer's laptop but behaves differently in production.

An API returns an unexpected response.

A customer reports a bug that nobody can reproduce.

A deployment succeeds, but the application becomes slower.

The problem is not that developers cannot write code.

The problem is that modern software is increasingly easy to build and increasingly difficult to understand as a whole.

That difference matters.

As web developers, we often measure progress by how quickly we can create something.

But perhaps we should also measure progress by how confidently we can change it.

Because a good application is not simply an application that works today.

A good application is one that can survive tomorrow's changes.

The Real Challenge Is No Longer Just Writing Code

For a long time, becoming a developer meant learning programming languages, algorithms, databases, frameworks, and development tools.

Those things still matter.

But the job has changed.

Today, a developer can ask an AI coding assistant to generate a React component, create an API endpoint, write a SQL query, produce a Docker configuration, or explain an error message.

This creates an interesting situation.

The ability to produce code is becoming less expensive.

The ability to make good decisions about code is becoming more valuable.

Imagine two developers.

Developer A can produce 5,000 lines of code in a day.

Developer B produces 1,000 lines.

At first glance, Developer A appears more productive.

But what happens six months later?

If Developer A's code is difficult to understand, poorly structured, tightly coupled, badly documented, and full of hidden assumptions, the team may spend hundreds of hours maintaining it.

Developer B may have created a smaller system with clear boundaries, simple architecture, meaningful tests, understandable naming, and fewer unnecessary dependencies.

The second developer may have created the more valuable software.

This leads to an important question:

Should developers optimize for how much code they can create, or how much complexity they can prevent?

I believe the second one matters more.

Complexity Is the Silent Cost of Web Development

Most applications don't become difficult because of one enormous feature.

They become difficult because of dozens or hundreds of small decisions.

You add authentication.

Then social login.

Then password reset.

Then two-factor authentication.

Then role-based permissions.

Then an admin dashboard.

Then notifications.

Then email templates.

Then background jobs.

Then caching.

Then analytics.

Then an external payment provider.

Then another API.

Then a reporting system.

Each feature sounds reasonable.

None of them is necessarily wrong.

But eventually, everything starts depending on everything else.

A simple change can become surprisingly expensive.

A developer wants to modify the user profile.

The profile depends on authentication.

Authentication depends on roles.

Roles affect API responses.

API responses are consumed by the frontend.

The frontend caches some data.

The cache is invalidated by another service.

The service sends an event.

Another service listens to the event.

A background worker processes it.

The worker updates the database.

And suddenly, changing one field is no longer a one-file change.

This is how software complexity grows.

Not because developers are careless.

Often, it grows because every individual decision seemed reasonable at the time.

Feature Creep Is Not the Only Problem

When developers talk about technical debt, they often imagine bad code.

But technical debt can also come from good code solving too many problems.

A system can be beautifully engineered and still become unnecessarily complicated.

Consider a small business website.

It might need:

A homepage
About page
Contact form
Product pages
Basic search
Simple authentication for administrators
A database
Analytics

That is a reasonable project.

But imagine deciding that it also needs:

Microservices
Kubernetes
Event-driven architecture
Three separate databases
Multiple caching layers
Five frontend libraries
A message broker
Several third-party services
A complex CI/CD pipeline
A custom design system
Multiple backend services

None of these technologies is inherently bad.

The problem is using complexity before complexity is necessary.

Architecture should solve problems, not create opportunities to use technologies.

This is one of the most important lessons a developer can learn.

Simple Does Not Mean Basic

There is a common misunderstanding in software development.

People sometimes think simple architecture means beginner architecture.

It doesn't.

A simple system can be extremely sophisticated.

The difficult part is knowing what not to build.

A developer who understands distributed systems may deliberately choose a simple monolith because it is the right solution.

A developer who understands caching may decide not to add a cache because the database is already fast enough.

A developer who understands microservices may decide that a modular monolith is more appropriate.

A developer who understands Kubernetes may decide that a managed hosting platform is enough.

That is not lack of knowledge.

That is engineering judgment.

The goal isn't to use fewer technologies because technologies are bad.

The goal is to use only the complexity that creates real value.

The First Question Should Not Be "Which Framework?"

When starting a new web project, developers often ask:

"Should I use React?"

"Should I use Next.js?"

"Should I use Node?"

"Should I use Laravel?"

"Should I use Django?"

"Should I use PostgreSQL?"

"Should I use MongoDB?"

Those are useful questions.

But they are not the first questions.

The first questions should be:

Who is going to use this application?

What problem are we solving?

What does the user actually need?

What happens if the application becomes successful?

What happens if nobody uses it?

What is the smallest version that can prove the idea?

Technology should come after understanding the problem.

Otherwise, developers can spend weeks building an impressive solution to a problem nobody actually has.

Build for the User, Not for the Architecture Diagram

One of the easiest traps for developers is becoming too focused on the internal system.

We discuss:

Components
Services
APIs
Databases
Queues
Containers
Deployment
Observability
Infrastructure

These things matter.

But users don't care about them.

A customer doesn't open an e-commerce website and think:

"Excellent, their event-driven architecture appears well designed."

They think:

"Can I find what I want?"

"Can I understand the price?"

"Can I complete checkout?"

"Why is this page loading so slowly?"

"Why did my payment fail?"

"Where is my order?"

The best engineering work eventually becomes invisible.

The user experiences the result, not the implementation.

That means developers need to develop a second skill beyond programming:

the ability to think like the person using the software.

Performance Is a User Experience Problem

Developers sometimes treat performance as an optimization task that can happen later.

But performance is part of the product.

If a page takes too long to load, users may leave.

If a search takes several seconds, users may assume the application is broken.

If a checkout process freezes, users may not try again.

If a mobile interface feels slow, users may choose another service.

A technically correct application can still be a poor application.

This is why performance should not simply mean:

"How many milliseconds did we save?"

The better question is:

"Did we make the user's experience meaningfully better?"

Sometimes the answer is reducing JavaScript.

Sometimes it is optimizing images.

Sometimes it is improving database indexes.

Sometimes it is removing unnecessary API requests.

Sometimes it is changing the UI so users don't need to wait for something that isn't necessary.

Performance is not only about making computers work faster.

It is about making people wait less.

Mobile Users Expose Bad Engineering Quickly

A developer working on a powerful desktop machine with a fast internet connection can easily forget that users may have very different environments.

Someone might be using:

An older Android phone
A limited mobile connection
A crowded public Wi-Fi network
A small screen
A battery that is almost empty
An outdated browser
An unstable connection

If an application only works beautifully under ideal conditions, it is not necessarily a robust application.

Web development requires empathy.

You have to ask:

What happens when conditions are not perfect?

What happens when the API is slow?

What happens when the request fails?

What happens when JavaScript doesn't load?

What happens when an image cannot be downloaded?

What happens when the user presses the button twice?

What happens when the user loses their internet connection?

These are not unusual situations.

They are normal situations.

Error Handling Is Part of the Product

One of the clearest differences between amateur and mature applications is how they handle failure.

Bad applications say:

"Something went wrong."

Better applications explain:

"We couldn't save your changes. Please try again."

Even better applications explain what happened and what the user can do next.

For developers, errors should also contain useful technical information.

A production error should help answer questions such as:

Which operation failed?
Which user or request was involved?
Which service generated the error?
What was the request ID?
Did the database respond?
Did an external API fail?
Was the problem temporary?
Can the operation safely be retried?

Error handling is not something we add because the application might fail.

We add it because applications will fail.

The goal of engineering is not to create a world where nothing goes wrong.

The goal is to create systems that behave predictably when something does go wrong.

The Most Dangerous Bugs Are Sometimes the Quiet Ones

A crashing application is obvious.

A broken calculation that produces a believable result can be much worse.

Imagine an application calculating:

Payments
Taxes
Inventory
User permissions
Subscription renewals
Financial reports
Delivery costs

If the system crashes, someone notices.

But if it quietly produces the wrong result, the problem may continue for weeks.

This is why testing should not focus only on whether a page loads.

We need to test whether the application behaves correctly.

There is a huge difference between:

"The button exists."

and:

"When the user presses the button under realistic conditions, the correct state is created, the database is updated correctly, duplicate requests are handled safely, and the user receives the expected response."

That is what reliable software means.

Tests Are Not Just for Developers

There is sometimes resistance to writing tests because developers see them as extra work.

But a test suite is really a form of communication.

It tells future developers:

"This behavior is important."

"Don't accidentally break this."

"These are the assumptions this component depends on."

Good tests reduce fear.

Without tests, developers often hesitate to change old code.

They think:

"I don't know what depends on this."

"Maybe changing this will break something."

"Let's not touch it."

That is how old systems become increasingly difficult to maintain.

Tests give developers confidence to improve software.

And confidence is one of the most valuable outcomes of engineering.

AI Makes This Even More Important

Artificial intelligence is changing the development process quickly.

A developer can describe a feature and receive a substantial amount of code.

That is powerful.

But there is a hidden risk.

If developers begin accepting generated code without understanding it, the amount of code in a project can increase much faster than the team's understanding of the project.

That is dangerous.

Imagine a developer asks an AI tool:

"Add authentication."

The tool generates:

Routes
Middleware
Database models
Session handling
Password logic
API endpoints
Frontend components
Error handling

The code may look convincing.

But who understands the security assumptions?

Who knows which parts are safe to modify?

Who knows what happens when a token expires?

Who understands how permissions are enforced?

Who knows whether sensitive information is being logged?

AI can accelerate implementation.

It cannot remove the responsibility of understanding what is being implemented.

The faster code becomes, the more important engineering judgment becomes.

AI Should Increase Our Questions, Not Reduce Them

When AI generates code, developers should become more curious, not less.

Instead of asking:

"Does this work?"

Ask:

"Why does this work?"

Then ask:

"What assumptions does this code make?"

"What could make it fail?"

"How would this behave with 100 users?"

"What happens with 1 million users?"

"What happens if the external service is unavailable?"

"What happens if two requests arrive simultaneously?"

"What data could this expose?"

"Can this code be maintained six months from now?"

These questions turn AI from a code generator into a development accelerator.

The developer remains responsible for the system.

Documentation Is an Engineering Tool

Documentation is often treated as something developers write when they have spare time.

That is a mistake.

Good documentation reduces the amount of knowledge that exists only inside someone's head.

Imagine a developer leaves a project.

If nobody understands:

Why a service exists
Why a strange database field is required
Why a certain API cannot be called twice
Why a particular workaround exists
How deployment works
How environment variables are configured

the team has lost more than a person.

It has lost context.

And context is expensive to recreate.

Good documentation doesn't need to be enormous.

Sometimes a short explanation is enough:

"We use this queue because the external provider occasionally takes several seconds to respond."

That single sentence can prevent another developer from "optimizing" the system and accidentally creating a problem.

Documentation preserves decisions.

Comments Should Explain Why, Not What

Developers often write comments like:

// Get user
// Loop through users
// Check status

These comments rarely help.

The code already explains what it is doing.

More valuable comments explain why.

For example:

// We intentionally process these records sequentially because the
// external API applies a strict rate limit.

Now the comment protects future developers from accidentally introducing concurrency.

A good comment prevents misunderstanding.

A bad comment simply repeats the code.

Your Database Is Not Just Storage

Many web applications are built with the assumption that the database is simply somewhere to put information.

It is much more important than that.

The database represents the application's state.

If the database design is poor, everything above it becomes more complicated.

A good database design helps enforce:

Relationships
Uniqueness
Data integrity
Constraints
Consistency
Efficient querying

Developers sometimes try to solve every data problem in application code.

But some rules belong in the database.

For example, if two users should never have the same unique identifier, relying only on application-level checks can create race conditions.

The database can enforce the rule.

This is another important principle:

Put responsibility at the layer best equipped to enforce it.

Security Cannot Be an Afterthought

Security is one of those topics developers sometimes postpone.

"We'll add it later."

But security is not a feature that can always be attached afterward.

Consider:

Authentication
Authorization
Input validation
Session management
Password storage
Access control
API security
Secrets management
Dependency vulnerabilities
Data exposure

Security should be considered while designing the system.

A beautiful application with weak authorization is still a bad application.

And security is not only the responsibility of a security specialist.

Every developer who writes code that handles user data participates in the security of that system.

The Principle of Least Privilege

One simple security principle is especially useful:

Give users and services only the permissions they actually need.

If a frontend only needs to read a particular piece of information, it should not have unrestricted access to everything.

If a service only needs to read from one database table, it may not need write access to the entire database.

If an administrator needs a certain capability, that doesn't automatically mean every administrator needs every capability.

Smaller permissions mean smaller consequences when something goes wrong.

Security is often about reducing the damage that a failure can cause.

Observability Changes How You Debug

There was a time when developers could open logs and search for an error.

Modern distributed systems can make that difficult.

A request might travel through:

Browser → CDN → API → Service → Queue → Worker → Database → External API

When something fails, where do you look?

This is where observability becomes valuable.

Developers need enough information to understand what the system is doing.

That can include:

Structured logs
Metrics
Traces
Request identifiers
Error tracking
Performance measurements

The goal is not to collect data simply because we can.

The goal is to answer questions.

What happened?

Where did it happen?

Why did it happen?

How often is it happening?

Who is affected?

The best monitoring system turns a mystery into an investigation.

Production Is Where the Real Application Begins

A common mindset among developers is:

"The application is finished."

But software is rarely finished.

Once real users arrive, new information appears.

Users behave differently than expected.

They find workflows developers never imagined.

Traffic patterns change.

Unexpected data appears.

External services behave differently.

Browsers expose new compatibility issues.

Performance problems appear at scale.

That means deployment isn't the end of development.

It is the beginning of learning from reality.

The best developers don't treat production as something to fear.

They treat it as a source of feedback.

Build for Change

One of the most valuable properties of a web application is not speed.

It is adaptability.

Requirements change.

Businesses change.

Customers change.

Regulations change.

Technology changes.

Team members change.

If every small change requires touching ten unrelated parts of the system, development becomes expensive.

Good architecture creates boundaries.

A developer should be able to modify one area without understanding the entire application.

This doesn't mean every application needs a complex architecture.

It means the system should have clear responsibilities.

The Best Code Is Often Boring

This may sound strange coming from a developer, but I think it is worth saying:

Boring code is often excellent code.

Code that is predictable.

Code that follows conventions.

Code that new developers can understand.

Code that doesn't require a 30-minute explanation.

Code that doesn't depend on clever tricks.

Code that fails clearly.

Code that has tests.

Code that can be changed safely.

That kind of code may not look impressive in a social media post.

It doesn't produce an exciting architecture diagram.

But it creates something far more valuable:

maintainability.

Don't Optimize for Developer Ego

Technology can become part of identity.

Developers may feel proud saying:

"I built this using..."

But the user doesn't care.

The customer doesn't care whether you used the newest framework.

They care whether the application solves their problem.

The business cares whether the product creates value.

The team cares whether the software can be maintained.

So instead of asking:

"Does this technology make me look advanced?"

ask:

"Does this technology make the product better?"

That question can eliminate a surprising amount of unnecessary complexity.

A Developer's Job Is Bigger Than Writing Code

Modern web development requires more than technical syntax.

A strong developer needs to understand:

The user

Who is using the application?

What are they trying to accomplish?

The business

Why does the application exist?

What does success look like?

The system

How do the components interact?

Where are the boundaries?

The data

What information is stored?

Who can access it?

The failure modes

What happens when something breaks?

The future

What happens when requirements change?

This is why experienced developers often seem slower when starting a project.

They ask questions before writing code.

That time isn't wasted.

It is preventing future mistakes.

Before You Add a Feature, Ask These Questions

The next time someone requests a feature, try asking:

1. What problem does this solve?

If the problem isn't clear, the feature may not be necessary.

2. Who needs it?

Different users may need different behavior.

3. What is the simplest version?

Start with the smallest useful implementation.

4. What can go wrong?

Think about failure before failure happens.

5. What data does it require?

Avoid collecting information without a reason.

6. What happens at scale?

A solution for 100 users may behave differently with 100,000.

7. How will we test it?

If you cannot explain how to test the feature, the requirements may not be clear enough.

8. How will we know it works in production?

Think about monitoring and observability.

9. How will someone modify it later?

Today's solution becomes tomorrow's legacy code.

10. Can we remove something instead?

Sometimes the best new feature is removing an old unnecessary feature.

The Developer Who Removes Complexity Creates Value

We often celebrate developers who build impressive things.

But there is another kind of engineering achievement that deserves more attention.

Removing unnecessary complexity.

Deleting unused dependencies.

Simplifying an API.

Removing duplicate logic.

Reducing database queries.

Eliminating unnecessary network requests.

Replacing five configuration files with one.

Removing an outdated service.

Making an onboarding process understandable.

Improving an error message.

Writing documentation.

Adding a test that prevents a recurring production bug.

None of these activities may look revolutionary.

But they make software better.

And software quality is often the result of hundreds of small improvements rather than one brilliant idea.

What Should We Actually Be Building?

This is the question I keep coming back to.

With AI making code generation faster, with frameworks making application development easier, and with cloud platforms removing much of the infrastructure burden, what should developers focus on?

My answer is:

We should build software that people can trust.

Software that is:

Understandable
Secure
Accessible
Performant
Maintainable
Observable
Reliable
Adaptable

We should build systems that don't merely demonstrate technical ability.

We should build systems that reduce frustration.

Systems that save time.

Systems that help businesses operate.

Systems that make complicated tasks simpler.

Systems that respect users' data.

Systems that continue working when conditions aren't perfect.

That is meaningful engineering.

The Future Developer May Write Less Code

And I think that's okay.

If AI becomes better at generating routine code, developers may spend less time manually writing boilerplate.

That doesn't make development less valuable.

It changes where the value exists.

Instead of spending hours creating repetitive code, developers can spend more time on:

Requirements
Architecture
Security
Testing
Performance
User experience
Data modeling
Reliability
Debugging
Product thinking
Technical strategy

The future may not belong to the developer who types the fastest.

It may belong to the developer who can look at a complicated problem and say:

"We don't need to make this complicated."

A Different Definition of Productivity

Perhaps we should stop measuring developer productivity primarily through lines of code, tickets completed, or features shipped.

What if productivity also included:

Bugs prevented
Complexity removed
Downtime avoided
Performance improved
Security problems prevented
Tests added
Documentation improved
User frustration reduced
Deployment risk reduced
Future maintenance made easier

Imagine a developer spends two days simplifying a system.

Nothing new appears on the homepage.

No exciting feature launches.

But future developers now need half the time to make changes.

Was that developer productive?

Absolutely.

The result simply isn't as visible.

The Web Doesn't Need More Code. It Needs Better Software.

We already have enormous amounts of software.

We have millions of websites.

Thousands of frameworks.

Countless libraries.

Cloud platforms.

AI coding assistants.

Development environments.

Automation tools.

The next challenge isn't simply creating more.

It is creating better.

Better doesn't necessarily mean bigger.

Better can mean simpler.

Better can mean faster.

Better can mean safer.

Better can mean easier to maintain.

Better can mean more accessible.

Better can mean that a user doesn't have to think about how complicated the system behind the screen is.

That may be one of the most important responsibilities of a developer:

Take complexity from the user and carry it inside the engineering system.

Users shouldn't have to understand our architecture.

They shouldn't have to understand our database.

They shouldn't have to understand our deployment pipeline.

They shouldn't have to understand our framework.

They should be able to accomplish what they came to do.

That's the product.

Final Thought

Web development has never been more accessible.

A motivated developer today can learn, experiment, build, deploy, and reach users faster than previous generations could have imagined.

That is exciting.

But accessibility also creates a new responsibility.

When building software becomes easier, building software responsibly becomes even more important.

We should not confuse speed with quality.

We should not confuse complexity with sophistication.

We should not confuse more code with more value.

And we should not let powerful tools convince us that understanding the result is optional.

The strongest developer is not necessarily the person who knows the most frameworks.

It may be the person who can take a complicated problem, understand the real need, design a sensible solution, anticipate failure, communicate clearly, and leave the system better than they found it.

Because at the end of the day, users don't need more code.

They need software that works.

And when it doesn't work, they need software that fails gracefully.

When requirements change, they need software that can change with them.

When the application grows, they need software that can grow without collapsing under its own complexity.

And when another developer joins the project six months later, they need software that can still be understood.

That is what I believe modern web development should be about: not simply building more, but building things worth maintaining.

What Do You Think?

As developers, we often talk about the technologies we use, the frameworks we prefer, and the tools that make us faster.

But maybe a more important conversation is this:

Are we actually becoming better at building software, or are our tools simply becoming better at producing code?

I'd love to hear from other developers:

What is the biggest source of complexity in your projects?
Have you ever inherited a system that was difficult to maintain?
What is one technology you stopped using because it added more complexity than value?
Has AI helped you write better software, or simply helped you write software faster?
What does "good software" mean to you?

Let's discuss it.

Because the future of web development isn't just about how quickly we can build.

It's about whether what we build deserves to last.

— Sumita
Web Developer

What Was Your First Programming Language?

Sun, 06 Sep 2026 21:21:42 +0000

Once upon a time there was a kid and an IBM PS/2. I was 11, armed with QBasic By Example (1993) and way too much curiosity for my own good. That book became my doorway into programming. PRINT loops, GOTO chaos, line numbers, and the thrill of watching a computer do exactly what I told it to, or crash spectacularly when I didn’t.

From there was a quick jump into C and later C++. I didn’t know it at the time, but that little QBasic book had already wired my brain for how code behaves, not just how it looks on the page. Moving into C felt like leveling up. Suddenly I had pointers, headers, real control flow, and enough rope to hang myself with. The best part was being able to compile and link my own .exe files and give them to friends.

C++ came next, bringing classes, objects, and a whole new way of thinking about structure. Moving from procedural programming into OOP was a huge step and tough to learn... I wont discuss my frustration with pointers...

Eventually I landed in C#, which felt like the modern, sane evolution of everything I’d learned up to that point. It had the structure I liked from C++, the clarity I wished C had, and enough guardrails to let me focus on building instead of fighting the language. It’s been home ever since.

What kicked off your programming life?
Was it Python? JavaScript? TI‑BASIC on a calculator? Scratch? Something weird and obscure?
Drop your first language and your age when you started — I want to see how everyone’s path compares.

Making HTTP Better on ESP32

Sat, 05 Sep 2026 09:23:34 +0000

HTTP on ESP32 Isn't Hard. The Unnecessary Work Around It Is.

Making an HTTP request from an ESP32 is relatively straightforward.

Connect to Wi-Fi, create an HTTP client, send a request, receive a response.

The real challenge usually appears later.

As an embedded application grows, HTTP communication starts accumulating responsibilities:

Authentication tokens
Custom headers
Query parameters and dynamic paths
JSON request bodies
JSON response parsing
Temporary buffers
Memory allocations
Repeated connections
Error handling and status validation

None of these things are particularly difficult on their own.

The problem is the amount of unnecessary work surrounding a simple HTTP request.

On a server or desktop application, that overhead might not matter much. On an ESP32 running continuously alongside sensors, Wi-Fi, display drivers, Bluetooth, and other tasks, memory usage and repeated allocations can become much more important.

This article explores a question I started asking while building ESP32 applications:

How much work does an ESP32 actually need to do to make an HTTP request?

A Simple Request Can Turn Into a Long Workflow

Consider a common situation.

An API returns the following JSON:

{
  "temperature": 24.8,
  "humidity": 68,
  "device": {
    "id": "esp32-office",
    "location": "office"
  },
  "metadata": {
    "version": "1.4",
    "updatedAt": 1725500000
  }
}

But your ESP32 only needs this:

temperature
device.id

A traditional workflow might look like this:

HTTP Request
     ↓
Receive the complete response
     ↓
Store the response in memory
     ↓
Create a JSON document
     ↓
Parse the entire JSON
     ↓
Navigate through the structure
     ↓
Extract two values
     ↓
Discard temporary data

This approach is completely valid.

In fact, a full JSON parser is often the right solution when your application genuinely needs to work with an entire JSON document dynamically.

But there is an important question:

If the application already knows exactly which values it needs, do we need to allocate and process everything else?

That question became the starting point for a different approach.

The Real Cost Isn't HTTP

HTTP itself is not necessarily the problem.

The surrounding workflow often is.

A request can involve:

Create Client
     ↓
Configure Headers
     ↓
Build Authentication
     ↓
Format URL & Query Parameters
     ↓
Build JSON Request Body
     ↓
Open Connection
     ↓
Send Request
     ↓
Receive Response
     ↓
Store Response
     ↓
Allocate JSON Document
     ↓
Parse JSON
     ↓
Extract Values
     ↓
Destroy Temporary Objects

Repeat that process continuously, and things become more interesting.

For an ESP32 application that runs for hours, days, or even months, developers often start thinking about questions that are less important in traditional applications:

How often am I allocating memory on the heap?
Am I storing data I don't actually need?
Can I reuse this connection across requests?
Can authentication configuration persist without repeated boilerplate?
Can I avoid repeatedly rebuilding headers and URLs?
Can I extract only the fields I care about directly into variables?
Will a missing JSON key crash my device or leave it in an unstable state?

The goal isn't to eliminate every allocation at all costs.

The goal is to avoid allocations and processing that don't provide value to the application.

Memory Predictability Matters on Embedded Devices

The ESP32 is a capable microcontroller, but it still operates under resource constraints.

An embedded application might be handling several things simultaneously:

ESP32 Application
│
├── Wi-Fi
├── Sensors
├── Display
├── Bluetooth
├── FreeRTOS Tasks
├── HTTP Communication
└── Application Logic

Every component competes for memory.

This is why memory predictability can be just as important as raw performance.

Repeated dynamic allocations are not automatically bad. However, when an application performs frequent network operations over long periods, reducing unnecessary temporary allocations can help create a more predictable memory profile.

This becomes particularly relevant when dealing with HTTP responses.

Do You Really Need the Entire JSON Response?

Let's return to the earlier example.

Suppose the ESP32 only needs:

temperature
device.id

Instead of building an entire JSON structure in memory, another approach is to bind those fields directly to variables.

For example:

float temperature;
char deviceId[32];

client.get("/sensor")
      .getBody("temperature", &temperature)
      .getBody("device.id", deviceId, sizeof(deviceId));

The application tells the HTTP client:

When you find temperature, write it here.

And:

When you find device.id, write it here.

The application doesn't need to manually navigate through a JSON document afterward.

The values go directly to their final destination.

This concept is called response binding, and it became the central idea behind my library, ESP32-HTTP-Client.

Instead of following this workflow:

Response
   ↓
String
   ↓
JSON Document
   ↓
Extract Values

The workflow becomes:

Response Stream
   ↓
Find Required Fields
   ↓
Write Directly Into Variables

The complete response body does not need to be stored before processing.

The library processes the response as a stream and binds matched fields directly to the variables provided by the application.

Nested Paths, Arrays, and Missing Keys

Response binding isn't limited to shallow properties. It supports deep dot notation and numeric array indexing:

char city[32];
int secondReading;

client.get("/data")
      .getBody("sensors.0.readings.1", &secondReading)
      .getBody("device.location.city", city, sizeof(city));

And critically for embedded reliability: if a key is missing or the schema changes, the target variable is simply left untouched. The library does not crash, throw exceptions, or leave memory in an inconsistent state.

Reducing Work Means More Than Reducing Memory

Memory was one motivation behind this approach.

But reducing unnecessary work can also improve code simplicity.

Consider the amount of code developers often write around a simple request using the standard ESP32 libraries (HTTPClient + ArduinoJson):

// The traditional approach: ~15-20 lines of procedural boilerplate
HTTPClient http;
http.begin("https://api.example.com/report");
http.addHeader("Authorization", "Bearer my-jwt-token");
http.addHeader("X-Device-ID", "ESP32-001");

int code = http.GET();
if (code == HTTP_CODE_OK) {
    // 1. Read complete payload into RAM (heap allocation #1)
    String payload = http.getString();

    // 2. Allocate JSON document (heap allocation #2)
    DynamicJsonDocument doc(2048);
    DeserializationError err = deserializeJson(doc, payload);

    if (!err) {
        // 3. Navigate structure and copy values manually
        int userId = doc["userId"];
        float temperature = doc["sensor"]["temp"];
        char city[32];
        strncpy(city, doc["address"]["city"] | "", sizeof(city));
    }
}
http.end();

Notice everything that happens here:

Authentication and headers are rebuilt for every single request.
Intermediate buffers (payload String and doc JSON tree) are allocated on the heap to store data the application will never use.
Manual parsing and navigation are written out imperatively.
Cleanup and disposal repeat on every iteration.

A good abstraction should reduce repetition without hiding important control from the developer.

With ESP32-HTTP-Client, those responsibilities are divided where they actually belong:

Authentication and headers belong to the client configuration and are declared once (client.bearer(...), client.setHeader(...)), persisting automatically across requests.
Buffers and deserialization are bypassed entirely—the response stream binds matched values straight into your destination variables.

So when the goal is simply to retrieve a few values from an API, the application code expresses only its actual intent:

int userId;
float temperature;
char city[32];

// Client already has auth & headers; request simply fetches and binds:
client.get("/report")
      .getBody("userId", &userId)
      .getBody("sensor.temp", &temperature)
      .getBody("address.city", city, sizeof(city));

The code describes the application's actual intent:

Make a request and give me these values.

And if a specific request needs query parameters, a custom timeout, or needs to capture a response header, they fold into the exact same fluent chain without extra boilerplate:

String token;

client.get("/report")
      .query("period", "latest")
      .timeout(5000)
      .getHeader("Authorization", &token)
      .getBody("userId", &userId)
      .getBody("sensor.temp", &temperature)
      .getBody("address.city", city, sizeof(city));

That is the philosophy behind the fluent API used by ESP32-HTTP-Client.

Fluent Payloads and Full REST Support

This fluent design isn't limited to GET requests. REST communication is two-way.

Building JSON request bodies manually with snprintf or String concatenations frequently introduces subtle formatting bugs and heap churn. With ESP32-HTTP-Client, sending structured data is just as straightforward:

int newId;

// POST request with fluent JSON body construction
client.post("/devices")
      .body("name", "ESP32-Office")
      .body("interval", 30)
      .body("active", true)
      .getBody("id", &newId);

The client provides first-class support for all standard REST methods: get(), post(), put() (with update() as an alias), patch(), and del().

Path and Query Parameters Without String Concatenation

Dynamic URLs in Arduino sketches are typically built with repetitive string operations:

// Fragile and causes heap fragmentation:
String url = "/devices/" + String(deviceId) + "/readings?limit=" + String(limit);

ESP32-HTTP-Client solves this at the builder level with .path() and .query():

client.get("/devices/{id}/readings")
      .path("id", deviceId)
      .query("limit", 20)
      .query("filter", "active")
      .getBody("summary.count", &count);

Placeholders are replaced and query parameters are appended smoothly, keeping the code readable and avoiding intermediate String objects on the heap.

Beyond Primitives: Struct <-> JSON Mapping

Binding individual primitive variables works well for small endpoints. But in production firmware, you often work with structured data models.

Traditionally, handling a data model on an ESP32 involves:

Allocating a DynamicJsonDocument.
Parsing the incoming JSON.
Manually copying each field into a C++ struct.
Freeing the document.
Repeating the reverse process whenever you need to serialize the struct to send it back.

ESP32-HTTP-Client addresses this with zero-allocation bidirectional struct mapping via the REST_JSON_MAP macro:

struct DeviceConfig {
    float telemetryInterval = 60.0;
    bool enabled = true;
    char mode[16] = "normal";

    REST_JSON_MAP(
        REST_FIELD(telemetryInterval),
        REST_FIELD(enabled),
        REST_FIELD(mode)
    )
};

Once declared, the struct can be populated directly from an API response:

DeviceConfig config;

// The network stream binds directly into the struct fields
client.get("/device/config").getBody(&config);

And sending a struct to an API is just as clean:

client.post("/device/config").body(config);

No intermediate JSON documents to size or manage. Serialization and deserialization happen directly between your native C++ structures and the network stream.

Authentication Shouldn't Become Repeated Boilerplate

Performance and memory are only part of the problem.

Authentication is another common source of repeated HTTP boilerplate.

Many IoT APIs require authentication using:

Bearer tokens
JWT tokens
HTTP Basic Authentication
API Keys
Custom headers

Without a reusable abstraction, authentication logic can easily start appearing before every request.

For example:

Request A
 ├── Add Authorization Header
 └── Send Request

Request B
 ├── Add Authorization Header
 └── Send Request

Request C
 ├── Add Authorization Header
 └── Send Request

But authentication usually belongs to the client configuration, not to every individual request.

A reusable client can configure authentication once:

client.bearer("your-jwt-token");

Then continue making requests:

client.get("/profile");

client.get("/devices");

client.get("/telemetry");

The authentication header persists across subsequent requests made by that client instance.

The same idea applies to Basic Authentication:

client.basic("username", "password");

And API keys:

client.apiKey("X-API-Key", "your-api-key");

The client also supports persistent custom headers:

client.setHeader("X-Device-ID", "ESP32-001");

These configurations remain associated with the client and are applied to subsequent requests.

Extracting Response Headers

What about headers returned by the server? Often, authentication tokens, rate limits, or server timestamps are sent in HTTP response headers rather than the JSON body.

Instead of writing custom header collection routines, you can extract response headers inside the same fluent chain:

String refreshedToken;
int rateLimit;

client.get("/telemetry")
      .getHeader("Authorization", &refreshedToken)
      .getHeader("X-RateLimit-Remaining", &rateLimit);

Header lookups are case-insensitive and can be captured into standard C types or Arduino Strings.

This may seem like a small improvement.

But in embedded applications, reducing repeated code also reduces the chances of inconsistent configuration between requests.

Reuse the Client, Not Just the Code

Another overlooked source of unnecessary work is connection management.

Imagine an application that does this repeatedly:

Create HTTP Client
      ↓
Connect
      ↓
Make Request
      ↓
Close Connection
      ↓
Destroy Client

Then starts again a few seconds later.

For applications making frequent requests to the same server, connection reuse can significantly reduce overhead.

ESP32-HTTP-Client enables HTTP Keep-Alive and reuses the underlying connection when possible, allowing subsequent requests to avoid unnecessarily rebuilding the connection.

The intended usage looks more like this:

ESP32HTTPClient client("https://api.example.com");

void loop() {
    float temperature;

    client.get("/sensor")
          .getBody("temperature", &temperature);

    delay(5000);
}

The client instance is reused.

That doesn't mean every application should keep a connection alive forever.

There are trade-offs.

An active HTTPS connection can retain TLS buffers in memory. According to the library's documented measurements, calling client.end() after a burst of requests can release resources when the device will remain idle for a long period.

So the better question isn't:

Should I always keep the connection alive?

It is:

Does connection reuse make sense for how frequently my device communicates?

That distinction matters.

Measuring the Difference

Performance claims without context are not particularly useful.

So I tested the approach using 100 consecutive HTTP GET requests with JSON responses on a real ESP32 device.

The benchmark compared:

Standard Approach
HTTPClient + ArduinoJson

vs.

ESP32-HTTP-Client
Streaming + Direct Response Binding

The Wi-Fi connection was already established before the benchmark started, and both approaches used their default configurations.

The documented benchmark results were:

Metric	HTTPClient + ArduinoJson	ESP32-HTTP-Client
Heap allocation per request	~58.2 KB	~15 bytes
Average RAM footprint	34.2%	24.3%
Minimum free heap	114.3 KB	128.6 KB
Average execution time	~750 ms	~59 ms

The difference comes from several architectural choices, including connection reuse and streaming JSON processing rather than storing the complete response and parsing it afterward.

However, these numbers should be interpreted correctly.

They represent this specific benchmark configuration.

They do not mean every HTTP request on every ESP32 application will be twelve times faster.

Network conditions, server behavior, payload size, TLS configuration, connection reuse, and application logic can all affect the result.

Benchmarking should always be reproducible and specific to the problem being solved.

The full benchmark setup and source information are documented with the project.

A More Practical Example

Let's consider a realistic IoT scenario.

An ESP32 communicates with a remote API.

It needs to:

Authenticate using a Bearer token.
Identify the device using a custom header.
Send telemetry periodically.
Receive configuration from the server.
Extract only the configuration values it needs.

The workflow looks like this:

               ESP32     
                 │
      Read Sensor Data (Temp & Humidity)
                 │
                 ▼
       Send Telemetry (POST /telemetry)
                 │
                 ▼
          Authenticated API
                 │
                 ▼
   Receive Configuration (GET /device/config)
                 │
                 ▼
     Extract Required Fields Directly

The client configuration happens once during initialization:

#include <WiFi.h>
#include "ESP32HTTPClient.h"

ESP32HTTPClient client("https://api.example.com");

void setup() {
    Serial.begin(115200);
    // Connect to Wi-Fi...

    // Configure persistent auth and headers once:
    client.bearer("your-jwt-token");
    client.setHeader("X-Device-ID", "ESP32-001");
}

Then, in the periodic loop, the application performs both the telemetry upload and configuration check without intermediate boilerplate:

void loop() {
    // 1. Read sensor data
    float currentTemp = 24.8;
    float currentHumidity = 65.0;

    // 2. Send telemetry via POST with a fluent JSON payload
    client.post("/telemetry")
          .body("temperature", currentTemp)
          .body("humidity", currentHumidity);

    if (client.isSuccess()) {
        Serial.println("Telemetry sent successfully.");
    }

    // 3. Retrieve server configuration via GET with direct response binding
    float interval = 30.0;
    bool enabled = true;

    client.get("/device/config")
          .getBody("telemetryInterval", &interval)
          .getBody("enabled", &enabled);

    if (client.isSuccess()) {
        Serial.printf("Config updated: interval=%.1fs, enabled=%d\n", interval, enabled);
    } else {
        Serial.printf("Request error [%d]: %s\n", 
                      client.getStatusCode(), 
                      client.getErrorMessage().c_str());
    }

    delay(interval * 1000);
}

The application does not need to manually:

Format a JSON string with snprintf or String additions.
Retrieve a complete JSON response string.
Allocate a JSON document on the heap.
Deserialize the document.
Navigate through the JSON structure.

Instead, it declares what it sends and what it expects.

That is a much closer representation of what the application actually needs.

But Should You Always Avoid a Full JSON Parser?

No.

This is important.

A full JSON library remains extremely useful.

There are situations where you genuinely need:

Dynamic JSON structures
Unknown fields
Complex transformations
Entire arrays
Full objects
Runtime exploration of a JSON document

In those situations, storing and manipulating the entire document may be the correct solution.

The goal is not:

Never use ArduinoJson.

The goal is:

Don't process more data than your application needs.

If your application requires only three predictable values from a large API response, direct response binding can be a simpler and more memory-conscious alternative.

If your application needs to inspect and manipulate an entire dynamic JSON document, a full JSON parser is probably the better tool.

Choosing the right abstraction depends on the problem.

When Does This Approach Actually Matter?

If your ESP32 sends one small request every few hours, HTTP optimization may not be your biggest concern.

But the approach becomes more interesting when your application:

Runs continuously.
Makes frequent requests.
Communicates with the same server repeatedly.
Has limited memory available.
Uses multiple peripherals (display, BLE, Wi-Fi, sensors).
Processes JSON responses.
Needs predictable memory usage without heap fragmentation.
Uses authentication across multiple API endpoints.

For these scenarios, reducing unnecessary allocations and repeated configuration can make the networking layer simpler and potentially more efficient.

The Idea Behind ESP32-HTTP-Client

I built ESP32-HTTP-Client around a simple question:

Can HTTP communication on an ESP32 be expressed closer to what the application actually needs?

Instead of:

Get everything
     ↓
Store everything
     ↓
Parse everything
     ↓
Use a small part

The approach becomes:

Request what you need
     ↓
Extract what you need
     ↓
Store it where you need it

The library combines several ideas:

Direct JSON response binding: Maps response values straight into primitive variables or native C++ structs (REST_JSON_MAP).
Streaming response processing: Parses data on the fly directly from the network stream with zero full-payload buffering.
Full REST suite with fluent payloads: Clean GET, POST, PUT, PATCH, and DELETE without manual string formatting.
Safe URL builders: Dynamic path parameters (.path()) and query strings (.query()) without dynamic String concatenation.
Response header extraction: Binds headers directly via .getHeader() in the same call.
Persistent authentication: Reusable Bearer tokens, Basic Auth, API keys, and custom headers.
HTTP Keep-Alive and connection reuse: Drastically reduces handshake latency across sequential requests.
Built-in reliability: Missing response fields never crash the device, and status checking (isSuccess(), callbacks) is baked in.

The objective was never simply to create another HTTP wrapper.

It was to question how much unnecessary work an ESP32 performs between:

"I need this data"

and:

"Here is the value."

Final Thoughts

Making HTTP requests on an ESP32 isn't difficult.

The challenge is everything that tends to accumulate around those requests as an application grows.

Authentication.

Headers.

Temporary buffers.

JSON parsing.

Repeated connections.

Repeated boilerplate.

For many projects, the traditional approach is perfectly fine.

But embedded development often benefits from asking a different question:

What work is actually necessary?

If the ESP32 already knows which values it needs from an API, processing and storing an entire response may not always be necessary.

If authentication remains the same across multiple requests, rebuilding the headers every time may not be necessary.

If the device communicates repeatedly with the same server, reconnecting from scratch may not always be necessary.

Small decisions like these can change how an embedded application behaves over time.

That is the idea behind ESP32-HTTP-Client:

HTTP isn't necessarily the expensive part. Sometimes, it's all the unnecessary work around it.

Explore the Project

ESP32-HTTP-Client is an open-source Arduino library designed for ESP32 applications that need a lightweight and fluent approach to REST communication.

You can explore the documentation, examples, benchmarks, and source code here:

ESP32-HTTP-Client Documentation

JsonToolBox

Fri, 04 Sep 2026 22:58:29 +0000

JsonToolBox is a free, open-source JSON toolkit built for developers, testers, technical writers, and anyone who works with structured data.

It provides browser-based tools for common JSON tasks, including formatting and beautifying JSON, validating syntax, minifying output, viewing JSON in a structured tree, comparing two JSON documents, and converting JSON to other commonly used formats.

JsonToolBox is designed for fast, focused use. You can open a tool, paste your data, perform the required operation, and copy or download the result without creating an account. JSON processing is performed locally in your browser, so your JSON content is not uploaded to a remote server for processing.

Typical use cases include inspecting API responses, debugging configuration files, checking JSON before deployment, preparing examples for documentation, comparing payloads, and converting structured data for development workflows.

The project is open source and available under the MIT License. The complete source code and development information are available on GitHub.

Website: https://jsontoolbox.cc
Source code: https://github.com/kbmjj123/jsontoolbox.cc

Can an Ecosystem Scale Through Independent Projects Instead of Accumulating Users?

Wed, 02 Sep 2026 08:20:27 +0000

Can an Ecosystem Scale Through Independent Projects Instead of Accumulating Users?

Tonight, Nicola and I completed a small but important step for the MyZubster ecosystem.

We did not add a registration counter.

We did not announce an unfinished platform as if it were ready.

We completed one capability—and made it verifiable.

Nicola’s independent MyZubster project

Nicola is developing an independent MVP inside the broader MyZubster experiment.

The repository is public:

github.com/nicolaususnicola-lgtm/myzubster-mvp

Tonight, we completed its first end-to-end user story:

Create an observation → HTTP 201 → save it → retrieve it → verify it automatically

The application can now:

accept a valid observation through its API;
generate an observation ID;
persist the data to JSON;
retrieve the saved observation;
reject missing or invalid input;
validate latitude and longitude ranges;
prove the full workflow through an automated test.

What verification revealed

Testing the complete workflow uncovered issues that were not obvious when examining each component separately.

The timestamp was being created when the Python module loaded, meaning multiple observations could potentially share it.

The API could also return an internal error when receiving missing JSON or invalid coordinates.

We corrected both problems.

Each observation now receives its own UTC timestamp, and invalid requests produce controlled 400 responses.

We also improved persistence by writing through a temporary file before replacing the destination JSON file. The automated test uses isolated temporary storage, so it never changes the repository’s real observation data.

A transparent development process

We did not modify main directly.

The work was completed on a separate branch:

zorgax/observation-e2e

We then opened a public pull request:

PR #1 — Verify observation creation, persistence and retrieval

GitHub Actions executed the complete test suite.

The CI passed successfully.

The changes are now public, reviewable and supported by reproducible evidence.

Why this is relevant beyond one Python MVP

MyZubster is based on a simple hypothesis:

An ecosystem does not have to scale only by accumulating users. It can scale by accumulating useful, independently developed capabilities.

Each participant can begin with a small project.

That project does not need to become a giant platform. It needs to solve something real and pass through a transparent development cycle:

Build → Validate → Connect → Measure → Verify → Replicate → Expand

If the project proves useful, it can later become a capability available to the broader network.

Instead of forcing every idea into one centralized application, the ecosystem can grow through independent modules, experiments and services.

One human + one AI

Tonight’s work also tested the one human + one AI model.

Nicola remains the owner of his project and its direction.

Zorgax, the AI coordination layer, can help inspect the repository, identify technical risks, prepare changes and build verification processes.

The AI does not replace human approval.

It helps transform an idea into smaller steps that can be inspected and verified.

The intended relationship is:

the human defines purpose and maintains control;
the AI assists with analysis and implementation;
automated tests provide evidence;
public repositories make the work auditable;
the community can review, challenge and improve the result.

What we have—and what we do not have yet

Nicola’s repository is still an MVP.

It is not production-ready.

It does not yet provide a complete MyZubster integration, advanced authentication, scalable storage or a finalized observation standard.

What it does provide is one working and verified capability.

That distinction matters.

Open-source development becomes more credible when we clearly separate:

ideas from implementations;
implementations from verified workflows;
verified workflows from production systems.

Tonight, Nicola’s project moved from the second category toward the third.

The next steps

Possible next steps include:

reviewing and merging the pull request;
adding Docker support for reproducible local execution;
defining a stable observation schema;
reorganizing application and test data;
evaluating stronger persistence options;
documenting how an independent observation project could connect to MyZubster;
measuring whether the capability is genuinely useful to others.

The goal is not to expand quickly.

The goal is to expand through evidence.

The broader experiment

If the answer eventually becomes yes, MyZubster will not expand simply because more people register.

It will expand because every useful independent project can become another capability available to the network.

That is the experiment.

Build → Validate → Connect → Measure → Verify → Replicate → Expand

MyZubster — Open-source ecosystem
Zorgax — AI intelligence and coordination layer
Principle — Human-controlled, evidence-driven development

Main repository: github.com/MyZubster-Ecosystem/myzubster

Website: myzubster.com

What do you think?

Can an ecosystem scale through independently built and verified projects instead of simply accumulating users?

Suggested tags

AI · Open Source · Software Development · AI Agents · Architecture · IoT · Sustainability

Shopify Development Agency for High-Performing Ecommerce Stores

Sun, 30 Aug 2026 06:00:53 +0000

A Shopify store is more than a digital catalogue. It is the foundation of an ecommerce business where design, functionality, speed, usability, and customer experience all work together. Businesses looking to establish or improve their online stores often partner with a professional Shopify development agency to create a website that reflects their brand and supports long-term growth.

Bloom Agency provides Shopify development solutions for businesses that want customized, responsive, and search-friendly ecommerce websites. From building a new Shopify store to redesigning an existing website, the development approach focuses on creating a smooth experience for both customers and store administrators.

What Is a Shopify Development Agency?

A Shopify development agency specializes in designing, developing, customizing, and optimizing ecommerce websites built on Shopify.

While Shopify provides the core technology and a wide range of themes and applications, businesses may need professional development to create a store that is customized to their products and business model.

A Shopify development agency can help with:

Shopify store development
Theme customization
Custom Shopify development
Ecommerce website design
Product and collection page development
Third-party application integration
Payment and shipping integration
Shopify migration
Website redesign
Performance optimization
SEO-friendly website structure

The right development approach ensures that the website is not only visually appealing but also practical, scalable, and easy to manage.

Shopify Website Development Services

Professional Shopify website development services can cover the complete lifecycle of an ecommerce website, from initial planning to launch.

Bloom Agency works with businesses to understand their products, customers, competitors, and online objectives before developing the store. This helps create a website structure that supports both customer experience and business operations.

Services can include Shopify store setup, theme customization, custom page development, product catalogue organization, navigation development, application integration, responsive design, and website testing.

Custom Shopify Store Development

Every business has different requirements. A standard Shopify theme may provide a good starting point, but customization can help a store stand apart from competitors.

Custom Shopify development can be used to create branded layouts, specialized product sections, custom landing pages, advanced navigation, promotional sections, product filters, and other functionality.

The objective is to create a Shopify store that matches the brand rather than making the business adapt completely to a pre-built template.

Shopify Website Development Company for Growing Brands

Choosing a Shopify website development company is an important decision for ecommerce businesses because the website can directly influence how customers interact with the brand.

A professional development team can help businesses create:

Responsive ecommerce websites
User-friendly navigation
Mobile-optimized shopping experiences
Customized product pages
Organized collections
Secure checkout experiences
Application integrations
Scalable website structures

A well-developed store also provides a stronger foundation for future SEO, advertising, content marketing, and conversion optimization.

Shopify Development Services for Ecommerce Businesses

The requirements of an ecommerce store can change as the business grows. A small catalogue may eventually become hundreds or thousands of products. New payment methods, shipping providers, marketing platforms, analytics tools, and customer engagement systems may also need to be integrated.

Professional Shopify development services can help businesses manage these changes without rebuilding the entire ecommerce website.

Development support may include new functionality, theme updates, application integrations, technical improvements, landing page creation, and ongoing website maintenance.

Mobile-Responsive Shopify Development

Customers frequently browse ecommerce websites using smartphones. A Shopify store therefore needs to provide a consistent experience across mobile, tablet, and desktop devices.

Responsive development ensures that menus, product images, descriptions, buttons, filters, forms, and other important elements adapt properly to different screen sizes.

Bloom Agency focuses on responsive design so customers can browse products and move through the purchasing process comfortably regardless of the device they use.

SEO-Friendly Shopify Development

Website development and SEO should be considered together. Technical problems, poor navigation, weak internal linking, slow pages, or an unclear website structure can make it harder for search engines and customers to understand an ecommerce website.

An SEO-friendly Shopify store can include:

Logical site architecture
Search-friendly URLs
Optimized page titles
Proper heading structures
Internal linking
Optimized images
Mobile responsiveness
Fast-loading pages
Product and collection optimization
Structured data where appropriate

After development, ongoing SEO can help improve the visibility of important product, collection, and informational pages.

Shopify Store Redesign

An ecommerce website may need a redesign when its visual identity is outdated, navigation is confusing, mobile performance is poor, or customers struggle to find products.

A Shopify redesign can focus on improving the homepage, product pages, collection pages, menus, calls to action, content hierarchy, and overall customer journey.

Instead of changing the appearance alone, a strategic redesign considers how customers discover products, evaluate them, and complete purchases.

Shopify Migration

Businesses operating on WooCommerce, Magento, custom ecommerce platforms, or other systems may decide to migrate to Shopify.

Migration requires careful planning because important website information needs to be transferred while maintaining the existing customer experience and search visibility.

A Shopify migration project may involve:

Product migration
Customer data migration
Collection and category migration
Content migration
Image migration
URL mapping
Redirect implementation
Shopify theme development
Testing before launch

A structured migration can reduce technical problems and help businesses transition to Shopify more efficiently.

Shopify Development for Different Industries

Shopify can be used by businesses across a wide range of industries, including fashion, beauty, jewelry, home products, lifestyle brands, accessories, consumer goods, and many others.

Each industry can require a different ecommerce experience.

For example, fashion stores may need size and colour variants, filters, lookbooks, and visual product presentation. Beauty brands may require product education, ingredient information, bundles, and subscription options. Jewelry businesses may need detailed product specifications, high-quality imagery, customization options, and trust-building content.

The development strategy should therefore be based on the business rather than applying the same website structure to every store.

Why Choose Bloom Agency?

Bloom Agency combines Shopify development with broader digital marketing expertise. This allows ecommerce websites to be developed with SEO, content, conversion optimization, analytics, social media, and paid advertising requirements in mind.

The objective is not simply to launch another Shopify store. It is to create an ecommerce platform that can support the business as its product catalogue, customer base, and marketing activities expand.

Bloom Agency can help businesses with Shopify store development, customization, redesign, migration, integrations, and ongoing improvements.

Build Your Shopify Store With a Growth-Focused Approach

A successful ecommerce website needs a combination of technology, design, usability, and strategy. Working with an experienced Shopify development agency can help businesses avoid common development problems and create a store that is prepared for customers and future growth.

Whether you are launching a new ecommerce business, migrating from another platform, or improving an existing Shopify store, professional development can provide the technical foundation required for a better online shopping experience.

Bloom Agency offers Shopify website development services designed around the individual needs of ecommerce businesses. The goal is to build Shopify stores that are responsive, functional, scalable, and ready to support long-term digital growth.

How a QA Problem Turned Into the SaaS I’m Building

Sat, 29 Aug 2026 14:19:38 +0000

I didn’t start building Dulvarn because I wanted to become a SaaS founder.

At least, not at first.

I started with a problem I kept seeing again and again in software delivery.

A team could have:

green CI
passing tests
successful builds
approved pull requests
deployment steps ready

And still, one question remained difficult to answer clearly:

Are we actually ready to release?

That question stayed with me.

Because in theory, software teams already have many signals.

CI tells us something.

Automated tests tell us something.

QA tells us something.

Security tools tell us something.

Pull requests tell us something.

Monitoring tells us something.

But those signals are often scattered across different tools, dashboards, tickets, reports, and conversations.

And when it is time to make the final release decision, the answer is not always as clear as the pipeline color suggests.

That gap is where Dulvarn started.

Green does not always mean confident

One of the ideas I kept coming back to was simple:

A green pipeline tells you that the checks you defined passed.

That is valuable.

But it does not automatically tell you that the release risk is low.

For example:

Build                     PASS
Automated tests           PASS
Security scan             PASS

Database migration        YES
Authentication change     YES
Rollback confidence       MEDIUM
Observability coverage    PARTIAL
QA coverage               LIMITED

Nothing here is necessarily red.

But it also does not feel like a release decision that should be made blindly.

The build passed.

The tests passed.

The scan passed.

But the release still deserves thought.

What changed?

How risky is the change?

Can we roll it back?

Do we have enough visibility after deployment?

Do we understand the weakest part of the release?

That difference between technical validation and release confidence became more interesting to me over time.

And once I noticed it, I started seeing it everywhere.

QA taught me to ask uncomfortable questions

Working in QA changes the way you look at software.

You naturally start asking:

What could fail?
What was not covered?
What assumption are we making?
What happens if the user does something unexpected?
What changed between environments?
What evidence do we actually have?

At first, those questions were mostly about features.

Does login work?

Can the user complete checkout?

Does validation behave correctly?

Does the API return the expected response?

But as I moved deeper into automation, CI/CD, DevOps, observability, and release engineering, the questions became broader.

I started asking:

What happens if the deployment succeeds, but the system becomes unhealthy?

What if the tests pass, but rollback is unclear?

What if the release includes a risky migration?

What if different teams each have part of the evidence, but nobody has the whole picture?

At that point, the problem was no longer only testing.

It was release decision-making.

Release readiness is often spread across too many places

In many teams, release evidence is not missing.

It is fragmented.

One signal lives in CI.

Another lives in test reports.

Security findings live somewhere else.

Deployment status is in another system.

Approvals may be in a ticket.

Important context may be in Slack.

Risk may be understood by one engineer, but not written down anywhere.

And then someone has to decide whether the release should go out.

That decision can become strangely informal compared to everything that came before it.

Code review is structured.

CI is structured.

Testing is structured.

Deployment is often structured.

But the release decision itself can still depend on scattered context and human memory.

That bothered me.

Not because people were careless.

But because the tools around them were usually optimized for execution.

Build.

Test.

Deploy.

They were less focused on the decision between those steps.

Dulvarn started as a release control idea

The idea behind Dulvarn came from that gap.

I wanted to explore a simple question:

What if release decisions were based on collected evidence instead of scattered signals and assumptions?

Not to replace CI.

Not to replace QA.

Not to replace DevOps.

And definitely not to replace people.

The point is not to make software delivery fully automatic and hope for the best.

The point is to make release risk more visible.

Something like:

CI
QA
Security
Change Context
Deployment Readiness
Operational Signals
Approvals
        ↓
Release Evidence
        ↓
Risk Context
        ↓
GO / CONDITIONAL GO / NO-GO

The label matters less than the explanation behind it.

A good release decision should not only say:

GO

It should also explain why.

And if the answer is:

CONDITIONAL GO

Then the team should understand the condition.

And if the answer is:

NO-GO

Then the reason should be clear enough to act on.

That is the direction I started building toward.

I am not trying to build another giant platform

One thing I care about is keeping the core idea clear.

Software teams already have enough tools.

They do not need another huge platform that tries to replace everything they use.

The interesting part is the layer between existing systems.

Collect the signals.

Understand the context.

Evaluate the risk.

Make the decision visible.

Keep the evidence.

That is the part I keep coming back to.

Dulvarn is not meant to be a magical AI system that takes control away from teams.

It is meant to support human-controlled release decisions.

The software can help organize evidence.

It can highlight risk.

It can make patterns easier to see.

It can preserve decision history.

But the responsibility still belongs with people.

That matters to me.

Especially because release decisions are not only technical.

They involve judgment.

Building the idea was easier than defining the product

This was one of the first lessons I learned.

Writing code is only one part of building a SaaS.

You also need to answer questions like:

Who exactly is this for?
Which problem is painful enough to solve?
What belongs in the MVP?
What should not be built yet?
How should onboarding work?
What should users see first?
What should remain manual?
What should be automated?
What is useful now, and what is just interesting?

Those questions are often harder than building another endpoint or UI component.

And they do not have clean pass/fail answers.

As a QA engineer, I was used to looking for defects.

As a product builder, I had to start looking for unnecessary complexity too.

That is a different skill.

And I am still learning it.

The temptation to build too much is real

When you build your own product, every idea feels useful.

Add another integration.

Add another dashboard.

Add another AI feature.

Add another report.

Add another workflow.

Add more settings.

Add more intelligence.

The product can become impressive very quickly.

It can also become impossible to understand.

I had to learn that a technically strong feature is not automatically a product priority.

Sometimes the better decision is:

Not yet.

That is surprisingly difficult when you are the person imagining the system and building it at the same time.

Because you can see the future version in your head.

But users do not start with the future version.

They start with the first useful version.

And that version has to be clear.

Building while working full-time changes everything

There is another reality behind Dulvarn.

I am building it while working a full-time job.

That means time matters.

Energy matters.

Focus matters.

You cannot treat every idea like an emergency.

You cannot spend weeks polishing something nobody has asked for.

You cannot rebuild the architecture every time a more elegant solution appears.

At least, not if you want to ship something.

This has forced me to think much more seriously about priorities.

What moves the product forward?

What creates evidence that the idea is useful?

What helps me get closer to real users?

What is just interesting engineering?

Those are different things.

And as a technical founder, it is very easy to confuse them.

Building Dulvarn changed the way I think about QA

Interestingly, building a SaaS has also made me think differently about QA.

When you own the whole product, quality becomes much bigger than testing.

A confusing onboarding step matters.

A broken deployment matters.

A slow page matters.

A missing error message matters.

Security matters.

Observability matters.

Documentation matters.

Support experience matters.

Pricing clarity matters.

The product is not only the code.

The product is the whole experience around the code.

That perspective feeds back into how I think about software quality in general.

Quality does not start when testing begins.

And it does not end when QA says passed.

It exists across the full lifecycle of the product.

This is still early

Dulvarn is not a finished story.

It is still early.

There are things I will probably change.

Features I will remove.

Assumptions I will test.

Positioning I will sharpen.

Workflows I will simplify.

Technical decisions I will rethink.

That is part of the process.

I do not want to write this series as if I already have everything figured out.

I do not.

I am building, learning, cutting scope, testing ideas, and trying to turn a real QA and release engineering problem into something useful.

That is exactly why I want to document it.

Not as a perfect founder story.

More as a record of what I am learning while building.

In this series, I want to write about the real process behind building Dulvarn.

Things like:

how I decide what belongs in the MVP
how I think about release risk
what I learn from user feedback
how I approach onboarding
how I avoid building too much
how I think about pricing
how I balance AI with human control
how I work on infrastructure
how I manage product decisions while working full-time
what I build and later remove

Not as a tutorial for building the perfect SaaS.

I definitely do not have that.

More as a practical founder log from someone trying to build a product from a problem he understands deeply.

Dulvarn did not start because I wanted to become a SaaS founder.

It started because QA kept leading me toward bigger questions.

Testing led to automation.

Automation led to CI/CD.

CI/CD led to DevOps.

DevOps led to release engineering.

And release engineering led to one question I could not stop thinking about:

If all our systems produce signals, who actually turns those signals into a release decision?

I am still working on the answer.

And I am building a product around it.

This is the first article in my How I’m Building a SaaS series.

In the next article, I want to write about one of the hardest lessons so far:

how to decide what not to build.

# Designing a Non-Custodial Multichain Wallet Hub for a Web3 Marketplace

Fri, 28 Aug 2026 07:40:06 +0000

Designing a Non-Custodial Multichain Wallet Hub for a Web3 Marketplace

Building a marketplace that supports cryptocurrency payments creates an architectural decision very early:

Who controls the keys?

While developing the open-source MyZubster ecosystem, I decided that the Marketplace and virtual world should be able to interact with multiple blockchain networks without turning the platform into a custodian.

The result is an experimental multichain Wallet Hub designed around four external settlement rails:

Ethereum (ETH)
Bitcoin (BTC)
Monero (XMR)
Tari

alongside MYZ, which remains a separate internal ecosystem accounting/reward layer.

The core rule: never put private keys in the application

A web application does not need a user's seed phrase to display a receiving address.

It does not need private keys to create marketplace settlement intent.

And it should not automatically gain authority over someone's cryptocurrency simply because they use the Marketplace.

The architecture therefore follows a simple boundary:

Marketplace → Settlement Intent → Public Address → User Wallet → Blockchain

The wallet owner remains responsible for signing the transaction.

The blockchain remains responsible for settlement.

The Marketplace coordinates the interaction.

Public configuration, private authorization

The frontend can receive public wallet configuration through environment variables:

REACT_APP_WALLET_ETH=
REACT_APP_WALLET_BTC=
REACT_APP_WALLET_XMR=
REACT_APP_WALLET_TARI=
These variables are intended for public receiving addresses only.

They must never contain:

seed phrases
private keys
extended private keys
wallet passwords
signing secrets

This distinction sounds obvious, but it becomes extremely important once a project starts supporting several blockchain networks.

Extending the Marketplace

The MyZubster Marketplace already supported multiple exchange modes and currencies.

The current work extends the settlement model with Bitcoin and Ethereum so listings can identify their intended rail.

Conceptually, a listing can look like this:

{
  "title": "Community gardening service",
  "price": 0.0001,
  "currency": "BTC",
  "exchangeMode": "payment"
}

But this object represents commercial intent, not proof of payment.

Creating the listing does not move Bitcoin.

Creating an order should not automatically move Bitcoin either.

Actual settlement happens independently.

Settlement is a state machine

One of the useful lessons from building this architecture is that application state and blockchain state should not be confused.

A transaction flow can be modeled as:

ORDER CREATED
      ↓
SETTLEMENT REQUESTED
      ↓
TRANSACTION AUTHORIZED
      ↓
TRANSACTION BROADCAST
      ↓
SEEN BY NETWORK
      ↓
CONFIRMED
      ↓
SETTLED

The Marketplace should only mark an external cryptocurrency payment as settled after obtaining appropriate evidence from the corresponding network.

This becomes particularly important in a multichain environment because confirmation semantics are not identical across Bitcoin, Ethereum, Monero and Tari.

The Wallet Hub

Inside MyZubster, the Wallet Hub acts as the interface between the Marketplace/virtual world and the supported settlement rails.

The intended architecture is:

                   MyZubster World
                         │
                         ▼
                    Marketplace
                         │
                         ▼
                    Wallet Hub
                  /      |      \
                 /       |       \
               ETH      BTC      XMR      TARI
                │        │        │         │
                ▼        ▼        ▼         ▼
             Network  Network  Network   Network

The important part is what is not inside that diagram:

private-key custody.

Different chains, different adapters

A multichain system should also avoid pretending every blockchain behaves like Ethereum.

A cleaner implementation uses network-specific adapters behind a common settlement interface.

Conceptually:

const settlementAdapters = {
  ETH: ethereumAdapter,
  BTC: bitcoinAdapter,
  XMR: moneroAdapter,
  TARI: tariAdapter
};

Each adapter can eventually implement operations such as:

getReceivingAddress()
validateAddress()
getTransactionStatus()
verifyPayment()

Signing can remain outside the Marketplace boundary.

This gives the application a common interface without erasing the differences between networks.

Bitcoin

Bitcoin integration can use an Electrum-based workflow for wallet/network interaction.

The important separation remains:

Marketplace
    ↓
public Bitcoin address
    ↓
external/user-controlled signing
    ↓
Bitcoin network
    ↓
confirmation verification

A transaction ID alone should not automatically mean "paid."

Confirmation status matters.

Monero

Monero requires its own integration model.

A Monero daemon and wallet RPC can provide the infrastructure needed for verification and wallet operations without exposing sensitive wallet material to the browser.

Again, the browser should never receive:

private spend key
private view key
seed
wallet password

Only the minimum information required by the application should cross the boundary.

Ethereum and Tari

ETH and Tari are exposed through the same Wallet Hub abstraction, while their network-specific adapters can evolve independently.

This is useful because the UI doesn't need to understand every protocol detail.

It only needs to understand something like:

asset
network
public destination
amount
transaction reference
status
confirmations/evidence

The backend adapter handles the chain-specific interpretation.

Security before convenience

It is tempting to build a "Pay" button that owns everything:

click
→ sign
→ send
→ confirm

That is convenient, but it dramatically changes the threat model if the server or frontend controls the keys.

For MyZubster, the safer initial architecture is deliberately less magical:

✓ public receiving addresses
✓ user-controlled authorization
✓ network-specific verification
✓ explicit settlement state
✓ separation of internal and external assets

✗ seed storage in frontend
✗ private keys in Git
✗ automatic custody
✗ assuming an order equals payment
✗ assuming a broadcast transaction equals confirmed settlement
Connecting the Marketplace to the virtual world

This work becomes more interesting because MyZubster isn't only a conventional marketplace.

The ecosystem is also experimenting with an interactive digital world containing community spaces, characters, chat, missions and other modules.

The longer-term architecture becomes:

Identity
   │
   ├── Community
   │
   ├── Missions
   │
   ├── Marketplace
   │       │
   │       └── Wallet Hub
   │              ├── ETH
   │              ├── BTC
   │              ├── XMR
   │              └── TARI
   │
   └── MyZubster World

That creates the possibility of virtual-world interactions that lead to real settlement rails while maintaining a clear security boundary.

Open-source implementation

The Wallet Hub work is being developed publicly in the MyZubster repository.

The current implementation is tracked in:

PR #811 — Connect metaverse market to multichain wallet hub

At this stage, it should be treated as active development rather than a claim of a production-ready financial system.

CI, security testing, deployment configuration and transaction-verification workflows are all part of moving from architecture to production.

What comes next

The next steps are particularly interesting from an engineering perspective:

complete CI and security validation;
finish deployment configuration for each public wallet rail;
implement network-specific transaction verification;
connect marketplace orders to settlement evidence;
define confirmation policies per network;
improve auditability without exposing sensitive wallet information;
keep internal MYZ accounting clearly separated from external cryptocurrency settlement.

The bigger lesson is simple:

Multichain doesn't have to mean multi-custodial.

A marketplace can coordinate several blockchain networks while keeping transaction authorization where it belongs:

with the wallet owner.

MyZubster is an open-source project under active development.

GitHub:
https://github.com/MyZubster-Ecosystem/myzubster

Wallet Hub implementation:
https://github.com/MyZubster-Ecosystem/myzubster/pull/811

The 40-Hour Testing Question: Where Is Your QA Team Losing a Week?

Wed, 26 Aug 2026 06:17:41 +0000

What would your QA team do with an extra 40 hours every month?

According to a 2024 Tricentis survey of more than 500 DevOps practitioners, managers, and executives, almost one-third of respondents (32%) estimated that AI-augmented DevOps tools could save their teams more than 40 hours per month. That is roughly an entire working week.

But the more interesting question isn't whether AI can save 40 hours.

It's where those 40 hours are being spent in the first place.

The real cost of automated testing isn't always running the tests

Automated testing is supposed to reduce repetitive work. Yet anyone who has managed a growing test suite knows that running the test is only one part of the process.

Tests need to be maintained when applications change. Locators break. Elements load differently. Network conditions vary. And when a test fails, someone still has to determine whether the failure points to a real product defect, an environment problem, a timing issue, or the test itself.

That investigation can take longer than the test execution.

This is the part of testing that is rarely captured by metrics such as the number of automated tests or percentage of automation coverage. A team may have thousands of automated tests and still spend a significant amount of engineering time keeping those tests reliable and understanding their failures.

The question, then, isn't simply how many tests you can automate. It's how much human effort your automation still requires.

Testing is already a major AI opportunity

The industry appears to be moving in that direction. In the same Tricentis research, 60% of respondents ranked testing as the most valuable area for AI investment across the software development lifecycle.

Teams are already applying AI to several testing activities. The survey found that 47.5% were using AI for test planning and deciding what to test, 44% for test-case generation, and 32% for analyzing test results. Another 42% of respondents said AI had made them more productive in testing and QA.

That tells us something important: the opportunity isn't limited to generating more test cases.

AI can potentially reduce the amount of manual effort required before, during, and after execution.

More tests don't automatically mean better testing

It is tempting to measure progress by test count. A larger suite appears to mean greater coverage and more confidence.

But a test suite is only valuable when its results can be trusted.

If every failure requires someone to investigate a broken locator, wait for an element that hasn't loaded, rerun an inconsistent test, search through logs, and collect evidence before anyone can understand what happened, the automation itself becomes another source of overhead.

This is why intelligent automation matters.

The goal isn't simply to execute more tests. It's to make the tests you already have easier to run, maintain, understand, and trust.

Development is getting faster. Testing cannot remain the bottleneck.

This becomes even more important as AI accelerates software development.

DORA's 2024 research found that AI adoption significantly increased individual productivity, flow, and job satisfaction. At the same time, it found negative effects on software delivery stability and throughput, reinforcing the importance of fundamentals such as small batch sizes and robust testing.

The lesson isn't that AI makes software development worse. It's that making one part of the development process faster doesn't automatically make the entire delivery process faster.

If developers can produce changes faster but QA teams still have to manually investigate every ambiguous failure, the bottleneck simply moves.

Testing has to become more efficient alongside development.

So where could those 40 hours come from?

They may not come from making test execution itself dramatically faster.

They could come from reducing everything that happens around execution: maintaining broken locators, waiting for application conditions, rerunning unreliable tests, investigating failures, and collecting the evidence needed to understand what happened.

That's where intelligent test automation can make a meaningful difference.

QAlity is built with this problem in mind. Instead of treating test execution as the entire testing workflow, QAlity brings intelligent waiting, locator healing, and execution evidence together to reduce the effort required to operate and understand automated tests.

The objective isn't to give teams another dashboard full of test results.

It's to reduce the work required to get from "the test failed" to "we know why."

The real goal of test automation

The 40-hour figure is an estimate, not a promise. But it gives teams a useful way to think about the value of AI-assisted testing.

If automation gives your team more time, what should that time be worth?

More exploratory testing. Better coverage. Stronger test strategies. More attention to performance and security. Or simply more time spent solving product problems instead of maintaining the machinery used to find them.

That's the opportunity.

The future of test automation isn't about running more tests. It's about spending less time dealing with them.

And if your QA team could get a week back every month, the better question might be:

What would you finally have time to test?

Sources

Tricentis, AI-augmented DevOps: Trends Shaping the Future, 2024. Survey of 500+ DevOps practitioners, managers, and executives.

Google Cloud DORA, Accelerate State of DevOps Report 2024.

Why Agencies Are Choosing White Label WordPress Development

Tue, 25 Aug 2026 13:09:52 +0000

You've got a client who needs a fully custom WordPress website. The deadline is tight, your in-house developers are already buried in three other projects, and hiring someone new isn't exactly a quick fix either. Sound familiar?

This is the exact moment most agency owners start rethinking how they operate. And more often than not, the answer they land on is white label WordPress development.

It's not a workaround or a shortcut. It's a smarter way to run an agency in a market where client expectations keep climbing and internal bandwidth rarely keeps pace.

What Does White Label WordPress Development Actually Mean?

In simple terms, white label WordPress development means hiring a team of WordPress specialists who build, customize, and maintain websites on your behalf, but completely under your brand name.
Your clients see your agency's logo, communicate with your team, and receive work that carries your identity. The development partner working behind the scenes stays invisible. To the client, it's entirely your work.

This model has been around for a while in different industries, but it's taken off in a big way within the agency world. And the reasons make a lot of sense once you look at what agencies are dealing with day to day.

The Real Pressure Agencies Are Facing

Growing agencies face a specific kind of challenge. They win more clients, which is great. But then comes the harder part: delivering for all of them without dropping the ball.

Hiring full-time developers feels like the obvious answer, but it comes with real costs. Salaries, benefits, onboarding time, training — it all adds up fast. And if work slows down, you're still paying that same fixed cost regardless.

That's where working with a white-label WordPress development company starts to make complete business sense. Instead of scaling your payroll, you scale your capacity. You bring in expert support when you need it and pull back when you don't. The flexibility alone is worth it for most growing agencies.

Why Agencies Are Making the Shift

It Keeps Costs Flexible

One of the biggest draws is the move from fixed costs to variable ones. You're not carrying the overhead of a full development team through slow months. You pay for what the project needs, when the project needs it. This makes budgeting more predictable and margins much easier to protect.
Access to Deep WordPress Expertise

White label WordPress teams do one thing, and they do it well. They're not splitting their attention across five different technologies. They live and breathe WordPress, from custom theme builds to plugin development to performance fixes. That specialization shows up directly in the quality of the work and the speed of delivery.

Faster Turnarounds, Happier Clients

Because these teams work within established processes and already know WordPress inside out, there's no learning curve eating into your project timelines. Work moves faster. Revisions are smoother. And your client gets their site launched on time, which is ultimately what builds long-term trust.

You Stay Focused on What You're Best At

When development is handled by a capable partner, your team can focus on strategy, client communication, and business growth. That's where your real value lies anyway. White label development lets you stop spreading yourself thin and start investing energy where it actually moves the needle.

It's Not the Same as Traditional Outsourcing

A lot of people hear "white label" and assume it's just another word for outsourcing. It's not, and the difference matters.

Traditional outsourcing is often transactional. You send a brief, someone delivers something, and you manage the gap between what you expected and what you got. Quality can be inconsistent, communication is often fragmented, and there's no real alignment with how your agency works.
White label WordPress development is built around long-term collaboration. A good white label partner adapts to your processes, follows your quality standards, respects your timelines, and treats your client relationships with the same care you do. They're not a vendor you manage from a distance. They function more like an extension of your own team.

When Does It Make the Most Sense to Go White Label?

Not every agency needs this right away, but there are clear signs it's time to make the move.
If your team is consistently stretched thin, if you're turning down projects because you don't have the development capacity, or if quality is starting to slip under the pressure of volume, those are signals worth paying attention to.

It also makes a lot of sense when you want to expand your WordPress service offering without the risk of building an entirely new internal team. Want to offer WooCommerce development or ongoing maintenance packages? A white label partner can make that possible almost immediately.

Agencies going through growth phases especially benefit here. Instead of scrambling to hire during a spike in demand, you already have a capable team ready to step in.

What to Look for in a White Label Partner

Choosing the right white label WordPress partner comes down to a few things that go beyond technical skill.

You want a team that communicates clearly, delivers consistently, and genuinely understands how agencies work. They should be comfortable operating behind the scenes without needing a lot of hand-holding. Look for proven experience, real client references, and a track record of meeting deadlines across varied project types.

Process alignment matters too. Your partner needs to slot into how your agency already works, not the other way around.

Conclusion

White label WordPress development has moved well beyond being a niche strategy. It's become a practical, proven model that agencies of all sizes are using to grow without the growing pains.

The ability to scale your capacity, protect your margins, deliver better work faster, and focus on what your agency does best — that combination is hard to argue with. For agencies that are serious about sustainable growth, white label development isn't just a nice option. It's increasingly becoming the foundation of how smart agencies operate.

Are You Using the Best Models for Your Agentic SDLC?

Sun, 23 Aug 2026 23:05:44 +0000

Picking a model on just a single factor (retail price, benchmark scores, industry hype) rarely predicts the true cost or quality of agentic development. I had a project that required an agentic development lifecycle and some free cycles, so the team ran an experiment: the same starting package (architecture and technical design docs, a product brief, an initial backlog, UX designs and mockups) through five different model combinations in GitHub Copilot. Each run planned its own work from the backlog, implemented every task it created, and tracked its consumption in AI Credits (AICs), GitHub's billing unit for Copilot usage.

All five runs completed everything they planned, yet the bill spanned 27x from cheapest to most expensive, and the model that benchmark sites measure as one of the cheapest per task produced the most expensive run of the exercise. The surprise, however, was that the combination I initially picked as the leader based on cost alone finished below the runner-up when factoring in code quality. And the most expensive, top-tier model didn't even produce the best output.

Quick findings

Cost spread. Five model combinations ran the same exercise, and all five completed everything they planned. The bill ranged from 304 to 8,185 AICs: a 27x spread, or 6.4x excluding the Auto experiment. Same work, same definition of done, wildly different cost.
Benchmarks measure their scenario, not yours. The model Artificial Analysis measures as one of the cheapest per task ($0.43) produced the most expensive run of the exercise. Benchmarks answer generalized scenarios; your prompts, context, and workflow are specific. Prove out cost and quality yourself, in your scenario.
The cost leader finished below the runner-up on quality. The most cost-efficient serious run (GPT-5.6 Sol + Terra, 1,283 AICs) looked like the winner on cost and visual output, but code quality measures scored it below the runner-up (Grok 4.5, 2,277 AICs): 18 of 35 versus 27 of 35. That code quality could come back later in re-work and maintenance costs.
Auto trades control for a discount. The Auto run was the cheapest and fastest of the exercise (304 AICs, about 14 minutes) and produced the weakest output by far, confirmed by both the review scores and the linter (14 errors where every other run had zero). Auto promises the lowest cost plus a 10% discount, but you give up all control and blindly trust the vendor and their router. The 10% discount likely costs you 10% more.

The setup

Every run started from the same package: architecture and technical design documents, a product brief, an initial backlog, and UX designs with mockups. Each run worked from a fresh branch, and issue tracking lived in local files so the tracking system itself stayed constant across runs.

Each run opened with a grilling exercise, where the agent interrogates the package to ground its understanding before writing anything. The architecture grilling had already happened ahead of this exercise, so cross-cutting concerns like concurrency, testing standards, and platform choices were generally resolved. What remained was product and feature understanding, plus the technical details specific to each feature: field lengths, validation rules on a form, that class of question. From the grilling, each run wrote a spec and broke the work into implementation tasks. This was all done in one session to maintain context fidelity and efficiency. That closed the planning phase.

Implementation meant working through the run's own task list until every task was marked complete; that was the definition of done for every run. Models could be switched between phases or mid-implementation, which is where the combinations come in. We tracked consumption in AICs throughout, recorded by hand or self-reported by the harness at the end of each session.

The team split the runs between us: the Grok and mixed-model runs, Opus 5, GPT Sol + Terra, and Auto.

The contenders

Five combinations made it into the exercise. Reasoning effort is listed per model because it moves both the bill and the output.

Run	Planning	Implementation
Mixed	Claude Opus 4.8 (medium)	Claude Sonnet 4.6 (medium), then Gemini 3.5 Flash (high)
Grok	Grok 4.5 (high)	Grok 4.5 (high)
Opus 5	Claude Opus 5 (low, 1M context)	Claude Opus 5 (low, 1M context)
GPT Sol + Terra	GPT-5.6 Sol (medium)	GPT-5.6 Terra (medium)
Auto	Auto model selection	Auto model selection

The mixed run was supposed to be Opus planning with Sonnet implementation. Partway through I accidentally switched to Gemini 3.5 Flash and didn't notice for several sessions, which turned it into an accidental three-model comparison. Whoops.
The Grok run earned its slot: Grok 4.5 had already put up Opus-class results at a fraction of the price in my own Ship Bench comparison, so it ran single-model at high effort for everything.
The Opus 5 run put the flagship at its cheapest setting: low effort, with the 1M context window.
The GPT run chased the Artificial Analysis cost-per-task numbers and the industry hype around GPT token efficiency: Sol for planning, Terra for implementation. The efficiency hype held up, at least on the bill.
The Auto run handed model selection to the vendor. Auto promises the lowest cost and a 10% discount; we wanted to see what that promise actually delivers.

The runs

The table first, then the color. Costs are split by phase; wall clock is as captured, with one honest gap. After the runs, I had every output reviewed: static analysis with a pinned toolchain, plus an independent reviewer pass scoring seven quality dimensions out of 35, scoped to what the exercise required.

Run	Planning	Implementation	Total AICs	Wall clock
GPT Sol + Terra	319	964	1,283	~47 min
Grok	249	2,028	2,277	~237 min
Mixed	622	3,756	4,378	not captured
Opus 5	590	7,595	8,185	~127 min
Auto	48	256	304	~14 min

Auto ran last and carries the least weight, so it anchors the table despite being the cheapest row. The Mixed run's wall clock wasn't captured.

GPT Sol + Terra (1,283 AICs, about 47 minutes). The cheapest serious run, and the fastest of them by a wide margin; the GPT models were noticeably quick throughout. It looked like the winner early: a low bill, and visual output that matched the designs once the planning instructions told it to adhere to them (before that fix, the visuals lagged Grok's). The review pass was less kind: 18 of 35, with the client logic concentrated in one large component and thin architecture overall. Cheap, fast, pretty. The code needs more discipline, the kind our SDLC would normally enforce by putting quality tooling early in the process.

Grok (2,277 AICs, about four hours). The runner-up on cost and the quality leader: 27 of 35 on the review, with the cleanest architecture of the five. It adhered the strongest to the visual designs, especially once the updated planning instructions were in place. Two caveats on the experience. It felt slow: tokens trickled compared to running the same model through Grok Build, though throughput numbers like these are easily skewed by provider capacity and can vary wildly. And it exposed a process gap when I forgot to start Docker: agents should confirm their tooling and environment before starting. Its first move was writing its own monorepo launch script, which set the tone for a run that followed instructions incredibly well.

Mixed (4,378 AICs). The accidental three-model run. Opus planning was the most expensive planning of the exercise (622 AICs; the grilling alone cost 350, against Grok's 175 for a longer conversation). In implementation, the Sonnet sessions averaged 789 AICs against Gemini Flash's 348, though sessions aren't equal units of work and effort settings differed, so read that as directional. The run's real failure was process: the tickets never linked back to the UI designs, the visuals drifted, and a separate 783-AIC review pass (not counted above) was needed to bring it back. It also accumulated the most dependency surface, showing up as 11 vulnerable npm packages at scan time where every other run carried little beyond the one CVE they all inherited. Mid-pack on review at 24 of 35, on the biggest codebase of the five.

Opus 5 (8,185 AICs, about 127 minutes). The most expensive run by nearly double, and the one the benchmark tables missed hardest: Artificial Analysis measures Opus 5 at low effort as one of the cheapest models per task ($0.43, despite its higher retail price), largely on output efficiency. In a real agentic workflow with a 1M context window, it burned more than any other run; the scaffold ticket alone cost 1,855 AICs. It also shipped the only build that doesn't restore end to end: its own warnings-as-errors policy escalated a dependency vulnerability warning into a build error, and no one ran a full solution build to catch it. Discounting the build and restore issues, the review score tied Grok's at 27 of 35, and it came closest to the designs without any instruction help, which says something about its reasoning. But the build has to work.

Auto (304 AICs, about 14 minutes). Cheapest and fastest, and weakest by far: generic browser dialogs for delete confirmations, 14 lint errors where every other run had zero, 17 of 35 on the review. It completed everything it planned, which is worth saying. What it produced just isn't anything you'd ship.

What the benchmarks said

For an external reference point, here is what Artificial Analysis measured for these models (Intelligence Index v4.1.1, retrieved August 2026). These are API list-price benchmarks, not Copilot credits; the units don't convert, which is part of the point.

Model (effort)	Intelligence Index	Cost per task
GPT-5.6 Sol (medium)	56	$0.37
Grok 4.5 (high)	54	$0.31
Claude Opus 5 (low)	52	$0.43
Gemini 3.5 Flash (high)	52	$0.69
Claude Sonnet 4.6*	48	$1.22
GPT-5.6 Terra (medium)	47	$0.12
Claude Opus 4.8*	57	$2.03

Benchmarked at max effort; our runs used medium. Auto has no benchmark entry, which tells you something on its own.

Two things stand out. The Opus 5 row is the exercise's reason to exist: benchmarked among the cheapest per task despite its premium retail price, it produced the most expensive run we had. And Terra, the cheapest per task on the board at $0.12, sits off the value frontier even in Artificial Analysis's own GPT-5.6 breakdown, which found Sol and Luna ahead of Terra at every effort level. Cheapest per task is not the same as best value. Benchmarks measure their scenario; the only cost and quality numbers that matter are the ones you prove out in yours.

What changes after running this

Test your own hypothesis. The benchmark tables got us to a shortlist and nothing further. If a benchmark's scenario is fixing bugs in a public repo and your scenario is building features from a design package, the numbers won't transfer. The only cost and quality figures that matter are the ones from your own process, your own prompts, your own codebase.

Discipline beats model choice. Every serious run completed everything it planned. What separated the good outcomes from the expensive ones wasn't the model card, it was the agentic SDLC around it: grounding the product understanding before writing code, instructions that actually carry the design intent, and quality tooling early enough to catch what the agent won't. With that in place, a variety of models can get you to success. The bill and the polish will vary; the outcome doesn't have to.

The archetypes rotate. Today's nicely balanced models (Grok), efficiency kings (the GPTs), and one-shot wonders (Opus 5, and really Claude Fable 5) won't be holding those titles next quarter. The lineup we ran here will be legacy by the time some readers find this article. Which is the actual takeaway: get into the habit of evaluating for yourself, because you'll be doing it again soon.

The benchmarks will get you to a shortlist. Your own runs tell you the truth.

What Should a Developer Learn When AI Can Write Code?

Sat, 22 Aug 2026 17:27:48 +0000

For decades, learning to code meant learning how to write code.

You learned syntax.
You memorized APIs.
You practiced algorithms.
You built projects.
You learned frameworks.

But AI has changed one fundamental part of that equation.

Writing code is becoming cheaper.

AI can generate a React component in seconds. It can write a REST API, explain an unfamiliar codebase, generate SQL queries, Dockerfiles, Terraform configurations, tests, and even entire applications.

So a natural question emerges:

If AI can write the code, what should developers actually learn?

The answer isn't less programming.

It's more engineering.

1. Learn to Understand Systems

AI can generate a function.

It is much harder for AI to understand why that function belongs in your architecture.

A developer still needs to understand:

How services communicate
Where state lives
How data flows through a system
Where failures can occur
How systems scale
What creates technical debt
What trade-offs exist between different designs

Knowing how to write a function is useful.

Knowing where that function should exist is engineering.

2. Learn Debugging, Not Just Coding

Generated code will fail.

Sometimes spectacularly.

The important skill isn't being able to ask:

"Can you fix this error?"

It's being able to ask:

"What is actually causing this behavior?"

Good developers develop hypotheses.

They inspect logs.

They reproduce problems.

They isolate variables.

They trace execution.

They understand error messages.

They verify assumptions.

AI can accelerate this process enormously—but you still need to know what to investigate.

3. Learn to Read Code

This may become more important than writing code.

When AI generates 500 lines of code, somebody has to determine whether those 500 lines are:

Correct
Maintainable
Secure
Unnecessarily complex
Compatible with the existing system
Performant enough
Actually solving the intended problem

The ability to read unfamiliar code quickly is becoming a superpower.

Code comprehension may become more valuable than code production.

4. Learn Computer Science Fundamentals

AI doesn't make fundamentals obsolete.

It makes them easier to apply.

You don't necessarily need to memorize every implementation detail of a hash table.

But you should understand:

Complexity
Data structures
Concurrency
Operating systems
Networking
Databases
Distributed systems
Security
Memory
Algorithms

Why?

Because when AI gives you three possible solutions, fundamentals help you recognize which one is actually appropriate.

5. Learn How to Ask Better Questions

Prompt engineering isn't about discovering the perfect magical prompt.

For developers, the more important skill is problem specification.

Instead of:

"Build authentication."

A strong developer thinks:

Who are the users?
What are the trust boundaries?
What authentication mechanism are we using?
What happens when tokens expire?
What happens if credentials are compromised?
How is authorization handled?
How do we test it?
What are the failure modes?

AI becomes dramatically more useful when you understand the problem deeply enough to specify it precisely.

6. Learn Git, Testing and CI/CD

These might sound boring compared with AI agents.

They're becoming more important.

When AI allows you to generate code at 10× the previous speed, your ability to safely integrate that code becomes a bottleneck.

That means understanding:

Git → Tests → CI → Review → Deployment → Monitoring

becomes increasingly valuable.

The future isn't:

Human writes code → AI helps.

It's increasingly:

Human defines intent → AI generates implementation → automated systems verify it → human reviews the important decisions.

7. Learn Security

This one is non-negotiable.

AI can generate insecure code very quickly.

Developers need to recognize:

Injection vulnerabilities
Authentication flaws
Authorization mistakes
Secrets exposure
Insecure dependencies
Broken access control
Supply-chain risks
Prompt injection
AI-specific attack surfaces

You don't need to become a penetration tester.

But you should be able to look at generated code and ask:

"How could someone abuse this?"

8. Learn Product Thinking

This might be the biggest shift.

AI reduces the cost of implementation.

That means choosing what to build becomes more important.

A developer who can turn:

"Users are having trouble tracking expenses."

into:

"Let's identify the actual workflow, define the smallest useful intervention, measure success, and then build it."

is far more valuable than someone who can generate 10,000 lines of code.

The future belongs to developers who understand both technology and the problem technology is solving.

9. Learn to Work With AI

Don't treat AI as a replacement for your engineering process.

Treat it as another engineering tool.

Use it to:

Explore unfamiliar repositories
Generate prototypes
Explain APIs
Write tests
Refactor code
Find edge cases
Review implementations
Generate documentation
Investigate bugs
Automate repetitive work

But maintain a simple rule:

Never outsource understanding.

If AI writes something you don't understand, you don't have working software.

You have code you haven't evaluated yet.

So What Should Developers Learn?

The skill stack is changing.

Old model

Syntax → Frameworks → Coding → Projects

Emerging model

Fundamentals → Systems Thinking → Problem Solving → AI Collaboration → Verification → Product Thinking

AI isn't making developers irrelevant.

It's raising the abstraction level.

The developer who only knows how to type code may struggle.

The developer who understands systems, trade-offs, users, security, debugging and architecture—and uses AI to amplify those skills will have an enormous advantage.

Because when everyone can generate code...

the scarce skill isn't producing code.

It's knowing what code should exist in the first place.

here’s what I’ve been up to since you last heard from me

Fri, 21 Aug 2026 10:23:54 +0000

It’s been a while since my last post here on CoderLegion, so I thought I’d give a quick update on what I’ve been up to since then.

A lot has happened. 😅

I’ve been spending the past few months building, experimenting, breaking things, fixing them, and trying to turn some of these ideas into actual products.

Here’s the short version:

🚀 Afia9jaVTU

I built Afia9jaVTU, a VTU platform focused on digital services and payments. It gave me the opportunity to work deeply with payment integrations, wallet systems, transaction flows, APIs and the realities of building financial products.

💳 ALATPay for Laravel

While working with ALATPay, I ended up building a Laravel package to make integrating ALATPay into Laravel applications easier.

That eventually became one of the projects I was particularly proud of because it wasn't just about building something for myself it was about creating something other Laravel developers could actually use.

🧰 Experimenting with Developer Tools

I've also been working on an idea for a developer tool.

It's still in the building/experimenting phase, so I don't want to reveal too much yet, but it's been an interesting exercise in thinking about developer workflows and the small problems we deal with every day.

🏢 Royal Bcode Ventures

And outside of writing code, I've been putting a lot of energy into growing Royal Bcode Ventures.

Running a technology business has been another kind of engineering altogether.

You're no longer just thinking about:

"How do I build this?"

You're also thinking:

"Who needs this?"
"How do I sell it?"
"How do I deliver it?"
"How do I support it?"
"How do I make it sustainable?"

That has probably been one of my biggest learning experiences so far.

Looking back, I realize I've gone from simply building applications to thinking much more about products, infrastructure, developer tools, open source, and business.

And honestly, I'm just getting started.

I want to start sharing more of the actual journey here again not just the finished projects, but the architecture decisions, things that broke, lessons learned, experiments, and everything in between.

So if you've been wondering what I've been doing...

I've been building. A lot. 🚀

We Forge Digital Experiences: Introducing PixelForge Studio — A New Web Development & Design Agency

Wed, 12 Aug 2026 06:04:07 +0000

Every great product starts with a simple belief: things worth having are worth building well. That belief is exactly why we started PixelForge Studio — a web development and digital design agency built for businesses that want more than just "a website." They want a digital experience that actually works.

If you're a small business owner, a startup founder, or an entrepreneur trying to build a real online presence, this article will walk you through who we are, what we do, and why we might be exactly the team you're looking for.

The Problem We Set Out to Solve

Anyone who has hired a freelancer or agency for a website knows the pain points: slow communication, generic templates, bloated WordPress themes that barely load, and "designers" who never think about conversion, speed, or user experience.

Small businesses and startups don't need another cookie-cutter website. They need a digital partner — someone who understands their brand, respects their budget, and builds something that genuinely helps them grow.

That gap is exactly what PixelForge Studio exists to close.

What Does "PixelForge" Even Mean?

The name is intentional. Forging is the process of shaping raw material into something strong, precise, and built to last — using heat, pressure, and skill. That's exactly how we approach every project.

We don't drag-and-drop templates and call it a day. We forge — carefully building every layout, every interaction, and every line of code with purpose.

Our tagline says it best: "We Forge Digital Experiences."

What We Actually Do

PixelForge Studio focuses on three core services:

1. Web Development with React.js and Tailwind CSS

Modern businesses need modern websites — fast-loading, mobile-responsive, and scalable. We build custom web applications and business websites using React.js and Tailwind CSS, two of the most powerful tools in modern front-end development. This means better performance, cleaner code, and a website that can actually grow with your business.

2. Shopify Store Development

Ready to sell online? We build clean, conversion-focused Shopify stores for businesses that want a reliable e-commerce presence without the complexity of a fully custom build. From product pages to checkout flow, we set up stores that are fast, mobile-friendly, and easy for you to manage.

3. WordPress Website Design

Not every business needs a fully custom web app. For clients who want a cost-effective, easy-to-manage solution, we design and develop professional WordPress websites that are clean, fast, and easy to update.

Why React.js and Tailwind CSS Matter for Your Business

A lot of clients ask us why we specialize in React.js and Tailwind CSS instead of just using page builders or plain HTML/CSS. Here's the short answer:

React.js allows us to build interactive, component-based websites and web apps that are fast, maintainable, and easy to scale as your business grows.
Tailwind CSS lets us design pixel-perfect, fully custom interfaces without the bloated CSS that slows down traditional websites.

Together, these tools let us deliver websites that load faster, rank better on search engines, and feel noticeably more polished than template-based alternatives.

Our Approach: Craftsmanship Over Templates

We believe there's a difference between a website that exists and a website that works. Our approach is built on three principles:

Precision — Every detail matters, from load speed to spacing.
Purpose — Every design decision should serve a business goal, not just look pretty.
Partnership — We treat client projects like our own, not just another ticket to close.

We're not corporate-boring, and we're not "just another freelancer" either. We're confident, modern, and not afraid to make bold design choices when the project calls for it.

Who We Work With

PixelForge Studio is built for:

Small businesses looking to establish or upgrade their professional online presence
Startups that need a fast, modern, and scalable web solution to launch or grow
Entrepreneurs who want a strong digital identity that reflects their brand seriously

Right now, we're connecting with clients primarily through Fiverr, Instagram, and Facebook — so if you're active on any of those platforms, you can follow our work, see real project examples, and reach out directly.

Built in Dera Ismail Khan, Serving Clients Worldwide

PixelForge Studio is proudly based in Dera Ismail Khan, Pakistan — and we believe great work isn't defined by location, it's defined by skill, consistency, and communication. Whether our client is local or on the other side of the world, our commitment stays the same: clear communication, quality execution, and on-time delivery.

Pakistan's tech and freelance talent pool is growing fast, and we're proud to be part of that movement — building world-class digital products from right here at home.

What's Next for PixelForge Studio

This is just the beginning. In the coming months, we're focused on:

Expanding our portfolio with real client projects and case studies
Showcasing our expertise in React.js and Tailwind CSS development
Sharing regular content on Instagram and Facebook — design tips, behind-the-scenes process, and client results
Strengthening our presence on Fiverr to reach more businesses that need reliable web development partners

Let's Build Something Worth Forging

If you're a small business owner ready to upgrade your website, a startup founder preparing to launch your MVP, or simply someone who wants a digital identity that actually reflects your brand's quality — PixelForge Studio is ready to help.

We don't just build websites. We forge digital experiences designed to perform.

Have a project in mind? Reach out to us on Fiverr, Upwork, Instagram, or Facebook — let's talk about how we can bring your idea to life.

📌 Explore our profiles and contact details: PixelForge Studio

PixelForge Studio — We Forge Digital Experiences.

Developmet Rant

Fri, 31 Jul 2026 20:35:35 +0000

As a lot of you know, I am not a developer, nor will i ever claim to be one, but I have been Vibe coding a lot lately and the one thing i now understand is how when you go to do one chage it sprials to a whole other subset of problems that you spend a week on trying to fix before you can even implement the change you wanted to in the first place.

Now i have created 4 subagents and after code change and update they all audirt different pieces, pipeline, design, security, and secrets, and maybe this is just me being over zealous and wanting thisgs to be good (not perfect) becuase as an engineer i see the upstream and downstream of this form my lens and need to make sure i dont break anthing in either direction so audits are needed.

But why cant what you think is a simple change take you two weeks and still be at the same spot you started at but with a lot more work.

Is it becuase I dont know what i am doing or something else?

Heisenbugs

Tue, 28 Jul 2026 16:39:58 +0000

This story is about the illusion we face when it comes to facing certain types of bugs, you look at it now it’s in one form, you check back and it’s changed completely so you end up like an idiot in front of the whole team.

build, extract, refactor

Tue, 28 Jul 2026 12:05:50 +0000

Towards the midpoint of last year, I rediscovered one of the developers I found when I started my journey - Mark Tellez. I'll admit, back then I was arrogant and didn't take what he was doing in those old videos seriously, and then he just went off the map.

In his livestreams he'd work on either client work or a suggestion from the chat. In everything he made he kept repeating these words: ''build, extract, refactor"

He didn't just say them, no. He'd say them and explain to us what they meant in real time...

build, extract, refactor

As developers we tend to rush to componentise things from the onset - sometimes when it's not necessary. This is what build, extract, refactor is meant to address

build

Mark says just build it. Wherever you are in your project, build it. Make it work, don't worry about structure. Your first and most important job is to have it built and working.

extract

As you're building, you're going to get to a point where things become too unruly. By this point, you should have noticed a structure forming all on its own - you didn't have to pre-emptively create one.

It is at this point you then start creating your components using the structure that has presented itself.

refactor

After you have taken the lead from your project and created your components, then comes the time to refactor them.

"Don't force it, the structure will reveal itself"
~ Mark Tellez

Why build, extract, refactor?

Now you could be asking yourself; "Why bother doing this? The way I've been making components works just fine"

You wouldn't be wrong asking those questions at all.

But riddle me this; Have you ever been working on a project and you encounter an error that you can't seem to figure out where exactly it's originating from? Only for you to discover it's from a file you componentised a while ago.

You could have avoided this by employing some elements of build, extract, refactor as you will have utilised the intrinsic structure of the project and not a pre-imposed one. Because you have let the project decide, things will have connected logically and tracing of errors is not as difficult.

Conclusion

Now I am not saying this is the be all end all way of building/structuring your projects, no. I am just presenting something you could consider...

Mark wasn't available for the start of this year, he had family responsibilities to handle, I am grateful for all the knowledge he imparted on me the past few months.

To this day, I have not come across a developer who will answer your questions in real-time as he's showing why one method is better than the other. One who will take a suggestion and build that suggestion as you watch.

Thank you Mark.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Polywork and LinkedIn

Why Every Shopify Store Needs the Right Growth Strategy

Tue, 28 Jul 2026 07:09:15 +0000

Introduction

Running a successful Shopify store requires more than simply adding products and launching a website. Today's online shoppers expect fast-loading pages, simple navigation, secure checkout, and an excellent user experience. Businesses that continuously improve their online stores are more likely to attract customers, build trust, and increase sales over time.

Build a Strong Online Store

A professionally designed website creates the first impression of your business. Investing in Shopify Website Development allows businesses to create responsive, visually appealing, and conversion-focused stores that perform well across desktops, tablets, and mobile devices. Custom functionality, optimized product pages, and seamless navigation all contribute to a better shopping experience.

Improve Organic Visibility

Even the best-designed online store needs visitors. Shopify SEO Services help businesses improve search engine rankings through technical optimization, keyword research, content improvements, image optimization, and better website architecture. A strong SEO strategy increases qualified organic traffic and helps customers discover your products when searching online.

Keep Your Store Running Smoothly

Regular updates are essential for maintaining website performance and security. Shopify Maintenance Services include theme updates, app management, bug fixes, security monitoring, performance optimization, and regular backups. Ongoing maintenance reduces technical issues, minimizes downtime, and ensures your online store continues to operate efficiently.

Focus on Customer Experience

Customer satisfaction plays an important role in eCommerce success. Fast page loading, easy navigation, secure payment processing, and a smooth checkout experience encourage visitors to stay longer and complete their purchases. Small improvements to usability can have a significant impact on conversion rates and repeat customers.

Adapt to Business Growth

As your business expands, your website should grow with it. Adding new features, integrating business tools, improving website functionality, and optimizing performance help your Shopify store meet changing customer expectations while supporting future growth.

Measure and Improve Performance

Monitoring website traffic, customer behavior, and sales performance helps identify areas for improvement. Regular analysis allows businesses to refine their online strategy, improve user engagement, and maximize the return on their digital investment.

Conclusion

Building a successful Shopify business requires continuous improvement rather than a one-time setup. A combination of professional website development, strategic search optimization, and regular maintenance creates a reliable, high-performing online store that supports sustainable business growth, improves customer satisfaction, and delivers long-term eCommerce success.

The Math Behind Neural Networks, Explained Like Nobody Did for Me

Sat, 25 Jul 2026 00:02:30 +0000

A calm, sequential guide for anyone entering the field. The article is divided into smaller chapters to make it easier to understand.

Deep learning can feel overwhelming at first. You encounter words like gradient, derivative, loss function, activation, and backpropagation, and it is rarely clear how they relate to each other or where they come from. This article builds the full picture from the ground up, starting from the simplest idea in mathematics, slope, and showing how that single idea grows into everything that powers a modern neural network. No step is skipped, and no formula appears without explanation.

By the end of Part 1.1, three concepts — slope, regression, and error — will form one continuous idea in your mind. You will understand what slope is and why it matters, what linear regression is trying to do, and what the error function measures. Part 1.2 then continues the journey with the derivative and gradient descent, the tools that turn a measurement of error into an actual improvement. Part 2 goes further still, introducing activation functions, multiple layers, and backpropagation, showing how everything here scales into deep networks.

Chapter 1: Slope — The Foundation of Everything

What Is Slope?

Slope answers one question: how much does the output change when the input changes?

If you drive 100 kilometers in 2 hours, your speed — the rate of change of distance with respect to time — is 50 km/h. That is a slope. If a ramp rises 3 meters over a horizontal distance of 6 meters, its steepness is 3/6 = 0.5. That is also a slope.

Formally, the slope between two points (x₁, y₁) and (x₂, y₂) is defined as:

This is called rise over run. The Greek letter Δ (delta) simply means change in.

A Concrete Example

Consider these three data points:

Taking points (1, 2) and (3, 6):

The slope is 2. Every time x increases by 1, y increases by 2. The relationship is perfectly linear and described by:

In real problems, however, we do not know the slope in advance. We have to discover it from data. That discovery process is called regression.

Chapter 2: Linear Regression — Learning the Slope from Data

From Knowing the Slope to Learning It
In Chapter 1 we had three neat data points that fell perfectly on a line, and we computed the slope directly with a formula. and the question this article exists to answer is how mathematics learns from data that does not fall on a clean line at all.

Real data is not like that. When you collect measurements from the world — house prices against square footage, patient weight against medication dosage, temperature against electricity demand — the points do not land on a single clean line. They scatter. No two points give you the same slope, and no formula can hand you the answer.

This is where regression begins. Instead of computing the slope from two chosen points, we ask a different question: what is the single straight line that best represents all of the scattered points at once ? That line will not pass through every point, but it will come as close as possible to all of them. Finding it means learning its slope and its vertical position from the data itself, rather than reading them off with a formula.

.....................

To read the full article, check out my blog: https://husseinmahdi.xyz/writing/math-behind-nn-1-1/
This is part of the "math-behind-neural-networks" series
Or on GoPenAI: https://blog.gopenai.com/the-math-behind-neural-networks-explained-like-nobody-did-for-me-cda519ef63e8

Technical Debt Didn't Disappear. We Just Started Paying for It in Tokens.

Tue, 21 Jul 2026 15:15:38 +0000

One of the most common claims about LLMs and AI agents is that they'll dramatically reduce the cost of software development. Instead of hiring more engineers, you can simply assign a task to a model and have it completed in minutes.

I think there's a lot of truth to that.

But there's one important caveat.

How technical debt used to scale

For years, the growth pattern of many large software projects looked something like this:

Technical debt → slower development → larger engineering teams → more
communication overhead → more regressions → even more technical debt.

As systems became more complex, companies hired more engineers. But every additional team increased coordination costs, introduced more communication paths, and gradually slowed development.

Technical debt never disappeared.

Companies simply paid for it with more people.

What changed with LLMs

LLMs don't eliminate the problem.

They change the price of one of the resources.

Instead of hiring five more engineers, a company can now "hire" thousands of times more compute.

When a model struggles, we increase the context window, add more agent loops, switch to a larger model, or simply regenerate the solution multiple times.

This can preserve development velocity – for a while.

But the underlying problem remains.

LLMs don't reduce system complexity.

I'd put it this way:

We used to pay technical debt with people. Now we can pay for it with
tokens. The debt hasn't gone away – it has simply changed currency.

Why development still gets more expensive

Several factors push us toward the same outcome.

Context becomes increasingly expensive

As projects grow, models need more files, dependencies, business rules, and historical context to make correct changes.

Eventually, the cost of solving a task isn't driven by the task itself.

It's driven by the cost of understanding the system.

Understanding becomes harder

LLMs perform remarkably well in clean, well-structured codebases. But do many enterprise systems really meet these standards?

When a project is full of massive services, circular dependencies, hidden side effects, and years of architectural compromises, the model has to spend far more computation simply figuring out what's happening.

At the same time, the probability of mistakes increases.

Verification becomes the bottleneck

Even if code is generated in seconds, it still has to be reviewed, tested, and safely integrated. If the architecture is poor, the cost of verification starts growing faster than the speed of generation.

That's why generating code faster doesn't automatically mean shipping software faster.

Regressions don't disappear

If a system lacks modularity and strong test coverage, AI can introduce regressions even faster than humans.

The reason is simple. It produces much more code per unit of time.

The more changes you make to a complex system, the greater the chance that something breaks.

Why the problem is harder to notice

This is where the AI era differs from previous generations.

Before, companies were constrained by hiring budgets and the number of available engineers.

Today, the constraint is less visible.

Instead of expanding the team, organizations gradually increase spending on inference, larger context windows, agent loops, repeated generations, automated testing, and additional validation.

From the outside, productivity appears to remain high. In reality, the cost of each additional feature quietly increases.

The problem hasn't disappeared. It's simply better disguised.

The real scarcity in the AI era

The most interesting conclusion has little to do with token costs.

The real scarce resource isn't code generation.

It's architectural entropy.

LLMs scale code production incredibly well.

They do very little to reduce the complexity of the system itself.

And once a system becomes too complex for humans to understand, it gradually becomes too complex for AI as well.

That's when the cost of every new change starts growing – not linearly, but exponentially.

At that point, it doesn't matter whether you're measuring costs in developer salaries or millions of burned tokens.

A possible law of the AI era

I'd summarize it like this:

Any technical debt that once required linear growth in engineering
headcount will now first require linear growth in token consumption –
and eventually lead to the same outcome: an exponential increase in
the cost of change. The only difference is that the limiting factor
shifts from the number of engineers to the amount of compute required
to understand the system.

If this hypothesis is correct, then the biggest competitive advantage in the AI era won't be generating code faster.

It will be maintaining an architecture that remains simple enough for both humans and AI to understand.

That, for MHO more than raw coding speed, may become the true bottleneck of software development over the next decade.

How Attackers Think: A Developer's Guide to Seeing Security Through an Attacker's Eyes

Sat, 18 Jul 2026 05:57:51 +0000

"Security isn't about building walls. It's about understanding how someone will try to climb over them."

Most developers build software with one person in mind: the user.

Attackers don't.

While you're thinking about user journeys, feature releases, and improving UX, attackers are asking very different questions:

Can I bypass authentication?
Can I access another user's data?
Can I manipulate API requests?
Can I make the application trust me?
What assumptions did the developers make?

One of the biggest mindset shifts a developer can make is learning to think like an attacker—not to exploit systems, but to build software that's resilient against misuse.

Let's walk through how attackers typically approach an application and, more importantly, what developers can learn from that mindset.

The Attacker's Objective

Contrary to popular belief, most attackers aren't trying to write sophisticated malware or discover movie-worthy zero-day exploits.

Most attacks have straightforward goals:

Steal data
Obtain credentials
Gain unauthorized access
Execute arbitrary code
Encrypt systems for ransom
Abuse cloud resources
Monetize compromised systems

Every action they take serves one of these objectives.

Before writing a single exploit, they spend time understanding the target.

Phase 1: Reconnaissance

Professional attackers spend far more time gathering information than exploiting vulnerabilities.

They want to answer questions such as:

Which technologies power the application?
Is it running on AWS, Azure, or Google Cloud?
Which framework versions are being used?
Which APIs are publicly accessible?
Are there staging environments exposed?
Does GitHub contain leaked credentials?
Are there forgotten subdomains?
Which employees have privileged access?

This process is known as reconnaissance.

Some common public sources include:

GitHub repositories
DNS records
Certificate Transparency logs
Search engines
Public documentation
Job postings
Technical blog posts
Public cloud storage

Attackers love information that developers accidentally expose.

A forgotten backup file or a public .env file can be worth more than an expensive exploit.

Phase 2: Mapping the Attack Surface

Once they understand the target, attackers begin identifying everything they can interact with.

Developers often think about features:

Login
Dashboard
Payments
Profile
Admin Panel

Attackers think about entry points:

Login endpoint
Password reset
Registration
API endpoints
File uploads
Webhook handlers
Admin APIs
GraphQL endpoints
Mobile APIs
Third-party integrations

Every exposed endpoint becomes a potential opportunity.

The larger the attack surface, the more opportunities exist for mistakes.

Phase 3: Testing Every Input

Attackers don't trust your validation.

Instead, they ask:

What happens if I send negative numbers?
What if I submit a 100 MB payload?
Can I upload executable files?
What if I remove required parameters?
Can I inject unexpected characters?
Does the server validate anything?

For example, while a normal user submits:

{
  "email": "alice@example.com"
}

An attacker might try:

{
  "email": "' OR 1=1 --"
}

Or:

{
  "role": "admin"
}

Or even:

{
  "price": -5000
}

Attackers aren't using the application as intended.

They're trying to discover assumptions the developers made.

Phase 4: Breaking Authentication

Authentication is usually one of the first major targets.

Attackers look for weaknesses such as:

Weak passwords
Password reuse
Credential stuffing
Brute-force attacks
Predictable reset tokens
Session fixation
Weak JWT validation
Missing Multi-Factor Authentication (MFA)

Their goal isn't always to hack passwords.

Sometimes it's much easier to steal a valid session cookie.

If authentication fails, everything behind it becomes vulnerable.

Phase 5: Exploiting Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Many applications get the first part right and the second part wrong.

Consider this API:

GET /api/users/123/profile

An attacker changes it to:

GET /api/users/124/profile

If the server returns another user's profile, you've just exposed sensitive data.

This type of vulnerability is known as Broken Object Level Authorization (BOLA) or Insecure Direct Object Reference (IDOR).

It's one of the most common API security issues.

The fix isn't hiding IDs.

The fix is verifying ownership on every request.

Phase 6: Looking Beyond the UI

Developers spend months polishing user interfaces.

Attackers usually ignore them.

Instead, they inspect network traffic.

They call APIs directly.

They modify requests.

They automate thousands of requests using scripts.

Modern applications expose functionality through APIs, making the backend the real attack surface.

This is why server-side validation is essential.

Anything enforced only in the frontend can be bypassed.

Phase 7: Chaining Small Weaknesses

Rarely does a single vulnerability lead to a catastrophic breach.

Instead, attackers combine multiple small issues.

Imagine this sequence:

Weak password

↓

Credential stuffing

↓

Account compromise

↓

Privilege escalation

↓

Cloud credential access

↓

Production database access

↓

Data exfiltration

Each individual issue might seem minor.

Together, they become devastating.

Security professionals often refer to this as an attack chain.

Breaking any link in the chain can stop the attack.

Phase 8: Targeting Misconfigurations

Hollywood loves zero-day exploits.

Reality is far less glamorous.

Many successful attacks happen because of simple configuration mistakes.

Examples include:

Public cloud storage buckets
Default administrator credentials
Debug mode enabled in production
Open databases
Overly permissive IAM roles
Secrets committed to Git
Unpatched dependencies
Exposed management consoles

These mistakes are far more common than sophisticated vulnerabilities.

Phase 9: Attacking the Cloud

Applications no longer live on a single server.

Today's infrastructure includes:

Kubernetes
Docker
AWS
Azure
Google Cloud
CI/CD pipelines
Serverless functions

Attackers increasingly focus on cloud identities instead of operating systems.

Typical targets include:

IAM roles
Temporary credentials
Metadata services
Kubernetes secrets
Service accounts
API keys

Identity has become the new security perimeter.

Phase 10: Compromising the Software Supply Chain

Your application is only one piece of your environment.

Attackers increasingly target:

Open-source packages
CI/CD pipelines
Build servers
Package repositories
Third-party libraries

A compromised dependency can affect thousands of downstream applications.

Developers should:

Regularly update dependencies
Verify package sources
Enable dependency scanning
Review build pipelines
Use Software Bill of Materials (SBOMs)

Supply chain security is now a core part of software engineering.

Phase 11: Exploiting Human Behavior

The most sophisticated firewall can't stop someone from voluntarily giving away their credentials.

Attackers frequently use:

Phishing emails
Fake login pages
Social engineering
Fake recruiters
SMS scams
Voice phishing
MFA fatigue attacks

Humans remain one of the most targeted attack vectors.

Security awareness matters just as much as secure code.

Phase 12: Maintaining Persistence

After gaining access, attackers often try to stay inside the environment.

Common persistence techniques include:

Creating hidden accounts
Installing SSH keys
Creating scheduled tasks
Registering new API tokens
Deploying backdoors
Creating OAuth applications

The longer they remain undetected, the more damage they can cause.

Phase 13: Covering Their Tracks

Professional attackers don't want defenders to know they were there.

Typical actions include:

Deleting logs
Clearing shell history
Modifying timestamps
Disabling monitoring
Blending into legitimate traffic
Removing forensic evidence

Good logging and centralized monitoring make these activities significantly harder.

How Developers Should Think

Instead of asking:

"Does this feature work?"

Ask:

What assumptions am I making?
What happens if every input is malicious?
Can users access data they shouldn't?
What if a session token leaks?
What if an attacker controls the client?
What happens if one service is compromised?
What's the blast radius?

Security is largely about questioning assumptions.

Practical Security Checklist

Before deploying an application, ask yourself:

Authentication

Is MFA enabled for privileged users?
Are passwords securely hashed?
Are login attempts rate-limited?
Are sessions invalidated on logout?

Authorization

Is every request authorized server-side?
Are object ownership checks implemented?
Are admin endpoints protected?

Input Validation

Are all inputs validated?
Are uploaded files scanned?
Are size limits enforced?
Are dangerous file types blocked?

Secrets

Are secrets stored outside source code?
Are API keys rotated regularly?
Are credentials encrypted?

Infrastructure

Are unnecessary ports closed?
Are dependencies updated?
Is debug mode disabled?
Are cloud permissions based on least privilege?

Monitoring

Are security events logged?
Are logs centralized?
Are alerts configured for suspicious behavior?
Is incident response documented?

The Biggest Lesson

The best security engineers don't think like developers.

They think like curious, persistent adversaries.

They assume:

Every input can be manipulated.
Every endpoint will be tested.
Every assumption will be challenged.
Every shortcut will eventually be discovered.

If you build software with those assumptions in mind, you'll naturally create systems that are far more resilient.

Final Thoughts

Security isn't about being paranoid.

It's about being prepared.

Attackers don't follow the happy path. They explore edge cases, unexpected inputs, forgotten configurations, and misplaced trust. By adopting that perspective during design, development, and testing, developers can identify weaknesses long before they become incidents.

You don't need to become an ethical hacker overnight. Start by asking one simple question every time you build a feature:

"If I wanted to break this, where would I start?"

That single question can transform the way you design software—and make your applications significantly more secure.

Most MCP Servers Are Not Dead. I Checked All 14,559 of Them.

Tue, 14 Jul 2026 06:38:11 +0000

You may have seen the claim that roughly half of all MCP servers are dead. It gets repeated every time the official registry comes up. I wanted a real number, so I inspected the entire official MCP registry and ran a health check against every server in it: 14,559 servers, checked on 2026-07-02, without a single API key.

The fully-dead rate is 4.1%.

Here is the complete verdict distribution:

Verdict	Count	Share
Healthy	11,582	79.6%
Degraded	2,212	15.2%
Dead	596	4.1%
Unknown	169	1.2%

So the honest summary is: about 1 in 5 servers is dead or broken in some way, and only about 1 in 25 is fully dead. That is a real quality problem, but it is nowhere near half, and the gap between the myth and the measurement matters if you build on this ecosystem.

The interesting part is where the failure hides

A single aggregate number conceals the actual structure. An MCP registry entry can point at up to three kinds of things: packages (npm, PyPI, OCI images), a source repository, and hosted remote endpoints. When I broke the failures down by layer, they were not evenly spread at all.

Packages are the reliable layer. Across npm, PyPI, and Docker Hub, only about 1% of declared packages are broken. If a server ships as a package, the artifact you install almost always still exists and resolves.

Repository links rot. 13.8% of declared GitHub repos are 404, gone, or archived. The code may live on inside a package, but the front door you would read before you trust it has fallen off.

Hosted remotes are the fragile layer. The registry declares 7,158 remote endpoints, and 13.6% of them are down. Worse, servers that declare a remote are the sickest cohort overall: 25.9% dead-or-broken and 7.5% fully dead, versus 4.1% dead across the whole registry.

That inversion was the "huh" moment for me, I expected abandoned packages would be the graveyard. They are not. The static artifacts are nearly immortal; what decays is anything that needs someone to keep a process up, a domain paid, and a TLS cert current. A hosted endpoint is a promise that renews monthly. A tarball on npm is a fact.

Two smaller findings round out the picture. On the sloppy end, 2.1% of servers publish a server.json that fails the JSON Schema it declares for itself, a pure conformance bug and trivially fixable. On the strong end, 3,719 servers complete a full MCP session with the checker: they answer initialize and return their tool list. That handshake is the strongest proof a server actually works that you can get without credentials.

Why this matters when you pick a server

The registry cannot tell you which cohort a listing belongs to. A server whose npm package installs cleanly and a server whose remote endpoint is down look identical on their registry pages. If you wire a remote MCP endpoint into an agent today, you draw from the cohort where roughly 1 in 4 is dead or broken, and nothing in the listing warns you.

One honest caveat: this is a single census with one check date, 2026-07-02. It is a snapshot, not a trend line, and it measures health and protocol conformance only. It says nothing about security or code quality.

How I checked

The census is reproducible with the tool that produced it: Akashi, a keyless MCP health checker (a single static Go binary, MIT). It reads only public signals: the MCP registry, the public GitHub API, npm, PyPI, anonymous Docker Hub, and a capability-only MCP initialize / tools/list handshake. It never authenticates to a probed server and every row in the dataset is a claim you can re-derive on your own machine:

akashi check <registry-name | github-repo-url | remote-url>

The check rolls up to one verdict, healthy, degraded, dead, or unknown, and Akashi can emit a shields.io badge stamped with the check date.

The full dataset is CC-BY at github.com/RoninForge/state-of-mcp, with a browsable index and one dated page per server at roninforge.org/data/state-of-mcp. If you maintain a server, checking your own listing is one command, and it tells you which layer to look at first.

curl -fsSL https://roninforge.org/akashi/install.sh | sh
akashi check your-server-name

Building an Anti-Proxy -Offline-First Attendance Platform with Next.js, Express & Firebase

Sat, 11 Jul 2026 03:43:18 +0000

Traditional attendance systems seem simple until you look at how they work in practice. Manual roll calls consume valuable class time, paper attendance sheets are inefficient, and many QR-based systems can still be exploited through proxy attendance.

I wanted to explore whether a better solution was possible.

This project is my attempt at designing and building an offline-first anti-proxy attendance platform from scratch as a solo developer. The goal wasn't just to digitize attendance, but to create a system that remains reliable in real-world environments while prioritizing security, scalability, and a smooth user experience.

The platform is built using Next.js 16, React 19, TypeScript, Express.js, Firebase Authentication, Firestore, Firebase Admin SDK, Tailwind CSS, Capacitor, Progressive Web Apps (PWA), Sentry, and dynamic QR-based authentication.

Rather than focusing only on features, this article explores the engineering decisions behind the project: why I chose an offline-first architecture, how dynamic QR validation improves security, the reasoning behind the technology stack, the challenges I faced during development, and the lessons I learned while building a production-style application that is already being used in my college club.

The project is still evolving, and I continue to improve it whenever I have time. My aim is to keep documenting that journey by sharing not only what works, but also the mistakes, trade-offs, and architectural decisions that shaped the system.

If you're interested in full-stack development, system design, Next.js, Firebase, TypeScript, or building software that solves practical problems, I hope you'll find something valuable in this article.

⭐ GitHub: https://github.com/siddarthpatelkama

LinkedIn: https://www.linkedin.com/in/siddarthpatelkama

I'm always open to feedback, suggestions, and discussions with fellow developers. If you have ideas for improving the project or questions about the implementation, I'd love to hear from you.

Effective Logging in Go: Best Practices and Implementation Guide

Wed, 08 Jul 2026 15:58:17 +0000

Introduction

Logging is an essential part of software development, allowing developers to debug applications, monitor performance, and trace issues efficiently. In Go, logging plays a crucial role in building scalable and maintainable applications.

In this blog, you’ll learn about:

The importance of logging in Go
How developers use it for debugging, monitoring, and auditing
Different ways to implement logging in Go
Performance considerations and best practices

By the end, you'll have a clear understanding of how to set up an efficient logging system in your Go applications.

Why Logging Matters in Go?

Logging is more than just printing messages to the console. It serves multiple purposes:

1. Debugging & Troubleshooting

Logs help identify bugs, errors, and unexpected behavior in an application.
Example: If an API request fails, logs can show request parameters, error codes, and stack traces for debugging.

2. Application Monitoring & Performance Tracking

Logs provide insights into execution time, memory usage, and request handling.
Helps in profiling slow functions and optimizing performance.

3. Security & Audit Logs

Tracks user actions (e.g., login attempts, database changes).
Helps detect unauthorized access or suspicious activities.

4. Distributed Systems & Microservices Logging

In microservices, logs are crucial for tracking requests across services.
Helps in tracing failures in distributed systems.

5. Compliance & Legal Requirements

Many industries require logging for compliance with GDPR, HIPAA, or ISO standards.

Logging in Go: Different Approaches

Go provides multiple ways to implement logging, ranging from built-in packages to third-party logging libraries.

1. Using the Standard log Package

Go’s built-in log package is simple but lacks advanced features like structured logging and log levels.

Basic Example:

package main

import (
	"log"
)

func main() {
	log.Println("This is a simple log message")
	log.Fatal("This is a fatal error") // Terminates the program
}

log.Println() → Prints a log message
log.Fatal() → Logs message and exits the program

Limitations:

No log levels (e.g., DEBUG, INFO, WARN, ERROR)
No structured logging
Not ideal for large applications

2. Using log.Logger for More Control

The log.Logger type allows custom configurations like output destinations.

Example: Custom Logger with File Output

package main

import (
	"log"
	"os"
)

func main() {
	file, err := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)
	if err != nil {
		log.Fatal(err)
	}
	logger := log.New(file, "INFO: ", log.Ldate|log.Ltime|log.Lshortfile)
	logger.Println("Application started successfully")
}

Advantages:

✅ Logs to a file instead of the console
✅ Customizable log prefix and timestamp

3.Using log/slog for Structured Logging (Recommended for Modern Go Apps)

Go 1.21 introduced slog, a structured logging package that enhances readability and performance.

Example: Using slog for JSON Logs

package main

import (
	"log/slog"
	"os"
)

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
	logger.Info("Application started", slog.String("env", "production"), slog.Int("port", 8080))
}

Why slog?

✅ Structured JSON logs for better processing
✅ Log levels (Info, Warn, Error, Debug)
✅ Custom attributes for better context

4. Using Third-Party Logging Libraries (logrus, zap, zerolog)

For production-grade applications, third-party libraries offer performance optimizations and better flexibility.

Example: Logging with logrus

package main

import (
	"github.com/sirupsen/logrus"
)

func main() {
	log := logrus.New()
	log.SetFormatter(&logrus.JSONFormatter{})
	log.WithFields(logrus.Fields{
		"module": "main",
		"status": "running",
	}).Info("Application started")
}

Why logrus?

✅ Formatted logs (JSON, text)
✅ Log levels & hooks for integrations
✅ Performance optimized

Example: Fast Logging with zap (High Performance)

package main

import (
	"go.uber.org/zap"
)

func main() {
	logger, _ := zap.NewProduction()
	defer logger.Sync()

	logger.Info("Application started", zap.String("env", "production"), zap.Int("port", 8080))
}

Why zap?

✅ Extremely fast (zero-allocation logger)
✅ Ideal for high-performance applications

Best Practices for Efficient Logging in Go

1️⃣ Use Log Levels: Always categorize logs into DEBUG, INFO, WARN, ERROR, FATAL.
2️⃣ Avoid Logging Sensitive Data: Exclude passwords, tokens, and personal data.
3️⃣ Use Structured Logging: JSON logs are machine-readable and easy to process.
4️⃣ Rotate Logs: Use tools like logrotate or Lumberjack to prevent log files from growing too large.
5️⃣ Use Context in Logs: Add request IDs, timestamps, and service names for debugging distributed systems.
6️⃣ Optimize for Performance: Use asynchronous logging if high throughput is required.

Additional Tip: Best Practice for Passing a Logger as a Parameter

When passing a logger into a function, it’s best to place it as the last parameter. This makes it optional when possible and ensures that the most critical parameters come first.

For example, instead of this:
func ProcessData(logger *log.Logger, data string) { ... }
Do this:
func ProcessData(data string, logger *log.Logger) { ... }

Conclusion:

Logging is an essential part of maintaining, debugging, and scaling Go applications. Whether you use the built-in log package or a structured logging library like slog, logrus, or zap, choosing the right approach can greatly impact your application's performance and maintainability.

What logging practices do you follow in your Go projects? Do you have a preferred logging library? Drop a comment below—I’d love to hear your thoughts!

Devs my hat is off to you

Sun, 05 Jul 2026 15:59:29 +0000

I am not a developer in any way and will never claim to be, I am a systems engineer and that's what I accel at.

Developers and programmers deserve huge respect for all they do!

Over the past few months I have been vibe coding (or plain language coding) and I already had an appreciation for what you do, but after spending hours vibe coding it's tiring.

But I don't vibe code like some that you see, I have a full on conversation with Claude before hand and really flesh out all of the details and foundation, the. Only once I have fleshed everything out I have Claude give me the exact prompt that it would follow to complete what I am doing. Probably the wrong way, but having this convo for a couple hours to dial everything in, works best for me.

If you are in the same boat, how do you approach things?

The modern developer's toolkit — Git, GitHub & Docker

Sun, 05 Jul 2026 04:13:14 +0000

A clean, complete guide to version control, collaboration, and containerization. Commands, workflows, and concepts — all in one place.

Cheat sheet — all essential commands

                                                  **Git**

git init Initialize a new repo
git clone Clone a remote repo locally
git status Show working tree status
git add . Stage all changes
git commit -m Commit staged changes with message
git log --oneline Compact commit history
git switch -c Create and switch to a new branch
git merge Merge branch into current
git stash Stash uncommitted changes
git stash pop Re-apply stashed changes
git revert Safely undo a commit
git tag v1.0.0 Tag the current commit

                                        **GitHub / Remote**

git remote add origin Link local repo to remote
git push -u origin main Push and set tracking branch
git pull Fetch and merge remote changes
git fetch origin Fetch without merging
gh pr create Open a pull request via CLI
gh pr list List open pull requests
gh run list View GitHub Actions runs

                                                   **Docker**

docker build -t name:tag . Build image from Dockerfile
docker run -p 8000:8000 name Run container with port mapping
docker run -d --name x name Run container in background
docker ps List running containers
docker logs -f Follow container logs
docker exec -it bash Shell into a running container
docker stop Stop a container
docker rm Remove a container
docker images List local images
docker rmi Delete an image
docker compose up -d Start all services in background
docker compose down Stop and remove all services
docker compose logs -f Follow logs for all services
docker system prune Clean up unused images/containers

That's the full toolkit.
Git tracks it. GitHub shares it. Docker ships it. Together they form the backbone of every modern production AI system.

Is Marketing Becoming the Most Important Skill for Developers?

Wed, 24 Jun 2026 20:51:03 +0000

Something I've been wondering about lately.

With AI making it easier and easier to build software, we're seeing more apps, tools, and SaaS products launched every single day. And a lot of them are technically solid.
But most of them go unnoticed.

So I started asking myself: if building is becoming accessible to almost everyone, what actually makes the difference between a product that gets traction and one that doesn't?
Is it still the quality of the code? The features? The design?
Or is it increasingly about how well you can market it, how you tell the story, reach the right audience, and make people choose your product over the others?

I'm also curious about the developer side of this. Do you think we need to develop marketing and distribution skills alongside our technical ones or is that a different role entirely?
And more broadly in 5 or 10 years, do you think the developers who thrive will be the most technically skilled, or the ones who know how to sell what they build?

Would love to hear your thoughts especially from anyone who has shipped their own product and had to figure out the marketing side. 👇

Building JetsCreative: My Experience as a Senior AI Developer Working on Production Systems

Wed, 24 Jun 2026 14:31:55 +0000

https://jetscreative.com

🔷 Post Content
Introduction

Recently, I’ve been working on JetsCreative (https://jetscreative.com) — a production-focused AI and automation system built to streamline workflows and improve how digital systems handle tasks, content, and structured operations.

As a senior AI developer focused on real production systems (not prototypes or demos), this project was another opportunity to stress-test how far LLM-based systems can go when properly engineered.

🧠 1. Real AI systems are architecture-first, not model-first

One of the earliest realizations while building JetsCreative was that the model itself is rarely the bottleneck.

What matters more:

System design and flow control
Separation of responsibilities across components
Data contracts between stages
Deterministic behavior around non-deterministic models

Without this structure, even the best models become unreliable in production.

Collaboration Opportunity – Remote Partner (Entry-Level / Non-Technical Role)

Sun, 21 Jun 2026 02:27:48 +0000

Hi there,

Hope you are doing well.

We are a small but growing software engineering team working with international clients on remote freelance platforms such as Upwork, Freelancer, and Fiverr.

We are currently looking to collaborate with a motivated individual based in Latin America who is interested in a remote, entry-level partnership role within our operations.

This is a non-technical coordination role, focused on communication and basic project support. Technical skills are optional but welcome.

🔹 Role Overview

You will support our team by helping coordinate freelance opportunities and maintaining client-facing workflows.

Your responsibilities may include:

Assisting with basic communication and coordination
Supporting organization of project information
Helping maintain structured workflows between clients and our technical team
Managing administrative aspects of project delivery (no technical execution required)

All technical development, implementation, and delivery is handled by our internal engineering team.

🔹 Important Structure
You will always retain full control of your own accounts and profiles
No access to your accounts or personal financial tools will be requested
All client work is handled transparently and collaboratively
This is a remote, flexible arrangement with minimal time commitment
🔹 Compensation
Monthly base compensation: $70 – $100
Additional performance-based bonus: 10% of project revenue generated through successful collaborations

Payments are made transparently based on agreed contributions.

🔹 Ideal Candidate

We are looking for someone who:

Has a positive and reliable communication style
Is comfortable working in remote, async environments
Is organized and detail-oriented
Wants to grow within a collaborative tech/business environment

No prior technical experience is required.

🔹 How to Apply

If this sounds interesting, feel free to reach out:

Email: Emails are not allowed
Microsoft Teams: https://teams.live.com/l/invite/FBAk3iOSJkDyS11JQ?v=g1

We are happy to share more details and answer any questions.

Looking forward to connecting.

Best regards,

The Core Ideas Behind Cloud Native Development

Fri, 19 Jun 2026 17:41:28 +0000

Building applications for the cloud isn't just about running code on someone else's servers. It's about fundamentally rethinking how we design, build, and operate software. Cloud native applications are built for the cloud from the ground up, not adapted to it afterward. This matters because it changes everything about scalability, resilience, and how fast you can deploy.

What Cloud Native Actually Means
Cloud native means your application is designed to exploit cloud infrastructure. It's not a monolithic block that runs on one server. Instead, it's a collection of loosely coupled services that can scale independently, fail gracefully, and deploy without touching other parts of the system.

Think of it like the difference between a shipping container and a truck full of individually packaged items. With cloud native, you're thinking in containers. Each service is self-contained, portable, and can be replaced or updated without stopping the whole operation.

The Core Architecture: Microservices
Instead of one massive application, you build many small services. Each one does one thing. Your user service handles authentication. Your payment service handles transactions. Your notification service sends emails. They communicate through APIs or message queues.

The advantage is obvious: if your payment service needs scaling during holiday traffic, you scale just that service. If your notification service has a bug, it doesn't take down the entire application. Different teams can work on different services independently. Deployment cycles speed up because you're not redeploying the whole system for a single change.

Containerization: Consistency Across Environments
Every service runs in a container. A container packages your code, its dependencies, runtime, and configuration into one portable unit. Docker made this practical. You build a container image once, and it runs identically on your laptop, your testing environment, and production servers.

This solves the "works on my machine" problem. No more debugging configuration differences between environments. The container is your contract: whatever runs in your container will run the same way everywhere it's deployed.

Orchestration: Managing the Chaos
With dozens or hundreds of containers running, manually managing them is impossible. Kubernetes and similar orchestration platforms handle this. They decide which servers containers run on, handle failures by restarting crashed containers, manage networking between containers, and scale up or down based on demand.

Kubernetes is complex, but it solves hard problems. It lets you declare "I want three instances of this service" and automatically maintains that, replacing failed instances. It handles load balancing, rolling updates, and configuration management.

DevOps: Breaking Down the Silos
Cloud native requires developers and operations to work together. DevOps practices like continuous integration and continuous deployment (CI/CD) are essential. Code changes are automatically tested and deployed without manual intervention. This means faster feedback, fewer bugs making it to production, and the ability to deploy multiple times a day if needed.

Resilience and Scalability Built In
Cloud native applications expect failure. A container dies, but orchestration replaces it. A service is slow, so you add more instances. Traffic spikes, and the system automatically scales. You're not trying to prevent every failure, you're designing to recover from failures gracefully.

Scalability is automatic. If you get traffic, metrics trigger orchestration to spawn more containers. If traffic drops, excess containers shut down. You pay for what you use.

The Trade-offs
Distributed systems are harder than monoliths. Debugging is trickier. You need monitoring and logging across services. Operations becomes more complex. Your team needs to understand containerization, orchestration, and cloud infrastructure.

But the benefits are real. Faster development cycles. Independent scaling. Fault isolation. The ability to update one service without touching others. For most companies building applications that will grow and change, cloud native is the right foundation.

The cloud native ecosystem is mature now. The tools exist. The patterns are proven. The question is whether your organization is ready for the shift in thinking it requires.