We make thingsworth using.

Ethicq is a small team. We build software tools and make original films. Each tool started with a problem someone we know was hitting and could not find a tool for. We build the one we wished existed, then use it ourselves.

The method is not the product.

We are not anti-AI. Careful use of machine learning and generative systems can make a tool genuinely more useful, and some of our tools rely on it. We are skeptical of AI as a brand identity. Software that leads with "AI-powered" treats the method as if it were the product. It is not.

What matters is what the person using the tool experiences: Does it work? Is it honest about what it knows? Does it make the task easier without making the person feel like a passive passenger?

That is the standard we hold our tools to. Intelligence where it actually helps. Human judgment always. Outputs you can read and act on, not black boxes you are asked to trust.

From problems we have seen.

Every tool here started with a problem someone close to us was hitting. Not a market opportunity. Not a category we wanted to enter. A specific problem, often boring, that we kept watching go unsolved, until we decided to build the thing we wished existed.

That is the only reason any of these exist. A counselor staring at an admissions list with no real explanation behind any of the decisions. A designer who hated that the words she had worked on lived inside someone else's code. A kid stuck at Bronze with no one to ask why his solution timed out. A junior whose backhand loses shape between Friday lessons. We started from those people, not from markets.

We make documentary and short film work in the same spirit. The subjects come from people we know, things we watched go uncovered, or stories we kept wanting to point friends at. The cameras follow the same instinct as the code.

Principles that hold across every project.

01

Use the right tool

The question is never 'how do we use AI here?' It is 'what does this person actually need?' Sometimes that is machine learning. Often it is something simpler. The method should follow the problem, not the other way around.

02

Be honest about uncertainty

Good software does not overclaim. If a tool is uncertain, it should say so on the page where the answer lives, not in a footnote nobody reads. Confidence has to be earned, every screen, every time.

03

Legibility is respect

When someone uses your tool and cannot understand what it did or why, that is a failure. Every output should be explainable. Every workflow should be inspectable. Opacity is not sophistication.

04

Build only what we have needed

Each tool here came from a problem we kept watching go unsolved. We do not start one until that problem appears, and we stop when it does not anymore. Scope is a craft decision, not a business failure. Most of the value is in finishing the last 10%.

Each project here has a specific reason for existing.