2 Years of Programming Chess Apps: My Lessons

I am the programmer behind Chessboard Magic, and over the last two years I have created more than sixty chess-related projects on the site. Some are small experimental games. Others are analytical tools. A few evolved into full-blown applications that now form the core of the platform.

It has been a strange journey for me for two reasons.

First, I had not programmed seriously since graduating more than twenty years ago. When I started, modern web development felt like stepping into a completely different industry. React, cloud hosting, APIs, OAuth, state management, responsive design, browser caching, deployment pipelines, AI tooling — none of this existed in the world I originally learned in.

Second, I was still relatively new to chess itself.

I only learned to play chess around five years ago, which means I was roughly three years into my chess journey when I started building chess software. I was not a titled player. I was not a lifelong expert. In many ways, I was building tools while simultaneously discovering what serious chess study even looked like.

Oddly enough, I now think that combination helped me.

I approached chess software less like a traditional chess programmer and more like a curious outsider asking:

• “What would actually help me improve?”
• “What information feels missing?”
• “What makes studying painful?”
• “What makes it fun?”

That mindset led me down a rabbit hole that completely consumed the last two years of my life.

In this article, I want to share some of the lessons I learned along the way. Not just technical lessons, but lessons about creativity, motivation, AI-assisted programming, product design, infrastructure, discoverability, monetization, and what happens when you commit to learning in public.

The AI Question

Especially now, in the era of AI-assisted development, I think there is a misconception that programming has somehow become “easy.” My experience has been almost the opposite.

AI dramatically lowers the barrier to entry, but it also dramatically increases the size of what an individual can attempt. You stop thinking in terms of:

“Can I build this?” and start thinking in terms of:
“How far can I realistically push this?”

That shift changes everything.

One of the biggest decisions I made early on was intentionally not using AI to write code for me.

At the time, AI-assisted programming was exploding, and there was already a growing wave of what people now call “AI slop code” — applications stitched together quickly by people who did not fully understand the technologies they were using.

I did not want that.

My primary goal was not simply to release an application. My goal was to learn how to program properly again.

So for the first year, I made a deliberate choice: I did not use AI to write a single line of code.

That decision cost me an unbelievable amount of time.

I manually learned React.
I manually learned responsive design.
I manually learned authentication systems, APIs, hosting, databases, caching, optimization, deployment, debugging, and architecture patterns.

There were countless nights where I probably could have solved something in ten minutes with AI assistance, but instead spent six hours reading documentation and experimenting.

Looking back, I do not regret it at all.

Because when systems eventually become large, complexity compounds quickly. If you do not understand your own architecture, debugging becomes miserable. Every new feature feels fragile. Every refactor becomes dangerous.

And perhaps most importantly, blindly relying on AI to debug large systems can send you into endless loops of fixes creating more fixes, which then create more bugs somewhere else entirely.

At small scale, AI-generated fixes can feel magical.
At large scale, they can become chaos if you do not understand what the system is actually doing.

What eventually changed for me was not my opinion on AI, but how I used it.

I stopped viewing AI as a code generator and started viewing it as an interactive documentation system.

That was the breakthrough.

Instead of asking:
“Build this for me.”

I started asking:

• “What are the trade-offs between these two libraries?”
• “How does this technology scale?”
• “What are the limitations of this hosting model?”
• “Why would I choose this database over another?”
• “What are the common mistakes people make with this architecture?”

That was where AI became incredibly powerful.

It became a brainstorming partner.
A research assistant.
A documentation explainer.
A second opinion.
A debugging companion.

But importantly, I still wanted to understand the answer.

I think this distinction matters a lot.

AI can absolutely help people get started faster. In fact, I think we are entering an era where one motivated person can build things that previously required small teams.

But long-term maintainable software still requires thought.

It requires understanding trade-offs.
It requires architectural thinking.
It requires knowing why something works, not just that it currently works.

