DEV Community: Arg Software

Your Website Looks Fine, But What's Really Going On Behind the Scenes?

Arg Software — Mon, 19 Oct 2026 19:14:43 +0000

Your website looks great.

The design is clean. The images load. The buttons work. Everything seems fine.

But what if your visitors are waiting longer than they should? What if something is making your website less secure? Or what if it's quietly loading things nobody actually needs?

Here's the thing about websites: some of their biggest problems are the ones you can't see.

And you shouldn't need to be a developer to find them.

That's why we built Arg Architect.

It started with a question we kept asking ourselves

At ARG, we spend a lot of time looking at websites. And we kept noticing the same thing.

A website could look perfectly fine on the outside, but behind the scenes, it is a different story.

Huge images slowing everything down. Security settings that had been overlooked. Third-party tools adding unnecessary weight. Things that had been there for months, sometimes years, without anyone noticing.

Finding these problems meant jumping between different tools, interpreting complicated reports, and sometimes sending information to external services.

We kept thinking: "Why is it so difficult to get a clear picture of what's happening on a website?"

So we built something for ourselves.

Something simple, practical, and private.

Then we thought, why not let everyone use it?

Meet Arg Architect

Arg Architect is a free browser extension that gives your website a health check.

You enter a website address, run an audit, and get a report showing what's working well, what could be improved, and why it matters.

Think of it like taking your car for an inspection. Everything might feel fine while you're driving, but it's reassuring to know someone has checked what's happening under the hood.

Except this inspection is free, and it takes about two minutes to run a quick check.

It looks at eight areas of your website, including:

Security: Are there weaknesses that could put your website or visitors at risk?
Performance: Is your website making people wait unnecessarily?
Efficiency: Is it downloading more than it needs?
Accessibility: Can people with different needs use it comfortably?
AI readiness: Can AI tools understand your website and find useful information?

It also examines page structure, file sizes, and how much your website depends on external services.

And here's our favorite part: it explains problems in language people can understand.

Instead of throwing mysterious error codes at you, it tells you what's wrong, why you should care, and what can be done about it.

You can even copy a finding and send it straight to your developer as a task.

Three things we weren't willing to compromise on

While building Arg Architect, we made three decisions that mattered to us.

1. Your data stays yours.

Your audit results stay in your browser, on your device. Even the small inference model used for part of the analysis runs locally. Two optional external lookups are disabled unless you give permission.

2. It respects your privacy.

You know those annoying cookie banners?

When Arg Architect encounters one, it doesn't automatically click "Accept All." It chooses to reject optional cookies or accept only what's essential.

We thought it would be pretty ironic to build a tool that checks websites for problems while casually accepting every tracking cookie along the way.

3. It doesn't pretend to know what it doesn't know.

A website might load quickly one moment and slowly the next.

That's why Arg Architect can run multiple controlled tests and use the middle result, rather than trusting one lucky attempt.

And if something can't be measured properly, it says so. No invented results. No false reassurance.

Your website has a new kind of visitor: AI

Here's something that wasn't on most people's minds a few years ago.

Today, it's not just humans visiting websites. AI assistants and automated tools are reading them too.

People are increasingly using AI to discover businesses, research products, and compare services.

But can these tools actually understand your website?

Arg Architect checks whether your site's information is accessible and understandable to AI systems and whether important details match what your pages really say.

It won't guarantee that AI will recommend your business. But it can help you understand whether your website is making things unnecessarily difficult.

And that feels like something worth knowing.

See what actually improves

Finding a problem is useful. Knowing you've fixed it is even better.

Arg Architect saves reports locally and lets you compare audits over time.

Maybe you optimized your images, removed an unnecessary tool, or launched a redesign.

Did it help?

Now you can see what changed, compare the results, and share reports with your team.

Less guessing. More evidence.

Why are we giving it away?

Because we built it for ourselves first.

At ARG, we believe good engineering starts with understanding what's really happening, not just what things look like on the surface.

Arg Architect is a small reflection of how we work.

And yes, it's also a way to introduce people to ARG.

But we'd rather do that by sharing something genuinely useful than by writing another advertisement about how great we are.

You don't need to become a client. You don't need to sign up for anything.

Just use it.

If it helps make your website a little faster, safer, or easier to use, we're happy.

Now we're curious about your website

Here's a little challenge.

Think of a website you care about. Maybe it's your business, your online shop, or something you've spent months building.

Now ask yourself:

Do you really know what's happening behind the scenes?

There's a simple way to find out.

Install Arg Architect, enter your website address, and run a quick audit.

Start with security. You might find everything looks good. You might discover something worth fixing.

Either way, you'll know something you didn't know before.

And we'd love to hear what you find.

Try Arg Architect for free:

How to Actually Enforce Clean Architecture in TypeScript

Arg Software — Thu, 17 Sep 2026 11:28:47 +0000

You wrote the docs. You did the PR reviews. You explained it during onboarding. And yet, six months later, a bunch of controllers are directly importing a repository, and nobody noticed.

The Real Problem With Architecture

