DEV Community: Eddie

Why We Built MicroLeague Sports Vol. 2

Eddie — Tue, 07 Jul 2026 13:59:23 +0000

Building a Time Machine for Sports

MicroLeague Dev Blog, Vol. 2

By Eddie Solar

In the first volume, I wrote about why we built MicroLeague Sports: fans have argued about hypothetical matchups for decades, and there has never been a way to actually play them.

The solution sounds trivial when you say it out loud. Take two teams, run a simulation, show the result.

It is not trivial. The moment you move past the score, you find that a sports simulation is not really a game problem at all. It is a data problem. And a historical sports simulation, one that has to reach across decades of a sport that kept changing underneath it, is one of the hardest data problems you can pick up.

This volume is about why.

The Question That Starts Every Simulation

Every matchup begins with the same question.

What would happen if these teams actually played?

The 1997 Bulls against the 2025 Thunder. The 2007 Patriots against the 1985 Bears. The 1927 Yankees against the 1998 Yankees.

Generating a winner is easy. A random number generator can hand you a final score in a millisecond. That is not the problem we are solving. The problem is generating a result that a sports fan looks at and accepts as plausible. Those are two completely different objectives, and understanding the gap between them is the entire job.

Believability Is a Harder Target Than Accuracy In Volume 1, I argued that believability is the moat. Here is the part that makes it a genuinely interesting technical problem rather than a marketing line.

For most predictive systems, you optimize against ground truth. The event happens, you compare your prediction to the outcome, you measure your error, you improve. There is a right answer to grade against.

Cross-era matchups have no right answer. The 1997 Bulls never played the 2025 Thunder. There is no box score, no historical result, no label to train against, ever. In machine learning terms, you are working a problem where the target you would normally optimize for does not exist and cannot be collected.

So you optimize for something else: plausibility. The output has to be internally consistent, has to respect what fans know to be true about both teams, and has to hold up under scrutiny from people who have watched thousands of hours of the sport. Fans will forgive uncertainty. A close game that could have gone either way is fine. What they will not forgive is nonsense. The instant a knowledgeable fan says there is no way that happens, the credibility of the entire system is gone, and it does not come back.

Optimizing for a target you can never directly measure is a strange and difficult thing to build toward. It is also the thing that makes this worth building.

The Era Problem

The hardest version of this challenge is that sports do not hold still.

The NBA of 1997 is not the NBA of 2025. The NFL of 1985 is not the NFL of 2007. Rules change. Pace changes. Strategy, training, talent pools, and analytics all change. Even a single franchise can be almost unrecognizable across two decades. Comparing teams across eras is not comparing wins and losses. It is comparing two different environments that happened to use the same scoreboard.

This is where raw statistics become actively dangerous.

Say one team averaged 120 points per game and another averaged 100. It looks obvious which offense is better. It is not obvious at all, because those numbers were produced under different conditions: different pace, different rules, different defensive schemes, different level of competition. The 120 might be a product of an era that ran forty more possessions a night. Compared directly, the raw number lies to you.

The statistical way to describe this is that era is a confounder. Almost every number a sport records is entangled with the conditions of the time it was recorded in. Pull the number out of its era and you have stripped away the context that gives it meaning. So the real work is not collecting statistics. Collecting is the easy part. The work is interpreting a number relative to the world that produced it: measuring a player against his own contemporaries, normalizing for the pace and rules of his era, and reconstructing what his dominance would translate to in a different environment.

Get that normalization right and a cross-era matchup feels authentic. Get it wrong and you have a fast random number generator with a sports skin on it. That difference is the whole product.

Data Is a Product, Not an Input Early on, we treated sports data the way most people do: as fuel you pour into a simulation. Load the stats, run the model, get a result.

That assumption did not survive contact with the era problem. Once you are normalizing across decades, the data stops being an input and becomes the foundation the entire system stands on. Every team, every season, every roster, every schedule, every statistic has to be collected, structured, and normalized before it can be trusted in a simulation. The quality of that layer sets the ceiling on everything above it.

That realization is what pushed us to build our own sports data platform rather than renting one. The logic is simple: if you do not control your data layer, you do not control your simulations. You inherit someone else's gaps, someone else's normalization choices, and someone else's ceiling.

This is a large enough topic that it gets its own volume. For now, the takeaway is that we stopped thinking of data as something we consume and started treating it as something we build.

One Engine, Many Sports From the start, we did not want to build a basketball simulator. We wanted to build a simulation engine that did not care which sport you handed it.