And honestly, learning those fundamentals is slow.
There is no shortcut around that.

If there is one lesson I would summarize from this entire section, it is this:
AI is an incredible accelerator, but it can also become a crutch.

If your goal is only to produce output quickly, AI can do that.
If your goal is to build stable systems and genuinely improve as an engineer, you still need to develop understanding yourself.

The people who will benefit most from AI long term are probably not the people who outsource all thinking to it, but the people who use it to amplify their own thinking.

Infrastructure, Hosting, and the Reality of Running a Web Product

One thing I massively underestimated at the beginning was how different it is to build an actual web product compared to simply building a fun application locally.

Creating a small HTML page or JavaScript demo is relatively easy today.

Running a real platform is something else entirely.

The moment you introduce user accounts, databases, storage, authentication, APIs, analytics, backups, permissions, bandwidth costs, scaling concerns, and security, you are no longer just “making apps.” You are building infrastructure.

And infrastructure decisions matter a lot.

One of the first things I learned is that every hosting approach comes with trade-offs.

Platform-as-a-Service solutions such as Supabase, Appwrite, or PocketBase can dramatically accelerate development because so much functionality comes ready-made out of the box.

Authentication.
Databases.
Storage.
APIs.
Serverless functionality.
Analytics integrations.

For solo developers, that speed is extremely valuable.

Meanwhile deployment-focused platforms like Vercel or Netlify make deployment almost absurdly simple.

Push to GitHub and your site updates automatically.

On the other side, infrastructure providers like DigitalOcean, Linode, or Hetzner give you significantly more control and can massively reduce long-term costs, but also increase operational complexity.

There is no universally correct answer.

It depends entirely on:

• What you are building
• Your technical skill level
• Your expected traffic
• Your budget
• Your long-term goals
• How much operational responsibility you want

AI can help explain these options, but ultimately you still need to understand your own use case.

One thing that became very apparent to me is that cloud costs are often not where beginners expect them to be.
People think about storage first.

In reality, bandwidth and operations can become the bigger issue.

How much data are you transferring?
How many database reads are occurring?
How often are users downloading large files?
Are you repeatedly transferring data that could be cached locally?

These questions matter because every architectural decision eventually turns into a cost decision.

One of the most valuable things I discovered was Cloudflare.

Caching, CDN distribution, bandwidth optimization, DNS management, rate limiting, and security protections became a huge part of how I thought about performance and scalability.

Before building web applications, I honestly never thought much about global delivery infrastructure.
Now I think about it constantly.

The deeper you go into software development, the more you realize programming is only part of the problem.
The rest is systems design.

And if you are serious about building an application for long-term use — rather than simply creating a quick proof of concept or fun toy — it is worth slowing down and thinking carefully about these decisions.

Brainstorm with AI.
Read discussions online.
Research trade-offs.
Think about scale before you need it.
Think about costs before they surprise you.

Because changing infrastructure decisions later can become very expensive, both financially and technically.

Mobile-First Thinking

From the beginning, I always viewed my applications through a mobile-first lens.

Part of that is simply reality.

Smartphones are everywhere now.

For many people globally, mobile devices are their primary computing platform. A huge percentage of web traffic today comes from phones, not desktops.

And chess fits mobile usage patterns perfectly.

People solve puzzles while commuting.

Review openings during lunch breaks.

Analyze games in bed.

Browse content casually throughout the day.

Chess is one of those activities that naturally fits short sessions and mobile interaction.

That means responsive design is no longer optional.

If your application works beautifully on desktop but feels frustrating on mobile, you are probably limiting your growth dramatically.

Another thing I realized early was that responsive web applications can very easily become mobile applications themselves.

Frameworks like Ionic Capacitor make it surprisingly straightforward to wrap responsive websites into Android and iOS applications.

That changes how you think about architecture.

You are no longer just designing a website.

You are potentially designing an application ecosystem.

Mobile responsiveness affects:

