What I Learned Building a Rules-Based Portfolio System

Building Starting Index felt a little like this road. There was a direction I wanted to go, but getting there meant working through the turns, tradeoffs, and a few places where the obvious path was not actually the best one.

My background is, let's say, varied. Maybe I'll write an article about that someday, but for this one I'll keep it simple. I've had tedious, repetitive jobs. I've had complex, high-cognitive-load jobs. I've also done plenty of work that lived somewhere in between. That work happened across a lot of industries and a lot of responsibility levels, from getting my hands dirty to architecting systems and thinking through how all the pieces needed to work together.

That mix shaped how I think and how I approach work. It made me care about the goal, the design, the person who has to use it, and whether the process can actually hold up when it has to be repeated.

When I look back across my career, a few common threads show up over and over again. Efficiency. Automation. Simplicity.

I want to do the job as efficiently as possible. I want to automate as much of the process as I reasonably can. And even when the problem is complex, I want the design to stay as simple as possible.

That mindset had a lot to do with how Starting Index was built.

Building the system forced tradeoffs. Concentration versus diversification. A predictable trading cadence versus a more responsive system. Rank weighting versus equal weighting. Simplicity versus optimization.

I tested a lot of combinations because I wanted to understand what each tradeoff actually cost. Not just which version looked best on a chart, but which version I could live with, maintain, explain, and trust when the market got uncomfortable.

I wasn't trying to make history look perfect. I was trying to understand which decisions changed the risk, which ones improved the result, and which ones added complexity without earning their place.

That led to a few lessons.

Lesson 1: Diversification Has a Cost

I wanted diversification, but I didn't want to give up too much long-term return if one sector was clearly leading the market.

So it was time to put on the thinking cap and figure out how to balance both.

My initial design had a sector cap, but it was costly. It reduced concentration risk, but it also gave up a lot of return in periods where one sector had strong momentum. So I went back through 30 years of historical data and looked at different time windows to see what happened when the sector cap was removed.

The answer was pretty simple. Risk went up.

But the more useful question was whether that increased risk was still acceptable. Max drawdown is the largest peak-to-trough decline in the test. If I could adjust the configuration so the historical max drawdown remained below the market over the same period, then the tradeoff became more interesting.

On one hand, I would be taking on more risk than the capped version. On the other hand, the test still showed lower historical drawdown than the market itself. That mattered to me because buying the broad market is a very common and accepted approach to investing, and it is one I personally used for many years.

That became an acceptable tradeoff. Allow more sector concentration when leadership was strong, but still spread the allocation across multiple companies and keep the historical drawdown profile within a range I could live with.

Lesson 2: Responsiveness Has a Cost Too

The next question was how static or dynamic the trading strategy should be.

Obviously I wanted strong returns, but through all the tests, tweaks, and logic additions, I was only able to pull out a modest amount of extra return from making the system more responsive.

The numbers looked a little better, but each tweak added complexity. Not just to the code, but to the operating requirements. A more responsive system starts to need constant market checks, broker queries, uptime monitoring, failure handling, and all the other delightful things that come with always-on software.

What happens if the Internet goes down?

What happens if the broker API has a bad morning?

What happens if the system misses a signal and has to decide whether to catch up, wait, or stand down?

At some point I had to ask whether the extra return was worth the extra machinery.

For me, the answer was no. I was perfectly at peace with a system that could query the market on a defined cadence, make decisions, create allocations, publish the results, and then lay dormant until the next cycle came around.

As someone who has had to maintain 24x7 systems for a living, I was 100% on board with not creating another one unless the return was clearly worth the headache.

Lesson 3: Weighting Changes the Ride

Weighting stocks is a subset of diversification in my opinion.

I originally designed the strategy to keep the weighting equal because that made sense across the original selection of 25 stocks. Each stock would only ever be 4% of the portfolio, so if one position fell hard, the damage would be limited.

That was clean. It was also leaving a lot of return on the table.

After more testing, I found that equal weighting did reduce drawdown risk, but at the cost of significant gains. That pushed me toward a different structure.

Instead of one portfolio allocation, I decided to create three. The main differences would be the number of stocks and how aggressively the weights were assigned.

That gave me a way to choose where I wanted to sit on the spectrum.

A smoother ride with a little less return potential.

A slightly bumpier ride with more return potential for the trouble.

Or a potential roller coaster with some calculated lows and, hopefully, much better views from the top.

That became Core, Balanced, and Growth.

Lesson 4: Complexity Has to Earn Its Place

The last big lesson was about whether I wanted to keep squeezing extra logic into the system for slightly better results.

I tried that approach. I added little components, tested them, adjusted them, and sometimes eked out a few extra percentage points in the backtests.

But then I stepped back and looked at what I had built.

It was too complex.

Complexity means more things to break. More things to remember when they do break. More headaches when it comes time to change, refactor, or explain the system to someone else.

It also meant that if I ever wanted or needed someone else to understand the system, they would have to learn a lot more before they would be able to know what was going on.

That wasn't worth it to me.

At the end of the day, the research results were strong enough that adding more moving parts did not feel worth it. I wanted a system that could be tested, followed, maintained, and explained without needing a conspiracy wall of diagrams and string.

If you want to see how those choices show up in the current profiles, the method page explains the process, and the profile records show how the Core, Balanced, and Growth profiles are tracked.