Today MicroLeague supports the NBA, the NFL, MLB, and the FIFA World Cup. On the surface those sports have almost nothing in common. Different scoring, different structures, different statistics, different rules. If you built each one as its own product, you would be building and rebuilding the same platform four times.

We did not, because underneath the differences every one of these sports shares the same primitives: teams, players, seasons, games, and championships. Once you model those shared concepts correctly and cleanly separate them from the sport-specific rules layered on top, something useful happens. The engine, the normalization framework, the prediction systems, and the community layer all become sport-agnostic. What stays unique to each sport is mostly its data and its rules.

The result is a line I think is the most important architectural sentence in this whole series:

Adding a new sport becomes a data problem, not a platform problem.

That is why soccer and the World Cup could join a system built for American sports without a ground-up rebuild, and it is why the roadmap of sports we can eventually support is far longer than the four live today. When expansion is a data exercise instead of an engineering rewrite, the ceiling moves.

The Simulation Is the Starting Point, Not the Destination The most useful thing users taught us is that the simulation is where the experience begins, not where it ends.

Fans do not just want the result. They want to predict it before it is revealed, argue about it after, build tournaments around it, earn rewards for being right, and build a reputation on the strength of their calls over time. Every simulation spins off a conversation. Every conversation seeds a community. And the community turns out to be a product surface of its own, one we will spend a later volume digging into.

The engine is the core. It is not the whole thing.

What We Are Building Next

Right now we are focused on the foundation that powers everything above it:

Proprietary sports data and the pipelines that keep it clean Sports APIs Sharper simulation logic Historical normalization across eras Creator tools, prediction systems, and rewards infrastructure

The goal was never to generate scores. The goal is to build the most engaging place for fans to explore alternate sports realities, to ask what if and actually get an answer worth arguing about.

We Are Building a Time Machine When people first hear about MicroLeague, they assume we build sports simulations. Technically true. But the simulation is one piece of a larger problem: building a system that can understand a sport across generations, and honestly compare teams that never played, players who never met, and dynasties separated by decades.

That is the real work. In a very literal sense, we are building a time machine for sports. Not to change history. To explore it, settle a few of its oldest arguments, and start some better ones.

And we are just getting started.

What's Next In Volume 3, I will go deep on the challenge underneath all of this:

Why Sports Data Is Harder Than Most People Think

Data pipelines, normalization, historical records, API design, and why owning your data layer is a strategic decision, not just a technical one, when you are building simulation-based products.

Follow the Journey MicroLeague Sports is an ongoing experiment at the intersection of sports, data, simulation technology, Web2 communities, AI, and Web3 rewards. We are building in public and documenting the wins, the mistakes, the architecture decisions, and the lessons along the way.

Explore MicroLeague

Create matchups and simulations

Learn about MicroLeague Coin (MLC)

Try It Yourself

Create your first cross-era matchup, run a simulation, make a prediction, and see who wins: MicroLeague Sports

Connect

If you work in or care about sports technology, data engineering, simulation, AI systems, Web3 infrastructure, or product development, I would genuinely like to hear your feedback.

Follow the Series

Volume 1: Why We Built MicroLeague Sports
Volume 2: Building a Time Machine for Sports
Volume 3: Why Sports Data Is Harder Than Most People Think (coming soon)
Volume 4: Designing a Sports Data Platform (coming soon)
Volume 5: From Simulations to Predictions, Rewards, and Community (coming soon)

The best sports debates never end. We are building the platform where they begin.

MicroLeague Sports

Built on data. Powered by the engine. Owned by the fans.

Why We Built MicroLeague Sports

Eddie — Thu, 04 Jun 2026 18:09:56 +0000

Why We Built MicroLeague Sports

MicroLeague Dev Blog, Vol. 1

By Eddie Solar

Every Sports Fan Has Had This Argument

The 1997 Chicago Bulls or the 2025 Oklahoma City Thunder.

The 2007 Patriots or the 1985 Bears.

Prime Kobe or Prime LeBron.

Sports fans have been having these arguments for decades, and they almost always end the same way: with raised voices, a few cited stats, and no resolution.

There is no game to watch. No box score to pull up. No final whistle to settle it. The matchup exists only in the space between two people who are never going to agree.

We started MicroLeague Sports because we think that space is one of the most interesting unsolved problems in sports.

And the more time we spent in it, the more we realized it is not really an argument problem at all.

It is a data and engineering problem wearing the costume of a bar argument.

That reframing is the whole reason this company exists.

The Debate Has No Resolution Function

Here is the thing that hooked us as builders.

Most sports questions resolve themselves.

Who won last night?

Check the score.

Who leads the league in OPS?

Query the data.

These are lookups. The answer exists; you simply retrieve it.