• Layout decisions
• Navigation
• Rendering performance
• Touch interactions
• Data density
• Typography
• Load times
• User retention

I learned very quickly that designing desktop-first and then trying to “shrink it down later” is painful.

It is much easier to design with constraints first.

For UI development, I eventually chose Material UI.

For solo development, it was an excellent choice.

Out of the box, applications already look reasonably polished. The component ecosystem is huge. Documentation is strong. It accelerates development massively.

That said, it definitely has quirks.

As applications become large, styling consistency, rendering behavior, dependency management, and customization complexity can become challenging.

But overall, it allowed me to focus far more on functionality rather than rebuilding UI systems entirely from scratch.

And for a solo developer trying to move quickly, that trade-off made complete sense.

Understanding Your Users

One thing I gradually learned is that building software is not really about software.

It is about people.

Chess alone has hundreds of millions of players worldwide, ranging from absolute beginners casually solving puzzles on their phones to professional players preparing for tournaments.

That means there is room for many different kinds of products.

But it also means you cannot build for everyone.

One of the biggest mistakes developers make is trying to create something that appeals to every possible user.
In reality, the strongest products usually solve a very specific problem for a very specific type of person.

You need to ask:

• Who is this for?
• Why would they use it?
• What problem does it solve?
• What emotional response are they looking for?
• Convenience?
• Improvement?
• Competition?
• Entertainment?
• Curiosity?

This is actually a large part of what product managers do in industry.

People often think product design is simply:
“Come up with an idea and build it.”

In reality, product thinking is usually much deeper than that.

A good product manager spends enormous amounts of time thinking about:

• User behaviour
• Friction points
• Retention
• Engagement
• Discoverability
• User psychology
• Feature prioritization
• Feedback loops
• Onboarding
• Simplicity versus flexibility

A lot of software development is ultimately about reducing friction.

• Every extra click.
• Every confusing menu.
• Every slow loading page.
• Every unclear workflow.

All of these things affect whether people continue using your application.

One thing I found especially interesting over the last two years is how different users often want completely different things from the exact same platform.

Some users want deep analysis.
Some want simplicity.
Some want entertainment.
Some want efficiency.
Some want structure.
Some want experimentation.

And balancing those competing needs becomes surprisingly difficult as applications grow.

In many ways, product development becomes a constant exercise in compromise.

One lesson I learned fairly early was that your first users are incredibly important.
Not just because they use the product, but because they become your best testers.

Over the last two years, I have had several early users who consistently provided feedback, reported issues, suggested ideas, and helped refine the applications significantly.

That kind of feedback is incredibly valuable because real users interact with software very differently from how developers imagine they will.

Users will:

• Misunderstand workflows
• Click unexpected things
• Use features incorrectly
• Expose edge cases
• Reveal friction points
• Ask questions you never considered

And honestly, that is a good thing.

Because those interactions help shape the product into something far more usable than you could have designed entirely alone.
I think many successful applications are not built purely by brilliant developers sitting in isolation.

They are refined gradually through constant interaction between creators and users.

And that process can be incredibly rewarding when you embrace it rather than resist it.

Understanding Your End Game

One of the most important questions you need to ask yourself is:
“What is the actual goal here?”

For me, the answer was never purely financial.

I work in the BI space professionally, and I could already see that general programming skills were becoming increasingly valuable far outside traditional software engineering.

Web applications.
Automation.
AI integrations.
Internal tools.
Data systems.
Embedded applications.

The lines between disciplines are blurring rapidly.

Chess simply became the vehicle I used to learn through.

That framing changed everything for me.

Because if your primary goal is learning, then every application becomes useful, even if it never makes money.

After the first year, I started realizing something interesting:
Each application I built was increasing my skill ceiling.

Every project introduced:

• A new architecture challenge
• A new optimization problem
• A new UI pattern
• A new scaling issue
• A new data problem
• A new integration problem

