DEV Community: Muhammad Masood Kausar

The Overengineering Trap We All Fall Into

Muhammad Masood Kausar — Wed, 22 Jul 2026 09:49:24 +0000

The most dangerous overengineering does not look careless.

It looks thoughtful.

It has clean interfaces, reusable components, configurable behavior, extension points, and an architecture diagram that makes the system appear ready for anything.

Then the next feature arrives.

A change that should take one afternoon touches seven layers, breaks three abstractions, and forces the team to understand a framework built for requirements that never appeared.

That is what makes overengineering difficult to recognize.

It rarely presents itself as unnecessary complexity. It presents itself as responsible engineering.

It Usually Begins With a Reasonable Fear

Developers do not overengineer because they want to make systems harder.

They usually remember an earlier project that became painful.

Maybe duplicated business logic spread across several screens. Maybe a component could not support a second use case. Maybe an integration became impossible to replace. Maybe a narrow implementation eventually required an expensive rewrite.

The next time a similar problem appears, the team tries to protect itself.

What if this feature grows?

What if another team needs it?

What if product asks for configuration?

What if we add more providers?

What if the rules change?

These are reasonable questions. The problem begins when imagined requirements receive the same architectural weight as real ones.

A single approval flow becomes a workflow engine. Two similar components become a universal rendering framework. One pricing exception becomes a configurable rules platform.

The team tries to avoid future pain and creates immediate friction instead.

The first use case now has to support requirements that do not exist. Developers must understand extension points nobody uses, configuration nobody needs, and interfaces protecting boundaries that have not appeared.

Thinking about the future is not the mistake.

Building the future before there is evidence is.

Reuse Is Expensive Before the Pattern Is Stable

Reusable code sounds like an obvious improvement.

Nobody wants five versions of the same logic. Shared behavior can reduce bugs, improve consistency, and make future changes easier.

But two pieces of code looking similar does not mean they represent the same concept.

The first abstraction usually looks clean. It removes duplication and gives the codebase a shared component, service, or helper.

Then another use case arrives.

It needs a different loading state.

The third needs different validation.

The fourth has different permissions.

Soon the reusable abstraction collects flags, callbacks, modes, configuration objects, and escape hatches.

The code is technically reusable, but changing it safely now requires understanding every consumer.

The team did not eliminate complexity. It concentrated complexity inside one shared dependency.

Sometimes a little duplication is more honest.

Duplication says, “These cases currently look similar, but we do not yet know whether they will change together.”

A premature abstraction says, “We already understand the shared concept.”

That confidence is often the expensive part.

Good abstractions usually become obvious after several real use cases expose what remains stable. Before that, reuse is often based on visual similarity rather than shared responsibility.

Architecture Should Protect Real Pressure

Architecture is valuable when it protects the system from something concrete.

A service layer may protect business rules from HTTP concerns. An adapter may isolate an unstable third-party API. A repository may centralize complex persistence behavior. A policy module may prevent authorization rules from spreading everywhere.

Those boundaries reduce meaningful pressure.

But layers added only because mature systems are expected to have layers create a different result.

A small feature gains controllers, services, repositories, mappers, interfaces, factories, validators, and adapters. Every file is small. Every class has one apparent responsibility.

Then one field changes.

The update must pass through an input type, controller, interface, service, mapper, repository, test fixture, and mock. The architecture looks organized, but ordinary changes feel like paperwork.

A layer that protects nothing is not automatically good architecture.

Sometimes it is ceremony.

Before introducing another boundary, ask what kind of change it makes cheaper.

Does it isolate something volatile?

Does it clarify ownership?

Does it prevent a failure the team has experienced?

Does it remove repeated decisions?

Does it make debugging more direct?

Without a concrete answer, the architecture may be solving developer anxiety rather than product complexity.

Flexibility Creates a Decision Tax

Flexible systems promise safety.

They can support more rules, more providers, more workflows, more rendering modes, and more future variation.

But every option introduces decisions.

Should the next requirement become another configuration field?

