Work With Us

Engineering solutions for systematic trading. Turn trading ideas into systems that can be tested, built and operated. Systematic trading involves more than finding a strategy that looks profitable. Research needs to be rigorous. Data needs to be reliable. Software needs to behave as intended. Execution, risk and monitoring need to be considered from the beginning. The challenge is connecting all these pieces into a coherent system. Capital in the Wild applies an engineering approach to systematic trading. We help traders and developers investigate problems, evaluate existing approaches and design practical solutions to the challenges of building systematic trading systems. Whether you're assessing a trading hypothesis, planning a system architecture or trying to understand why an existing implementation isn't working as expected, we can help you work through the problem methodically. Start with the problem. Engineer the solution. [Discuss your project]

What we can help with

01 — Research & Strategy Validation

Understand what your results actually demonstrate. A strategy can look compelling in a backtest and still fail to deliver in practice. Weak assumptions, overfitting, data problems, transaction costs and unrealistic execution models can all undermine the results. We help examine the research process behind a strategy, identify potential weaknesses and establish what needs to be tested before drawing stronger conclusions. This may include:

• Reviewing research methodology and backtesting assumptions.
• Examining overfitting risks and the robustness of results.
• Identifying missing costs, execution constraints or market assumptions.
• Developing a structured validation plan.
• Defining the next research steps and the evidence needed to proceed.

Best suited to: traders and researchers who have an idea, an existing strategy or a set of results they want to assess more rigorously. The outcome: a clearer understanding of the strengths, limitations and unanswered questions in your research, with a prioritised plan for further investigation. This is a research and technical review, not a guarantee that a strategy will be profitable.

02 — Trading System Architecture

Design the system before the complexity grows. A systematic trading operation brings together data, research, portfolio logic, execution, risk controls and monitoring. Decisions made early can determine how difficult the system becomes to test, maintain and operate. We help turn requirements into a coherent technical design, with clear components, responsibilities and interfaces. This may include:

• Defining system requirements and boundaries.
• Designing data and processing pipelines.
• Separating research, strategy logic, execution and monitoring.
• Identifying dependencies, failure modes and operational risks.
• Evaluating implementation options and trade-offs.
• Producing an architecture document and staged implementation plan.

Best suited to: developers building their first systematic trading platform, or traders planning to move from research into a more robust implementation. The outcome: a practical system design that makes the major engineering decisions explicit before substantial implementation work begins.

03 — Implementation & Engineering

Translate the design into working components. A good architecture only becomes useful when it can be implemented, tested and maintained. The appropriate level of engineering depends on the problem, the existing codebase and the reliability the system requires. Depending on the project, we may be able to help with:

• Structuring a codebase and defining component boundaries.
• Implementing or improving data-processing workflows.
• Designing backtesting and testing infrastructure.
• Building validation, logging and monitoring into the system.
• Reviewing implementation choices and technical trade-offs.
• Establishing testing and deployment practices.

Best suited to: developers and technically minded traders who need help resolving a specific implementation problem or establishing a sound engineering foundation. The outcome: a defined technical deliverable, such as a reviewed design, implementation plan, tested component or documented set of improvements, agreed before work begins. Implementation work is scoped individually. We only take on work that fits our current capabilities and available capacity.

04 — System Review & Troubleshooting

Find the weakness before building more on top of it. Sometimes the problem isn't a lack of ideas. It's uncertainty about an existing system. Perhaps the backtest results don't make sense. Perhaps a research process has become difficult to maintain. Perhaps the architecture has grown organically and is now holding development back. A focused review can help establish where to investigate first. We can work through questions such as:

• Where are the most important assumptions in this system?
• Which components are difficult to test or validate?
• Where might data quality or implementation choices be distorting results?
• What operational failure modes haven't been addressed?
• Which improvements are essential, and which can wait?

Best suited to: people who already have a trading system, research codebase or development process but need an independent technical perspective. The outcome: a structured review of the problem, its likely causes, the uncertainties that remain and a prioritised set of next steps.