Clean Architecture, Hexagonal Architecture, layered architecture, or whatever approach you follow: the rules often exist in only two places: your head and a README nobody reads.

The moment a deadline hits, someone takes a shortcut. A controller calls a repository directly. A domain model imports a NestJS decorator. An infrastructure class leaks into the application layer.

It is not malicious. It is invisible.

Nobody gets a red light. The tests still pass. The application still ships.

Six months later, you have a codebase that looks structured but behaves like a mess.

The fix is not more pull request comments or awareness. It is making the rules enforceable.

Architecture Tests: Rules That Enforce Themselves

Architecture tests are automated tests that do not test your business logic. They test the structure of your application.

They answer questions such as:

Does anything in the domain layer import from infrastructure?
Is any controller talking directly to a repository?
Do all use cases follow the naming convention we agreed on?
Does the project contain circular dependencies?

If the answer is ever yes, the build fails. No human intervention is required.

We are going to use ArchUnitTS, an actively maintained architecture-testing library for TypeScript inspired by ArchUnit from the Java ecosystem.

npm install archunit --save-dev

Setting the Rules

Imagine you are running a NestJS application with this layered structure:

src/
  domain/         # Entities, value objects, domain errors
  application/    # Use cases, service interfaces
  infrastructure/ # Repositories, ORM, external services
  http/           # Controllers, DTOs, HTTP concerns

Here are the architectural rules you might want to enforce.

The Domain Must Not Depend on Application or Infrastructure

import { projectFiles } from 'archunit';

it('domain should not depend on application or infrastructure', async () => {
  const rule = projectFiles()
    .inFolder('src/domain')
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/application')
    .or()
    .inFolder('src/infrastructure');

  await expect(rule).toPassAsync();
});

Controllers Must Not Import Repositories Directly

it('controllers should not import repositories directly', async () => {
  const rule = projectFiles()
    .inFolder('src/http')
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/infrastructure/repositories');

  await expect(rule).toPassAsync();
});

Application Must Not Depend on Infrastructure

it('application should not depend on infrastructure', async () => {
  const rule = projectFiles()
    .inFolder('src/application')
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/infrastructure');

  await expect(rule).toPassAsync();
});

Enforcing Naming Conventions

Beyond dependency direction, you can enforce the conventions your team agreed on: the ones currently living in a Notion document nobody opens.

All Use Cases Must End With `UseCase`

it('use cases must follow the naming convention', async () => {
  const rule = projectFiles()
    .inFolder('src/application/use-cases')
    .should()
    .matchPattern('*UseCase.ts');

  await expect(rule).toPassAsync();
});

Domain Interfaces Must Be Prefixed With `I`

it('domain interfaces should be prefixed with I', async () => {
  const rule = projectFiles()
    .inFolder('src/domain')
    .that()
    .areInterfaces()
    .should()
    .haveNameMatching(/^I[A-Z]/);

  await expect(rule).toPassAsync();
});

Infrastructure Interfaces Must Be Prefixed With `I`

it('infrastructure interfaces should be prefixed with I', async () => {
  const rule = projectFiles()
    .inFolder('src/infrastructure')
    .that()
    .areInterfaces()
    .should()
    .haveNameMatching(/^I[A-Z]/);

  await expect(rule).toPassAsync();
});

The Project Must Not Contain Circular Dependencies

it('should have no circular dependencies', async () => {
  const rule = projectFiles()
    .inFolder('src/**')
    .should()
    .haveNoCycles();

  await expect(rule).toPassAsync();
});

The Silent Killer Other Libraries Miss

Here is something worth knowing before selecting an architecture-testing library: a passing test that inspected zero files is worse than no test at all.

Imagine you write this rule:

const rule = projectFiles()
  .inFolder('src/doamin') // Typo: this should be "domain"
  .shouldNot()
  .dependOnFiles()
  .inFolder('src/infrastructure');

Many libraries will match zero files, perform zero checks, and report that the test passed.

Your architectural rule silently does nothing forever.

ArchUnitTS fails empty tests by default. The test will not pass until the pattern matches actual files.

It seems like a small detail, but this is exactly the kind of false confidence that causes real incidents.

Why This Changes Everything

The usual ways of enforcing architecture are expensive:

Pair programming is valuable, but it does not scale to every change.
Pull request reviews catch violations late and introduce friction.
Documentation gets ignored when deadlines approach.
Verbal agreements are forgotten by the next sprint.

Architecture tests reverse the model.

You write the rule once, and it runs on every push. A developer cannot accidentally violate a dependency rule without the CI pipeline immediately identifying the offending file.

This also makes onboarding easier.

Instead of explaining, “We do not import repositories in controllers here,” you can let the test demonstrate the rule. The tests become living documentation that remains synchronized with the codebase.

The Takeaway

Your architecture is only as strong as your ability to enforce it.

Documentation decays, memory fades, and deadline pressure is real. Architecture tests turn structural rules into executable constraints that run on every push.

Write these tests when you establish an architectural rule, include them in your CI pipeline, and stop discovering structural violations during pull request reviews months later.

How does your team enforce architectural boundaries: automated tests, lint rules, or code reviews?

Originally published on ARG Software.