Should it be a new strategy?

Does it belong inside the shared abstraction?

Should the team add an escape hatch?

Which combinations are valid?

Who tests them?

Who documents them?

A system may support dozens of combinations while nobody understands which combinations are actually safe.

That is not useful flexibility.

It is uncontrolled variability.

The hidden cost is not only additional code. It is the number of architectural decisions developers must make before completing ordinary product work.

Instead of solving the requirement directly, they must first negotiate with the framework surrounding it.

The best internal systems reduce unnecessary decisions for the next developer. They make the obvious path clear and safe.

Overengineered systems make ordinary work require architectural judgment.

The Next Change Is the Real Test

A design cannot be judged only by how clean it looks when first introduced.

The real test is what happens when the requirement changes.

Can the behavior be found quickly?

Can one use case change without risking unrelated ones?

Does the abstraction explain the business concept, or hide it?

Can a developer trace a wrong value without walking through several indirection layers?

Does the architecture make the change smaller, or merely distribute it across more files?

This is where many impressive designs reveal their cost.

They were optimized for the first implementation, the code review, or an imagined future. They were not optimized for the actual changes the product eventually required.

The future often arrives, but rarely in the exact shape the original abstraction predicted.

Let Complexity Earn Its Structure

The answer is not to reject architecture, reuse, or abstraction.

Underengineering creates its own damage. Scattered rules, hidden dependencies, duplicated behavior, missing boundaries, and careless shortcuts can make a codebase equally painful.

The better rule is simpler:

Let complexity earn structure.

Build the current behavior clearly.

Keep important decisions visible.

Protect boundaries that already matter.

Avoid coupling that would make later extraction difficult.

Then wait for real use cases to reveal what is genuinely shared.

A good first version does not need to be careless. It can be readable, tested around meaningful risks, and arranged so future refactoring remains possible.

It simply does not pretend to know the final architecture before the product has supplied enough evidence.

Overengineering is not thinking about tomorrow.

It is forcing today’s work to pay for a tomorrow that still exists only in our imagination.

I explored the deeper debugging costs, decision overhead, scalability assumptions, and practical signals of premature abstraction in the complete essay:

Read the full article on Medium: The Overengineering Trap We All Fall Into

Have you worked with a future-proof design that eventually made simple changes harder?

The Node.js Shortcut That Quietly Created a Security Hole

Muhammad Masood Kausar — Tue, 21 Jul 2026 07:46:18 +0000

We verified who made the request, but never verified whether that user was allowed to access the requested resource.

The endpoint rejected unauthenticated requests, so we assumed it was secure.

It was not.

The route had authentication middleware. Invalid tokens returned 401. Expired sessions were rejected. The controller received a verified user.

Everything looked protected.

But an authenticated user could change the resource ID in the URL and access data belonging to another account.

Authentication worked exactly as expected.

Authorization was missing.

That difference came down to one condition in a database query, but in the application’s security model, it was the entire boundary.

The Route Looked Secure

The route looked like a normal protected Node.js endpoint:

router.get(
  "/documents/:documentId",
  validateAccessToken,
  attachCurrentUser,
  getDocument
);

The middleware performed all the expected work:

verified the access token
rejected invalid sessions
loaded the current user
attached the user to the request

The controller only ran after authentication succeeded.

That created a dangerous assumption:

Authenticated request = trusted request

But authenticated users should not automatically be trusted with every resource in the application.

A logged-in customer should not be able to read another customer’s invoice.

A member of one organization should not be able to access another organization’s projects.

A normal employee should not be able to approve an administrative request.

A project viewer may be allowed to read a project but not delete it.

Authentication answers one question:

Who is making this request?

Authorization answers another:

Is this user allowed to perform this action on this resource?

Identity is only an input to the authorization decision.

It is not the decision itself.

The Shortcut Was Loading Records by ID Alone

The controller accepted a resource ID from the URL:

async function getDocument(request, response) {
  const document = await documentService.findById(
    request.params.documentId
  );

  return response.json(document);
}