Who we work with

Traders and researchers

You understand markets and have ideas worth investigating, but you want a more rigorous way to evaluate them. We can help you strengthen your research process, scrutinise your backtests and understand the engineering required to move from a promising hypothesis towards a functioning system. You don't need to be an experienced software engineer to benefit from a research or architecture review. The scope will depend on the technical depth of the problem.

Developers and technical builders

You have programming or software engineering skills and want to apply them to systematic trading. We can help you understand the structure of a trading system, navigate the specific challenges of quantitative research and design infrastructure that is testable, maintainable and appropriate to its intended use. You don't need to arrive with a finished trading strategy. Some projects begin with a system design or implementation question rather than a validated source of returns.

How an engagement works

We believe the engineering process should begin with a clearly defined problem, not a predetermined solution.

1. Describe the problem

Tell us what you're building, what isn't working or what decision you need to make. You don't need a perfect technical specification. A concise description of the problem, what you've tried and what you want to achieve is a good starting point.

2. Establish the scope

We'll determine whether the problem fits our capabilities and what kind of engagement makes sense. That might be a focused review, an architecture session, a written assessment or a more substantial piece of implementation work. We'll clarify the expected deliverables, assumptions, access requirements, timescale and price before work begins.

3. Investigate and engineer

We work through the agreed problem systematically. Depending on the engagement, this could involve reviewing code or research, discussing design options, testing assumptions, producing documentation or implementing a defined component. The emphasis is on understanding the problem and making defensible engineering decisions, rather than adding complexity for its own sake.

4. Deliver and explain

You'll receive the agreed output: potentially a review, architecture, technical deliverable, implementation plan or working component. We'll explain the decisions, limitations and remaining uncertainties so you can understand the result and decide what to do next.

5. Decide what comes next

Some problems can be resolved in a single engagement. Others reveal further work. There's no obligation to continue. If additional work makes sense, we'll define it as a separate scope.

Our engineering principles

Evidence before confidence

We distinguish what has been demonstrated from what is assumed, estimated or still unknown.

Simplicity before unnecessary complexity

A system should be no more complicated than the problem requires. Additional components and optimisation are not improvements unless they solve a real problem.

Reliability is part of the design

Testing, data quality, execution constraints, risk controls and monitoring are engineering concerns, not afterthoughts.

Clear scope and explicit trade-offs

We define what we're solving, what we're delivering and what falls outside the engagement. Technical decisions should account for their costs, limitations and operational consequences.

No promises of returns

Engineering can improve the quality of research and implementation, but it cannot guarantee a profitable strategy or eliminate market risk. A sound process can establish that an idea is weaker than expected. Discovering that early is a useful result, even when it means deciding not to build or deploy the strategy.

What we don't do

Capital in the Wild focuses on systematic trading research, software, architecture and engineering. We do not promise profitable strategies, guaranteed returns or risk-free trading. We do not represent a backtest as evidence of live profitability. Our engineering engagements are not a substitute for regulated investment advice, discretionary portfolio management or legal, tax and compliance advice. We do not assume responsibility for operating your trading account or deploying capital unless a separately agreed arrangement explicitly and lawfully provides for it. We also won't claim that every problem needs a custom platform, a complete rebuild or a complex automated solution. Sometimes the right answer is to simplify the design, improve the testing process or stop pursuing a weak hypothesis. The objective is to solve the right problem, not to maximise the amount of engineering work.

Let's discuss your project

You don't need to arrive with a finished design or a complete specification. You need a problem worth understanding and a clear idea of what you want to achieve. Tell us a little about your system, the challenge you're facing and the outcome you're looking for. We'll assess whether it's a good fit and discuss a sensible next step. Useful information to include:

• Are you approaching this as a trader, researcher or developer?
• What are you trying to build, test or improve?
• What have you tried so far?
• What would a useful outcome look like?

We'll respond with an indication of whether we can help and, if appropriate, a proposed scope for the work. [Discuss your project] Capital in the Wild — systematic trading is an engineering problem.