What we are good at
- Reasoning about an existing codebase honestly
- Turning fuzzy intent into work that can be picked up cold
- Keeping the reasoning attached all the way to review
- Implementing well-scoped changes end to end
About
We are building one thing, for a problem we got tired of living with.
Steelax is a small company with a single product. This page explains what we are trying to do, the principles we hold while doing it, and how we work with the teams who rely on us.
Why we built it
The best thinking about a product rarely makes it into the product.
Before Steelax, we spent years on both sides of the same handoff. On the product side, writing documents that were accurate the week they were written and quietly wrong a month later. On the engineering side, receiving a one-line ticket and spending a morning reconstructing the conversation that must have produced it.
Nobody involved was doing a bad job. The work was genuinely careful. The problem was structural: the reasoning lived in a conversation, the decision lived in a document, the task lived in a tracker, and the truth lived in the code. Four systems, no thread between them, and a person doing the stitching by hand every single time.
So the same things kept happening. A spec described a flow that had been changed twice since it was written. A ticket said what to build but not what problem it solved, so the engineer solved a slightly different one. An idea got cut because nobody could remember whether the constraint behind it still applied. Each loss was small. Across a quarter, they were most of the gap between what a team meant to build and what it shipped.
We tried the obvious fixes first, the way everyone does. Better templates. Stricter definition of ready. A documentation day. They all worked for about six weeks, because they all treated it as a discipline problem. It is not. It is a continuity problem, and process cannot hold continuity that no system is holding.
What changed is that a tool can now read a codebase and a backlog and a pile of specs at the same time, and reason about them together. That makes a different kind of product possible: not a better document editor, and not a code generator bolted onto a chat box, but something that holds the thread. It answers questions about the product you actually have. It argues with the idea before it becomes a ticket. It writes the work with the reasoning still attached. And when a task is well understood, it implements it and hands you a pull request to judge.
That is the whole of Steelax. We are not trying to replace the thinking. We are trying to stop it leaking out between the tools.
Principles
Five things we will not trade away.
Every product decision we make runs into one of these eventually. Writing them down makes it harder for us to quietly drop one.
- Grounded beats fluent
- An answer that sounds right and is not grounded in your systems is worse than no answer, because it costs you the time to discover it was wrong. Steelax cites its sources and says when it cannot see something, even when that makes it look less capable.
- Disagreement is the feature
- A tool that agrees with every idea you bring it is a very expensive mirror. The value is in the moment it tells you the thing you proposed will break something you forgot about, which means we optimise for being useful rather than for being pleasant.
- Judgment stays with people
- Decisions with legal, financial, security or customer-facing consequences are flagged and handed to a person. We will keep drawing that line conservatively, and we would rather be asked why something was not automated than explain why it was.
- Your systems stay yours
- No second backlog, no migration, no export problem. Steelax writes into the tracker and the repository you already use. If you stop paying us tomorrow, everything it produced is still exactly where your team left it.
- Say the unflattering thing first
- If a plan does not fit, if a feature is not ready, if the honest answer to a security question is not yet, we say it before the contract rather than after. It costs us some deals. It costs us no customers.
How we work
Small company, narrow product, direct line.
We ship continuously and write up anything that changes behaviour. When something breaks we say what broke, what we did and what we changed so it does not happen again, with no public relations layer in between.
Support is handled by the people who build the product. There is no first line, which means the person answering your question can usually fix the thing you are asking about.
We take on integration work when customers ask for it and tell you honestly when something is not planned, rather than parking it on a roadmap where it can sit quietly for two years.
What we are not
- A project management tool or a replacement tracker
- A roadmap, portfolio or resourcing system
- An autonomous engineer that ships without review
- A general assistant that answers anything about anything
We would rather be trusted than impressive.
It would be easy to build a version of this product that always has an answer, never hedges and never flags a decision back to a person. It would demo beautifully and it would waste your time within a fortnight.
We have taken the slower route on purpose: cite the evidence, name the uncertainty, stop at the line where judgment begins. The teams we want to work with can tell the difference, and they are the ones who stay.
Tell us what keeps getting lost in your handoff.
The most useful conversations we have start with a specific thing that went wrong recently, not with a feature question.
You will talk to the teamNo handoff from a sales call to someone who knows the product.
We will tell you if it is a poor fitNot every team has the problem this product solves.
One product, no upsell pathThree plans, published prices, nothing hiding behind a demo.