The service then loaded the record using only that ID:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
  },
});

This code looked clean.

It was easy to read.

It also asked the wrong question.

The query asked:

Does a document with this ID exist?

It did not ask:

Does this document belong to the current user or account?

The database had no knowledge of the security boundary.

For an account-scoped application, the query should include the account:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
    accountId: currentUser.accountId,
  },
});

For user-owned resources, it might include ownerId:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
    ownerId: currentUser.id,
  },
});

For a multi-tenant system, it might include tenantId:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
    tenantId: currentUser.tenantId,
  },
});

This is not just another database condition.

It changes the meaning of the operation.

The unsafe version means:

Find this document.

The scoped version means:

Find this document inside the boundary this user is allowed to access.

The database query should understand the security boundary, not only the resource identifier.

Why a Valid Token Made the Bug Harder to Notice

Most authentication tests verify that anonymous users are rejected:

it("rejects requests without a token", async () => {
  await request(app)
    .get("/documents/123")
    .expect(401);
});

This is useful, but it only proves that unauthenticated users cannot access the endpoint.

A positive test may verify that the owner can access the document:

it("allows the owner to access the document", async () => {
  const user = await createUser();

  const document = await createDocument({
    ownerId: user.id,
  });

  await request(app)
    .get(`/documents/${document.id}`)
    .set("Authorization", createToken(user))
    .expect(200);
});

This test also passes.

The missing scenario is the one that exposes the vulnerability:

a real user
a valid token
a real resource
the wrong owner

it("does not expose another user's document", async () => {
  const owner = await createUser();
  const otherUser = await createUser();

  const document = await createDocument({
    ownerId: owner.id,
  });

  await request(app)
    .get(`/documents/${document.id}`)
    .set("Authorization", createToken(otherUser))
    .expect(404);
});

The most valuable security test often uses a valid token belonging to the wrong user.

This type of bug can also survive code review because authentication and data access usually live in different layers:

Route
  → Middleware
    → Controller
      → Service
        → Repository

A reviewer sees the authentication middleware in the route file.

Another reviewer sees a simple findById method in the repository.

Each piece looks reasonable in isolation.

The vulnerability appears only when the complete request path is examined.

The route proves identity.

The controller accepts a client-controlled identifier.

The repository loads the resource without ownership or tenant scoping.

The response returns the result.

Each file looked secure on its own.

The security hole existed between them.

UUIDs Did Not Fix the Authorization Problem

A common response to this vulnerability is to replace sequential IDs with UUIDs.

Sequential IDs are easy to guess:

/documents/1001
/documents/1002
/documents/1003

UUIDs are much harder to enumerate:

/documents/f9a81862-0db8-4f61-b7ea-9a74d97d71b4

That can reduce predictable resource discovery.

It does not create permission.

A user may still obtain a valid identifier through:

a copied URL
browser history
logs
analytics
notifications
support tickets
screenshots
frontend state
another API response
another vulnerable endpoint

When authorization is missing, possession of the identifier becomes possession of the resource.

That is not a safe access model.

A resource ID identifies an object.

It does not grant permission to access it.

A UUID can hide the door, but it cannot replace the lock.

The Same Shortcut Affected More Than Read Endpoints

Once a service exposes a generic method like this:

findById(id: string)

it often becomes the default lookup for several endpoints:

GET    /documents/:id
PATCH  /documents/:id
DELETE /documents/:id
POST   /documents/:id/share
POST   /documents/:id/archive

The missing boundary may allow another authenticated user to:

read private data
update records
delete content
download attachments
resend invitations
trigger workflows
change ownership
modify billing information
approve restricted actions

Authorization also depends on the requested action.

A user may be allowed to read a project but not delete it.

An editor may update a draft but not publish it.

A manager may approve expenses only below a specific amount.

A support agent may view customer details but not change payment information.

A better authorization model is:

User + Action + Resource + Context = Authorization decision

Not:

Valid token = Permission granted

