TL;DR: Founded Arcadia (Komoditi.io) in 2023 to build a trading card marketplace. Went through multiple complete rebuilds trying to perfect the architecture while accommodating an inexperienced team member. Lost momentum between technical challenges, constant refactoring, and lack of market validation.
Key lessons: ship faster with smaller MVPs, choose stacks your team can execute with, leverage SaaS tools instead of building everything custom, and validate with users before optimising architecture.
🛣️ The Journey
In 2023, I founded Arcadia (operating as Komoditi.io Pte Ltd) with a clear vision: to build the next generation trading card platform. The idea was ambitious yet simple — create a marketplace where collectors could buy, sell, and trade cards from Pokemon, Magic: The Gathering, Yu-Gi-Oh!, and other popular franchises, all while connecting through secure real-time messaging.
As both founder and core software developer, I wore every hat imaginable. I architected the database schemas, designed the APIs, built the frontend interfaces, and debugged production issues at 3 AM. The early days were exhilarating. Every line of code felt like progress, every feature launch like a small victory.
🗻 The Downhill
While the technical rebuilds were challenging, they weren't the only factors that led to Arcadia's decline. The journey downhill was shaped by several interconnected issues that compounded over time.
1. 🛠️ The Rebuilds
But building a platform from the ground up is rarely a straight path. What started as one codebase evolved through several complete rebuilds:
- The first version was scrappy and functional, but the architecture couldn't scale with our ambitions
- The second rebuild addressed technical debt but introduced new complexities in the messaging system
- Each subsequent iteration promised to be "the final one," yet always revealed new fundamental issues that demanded starting over
With each rebuild, I told myself it would be different this time. That the lessons learned would finally translate into a stable, scalable foundation. But the cycle continued — build, discover limitations, tear down, rebuild.
2. 👬 The Team Factor
Part of the rebuild cycle stemmed from a challenge I hadn't fully anticipated: working with inexperienced programmers on the team. What seemed like an opportunity to grow the team and distribute the workload became another source of complexity.
I spent more time simplifying architectures and refactoring complex systems into basic patterns than actually developing new features. Code reviews and mentorship consumed hours that could have gone to feature development, while each rebuild had to balance technical needs with team capabilities.
The codebase became a compromise — too advanced for my teammate to work with confidently, yet too simplified to handle the platform's growing complexity, especially when higher-level languages required more tests that increased an already large software codebase. This tension fuelled the rebuild cycle. I'd build something robust, realise it exceeded the team's capability to maintain, then rebuild it simpler, only to hit scalability walls again.
In hindsight, the mismatch between technical ambition and team capability was a critical factor I underestimated. Building the right product requires building with the right team — or being honest about going solo from the start.
🌒 The Fade
Two critical factors accelerated the fade: my unwillingness to commit fully to an uncertain market, and the harsh reality of over-extending my initial drive without the validation needed to sustain it.
1. 😮💨 Over-extending Initial Motivation
Somewhere between the architectural decisions and the endless refactoring, something shifted. The excitement that once fuelled late-night coding sessions began to dim. The vision that seemed so clear at the start became obscured by the weight of technical challenges and the isolation of being a solo technical founder.
The passion that drove me to start Arcadia didn't disappear all at once. It eroded gradually — with each rebuild that didn't quite solve the problems I'd hoped it would, with each feature that took twice as long to implement as planned, with each moment of doubt about whether the market even wanted what I was building.
By 2025, the drive to continue had faded. Not from a single failure, but from the accumulated exhaustion of fighting the same battles repeatedly. The "Coming Soon" page remained, a quiet marker of ambitions that once burned bright but eventually flickered out.
2. 🎲 Unwilling to Bet the Farm
Beyond the technical and team challenges, I faced a fundamental business reality: the uncertainty of the Southeast Asian trading card market.
The trading card market in SEA was still nascent compared to North America or Europe. While passionate collectors and growing communities existed, the critical question remained — was the market large and mature enough to support a venture-backed platform? Could we achieve the scale needed to justify significant investment?
Success would likely require blitzscaling — rapidly burning capital to capture market share before competitors established themselves. But blitzscaling demands conviction, and I lacked confidence in the market's readiness.
The math was sobering: aggressive scaling required a clear path to ROI within two years. That meant not just building the right product, but timing the market perfectly, executing flawlessly on customer acquisition, and betting that trading card enthusiasm in SEA would grow fast enough to support our burn rate.
I wasn't willing to bet everything on an unproven market hypothesis. The combination of technical challenges, team limitations, and market uncertainty created a risk profile I couldn't justify — not to potential investors, and more importantly, not to myself.
Sometimes the hardest decision is recognising when the timing isn't right, even if the idea still has merit.
🏫 The Lessons
Looking back, this journey revealed several hard truths about building a startup as a technical founder.
1. 🚤 Fail Faster, Ship Smaller
The biggest mistake was not failing faster. I spent months perfecting architectures and rebuilding systems when I should have been shipping smaller MVPs and getting real market feedback. Each rebuild delayed the moment of truth — would users actually want this? I optimized for technical elegance when I should have optimized for learning velocity.
A scrappy MVP that reaches users in two months teaches you more than a perfectly engineered platform that launches in twelve. The market doesn't care about your architecture. It cares about whether you solve their problem.
2. 🖥️ Stack Choices Matter
Through the multiple rebuilds, I cycled through different technology stacks — Python, Rust, Expo, Flutter — each with their own tradeoffs. I learned the hard way that every language and framework has different demands:
- Python offered rapid development but performance concerns at scale
- Rust promised speed and safety but came with a steep learning curve and slower iteration
- Expo and Flutter for mobile had different ecosystem maturity and deployment complexities
The constant switching was partly driven by trying to find the perfect stack, when in reality the perfect stack is the one your team can execute with and ship fast. The technology choice should serve the team and timeline, not the other way around.
3. 🧱 SaaS Over Custom
Perhaps the most expensive lesson: I built too much from scratch. Authentication systems, messaging infrastructure, payment processing — all things that mature SaaS solutions handle better, faster, and cheaper than a small team ever could.
I confused building the platform with building every component of the platform. Understanding the landscape of SaaS tools for application development — from Firebase and Supabase to Stripe and Twilio — could have freed up months of development time to focus on the actual unique value proposition.
The Real Takeaway
Technical excellence alone isn't enough. Motivation is a finite resource, and rebuilding without validation drains it faster than anything else. Sometimes the bravest thing a founder can do isn't to persist — it's to recognise when it's time to step back, learn the lessons, and carry them forward to the next venture.
Image Gallery
Gallery
Made with Bullet