So I intentionally started treating applications as stepping stones.

The goal was not necessarily:
“Build the perfect app.”

The goal became:
“Build something that forces me to learn.”

Ironically, that approach also created another unexpected benefit:
Organic traffic.

At first, many of my smaller applications were simply experiments.
But over time, they started getting indexed by search engines.

That turned out to be incredibly important.

Today there are millions of applications online competing for attention. Building something good is not enough. People need to discover it.
And discoverability is hard.

I made a conscious decision very early on not to spend money on paid advertising.

Instead, I focused on:

• Search discoverability
• Useful tools
• Consistent releases
• Shareable features
• SEO-friendly content
• Word of mouth
• Building genuinely useful applications

Over time, that compounded.

Today the platform receives roughly 5,000 unique users and around 40,000 page views every 30 days, with approximately half of the traffic coming from search engines.

The rest comes mostly from occasional Lichess mentions and word of mouth.

To me, that was one of the biggest lessons:
Distribution matters.

You can build an amazing application that nobody ever finds.

And if your goal is eventually commercial success, discoverability may matter just as much as engineering quality.
One thing I also underestimated early on was how important SEO and discoverability actually are.

A lot of developers think:
“If I build something good, users will naturally appear.”

Unfortunately, the internet does not really work like that anymore.

There are millions of websites competing for attention.
Even genuinely useful products can disappear into obscurity if nobody ever discovers them.

This is why SEO specialists exist as entire professions.

Good SEO is not just stuffing keywords onto a page. Modern SEO is often about:

• Information architecture
• Page structure
• Performance
• Mobile responsiveness
• Internal linking
• User retention
• Search intent
• Content strategy
• Consistency
• Technical optimization

In many ways, search engines are trying to answer a simple question:
“Does this page genuinely help people?”

The frustrating reality is that discoverability can take a very long time.

For months, sometimes years, it can feel like nobody is using what you build.

Then gradually pages start indexing.
Traffic slowly compounds.
Search engines begin understanding your site.
Users start sharing links.
And momentum slowly builds.

I think this is one reason why many developers quit too early.

The feedback loop for discoverability is incredibly slow.

One thing that helped me significantly was building many smaller applications instead of putting everything into one giant flagship project.
Each smaller application became another entry point into the platform.

Another indexed page.
Another searchable feature.
Another way for users to discover the site organically.

Over time, that compounds surprisingly well.

Solo Development vs Building With Others

Another major lesson I learned over the last two years is that solo development is both incredibly empowering and incredibly exhausting.

There is something deeply satisfying about building an entire platform yourself.

You control the vision.
You control the architecture.
You move quickly.
You make decisions instantly.
You are not waiting for meetings, approvals, or alignment.

For learning, solo development can be amazing because you are forced to touch every part of the stack:

• Frontend.
• Backend.
• Infrastructure.
• Databases.
• Authentication.
• Optimization.
• Product design.
• Deployment.
• Analytics.
• SEO.
• Support.

You become a generalist very quickly.

And honestly, I think that broad exposure accelerated my growth enormously.

But solo development also comes with real downsides.

You become the engineer, the designer, the tester, the infrastructure person, the support desk, the product manager, the marketer, and sometimes even the technical support line at two in the morning.

There is always another issue to fix.
Another feature idea.
Another optimization.
Another bug.
Another deployment.
Another user request.
And burnout is very real.

One thing I increasingly understand is why startups and companies build teams rather than relying on single individuals forever.
Collaboration changes the experience dramatically.

Working with friends or people who share the same interests can make the journey significantly more enjoyable.

You distribute responsibility.
You gain different perspectives.
You challenge each other's ideas.
You stay motivated during slower periods.

And perhaps most importantly, you stop feeling like you are carrying the entire project mentally by yourself.
Today it is easier than ever to find people with similar interests online.
Forums.

Discord communities.
Reddit communities.
Open-source projects.
Chess communities.
Developer groups.