Cross-era questions are different.

Would the '96 Bulls beat the '17 Warriors?

There is no row in any database because the game was never played and never will be.

There is no ground truth to retrieve.

The only honest way to answer it is to build a system that can take two teams that never met, across rule sets and eras that never overlapped, and produce an outcome that informed fans actually accept as plausible.

That is a genuinely hard problem.

And it becomes more interesting the deeper you go.

We'll spend future articles discussing the engine itself, but it is worth understanding the challenge now because it transformed a fun idea into a company we wanted to build.

Why Existing Products Don't Solve It

Before building anything, we studied what already existed.

Everything fell into one of three buckets.

Sports Media

Sports media is built for consumption.

Analysis, hot takes, highlights, podcasts, and debate shows.

Fans consume the content.

They rarely participate in it.

And they certainly do not resolve anything.

The format is designed to keep the argument alive.

Not settle it.

Fantasy Sports

Fantasy sports allows fans to participate.

But it is anchored to the present.

You draft today's players for today's season.

You cannot place Michael Jordan on a roster with Shai Gilgeous-Alexander.

You cannot run a tournament featuring champions from every decade.

The model is tied to the current calendar.

Sports Simulations

Sports simulations can technically answer cross-era questions.

But most were built for hobbyists.

They are often difficult to access, difficult to configure, and focused on gaming rather than discussion.

Most fans do not want to spend hours configuring a simulation.

They want to ask a question and get a result worth debating.

The gap became obvious.

Nothing combined:

the accessibility of media
the participation of fantasy sports
the resolving power of simulation

into a single experience built around the way fans actually argue.

What We Set Out to Build

We did not want to build another content site.

We did not want to build another fantasy platform.

We wanted to build something that sits in the middle.

A place where a fan can:

create a matchup that never happened
get a believable result
predict the outcome
debate the result
build credibility through sports knowledge

The shift we cared about was simple:

Turn fans from consumers into participants.

Not reading someone else's take.

Creating the scenario.

Making the prediction.

Defending the argument.

And being measured on whether they were right.

The First Prototype

Like most products, MicroLeague started with a single question:

Could we build an engine that takes two teams that never met and produces a result a fan would believe?

The earliest version did exactly that.

Nothing more.

Pick two teams.

Define the matchup.

Receive:

a game summary
a final score
key moments
standout performances

No accounts.

No community.

No rewards.

Just the core loop.

It resonated immediately.

But not for the reason we expected.

We thought people would care most about the score.

What they actually cared about was everything around the score.

A simulated game between the 1997 Bulls and the 2025 Thunder generated more discussion than the final result itself.

Fans wanted to explain:

why the result was wrong
why a player would dominate
why a different ruleset would change everything

That was the signal.

We were not building something that produced scores.

We were building something that produced arguments.

The score was simply the opening move.

The Hard Part Is Believability, Not Math

It is easy to generate a number.

It is hard to generate a number that fans trust.

That distinction defines the entire engineering challenge.

Producing some output for a 1970s team versus a 2020s team is trivial.

Producing an output that survives contact with knowledgeable fans is not.

Every matchup creates difficult questions:

How do you normalize statistics across eras?
How do you compare players from completely different basketball environments?
How do you account for rules, pace, strategy, and competition levels?
How do you evaluate dominance relative to an era instead of using raw statistics?

And underneath all of it:

What does believable actually mean?

Because believability is ultimately judged by fans.

Not by the system.

These are not questions with a single correct answer.

They are modeling decisions.

And every decision is an opportunity to either earn trust or lose it.

The interesting work is not generating outcomes.

The interesting work is producing outcomes that feel authentic to people who know the sport best.

The believability problem is the moat.

And it is the problem we find most interesting to solve.

One Engine, Three Sports, and Now a Fourth

One architectural decision made everything else possible.

We did not build separate engines for basketball, football, and baseball.

We built a single engine capable of understanding all three.

At launch.

The engine reasons across more than a century of sports history and can support:

cross-era matchups
alternate timelines
hypothetical tournaments
historic championship clashes

The engine does not care whether the sport is basketball, football, or baseball.

It cares about:

data
rules
context
competitive structure

Those concepts exist in every sport.

Internally, we have a less technical name for it:

The Time Machine for Sports

The practical benefit is significant.

Adding a new sport becomes primarily a data problem rather than a complete engineering rebuild.

Recently, we proved it.

With the World Cup arriving in North America, we accelerated development of soccer support.

Fans can now simulate historic World Cup matchups dating back to the earliest tournaments.

The engine remained the same.

The sport changed.

That validation reinforced our belief that the architecture can scale beyond the sports we support today.