Nested Routes Can Create False Confidence

Nested URLs often look naturally secure:

/projects/:projectId/comments/:commentId

The route appears to say that the comment belongs to the project.

But the URL does not enforce that relationship.

A controller may verify access to the project and then load the comment using only commentId:

const comment = await commentRepository.findOne({
  where: {
    id: commentId,
  },
});

That comment could belong to another project.

The query should verify both identifiers:

const comment = await commentRepository.findOne({
  where: {
    id: commentId,
    projectId,
  },
});

The project itself must also exist inside the user’s permitted organization, account, or tenant.

A nested URL does not prove the relationship.

The data-access layer must enforce it.

The Real Fix Was Architectural

The fastest fix may be a manual ownership check:

if (document.ownerId !== currentUser.id) {
  throw new ForbiddenError();
}

That is better than no authorization.

But repeating checks manually across controllers creates another problem.

Eventually:

one endpoint forgets the check
one endpoint checks ownership but not tenancy
one endpoint applies a different role rule
one endpoint loads sensitive data before rejecting the request
one endpoint handles administrators globally instead of per organization

Authorization becomes duplicated business logic.

Duplicated security logic eventually becomes inconsistent security logic.

The stronger approach is to make authorization part of the resource-access design.

Option 1: Scoped repository methods

For simple ownership or account rules, use methods that require the security boundary:

async function findAccountDocument(
  documentId: string,
  accountId: string
) {
  return documentRepository.findOne({
    where: {
      id: documentId,
      accountId,
    },
  });
}

The method does not provide an easy way to load a document outside the current account.

Option 2: Explicit policy services

More complex permissions may need a dedicated authorization policy:

const document = await documentService.findById(documentId);

authorizationService.assertCanReadDocument({
  user: currentUser,
  document,
});

This is useful when access depends on:

ownership
roles
team membership
organization membership
resource state
sharing rules
subscription level
administrative scope

Option 3: Framework guards

In NestJS, guards can handle authentication and high-level role checks.

However, a generic role guard may not have enough information to make a resource-level decision.

Knowing that a user has the role manager does not prove that the user manages the organization that owns the requested document.

Role authorization and resource authorization often need to work together.

Option 4: Database-level isolation

Some applications use tenant-aware database clients or row-level security.

This adds another layer of protection when application code forgets a filter.

It can be powerful, but it also adds complexity. Policies must be observable, testable, and understood by the team.

There is no single authorization design for every application.

The important requirement is this:

The security boundary should be explicit, reusable, testable, and difficult to bypass accidentally.

The safest authorization check is the one the application cannot easily forget to perform.

Test Security Boundaries, Not Only Endpoints

After finding this bug, the test strategy should change.

Do not only test whether the endpoint works.

Test which identities can perform which actions.

A useful authorization matrix might look like this:

Scenario	Expected result
No token	`401`
Invalid token	`401`
Owner with valid token	Success
Different user with valid token	Rejected
User from another tenant	Rejected
User with insufficient role	Rejected
Viewer attempting deletion	Rejected
Administrator inside allowed scope	Success

Test more than reads:

create
read
update
delete
download
share
approve
archive
transfer ownership

For multi-tenant systems, create at least two tenant contexts:

Tenant A user → Tenant A resource → Allowed
Tenant A user → Tenant B resource → Rejected

For nested resources, intentionally mix identifiers:

Project A ID
+
Comment from Project B
=
Rejected

Applications should also decide whether unauthorized resource requests return 403 or 404.

A 403 response confirms that the resource exists but access is forbidden.

A 404 response can avoid revealing whether a protected resource exists.

The right choice depends on the API contract and threat model.

What matters is that the behavior is deliberate and consistent.

Partial Protection Is Still a Security Failure

The shortcut did not look reckless.

It looked like ordinary controller and repository code behind an authenticated route.

That was why it survived.

The token was valid.

The current user was known.

Anonymous requests were rejected.

The endpoint was still unsafe because the requested resource had no enforced ownership, tenant, role, or permission boundary.