There are thousands of people experimenting, learning, and building things together.

And honestly, I think many developers underestimate how valuable that social aspect can become over long periods of time.
Because building software over multiple years is not just a technical challenge.

It is an emotional and psychological one as well.

There will absolutely be periods where motivation disappears.
Periods where progress feels invisible.
Periods where you question whether anyone cares about what you are building.

Having other people around you can help tremendously during those moments.

At the same time, solo development does offer something unique:
A direct relationship between your ideas and the final product.

There is something very pure about that.

And I think both approaches have their own strengths.

Some people thrive in teams.
Some people thrive independently.
Most people probably benefit from a mixture of both.

The Brutal Mathematics of Monetization

I think one of the biggest misconceptions people have about software products is how difficult monetization actually is.
Especially today.

People often imagine:
“Build a good application, get users, make money.”

Reality is usually far harsher than that.

Most modern products operate somewhere within a freemium model:
Provide a large amount of value for free, then hope a small percentage of users convert into paying customers.

This model exists because acquiring users is extremely difficult.

Even some of the largest technology companies in the world lose money initially to acquire and retain users at scale.
User growth itself has value.

And for smaller developers, this creates a difficult balancing act.

You need enough free functionality for people to care about your product at all.

But you also need enough premium value for some users to justify paying.

When you actually run the numbers, things become sobering very quickly.

For example, my Repertoire Builder has nearly 5,000 registered users, around 400 monthly active users, and roughly 40 paying subscribers after about a year.

Thankfully, my personal goals were never primarily financial, so I view this positively.
But if someone enters this space expecting fast financial returns, reality can hit hard.

Let us imagine a simplified example.
Suppose:

• 10,000 users register
• 1,000 become active monthly users
• 5% convert to paid subscriptions
• The average subscription is $5/month

Initially that sounds decent.
But then you subtract:

• Hosting costs
• Storage costs
• Database costs
• Bandwidth costs
• AI API costs
• Payment processing fees
• Taxes
• Infrastructure scaling
• Customer support
• Maintenance time
• Development time
• Opportunity cost

Suddenly the economics look very different.

Educational applications are especially challenging because users often expect enormous amounts of free value.
Chess users in particular are already accustomed to extremely high-quality free platforms.

That creates a very competitive environment.

This is why understanding your motivation matters so much.

Are you building:

• To learn?
• To experiment?
• To create a portfolio?
• To solve a problem?
• To build a business?
• To eventually raise investment?
• To create a side income?

There is no wrong answer.

But your strategy should align with your actual goal.
Because software development can easily consume years of your life.
You should understand what success looks like for you personally before you begin.

Final Thoughts

Despite all the challenges, I honestly think this is one of the most exciting periods ever to be a creator.

AI is lowering barriers dramatically.

More and more people are experimenting with chess applications, analysis tools, training systems, educational platforms, and AI-assisted experiences. I genuinely think that is a good thing.

For every thousand projects created, maybe one ends up being genuinely transformative.

But those transformative ideas only emerge because people are willing to experiment in the first place.
And experimentation is becoming more accessible than ever.

Two years ago, I was someone returning to programming after more than two decades away from the field, while still being relatively inexperienced at chess.

Today, I maintain a large chess platform with dozens of applications, thousands of users, millions of stored moves, cloud infrastructure, engine integrations, analytics systems, and hundreds of thousands of lines of code.

And honestly, I still feel like I am learning every single day.

So if you are thinking about building something yourself, my advice is simple:

• Start.
• Build small things.
• Learn deliberately.
• Understand your tools.
• Think carefully about infrastructure.
• Focus on discoverability.
• Be patient with growth.

And most importantly, build things that genuinely interest you.

Because curiosity compounds surprisingly far over time.

I hope you enjoyed this retrospective, found some of it useful, and maybe even felt inspired to build something yourself.
And if you ever have questions, feel free to reach out to me.