The hardest part of building a trading bot isn't the code — it's deciding what the bot should NOT do

I've been building a trading automation product for Gold (XAUUSD), and one of the biggest lessons I've learned has nothing to do with writing code.

The hardest part isn't deciding what your trading bot should do.

It's deciding what it should not do.

When you start building an automated trading system, it's tempting to keep adding features.

More indicators.

More entry conditions.

More markets.

More timeframes.

More filters.

More "smart" logic.

More settings.

Eventually, you can end up with a complicated system that looks impressive on paper but is difficult to understand, test and maintain.

That was one of the things that made me rethink how I wanted to build Goldmine.

Start with one problem

Goldmine is focused on one market:

Gold (XAUUSD).

And one primary environment:

MetaTrader 5.

That constraint is intentional.

Instead of trying to build an EA that trades every forex pair, cryptocurrency and index, we're starting with a market that we understand deeply and building around a specific use case.

I think there's an interesting product lesson here.

Sometimes the best way to make a product more useful is to make its scope smaller.

Automation creates a different kind of problem

With a manual trading strategy, a trader can look at a chart and make contextual decisions.

A human can say:

"This setup technically qualifies, but something doesn't look right."

A computer doesn't have that intuition unless you explicitly program the conditions that represent it.

So when converting a trading strategy into software, you have to turn vague ideas into rules.

Instead of:

"The market looks bullish."

You need something closer to:

"If conditions A, B and C occur, the system considers a long setup."

That's where the real work begins.

You have to define:

• What qualifies as an entry?

• What invalidates the setup?

• When should the system stay out?

• How should risk be calculated?

• When should a position be closed?

• What happens during unusual volatility?

• What happens if market conditions change?

• What happens when the strategy loses?

Those questions are much more important than adding another indicator.

Backtesting can also create false confidence

Another lesson I've learned is that a beautiful backtest isn't necessarily a beautiful product.

It's very easy to optimize a strategy against historical data until the results look fantastic.

But that's not the same thing as proving that the strategy will perform the same way in the future.

That's why I'm increasingly interested in the process around testing rather than simply the final number.

A serious automated trading product needs to consider things like:

Out-of-sample testing

Forward testing

Different market conditions

Drawdown

Transaction costs

Spread

Slippage

Execution conditions

And, most importantly, the possibility that the strategy simply doesn't work as expected.

That last part is uncomfortable, but I think it's necessary if you're building a financial product.

Don't hide the risk

Trading software is a strange category.

You can build an excellent product and still have users lose money because markets are unpredictable.

That means the product experience can't be based entirely around showing the best possible results.

I don't want Goldmine positioned as a machine that guarantees profits.

There are no guarantees in trading.

Instead, I want users to understand what the system does, what assumptions it makes, how it can be configured and what risks are involved.

I think transparency is going to become increasingly important as more automated trading products enter the market.

The product is bigger than the bot

Goldmine started as an Expert Advisor.

But I'm beginning to think about it as a broader product ecosystem.

The future could include:

• automated trading tools

• indicators

• strategy development

• analytics

• educational resources

• research tools

• other systematic trading products

But I'm deliberately trying not to build everything at once.

The first job is to make the core product useful.

Then listen to users.

Then improve it.

Then expand.

The founder lesson

Building Goldmine has reinforced something I've seen repeatedly in product development:

A smaller product with a clear purpose can be more valuable than a bigger product with a confusing purpose.

Every feature has a cost.

Every additional market adds complexity.

Every additional setting creates another decision for the user.

Every new piece of logic creates something else that needs to be tested.

So I'm learning to ask a different question whenever I want to add something:

Does this make the product meaningfully better for the person using it?

If the answer is no, it probably doesn't belong in the product.

That's the principle I'm taking forward as we continue building Goldmine.

I'd love to hear from other Indie Hackers:

Have you ever removed features from your product and found that the product actually became better?

What made you decide what to leave out?