I’m Building a City. Again.
A few weeks ago, I started building a city simulation in my free time. I called it Polis.
I am building it mostly for fun, with a lot of help from Claude. The fact that I can now turn a small idea into a working game in the evenings and on weekends is, in itself, a reflection of how much software development has changed.
Part of the motivation is simple nostalgia.
I played SimCity obsessively as a kid. Hundreds of hours. My parents thought I was wasting time.
They were not entirely wrong. But they were not entirely right either.
What I Actually Learned from SimCity
I studied engineering, started a company and figured things out as I went. I never went to business school.
Looking back, a surprising amount of what I learned about systems, trade-offs, limited resources, and delayed consequences traces back to those hours spent in front of a city simulation.
Not simply as a metaphor. As a real experience that shaped how I reason.
In SimCity, you start simple. Roads. Zones. Power. Water.
People arrive. The city grows. For a while, it feels easy.
Starting a business can feel similar. Building something and launching it is often the easy part.
The first difficult question is whether people genuinely want what you have built. In business language, that is product-market fit. Getting there usually requires iteration, persistence and some luck.
The second difficult question is whether you can grow without breaking the system around it. Citizens need jobs. Roads become congested. Neighbourhoods decline because you stopped paying attention to them. You cut a budget that seemed unimportant and the consequences appear much later, when the original decision is almost forgotten.
The game does not always tell you when you have made a bad decision. It just plays out.
I have watched the same thing happen in companies.
Underinvest in product quality, and customers may not leave this quarter. They leave next year. By then, recommendations have slowed down, the data is quietly getting worse, and the original cause is difficult to identify.
Dashboards tell you what has already happened. The real skill is reading the system well enough to see what may happen next.
Why I Called It Polis
The name Polis was not my idea. Full credit belongs to my colleague Dimitris Tsigkos.
Some time ago, Dimitris used the contrast between polis and idiōtēs as part of an internal rallying message in our company.
The polis is the community.
The idiōtēs is the private individual, focused mainly on their own affairs. The word later became the ancestor of the modern English word “idiot.”
The contrast stayed with me.
A city cannot work if every neighbourhood optimizes only for itself. A company cannot work if every team optimizes only for its own metrics.
Engineering cannot ignore support. Sales cannot ignore onboarding. Product cannot ignore complexity.
The health of the whole system matters more than the local optimum of any single part.
That is the idea behind the name.
Why I Built It
I am building Polis because I enjoy it.
But I also think simulations can teach things that are difficult to teach in a classroom: systems thinking, trade-offs under real constraints and the gap between a decision and its consequences.
These are not abstract ideas. You understand them better when you experience them.
Polis is free to play. If you want to look under the hood, I put together a short presentation and a more detailed technical overview — and if you would rather just make something, you can build your own map with the city generator.
Let your kids try it. Maybe they’ll build something one day. Maybe they’ll just enjoy it. Either way, they probably won’t realise they’re learning anything.
Neither did I.