The lasting fix was not a stronger token, a longer identifier, or another scattered condition.

It was making authorization part of the resource-access model and testing the application with valid users who should still be denied.

Security failures often survive because partial protection is mistaken for complete protection.

A valid token should open the application.

It should never open every record inside it.

Which authorization boundary is easiest to miss in your APIs: ownership, roles, tenant isolation, or action-specific permissions?

A Streaming-First UI Framework Built for the AI Era

Muhammad Masood Kausar — Mon, 20 Jul 2026 14:04:38 +0000

Most AI products still stream words.

But what if an AI model could stream the interface itself?

I recently explored Aktion, an ambitious open-source project created by my mentor, Asfandiyar Khan, a senior frontend engineer based in Germany.

Aktion is a streaming-first UI framework designed to turn compact, JavaScript-shaped instructions into reactive and interactive user interfaces.

Instead of producing another Markdown response or a large block of frontend code, an AI model can progressively generate:

Cards
Charts
Forms
Tables
Dashboards
Navigation
Interactive workflows

What makes Aktion different?

Traditional AI-generated frontend code often requires the model to coordinate several independent systems:

Framework syntax
Package imports
State management
Routing
Form handling
Styling
Data fetching
Component libraries
Dependency versions

Aktion takes a different approach.

It gives developers and AI agents:

A compact JavaScript-shaped reactive language
A unified UI runtime
A consistent component vocabulary
Built-in application capabilities
A framework-agnostic Web Component
Streaming support for progressively generated interfaces

The central integration point is the <aktion-app> Web Component.

Because of this approach, Aktion can be embedded inside React, Vue, Angular, Svelte, plain HTML, or another host environment without rebuilding the generated UI layer for every framework.

Why streaming-first UI matters

Most AI interfaces wait until a response is complete before presenting the final output.

Aktion is designed so completed statements can be rendered while the model is still generating the rest of the response.

A heading can appear first.

Then a chart.

Then filters, forms, cards, and interactive controls.

The AI response does not only describe an application.

It gradually becomes the application.

A smaller target for AI-generated interfaces

One of Aktion’s most interesting ideas is its constrained language.

AI models normally have enormous freedom when generating frontend applications. They must choose libraries, understand different APIs, manage imports, and connect tools that were not necessarily designed to work together.

More freedom can also create more incompatible decisions.

Aktion reduces that decision space by providing one language, one runtime, and one predictable set of interface primitives.

The important idea is not only that Aktion contains many features.

It is that AI-generated interfaces may become more dependable when models generate into a smaller and more controlled environment.

More than a component library

Aktion brings several common frontend concerns into one system, including:

Reactive state
Routing
Forms
Data fetching
Themes
Responsive styling
Charts
Realtime interfaces
Internationalization
Testing utilities
Server-side rendering
A large built-in component vocabulary

This does not automatically make it the right solution for every application.

However, it makes Aktion an interesting experiment in how frontend runtimes could evolve for generative UI.

The engineering effort behind Aktion

Building a framework is very different from building a small library.

Aktion brings together:

A language
A parser
A reactive runtime
A rendering system
A component vocabulary
Streaming behavior
Developer tooling
LLM integration
Documentation
Interactive demonstrations

It is inspiring to see my mentor transform years of frontend experience into such an ambitious open-source project.

An idea worth exploring

Aktion may still be an early project, and questions around security, runtime size, extensibility, debugging, and long-term stability deserve careful discussion.

But the architectural question behind it is important:

Should AI continue generating unrestricted frontend applications, or should we design smaller runtimes that give models a clearer and more predictable target?

The future of generative UI may not depend only on making AI models more capable.

It may also depend on designing better environments for them to generate into.

Explore the project

🌐 Visit the Aktion project homepage

💻 View Aktion on GitHub

📖 Read my complete article on Medium

Congratulations to Asfandiyar Khan on this impressive engineering effort and valuable contribution to the open-source community.

What are your thoughts on streaming-first generative UI?