From Simulator to System

As people used the prototype, another realization emerged.

The simulations created conversations.

The conversations created community.

And the community became just as important as the engine.

That led to a new question.

How do you identify the fans who consistently know what they're talking about?

Online sports discussions have no credibility layer.

Everyone has an opinion.

And every opinion carries the same weight.

The loudest voice wins.

Not necessarily the most informed one.

So we started asking:

What if credibility could be earned?

What if the platform tracked:

prediction accuracy
successful takes
tournament picks
debate participation

What if sports knowledge became measurable?

Over time, MicroLeague stopped being just a simulator.

It started becoming a system.

A place where reputation is built on being right.

Not simply being loud.

How We Think About the Technology Stack

Building this requires multiple layers working together.

Data

Data is the foundation.

Historical teams, players, statistics, seasons, tournaments, and league context power every matchup.

Without structured historical data, there is no believable simulation.

The Simulation Engine

The engine is the brain.

It compares teams, players, seasons, and rule sets across eras and produces outcomes.

It is the most challenging part of the platform and the part we are most excited to continue improving.

Web2

Web2 powers the social layer.

accounts
communities
leaderboards
predictions
rewards

The platform must feel familiar and fast for mainstream sports fans.

Web3

Web3 is infrastructure, not marketing.

Blockchain introduces:

ownership
transparency
portable rewards

We use it where it creates real value.

Sports come first.

Technology earns its place.

Not the other way around.

Where We Are Today — And Where We're Going

MicroLeague is still early.

But fans can already:

create cross-era matchups
create tournaments
run simulations
share results
predict winners
earn XP and rewards
debate outcomes
build credibility through sports knowledge

What we are building toward is larger.

A platform where:

fans create alternate sports realities
historical data drives believable outcomes
communities compete through predictions and fantasy leagues
credibility is earned rather than claimed
reputation is built on being right
fans can act as analysts, creators, GMs, and owners

The goal underneath all of it is simple.

We want to give sports fans something they have never truly had:

The ability to rewrite history.

Run their own leagues.

And potentially earn rewards for being right.

The ability to settle the argument.

Or start a much better one.

Because some of the most interesting games in sports history are the ones that were never played.

What's Next

In Volume 2, we'll dive into the simulation engine itself.

We'll explore how MicroLeague evolved from a simple score generator into a cross-era simulation platform and why producing results that fans trust requires solving problems that have very little to do with generating a score and everything to do with modeling sports honestly.

We're building in public.

And we'd rather show our work than simply talk about it.

If you're interested in sports, data, simulation, modeling, or building ambitious products, follow along.

The arguments are about to get a lot more interesting.

MicroLeague Sports

Built on data. Powered by the engine. Owned by the fans.

Ready to settle the debate? Create your first matchup at MicroLeague Sports.

Learn more about MicroLeague Coin (MLC), the utility token powering rewards, predictions, creator incentives, and community participation across MicroLeague Sports.

MediXall Group: Focused on the Bigger Picture

Eddie — Tue, 28 Apr 2020 20:12:21 +0000

I am the VP of Software Development at MediXall Group, a healthcare technology startup in South Florida. Recently, we pivoted our business model and have been diligently working on a new new product for the past few months.

Just like most companies, COVID-19 has required us to make some changes in order to insure the best possible future for our product. Now, this might sound like the cliche business response, but in no way is our Company in any financial trouble. Our leadership team decided to be proactive and plan for more troubled times if there were any.

Our President, Michael Swartz, was the first one to step up and take a pay cut to make sure no one else had to. A few weeks later he requested that the leadership team join in on the pay cut as well. Without hesitation, everyone agreed to take a pay cut. Again, our main focus was to prevent the rest of the team from having to take a pay cut.

Unfortunately, this was not preventable in order to insure the future of our new product. We had several meetings to explore the options available to us. We met with the whole team and explained the plan. We asked team members to take a small pay cut. In all honesty, we were expecting an all out revolt, but to our surprise, everyone was more than willing to take a pay cut. What was even more amazing to see was that they weren't just willing to do it just to keep a job, but rather because the entire team is fully committed and invested in the growth and success of the new product. The passion behind everyone’s desire to release the best possible product was palpable. To this day, productivity has not gone down but has significantly improved.

Even with the pay cut implemented, the team remained dedicated to continue the hiring process of in-house designers to further optimize our new product.

As a Company, we have had to make several adjustments such as transitioning to remote work. It's truly incredible to see how everyone has adjusted to these changes and believe in the future of this product now more than ever.

I would love to know how your team is handling the various challenges and hurdles that come from this unprecedented time.