Most software assumes the environment will cooperate.

Data is structured. Systems align. Inputs are known. There is time to refine. That is not the environment we work in.

The systems we build operate across data that is inconsistent, incomplete, and often in conflict. It comes from different sources, across different domains, with no guarantee that it agrees with itself.

We are not building tools to make that data look better.

We are building systems that can work with it as it is. This changes what the work looks like.


You will not be working inside a single service or optimizing a narrow layer of a stack. You will move across systems, trace how data is formed, understand why it breaks, and decide how to make it usable without stripping away the context that gives it meaning.



Some problems will look like engineering problems. Others will not. You will still be expected to solve them. There is no clean boundary between building and figuring out what is actually happening. Both matter. Both are part of the job.


We do not wait for complete requirements.

We build early versions, put them in real environments, and learn from how they behave. The feedback is often incomplete. Sometimes it is contradictory. You will have to decide what to act on and what to ignore.



This is not a process-driven environment. It is a judgment-driven one. The standard is simple.

The system has to work when someone depends on it. Not in isolation. Not under ideal conditions. In the environment it is actually used.



That requirement shapes everything. How we design. How we test. How we decide what is finished.

People who do well here tend to approach problems the same way.



They are comfortable operating without full clarity. They move forward anyway. They pay attention to what actually happens, not just what was intended. They are willing to be wrong, adjust quickly, and improve based on real feedback.



They take responsibility for outcomes, not just implementation. This is not a good fit for someone who needs tightly defined problems or prefers distance from how their work is used.

Torch was founded in Kansas City and continues to build here. We have chosen to build a team based on how people work together, not where they are located. The result is a group that operates at a high level across engineering, data, and applied AI without relying on a traditional tech hub.



We also spend time in the environments where our systems are used. You will work on problems that matter, with people who take them seriously.



We offer competitive compensation, equity, and full benefits. We provide flexibility in how work gets done.

More importantly, you will build systems that are used in real conditions and have visible impact.