{"slug": "2-years-of-programming-chess-apps-my-lessons", "title": "2 Years of Programming Chess Apps: My Lessons", "summary": "After two years of programming more than sixty chess-related projects, the developer behind Chessboard Magic has shared lessons learned from building software while simultaneously learning to play chess. The programmer, who had not coded seriously in over twenty years, deliberately avoided using AI to write code for the first year to rebuild foundational skills in modern web development. The experience highlights how AI-assisted programming raises the ceiling on what individuals can attempt while demanding deeper architectural understanding to avoid compounding complexity.", "body_md": "# 2 Years of Programming Chess Apps: My Lessons\n\n**“A journey of a thousand miles begins with a single step.” - Lao Tzu from the Tao Te Ching**\n\nI 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.\n\nIt has been a strange journey for me for two reasons.\n\nFirst, 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.\n\nSecond, I was still relatively new to chess itself.\n\nI 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.\n\nOddly enough, I now think that combination helped me.\n\nI approached chess software less like a traditional chess programmer and more like a curious outsider asking:\n\n- “What would actually help me improve?”\n- “What information feels missing?”\n- “What makes studying painful?”\n- “What makes it fun?”\n\nThat mindset led me down a rabbit hole that completely consumed the last two years of my life.\n\nIn 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.\n\nThe AI Question\n\nEspecially 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.\n\nAI 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:\n\n“Can I build this?” and start thinking in terms of:\n\n“How far can I realistically push this?”\n\nThat shift changes everything.\n\nOne of the biggest decisions I made early on was intentionally not using AI to write code for me.\n\nAt 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.\n\nI did not want that.\n\nMy primary goal was not simply to release an application. My goal was to learn how to program properly again.\n\nSo for the first year, I made a deliberate choice: I did not use AI to write a single line of code.\n\nThat decision cost me an unbelievable amount of time.\n\nI manually learned React.\n\nI manually learned responsive design.\n\nI manually learned authentication systems, APIs, hosting, databases, caching, optimization, deployment, debugging, and architecture patterns.\n\nThere 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.\n\nLooking back, I do not regret it at all.\n\nBecause 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.\n\nAnd 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.\n\nAt small scale, AI-generated fixes can feel magical.\n\nAt large scale, they can become chaos if you do not understand what the system is actually doing.\n\nWhat eventually changed for me was not my opinion on AI, but how I used it.\n\nI stopped viewing AI as a code generator and started viewing it as an interactive documentation system.\n\nThat was the breakthrough.\n\nInstead of asking:\n\n“Build this for me.”\n\nI started asking:\n\n- “What are the trade-offs between these two libraries?”\n- “How does this technology scale?”\n- “What are the limitations of this hosting model?”\n- “Why would I choose this database over another?”\n- “What are the common mistakes people make with this architecture?”\n\nThat was where AI became incredibly powerful.\n\nIt became a brainstorming partner.\n\nA research assistant.\n\nA documentation explainer.\n\nA second opinion.\n\nA debugging companion.\n\nBut importantly, I still wanted to understand the answer.\n\nI think this distinction matters a lot.\n\nAI 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.\n\nBut long-term maintainable software still requires thought.\n\nIt requires understanding trade-offs.\n\nIt requires architectural thinking.\n\nIt requires knowing why something works, not just that it currently works.\n\nAnd honestly, learning those fundamentals is slow.\n\nThere is no shortcut around that.\n\nIf there is one lesson I would summarize from this entire section, it is this:\n\nAI is an incredible accelerator, but it can also become a crutch.\n\nIf your goal is only to produce output quickly, AI can do that.\n\nIf your goal is to build stable systems and genuinely improve as an engineer, you still need to develop understanding yourself.\n\nThe 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.\n\nInfrastructure, Hosting, and the Reality of Running a Web Product\n\nOne 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.\n\nCreating a small HTML page or JavaScript demo is relatively easy today.\n\nRunning a real platform is something else entirely.\n\nThe 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.\n\nAnd infrastructure decisions matter a lot.\n\nOne of the first things I learned is that every hosting approach comes with trade-offs.\n\nPlatform-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.\n\nAuthentication.\n\nDatabases.\n\nStorage.\n\nAPIs.\n\nServerless functionality.\n\nAnalytics integrations.\n\nFor solo developers, that speed is extremely valuable.\n\nMeanwhile deployment-focused platforms like Vercel or Netlify make deployment almost absurdly simple.\n\nPush to GitHub and your site updates automatically.\n\nOn 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.\n\nThere is no universally correct answer.\n\nIt depends entirely on:\n\n- What you are building\n- Your technical skill level\n- Your expected traffic\n- Your budget\n- Your long-term goals\n- How much operational responsibility you want\n\nAI can help explain these options, but ultimately you still need to understand your own use case.\n\nOne thing that became very apparent to me is that cloud costs are often not where beginners expect them to be.\n\nPeople think about storage first.\n\nIn reality, bandwidth and operations can become the bigger issue.\n\nHow much data are you transferring?\n\nHow many database reads are occurring?\n\nHow often are users downloading large files?\n\nAre you repeatedly transferring data that could be cached locally?\n\nThese questions matter because every architectural decision eventually turns into a cost decision.\n\nOne of the most valuable things I discovered was Cloudflare.\n\nCaching, CDN distribution, bandwidth optimization, DNS management, rate limiting, and security protections became a huge part of how I thought about performance and scalability.\n\nBefore building web applications, I honestly never thought much about global delivery infrastructure.\n\nNow I think about it constantly.\n\nThe deeper you go into software development, the more you realize programming is only part of the problem.\n\nThe rest is systems design.\n\nAnd 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.\n\nBrainstorm with AI.\n\nRead discussions online.\n\nResearch trade-offs.\n\nThink about scale before you need it.\n\nThink about costs before they surprise you.\n\nBecause changing infrastructure decisions later can become very expensive, both financially and technically.\n\nMobile-First Thinking\n\nFrom the beginning, I always viewed my applications through a mobile-first lens.\n\nPart of that is simply reality.\n\nSmartphones are everywhere now.\n\nFor many people globally, mobile devices are their primary computing platform. A huge percentage of web traffic today comes from phones, not desktops.\n\nAnd chess fits mobile usage patterns perfectly.\n\nPeople solve puzzles while commuting.\n\nReview openings during lunch breaks.\n\nAnalyze games in bed.\n\nBrowse content casually throughout the day.\n\nChess is one of those activities that naturally fits short sessions and mobile interaction.\n\nThat means responsive design is no longer optional.\n\nIf your application works beautifully on desktop but feels frustrating on mobile, you are probably limiting your growth dramatically.\n\nAnother thing I realized early was that responsive web applications can very easily become mobile applications themselves.\n\nFrameworks like Ionic Capacitor make it surprisingly straightforward to wrap responsive websites into Android and iOS applications.\n\nThat changes how you think about architecture.\n\nYou are no longer just designing a website.\n\nYou are potentially designing an application ecosystem.\n\nMobile responsiveness affects:\n\n- Layout decisions\n- Navigation\n- Rendering performance\n- Touch interactions\n- Data density\n- Typography\n- Load times\n- User retention\n\nI learned very quickly that designing desktop-first and then trying to “shrink it down later” is painful.\n\nIt is much easier to design with constraints first.\n\nFor UI development, I eventually chose Material UI.\n\nFor solo development, it was an excellent choice.\n\nOut of the box, applications already look reasonably polished. The component ecosystem is huge. Documentation is strong. It accelerates development massively.\n\nThat said, it definitely has quirks.\n\nAs applications become large, styling consistency, rendering behavior, dependency management, and customization complexity can become challenging.\n\nBut overall, it allowed me to focus far more on functionality rather than rebuilding UI systems entirely from scratch.\n\nAnd for a solo developer trying to move quickly, that trade-off made complete sense.\n\nUnderstanding Your Users\n\nOne thing I gradually learned is that building software is not really about software.\n\nIt is about people.\n\nChess alone has hundreds of millions of players worldwide, ranging from absolute beginners casually solving puzzles on their phones to professional players preparing for tournaments.\n\nThat means there is room for many different kinds of products.\n\nBut it also means you cannot build for everyone.\n\nOne of the biggest mistakes developers make is trying to create something that appeals to every possible user.\n\nIn reality, the strongest products usually solve a very specific problem for a very specific type of person.\n\nYou need to ask:\n\n- Who is this for?\n- Why would they use it?\n- What problem does it solve?\n- What emotional response are they looking for?\n- Convenience?\n- Improvement?\n- Competition?\n- Entertainment?\n- Curiosity?\n\nThis is actually a large part of what product managers do in industry.\n\nPeople often think product design is simply:\n\n“Come up with an idea and build it.”\n\nIn reality, product thinking is usually much deeper than that.\n\nA good product manager spends enormous amounts of time thinking about:\n\n- User behaviour\n- Friction points\n- Retention\n- Engagement\n- Discoverability\n- User psychology\n- Feature prioritization\n- Feedback loops\n- Onboarding\n- Simplicity versus flexibility\n\nA lot of software development is ultimately about reducing friction.\n\n- Every extra click.\n- Every confusing menu.\n- Every slow loading page.\n- Every unclear workflow.\n\nAll of these things affect whether people continue using your application.\n\nOne thing I found especially interesting over the last two years is how different users often want completely different things from the exact same platform.\n\nSome users want deep analysis.\n\nSome want simplicity.\n\nSome want entertainment.\n\nSome want efficiency.\n\nSome want structure.\n\nSome want experimentation.\n\nAnd balancing those competing needs becomes surprisingly difficult as applications grow.\n\nIn many ways, product development becomes a constant exercise in compromise.\n\nOne lesson I learned fairly early was that your first users are incredibly important.\n\nNot just because they use the product, but because they become your best testers.\n\nOver the last two years, I have had several early users who consistently provided feedback, reported issues, suggested ideas, and helped refine the applications significantly.\n\nThat kind of feedback is incredibly valuable because real users interact with software very differently from how developers imagine they will.\n\nUsers will:\n\n- Misunderstand workflows\n- Click unexpected things\n- Use features incorrectly\n- Expose edge cases\n- Reveal friction points\n- Ask questions you never considered\n\nAnd honestly, that is a good thing.\n\nBecause those interactions help shape the product into something far more usable than you could have designed entirely alone.\n\nI think many successful applications are not built purely by brilliant developers sitting in isolation.\n\nThey are refined gradually through constant interaction between creators and users.\n\nAnd that process can be incredibly rewarding when you embrace it rather than resist it.\n\nUnderstanding Your End Game\n\nOne of the most important questions you need to ask yourself is:\n\n“What is the actual goal here?”\n\nFor me, the answer was never purely financial.\n\nI work in the BI space professionally, and I could already see that general programming skills were becoming increasingly valuable far outside traditional software engineering.\n\nWeb applications.\n\nAutomation.\n\nAI integrations.\n\nInternal tools.\n\nData systems.\n\nEmbedded applications.\n\nThe lines between disciplines are blurring rapidly.\n\nChess simply became the vehicle I used to learn through.\n\nThat framing changed everything for me.\n\nBecause if your primary goal is learning, then every application becomes useful, even if it never makes money.\n\nAfter the first year, I started realizing something interesting:\n\nEach application I built was increasing my skill ceiling.\n\nEvery project introduced:\n\n- A new architecture challenge\n- A new optimization problem\n- A new UI pattern\n- A new scaling issue\n- A new data problem\n- A new integration problem\n\nSo I intentionally started treating applications as stepping stones.\n\nThe goal was not necessarily:\n\n“Build the perfect app.”\n\nThe goal became:\n\n“Build something that forces me to learn.”\n\nIronically, that approach also created another unexpected benefit:\n\nOrganic traffic.\n\nAt first, many of my smaller applications were simply experiments.\n\nBut over time, they started getting indexed by search engines.\n\nThat turned out to be incredibly important.\n\nToday there are millions of applications online competing for attention. Building something good is not enough. People need to discover it.\n\nAnd discoverability is hard.\n\nI made a conscious decision very early on not to spend money on paid advertising.\n\nInstead, I focused on:\n\n- Search discoverability\n- Useful tools\n- Consistent releases\n- Shareable features\n- SEO-friendly content\n- Word of mouth\n- Building genuinely useful applications\n\nOver time, that compounded.\n\nToday 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.\n\nThe rest comes mostly from occasional Lichess mentions and word of mouth.\n\nTo me, that was one of the biggest lessons:\n\nDistribution matters.\n\nYou can build an amazing application that nobody ever finds.\n\nAnd if your goal is eventually commercial success, discoverability may matter just as much as engineering quality.\n\nOne thing I also underestimated early on was how important SEO and discoverability actually are.\n\nA lot of developers think:\n\n“If I build something good, users will naturally appear.”\n\nUnfortunately, the internet does not really work like that anymore.\n\nThere are millions of websites competing for attention.\n\nEven genuinely useful products can disappear into obscurity if nobody ever discovers them.\n\nThis is why SEO specialists exist as entire professions.\n\nGood SEO is not just stuffing keywords onto a page. Modern SEO is often about:\n\n- Information architecture\n- Page structure\n- Performance\n- Mobile responsiveness\n- Internal linking\n- User retention\n- Search intent\n- Content strategy\n- Consistency\n- Technical optimization\n\nIn many ways, search engines are trying to answer a simple question:\n\n“Does this page genuinely help people?”\n\nThe frustrating reality is that discoverability can take a very long time.\n\nFor months, sometimes years, it can feel like nobody is using what you build.\n\nThen gradually pages start indexing.\n\nTraffic slowly compounds.\n\nSearch engines begin understanding your site.\n\nUsers start sharing links.\n\nAnd momentum slowly builds.\n\nI think this is one reason why many developers quit too early.\n\nThe feedback loop for discoverability is incredibly slow.\n\nOne thing that helped me significantly was building many smaller applications instead of putting everything into one giant flagship project.\n\nEach smaller application became another entry point into the platform.\n\nAnother indexed page.\n\nAnother searchable feature.\n\nAnother way for users to discover the site organically.\n\nOver time, that compounds surprisingly well.\n\nSolo Development vs Building With Others\n\nAnother major lesson I learned over the last two years is that solo development is both incredibly empowering and incredibly exhausting.\n\nThere is something deeply satisfying about building an entire platform yourself.\n\nYou control the vision.\n\nYou control the architecture.\n\nYou move quickly.\n\nYou make decisions instantly.\n\nYou are not waiting for meetings, approvals, or alignment.\n\nFor learning, solo development can be amazing because you are forced to touch every part of the stack:\n\n- Frontend.\n- Backend.\n- Infrastructure.\n- Databases.\n- Authentication.\n- Optimization.\n- Product design.\n- Deployment.\n- Analytics.\n- SEO.\n- Support.\n\nYou become a generalist very quickly.\n\nAnd honestly, I think that broad exposure accelerated my growth enormously.\n\nBut solo development also comes with real downsides.\n\nYou 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.\n\nThere is always another issue to fix.\n\nAnother feature idea.\n\nAnother optimization.\n\nAnother bug.\n\nAnother deployment.\n\nAnother user request.\n\nAnd burnout is very real.\n\nOne thing I increasingly understand is why startups and companies build teams rather than relying on single individuals forever.\n\nCollaboration changes the experience dramatically.\n\nWorking with friends or people who share the same interests can make the journey significantly more enjoyable.\n\nYou distribute responsibility.\n\nYou gain different perspectives.\n\nYou challenge each other's ideas.\n\nYou stay motivated during slower periods.\n\nAnd perhaps most importantly, you stop feeling like you are carrying the entire project mentally by yourself.\n\nToday it is easier than ever to find people with similar interests online.\n\nForums.\n\nDiscord communities.\n\nReddit communities.\n\nOpen-source projects.\n\nChess communities.\n\nDeveloper groups.\n\nThere are thousands of people experimenting, learning, and building things together.\n\nAnd honestly, I think many developers underestimate how valuable that social aspect can become over long periods of time.\n\nBecause building software over multiple years is not just a technical challenge.\n\nIt is an emotional and psychological one as well.\n\nThere will absolutely be periods where motivation disappears.\n\nPeriods where progress feels invisible.\n\nPeriods where you question whether anyone cares about what you are building.\n\nHaving other people around you can help tremendously during those moments.\n\nAt the same time, solo development does offer something unique:\n\nA direct relationship between your ideas and the final product.\n\nThere is something very pure about that.\n\nAnd I think both approaches have their own strengths.\n\nSome people thrive in teams.\n\nSome people thrive independently.\n\nMost people probably benefit from a mixture of both.\n\nThe Brutal Mathematics of Monetization\n\nI think one of the biggest misconceptions people have about software products is how difficult monetization actually is.\n\nEspecially today.\n\nPeople often imagine:\n\n“Build a good application, get users, make money.”\n\nReality is usually far harsher than that.\n\nMost modern products operate somewhere within a freemium model:\n\nProvide a large amount of value for free, then hope a small percentage of users convert into paying customers.\n\nThis model exists because acquiring users is extremely difficult.\n\nEven some of the largest technology companies in the world lose money initially to acquire and retain users at scale.\n\nUser growth itself has value.\n\nAnd for smaller developers, this creates a difficult balancing act.\n\nYou need enough free functionality for people to care about your product at all.\n\nBut you also need enough premium value for some users to justify paying.\n\nWhen you actually run the numbers, things become sobering very quickly.\n\nFor example, my Repertoire Builder has nearly 5,000 registered users, around 400 monthly active users, and roughly 40 paying subscribers after about a year.\n\nThankfully, my personal goals were never primarily financial, so I view this positively.\n\nBut if someone enters this space expecting fast financial returns, reality can hit hard.\n\nLet us imagine a simplified example.\n\nSuppose:\n\n- 10,000 users register\n- 1,000 become active monthly users\n- 5% convert to paid subscriptions\n- The average subscription is $5/month\n\nInitially that sounds decent.\n\nBut then you subtract:\n\n- Hosting costs\n- Storage costs\n- Database costs\n- Bandwidth costs\n- AI API costs\n- Payment processing fees\n- Taxes\n- Infrastructure scaling\n- Customer support\n- Maintenance time\n- Development time\n- Opportunity cost\n\nSuddenly the economics look very different.\n\nEducational applications are especially challenging because users often expect enormous amounts of free value.\n\nChess users in particular are already accustomed to extremely high-quality free platforms.\n\nThat creates a very competitive environment.\n\nThis is why understanding your motivation matters so much.\n\nAre you building:\n\n- To learn?\n- To experiment?\n- To create a portfolio?\n- To solve a problem?\n- To build a business?\n- To eventually raise investment?\n- To create a side income?\n\nThere is no wrong answer.\n\nBut your strategy should align with your actual goal.\n\nBecause software development can easily consume years of your life.\n\nYou should understand what success looks like for you personally before you begin.\n\nFinal Thoughts\n\nDespite all the challenges, I honestly think this is one of the most exciting periods ever to be a creator.\n\nAI is lowering barriers dramatically.\n\nMore 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.\n\nFor every thousand projects created, maybe one ends up being genuinely transformative.\n\nBut those transformative ideas only emerge because people are willing to experiment in the first place.\n\nAnd experimentation is becoming more accessible than ever.\n\nTwo years ago, I was someone returning to programming after more than two decades away from the field, while still being relatively inexperienced at chess.\n\nToday, 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.\n\nAnd honestly, I still feel like I am learning every single day.\n\nSo if you are thinking about building something yourself, my advice is simple:\n\n- Start.\n- Build small things.\n- Learn deliberately.\n- Understand your tools.\n- Think carefully about infrastructure.\n- Focus on discoverability.\n- Be patient with growth.\n\nAnd most importantly, build things that genuinely interest you.\n\nBecause curiosity compounds surprisingly far over time.\n\nI hope you enjoyed this retrospective, found some of it useful, and maybe even felt inspired to build something yourself.\n\nAnd if you ever have questions, feel free to reach out to me.\n\n[Discuss this blog post in the forum](/ublog/PoajTjaa/discuss)\n\n## You may also like\n\n[HollowLeaf](/@/HollowLeaf/blog/notation-trainer/QWSlH3s7)\n\n## Notation Trainer\n\nPractising Chess Notation[thibault](/@/thibault/blog/how-i-started-building-lichess/JwtcE0KO)\n\n## How I started building Lichess\n\nI get this question sometimes. How did you decide to make a chess server? The truth is, I didn't.[TotalNoob69](/@/TotalNoob69/blog/customizing-lichess-pieces-boards-sounds-and-more-with-lichess-tools/1nQoshDg)\n\n## Customizing Lichess pieces, boards, sounds and more with LiChess Tools\n\n... not exactly technical, but many people requested this[CM HGabor](/@/HGabor/blog/how-titled-players-lie-to-you/ickXiOem)\n\n## How titled players lie to you\n\nThis post is a word of warning for the average club player. As the chess world is becoming increasin…[ChessMonitor_Stats](/@/ChessMonitor_Stats/blog/where-do-grandmasters-play-chess-lichess-vs-chesscom/Zoi9GqPK)\n\n## Where do Grandmasters play Chess? - Lichess vs. Chess.com\n\nThis is the first large-scale analysis of Grandmaster activity across Chess.com and Lichess from 200…[HollowLeaf](/@/HollowLeaf/blog/fischer-random-trainer/wnaAfPDg)", "url": "https://wpnews.pro/news/2-years-of-programming-chess-apps-my-lessons", "canonical_source": "https://lichess.org/@/HollowLeaf/blog/2-years-of-programming-chess-apps-my-lessons/PoajTjaa", "published_at": "2026-06-04 10:17:29+00:00", "updated_at": "2026-06-04 10:48:45.446244+00:00", "lang": "en", "topics": ["ai-tools"], "entities": ["Chessboard Magic", "Lao Tzu"], "alternates": {"html": "https://wpnews.pro/news/2-years-of-programming-chess-apps-my-lessons", "markdown": "https://wpnews.pro/news/2-years-of-programming-chess-apps-my-lessons.md", "text": "https://wpnews.pro/news/2-years-of-programming-chess-apps-my-lessons.txt", "jsonld": "https://wpnews.pro/news/2-years-of-programming-chess-apps-my-lessons.jsonld"}}