From a Nokia Phone to RexiO: The Story Behind Everything
A founder's honest, unfiltered account of building RexiO — from a Nokia button phone to launching a Bangla-first AI platform, covering the failures, the rewrites, the lost relationship that redirected his life, and the belief that great technology doesn't require Silicon Valley to begin.
RexiO: The Story Behind Everything
By Mohammad Sijan, Founder & Lead Architect, SpritEX AI
Chapter 1 — Before RexiO
I'm writing this one day after RexiO officially launched.
For the past year and a half, most people who knew me only saw one thing: someone who was always working. Friends would message me and wait hours for a reply. Family would ask what I was building, and I'd struggle to explain it in a way that made sense. My laptop was almost always open. Some nights I slept normally. Some nights I didn't sleep at all.
Yesterday, after months of building, rewriting, deleting, rebuilding, testing, and doubting myself more times than I can count, RexiO finally went live.
People congratulated me. Some called it inspiring. Others simply saw another AI product on the internet.
The truth is, none of them saw where it really started.
If I wanted to make this sound impressive, I'd probably begin with artificial intelligence, large language models, or the day I registered the RexiO domain. That would make a cleaner story.
It just wouldn't be the real one.
The real story starts many years earlier, in a small village in Faridpur, Bangladesh, long before I knew what programming was, long before I had ever heard the words startup, machine learning, or artificial intelligence.
I wasn't born into a family of engineers. Nobody around me was building software. Nobody taught me how computers worked. Everything that eventually became RexiO started from simple curiosity.
Looking back now, I don't think curiosity is something you suddenly discover one day. Some people seem to carry it from childhood without realizing it. I was one of them.
Whenever I found something I didn't understand, I wanted to know how it worked. If something broke, I wanted to open it. If someone built something interesting, I wanted to know how they built it.
I wasn't trying to become a software engineer. I wasn't trying to start a company. I just couldn't stop asking "how?"
That single question quietly shaped almost every important decision I've made since.
I grew up in a middle-class family where education mattered more than almost anything else. My parents weren't wealthy, but they never let me feel like I had less than what I genuinely needed. They believed education could change a person's future, and from an early age I tried to live up to that belief.
School became the one place where I consistently felt confident. I usually ranked near the top of my class, and every good result made my parents proud. At the time, I thought those report cards were the biggest achievements of my life.
Years later, I realized they were simply teaching me something much more valuable: keep showing up, keep learning, keep improving. Those habits stayed with me long after the grades stopped mattering.
Back then, I had no idea that one day I'd spend months solving bugs that nobody else could see, train AI models on borrowed GPUs, or build software that people across the country would eventually use.
I was just another kid growing up in a village. And like most kids, I had absolutely no idea what my life was about to become.
That story begins with a Nokia button phone and an internet connection I didn't even understand.
Chapter 2 — A Nokia Phone, Two-Taka Data Packs, and My First Internet Connection
If I had to point to the exact moment everything began, it wasn't when I wrote my first line of code. It wasn't when I built my first website. It wasn't even when I got my first smartphone.
It started much earlier than that.
I was around nine years old when I first came across something called the Internet. To be honest, I had no idea what it actually was. I couldn't explain it. I didn't know how it worked or why it worked.
All I knew was that there was a small "Internet" icon on a Nokia button phone, and somehow, when I opened it, I could see things that weren't stored inside the phone itself. That felt like magic.
Sometimes it connected. Sometimes it didn't. Sometimes the SIM balance disappeared much faster than expected. I had absolutely no understanding of mobile data or network charges back then. I just knew that pressing that little icon somehow opened a window to another world.
Looking back now, it's funny. Today I spend my days building AI systems that process millions of tokens, route requests across multiple models, and communicate with servers spread around the world. Back then, I didn't even understand what happened after pressing one button.
But curiosity doesn't care how much you know. It only cares that you keep asking questions.
A couple of years later, near the end of primary school, my father bought our family's first smartphone — a Microsoft Lumia running Windows Phone. Compared to what people carry today, it was incredibly limited. To me, it felt unlimited.
That phone completely changed how I spent my free time. I created my first Facebook account. I discovered YouTube. I learned how to install apps. I spent hours inside Opera Mini because it used less data than other browsers. Back then, every megabyte mattered.
I still remember buying those tiny internet packages — two taka for two megabytes. If I was careful, I could make that last for several days. I learned very quickly, not because someone taught me how to save data, but because running out of data meant waiting until I could afford more.
Most people remember their first smartphone because of the games. I remember it because it made the internet feel real. It wasn't just something I occasionally opened anymore. It became a place I wanted to explore.
Like almost every kid my age, I played games too — Clash of Clans was probably my favorite. But even while playing, I found myself more interested in everything around the game than the game itself. How were these games made? How did millions of people connect at the same time? How could someone in another country build something that appeared on my phone in a village in Bangladesh?
Nobody around me had answers to questions like these. So I started looking for them myself.
Around the same time, something else caught my attention: English. I wasn't good at it — not even close. If I had to estimate now, maybe I understood sixty or seventy percent of what I was trying to say. The grammar was terrible. The pronunciation wasn't much better. But I didn't really care.
Whenever I saw foreigners online — or occasionally in real life — I wanted to talk to them. "Where are you from?" "What's your name?" "How are you?" Sometimes my English was wrong. Sometimes they probably didn't understand me. It didn't matter. Every conversation taught me something.
I didn't know it then, but that willingness to speak imperfect English would later become one of the biggest advantages of my career. Almost every piece of technical documentation, every programming tutorial, every research paper, every AI discussion, was written in English. If I had waited until I felt fluent before using the language, I probably wouldn't have started building anything for years.
Instead, I learned while doing. That pattern would repeat itself again and again throughout my life. I never waited until I felt completely ready. I learned by building, by breaking things, by making mistakes. And that habit eventually became far more valuable than perfect English ever could have been.
At the time, though, I was just a kid with a Windows phone, a tiny internet package, and an endless list of questions. I still didn't know what programming was. I still had never built a website. I still had no idea what direction my life was heading.
That changed after I got into Faridpur Zilla School. Without realizing it, I had just walked into the next chapter of my life.
Chapter 3 — Faridpur Zilla School
Looking back, there are a few moments in life that quietly change everything. At the time, they don't feel extraordinary. They're just another day, another exam, another decision. Getting admitted to Faridpur Zilla School was one of those moments.
I was in Class Five when I sat for the admission test. Like most students, I wanted to get in because everyone knew it was the best school in the district. Studying there meant something. Parents wanted it for their children. Students dreamed about it. Teachers respected it.
I didn't spend months preparing. I simply took the exam and hoped for the best. When the results were published, I had secured the 11th position.
I still remember how happy my family was. Relatives came to congratulate us. Neighbors stopped by. Even people I barely knew seemed genuinely happy for me. Back then, I didn't fully understand why that achievement meant so much to everyone around me. Today, I do.
For many families in villages like mine, education isn't just education. It's possibility. It represents a future that might be a little bigger than the present.
That school gave me much more than better teachers. It gave me a different environment. I met students who thought differently. I became more competitive. I became more confident. Most importantly, I slowly started believing that maybe I could build things that reached beyond my own village.
Around that same period, another thing happened that would quietly shape the rest of my life. My father, with the help of my uncle who was living in Singapore, bought a Xiaomi Redmi Note 6 Pro. At first, it wasn't exactly "my phone" — it belonged to the family. Eventually, it became mine.
I honestly don't think anyone in my family realized what they had just given me. To them, it was a smartphone. To me, it became a classroom. Not a single day went by without learning something new from it. I watched tutorials, read articles, installed random apps just to see what they did. If I found something interesting, I'd spend hours trying to understand it.
There was another person who unknowingly influenced me during that time. An older brother from our area used to come tutor me in the evenings. If I'm completely honest, I probably spent more time asking to borrow his phone than actually studying. Whenever he let me use it, I'd disappear into the internet — games, Facebook, technology blogs, anything related to computers or websites, anything that looked complicated enough to make me curious.
One website quickly became part of my daily routine: TrickBD. For many Bangladeshi teenagers interested in technology, TrickBD was more than just a website. It was where people shared what they had learned — tutorials, tips, apps, website tricks, programming basics. I didn't know it then, but I was teaching myself through thousands of small pieces of information. Not through a structured course, not through expensive books — just curiosity, one article after another.
When I ran out of internet data, Facebook Free Basics became my backup. It wasn't the full internet, but it was enough to keep learning. Enough to keep exploring. Enough to keep asking "what's next?"
Then one evening, something happened that completely changed the direction of my life. That same older brother showed me a website he had built. It wasn't some massive application. It wasn't beautifully designed. It wasn't technically impressive by today's standards. He had built it using Wapka, following tutorials from TrickBD.
But none of that mattered. Because it was the first time I had seen an ordinary person create something that existed on the internet. Until then, websites felt like they simply appeared. Facebook existed. Google existed. YouTube existed. I never stopped to think that someone had actually built them.
Watching him open a website that he had created completely changed my perspective. For the first time, I realized something incredibly simple: websites aren't magic. People build them. And if people build them, maybe I could too.
That single thought refused to leave my mind. From that day forward, I wasn't just using the internet anymore. I wanted to understand how it was made.
I had absolutely no idea that this curiosity would eventually lead me toward programming, cybersecurity, artificial intelligence, and finally RexiO. At the time, I just wanted to build my own website. I didn't know HTML. I didn't know CSS. I didn't know PHP. I didn't even know where to begin.
But I was about to discover something that would define almost every project I've ever built since: you don't have to know everything before you start. Sometimes, starting is how you learn everything.
Chapter 4 — The First Website I Had No Idea How to Build
After seeing that website built with Wapka, I couldn't stop thinking about it. For days, I kept asking myself the same question: how do people actually build websites?
I didn't have anyone to teach me. There were no programming classes, no mentors, no roadmap. Just an internet connection that disappeared whenever my data pack ran out.
So I did what I had always done. I started searching. Every answer led to another question. Every tutorial introduced five new things I didn't understand. Most of those tutorials came from TrickBD. Some came from random blogs. Others came from YouTube videos with terrible audio quality that I watched over and over again until I understood what the person was trying to explain.
I wasn't learning programming — at least, that's not what it felt like. I was solving one tiny problem at a time.
Eventually, I created my first Wapka site. It was terrible. I don't think anyone would have called it a good website. But it existed. And that mattered, because for the first time in my life, something on the internet existed because I had made it.
That feeling is difficult to explain. Even today, after building much larger systems, I still remember how exciting that first website felt.
Once I realized I could build one website, I immediately wanted to build another. Soon Wapka wasn't enough anymore. I moved to Wapkiz, then started modifying templates instead of simply using them. Whenever I saw a feature on another website, I'd try to recreate it. Usually, I'd fail. Sometimes I'd accidentally break everything, then spend hours trying to fix the mess I had created.
Without realizing it, I had started teaching myself one of the most important skills in software engineering: debugging. Nobody enjoys debugging. But every developer eventually learns that building software isn't about writing perfect code — it's about refusing to give up until you understand why something doesn't work. That lesson came much earlier than programming itself.
Around that time, something happened that still makes me smile when I think about it. Before I even knew HTML properly, before I understood CSS, before I had any real idea what I was doing, someone on Facebook asked me if I could build a website.
Looking back, I probably should have said no. Instead, I said yes.
I had around twenty taka of mobile balance. That was enough to stay online while I figured things out. I spent weeks experimenting, reading tutorials, breaking things, starting over, and slowly putting together something that resembled a website. There wasn't much design. There was almost no styling. Calling it "responsive" would have been generous.
But it worked. More importantly, it worked well enough for the person who asked for it.
When I finally delivered it, I felt something I'd never experienced before. Someone had trusted me to build something. And despite knowing almost nothing when I started, I had actually finished it.
That project didn't make me rich. It didn't go viral. It didn't change the internet. But it changed me. It taught me something that has stayed with me ever since: you don't become ready first. You become ready because you accept challenges before you feel prepared.
That first client unknowingly gave me much more than my first opportunity. They gave me confidence.
After that, learning became almost addictive. Every new project exposed another weakness. If I couldn't solve something, I'd spend hours searching until I could. One technology naturally led to another — Wapka became Wapkiz, Wapkiz led me toward WordPress, WordPress made me curious about PHP, PHP introduced me to databases, and databases introduced me to backend development. Every answer unlocked another door.
There was never a grand plan. I wasn't thinking about becoming a founder. I wasn't thinking about building an AI company. I wasn't even thinking about making a career out of programming. I was simply following my curiosity wherever it wanted to go.
Somewhere along the way, people around me slowly started noticing. Whenever someone's Facebook account had a problem, whenever an Instagram account got hacked, whenever a website stopped working, my name somehow entered the conversation. "Ask Sijan." "I think he knows." Sometimes I actually knew. Sometimes I had absolutely no idea. But I'd still spend hours trying to figure it out.
That's how I slowly drifted into cybersecurity — not because I planned to, but because people brought me problems, and I became interested in solving them.
Looking back now, I realize something interesting. None of the skills that eventually helped me build RexiO came from a single course. They came from hundreds of small problems: a broken website, a hacked account, a missing feature, a confused client, a tutorial that didn't explain enough. Each problem taught me one small lesson. Years later, those lessons came together to form something much bigger.
I still didn't know it yet. But I was no longer just a student who liked technology. Without realizing it, I had started becoming an engineer.
Chapter 5 — 2021
For most of this story, I've talked about technology. But if I'm going to tell the truth, then I can't pretend technology was the only thing shaping my life. It wasn't.
In 2021, I met someone. I'm not going to mention her name. Some stories belong to more than one person, and I don't think it's fair to tell every detail just because I'm writing mine.
What I will say is this: she became one of the most important people in my life.
At that point, I was already building websites. I was taking on projects. I was learning new technologies almost every week. People who knew me probably assumed I was obsessed with work. I wasn't. Not yet.
If you had asked me back then what kind of future I wanted, I probably wouldn't have described a startup. I wouldn't have described building AI. I wouldn't have described spending years creating products. Honestly, I wanted something much simpler — a stable life, meaningful work, the people I cared about close to me. That was enough.
Building things was still my biggest hobby, but it hadn't become my life's mission. There's a difference between enjoying something and deciding to dedicate your life to it. Back then, I was still in the first category.
Life, however, has a strange way of changing priorities. Over time, that relationship came to an end. I'm intentionally leaving the details out — not because they aren't important, but because they belong in the past.
For a while, I felt completely lost. Anyone who's experienced losing someone they genuinely cared about probably understands that feeling. You wake up, you try to continue your day, everything looks normal, nothing feels normal. People often imagine heartbreak as dramatic scenes from movies. In reality, it's usually much quieter. You simply lose interest in things that used to make sense.
I had two choices. I could spend my energy trying to hold onto something that was already over. Or I could put that same energy somewhere else.
At first, building became a distraction. I opened my laptop simply because it kept my mind occupied. One problem became another. One project became two. Hours turned into days. Days turned into weeks. Somewhere along the way, something changed. Work stopped being an escape. It became purpose.
That period completely rewired the way I thought about my future. For the first time in my life, I asked myself a question I had somehow avoided until then: if I'm going to spend years building something, what should it be? Not another website. Not another client project. Not another short-term idea. Something bigger. Something that could genuinely improve people's lives.
I didn't know what that thing was yet. I only knew I wanted to build it.
Looking back now, I don't see that chapter of my life as something negative. Pain has a way of forcing clarity. It removes distractions. It exposes what actually matters. Without that experience, there's a very real chance I would have lived a completely different life. Maybe a quieter one. Maybe a more comfortable one. But probably not this one.
People sometimes ask founders what inspired them to start their company. They expect one dramatic moment, one brilliant idea, one life-changing conversation. The truth is usually much messier. Sometimes companies begin because you become obsessed with solving a problem. Sometimes they begin because you're simply curious. And sometimes, they begin because life pushes you in a direction you never expected to walk.
For me, it was a little bit of all three.
I still didn't know that RexiO would exist. I hadn't written a single line of AI code. I wasn't calling myself a founder. But the person I was becoming had changed. For the first time, I stopped thinking only about building websites. I started thinking about building something that might outlive me.
That question stayed in my head for months. Eventually, it led me somewhere I had never imagined. Artificial intelligence.
Chapter 6 — Falling Into the AI Rabbit Hole
People often ask me when I became interested in artificial intelligence. The honest answer is that I don't know. There wasn't a single moment. It happened slowly.
Long before ChatGPT became a global phenomenon, I was already fascinated by the idea that computers could do more than follow instructions. I spent hours reading about machine learning, recommendation systems, neural networks, and language models, even though I understood only a small part of what I was reading. Most of it went over my head. I kept reading anyway.
That's always been how I learn. I don't wait until everything makes sense before I continue. I keep going until it eventually does.
When ChatGPT launched, like millions of other people, I tried it out. At first, it simply felt impressive. Then it became useful. Very quickly, it became impossible to ignore. For the first time, I wasn't just reading about AI — I was using it every single day.
The more I used it, the more I noticed something interesting. Most people were asking AI to answer questions. I was asking a different question: how is something like this even possible?
That curiosity sent me down another rabbit hole. Transformer architectures. Embeddings. Tokens. Prompt engineering. Retrieval-Augmented Generation. Fine-tuning. Inference. Open-source language models. Every topic led to another. Every research paper introduced concepts I had never heard before.
I wasn't studying AI because someone told me to. I was studying it because I couldn't stop thinking about it.
Around the same time, AI quietly became part of the way I learned everything else. Whenever I got stuck while programming, I'd ask ChatGPT. When I wanted another opinion, I'd ask Claude. When I wanted to compare ideas, I'd ask Gemini. Sometimes they were right. Sometimes they were completely wrong. That turned out to be one of the biggest lessons.
AI shouldn't replace your thinking. It should amplify it. If you blindly accept every answer, you'll build broken software. But if you learn how to question AI, challenge it, and work with it like a collaborator instead of a search engine, it becomes something incredibly powerful.
Looking back, I think that's where my relationship with AI became different from how most people use it. I wasn't trying to find shortcuts. I was trying to understand the technology itself.
Every day I learned something new. Every week I built something slightly more complicated than the week before. Without realizing it, I had started preparing for a project that didn't even exist yet. I just didn't know its name.
That name would eventually become RexiO. But before RexiO, there was another project. One that almost nobody remembers today, because it never launched. Ironically, without that unfinished project, RexiO probably wouldn't exist at all.
Chapter 7 — The Project That Was Never Meant to Become RexiO
By the time AI had become part of my daily workflow, I wasn't planning to build an AI company. In fact, RexiO didn't exist — not even as an idea.
The project I was spending most of my time on was called spritex-social. Very few people have ever heard that name, because it never officially launched. It was supposed to be a social platform. A small group of friends tested early versions, reported bugs, suggested features, and helped me understand what worked and what didn't.
Like almost every side project I'd built before, I kept adding ideas faster than I could finish them. Then one day, I built something that wasn't supposed to be the main feature.
Users would eventually have questions — how do I change my profile, where do I find this setting, how does this feature work. Instead of writing endless documentation, I thought: why not let AI answer those questions?
At the time, that sounded like a small feature. Nothing revolutionary. I connected Google's Gemini API through Google AI Studio, built a simple Retrieval-Augmented Generation (RAG) system, and gave the chatbot access to information about the platform. It worked surprisingly well. Users could ask questions naturally, and instead of searching through help pages, the AI answered them directly.
That was the original purpose. Nothing more.
But something unexpected happened. I found myself spending more time improving the chatbot than improving the social platform itself. Every small improvement made me wonder what else it could do. Could it remember conversations? Could it understand context better? Could it use tools? Could it search for information? Could it complete tasks instead of simply answering questions?
The more questions I asked, the less interested I became in building another social platform. I became obsessed with building a better AI.
Looking back now, I think that was the exact moment the direction of my life changed. Not because I suddenly had a brilliant business idea, but because I had accidentally discovered a problem I genuinely wanted to solve.
For weeks, I couldn't stop thinking about it. The support chatbot slowly became an experiment. The experiment slowly became a prototype. The prototype slowly became an entirely different product. At some point, I had to admit something to myself: I wasn't building spritex-social anymore. I was building something else. Something much bigger.
That's when I made one of the hardest product decisions I've ever made. I stopped. Not because the project had failed. Not because the technology didn't work. Because I realized my attention had already moved somewhere else.
Founders often talk about knowing when to keep going. Almost nobody talks about knowing when to let go. Sometimes the best decision isn't continuing the project you've already invested months into. Sometimes it's having the courage to leave it behind because you've found something even more important.
That's exactly what happened. Spritex-social never became the product I originally imagined. Instead, it became the foundation of everything that came after.
I often think about that first AI chatbot. It wasn't particularly smart. It couldn't reason like today's models. It couldn't remember much. It wasn't even designed to become a product. But without it, there would almost certainly be no RexiO. That tiny support assistant quietly answered the biggest question I'd been asking myself for months: this is what I want to build.
From that point onward, I stopped treating AI as a feature. AI became the product itself.
The next challenge, however, was much bigger. Building a chatbot was easy. Building an AI people could genuinely rely on was something completely different.
Chapter 8 — Building Something Bangladesh Actually Needed
Once I decided to move on from spritex-social, I had a blank canvas in front of me. No users. No roadmap. No investors. No team waiting for instructions. Just an idea that refused to leave my head.
I didn't want to build another ChatGPT clone. The internet already had enough of those. If RexiO was going to exist, it needed a reason to exist. That question became my obsession: what does Bangladesh actually need from AI?
For weeks, I kept asking myself that. The easy answer was obvious — "an AI that supports Bangla." But that didn't feel like enough. Most major AI models already supported Bangla to some extent. Some translated reasonably well. Some even understood local phrases. Supporting Bangla wasn't the real problem.
The real problem was much deeper. Most AI products were designed for a global audience first. Bangladesh was an afterthought. They understood the language. They didn't understand the people. There's a difference. A big difference.
If you ask someone from Bangladesh about university admissions, government services, mobile banking, local businesses, cultural references, or even how people naturally communicate online, context matters just as much as language. Translation alone doesn't solve that.
I didn't want RexiO to sound like an English AI speaking Bangla. I wanted it to think like it belonged here. That idea changed everything. Instead of asking "which model is the smartest," I started asking "which experience feels the most useful for someone in Bangladesh." Those are completely different questions.
Around that time, the first version of SpritEX AI started taking shape. The frontend was incredibly simple — just HTML, CSS, and JavaScript. No fancy frameworks, no complicated architecture. It was enough to prove the idea. Like many early AI projects, it sent requests directly to external APIs. Technically, it worked. But something kept bothering me: I wasn't really building an AI product. I was building an interface for someone else's AI.
That realization changed my priorities overnight. If I wanted RexiO to become something people could genuinely rely on, I needed control — over conversations, routing, prompts, memory, model selection, and everything that happened before and after an AI generated a response.
So I stopped focusing only on the frontend. I built a backend. Node.js became the heart of the project. Not because it was perfect, but because it allowed me to move quickly while I was still figuring things out. Supabase handled authentication, storage, and the database. Every day, another piece of the system slowly came together.
Looking back now, I don't think I was building "features." I was building infrastructure. Most users never notice infrastructure. They notice whether something feels smooth, fast, reliable, natural. That's what I was chasing.
At the same time, I was spending hours every day talking to AI — not just through APIs inside RexiO, but personally. Claude. ChatGPT. Gemini. Perplexity. Sometimes all four on the same problem.
People often ask me whether AI replaced learning. For me, it did the opposite. AI accelerated learning. Instead of spending three days stuck on one concept, I could ask questions, challenge answers, compare different opinions, read documentation, test ideas, and understand things much faster than I ever could alone. I wasn't copying code. I was learning how systems were designed, why certain architectures worked, and why others failed. Every answer raised another question. Every question improved RexiO.
I often joke that AI helped me build an AI. The funny thing is, it's completely true. Without tools like ChatGPT, Claude, and Gemini, RexiO would still have been possible — but it almost certainly wouldn't have happened this quickly. For the first time in history, a single developer could realistically build systems that once required entire engineering teams. That doesn't mean AI replaces engineers. It raises the ceiling for what one engineer can accomplish. I experienced that firsthand.
The more I learned, the more ambitious RexiO became. It stopped being just another chatbot. It slowly evolved into something else — something that could eventually think, remember, search, use tools, and help people solve real problems instead of simply answering questions.
The vision was becoming clearer. The technology, however, was about to become much more complicated.
Chapter 9 — Rebuilding Everything
One of the biggest misconceptions about building software is that progress always moves forward. It doesn't. Sometimes, the biggest progress comes from deleting months of work and starting over. RexiO taught me that lesson more than once.
The early versions of the platform were built with plain HTML, CSS, and JavaScript. At first, I loved how simple everything was — no build tools, no frameworks, no complicated state management. If something broke, I usually knew exactly where to look.
That simplicity didn't last very long. As RexiO grew, so did the complexity. A simple chat interface slowly turned into something much bigger: conversation history, authentication, streaming responses, multiple AI models, user settings, memory, tool execution, file uploads, image generation, voice support. Every new feature added another layer of complexity. Eventually, I reached a point where adding a new feature often meant worrying about breaking three existing ones. That wasn't sustainable.
One night, after staring at the codebase for hours, I admitted something to myself that I had been avoiding: the architecture had reached its limit. I had two choices — keep patching the old system, or rebuild it properly.
Rewriting months of work is terrifying. Not because it's technically difficult, but because it feels like you're throwing away hundreds of hours of your life. For several days, I kept asking myself the same questions: what if the rewrite takes months, what if I introduce even more bugs, what if I never reach the same level of stability again. Eventually, another question became more important: what happens if I don't rewrite it? I already knew the answer. Sooner or later, the project would become impossible to maintain.
So I started over. This time, the frontend would be built with React — not because React was trendy, but because RexiO had simply become too complex for the architecture I had started with. React gave me something I desperately needed: structure, predictability, scalability.
Of course, rewriting everything didn't magically solve my problems. It created entirely new ones. For weeks, it felt like every bug I fixed introduced another bug somewhere else. State refused to synchronize. Streaming responses randomly stopped. Components rendered when they shouldn't. Authentication occasionally behaved in ways that made absolutely no sense.
One problem in particular almost drove me insane: a circular dependency hidden deep inside the application caused parts of the system to initialize in the wrong order. Nothing crashed. Nothing produced a clear error. Things simply behaved strangely. Those kinds of bugs are the worst — the application looks alive, it just refuses to behave logically. I spent hours tracing execution flow, reading logs, removing code, adding logs again, questioning every assumption I'd made. Eventually, after what felt like forever, I found the cause. The fix itself wasn't particularly large. Finding it was the hard part.
That experience permanently changed the way I design software. Since then, I've become almost obsessed with keeping architectures modular. The more independent each part of the system is, the easier everything becomes later.
Around the same time, I replaced simple state handling with Zustand. It wasn't the most exciting decision — users would never notice it — but I noticed it every single day while developing. The application became easier to reason about. State became predictable. Features became easier to extend. Good architecture is strange: when it's done properly, nobody notices; when it's done badly, everyone does.
As the frontend matured, the backend became more ambitious too. Node.js was no longer just forwarding API requests. It had become the brain coordinating everything. Instead of treating every AI model equally, I built an orchestration layer. Different tasks required different strengths — some models were better at reasoning, others were faster, some produced better code, others handled long conversations more naturally. I didn't want users to think about which model to choose. I wanted RexiO to make that decision intelligently.
That idea eventually led me to integrate OpenRouter. Rather than locking users into a single model, RexiO could route requests to whichever model made the most sense for that specific task. But routing wasn't enough — before a request reached any model, RexiO first needed to understand what the user was actually trying to do. That meant building an intent classification system. A coding question shouldn't follow the same pipeline as a creative writing request. A real-time information request shouldn't be handled the same way as casual conversation. Every request needed context before it needed intelligence.
Then came tools. At first, there were only a few — search, file reading, basic utilities. Then the number slowly grew: ten, fifteen, twenty, and eventually more than thirty different tools became part of the platform. Some searched the web. Some analyzed files. Some generated images. Some connected conversations to external services. Others simply existed to make the AI feel more capable than a text box answering questions.
Around that time, another realization hit me. Large language models are powerful. Memory is what makes them personal. Without memory, every conversation begins from zero — every chat feels like meeting someone for the first time. That's not how human relationships work, and I didn't think AI should work that way either. I wanted RexiO to remember. Not everything, not forever — just enough to make future conversations genuinely better. That decision eventually became one of the core ideas behind the platform.
Looking back now, it's funny. From the outside, people saw a chat interface. I saw hundreds of interconnected systems quietly working together behind it — authentication, streaming, routing, memory, tools, caching, state management, error recovery. None of those things appear in screenshots. Most users will never know they exist. And honestly, that's exactly how good engineering should feel. If people notice the engineering, something has probably gone wrong.
By this point, RexiO had stopped feeling like a personal project. It had started feeling like a real platform. But there was still one problem I couldn't ignore: no matter how good the architecture became, I was still relying almost entirely on models built by other companies. I knew that couldn't be the long-term future. If RexiO truly wanted to become a Bangla-first AI platform, one day it would need a brain of its own.
Chapter 10 — Building a Brain of Our Own
As RexiO continued to grow, one question kept coming back to me: what happens if every AI model we depend on disappears tomorrow? It wasn't a paranoid question. It was a practical one.
Almost every AI startup begins by building on top of someone else's models. There's nothing wrong with that. In fact, I think it's the right way to start — you move faster, you learn faster, you validate your ideas before investing years into building your own technology. That's exactly what I did. RexiO used different frontier models because they were simply the best tools available.
But I never wanted that to be the end of the story. From the very beginning, I wanted RexiO to become more than an interface connecting people to existing AI. I wanted it to develop intelligence that belonged to RexiO itself. Not because I believed we could immediately outperform companies spending billions of dollars every year — that would have been unrealistic. My goal was different. I wanted models that understood Bangla naturally, trained with Bangladeshi users in mind, that reflected the philosophy I wanted RexiO to have: honest, helpful, thoughtful, local by default.
That decision started another learning journey from scratch. I had never trained a language model before. I didn't have expensive GPUs. I didn't have a research lab. I didn't even have enough hardware to run many models locally.
So I started where thousands of independent AI builders start: Google Colab, free GPUs, limited sessions, unexpected disconnections, restarting notebooks, downloading checkpoints again, waiting for installations, running out of VRAM, trying again. It was frustrating. Sometimes an entire training session would fail after hours of waiting. Sometimes I made a mistake in the dataset. Sometimes the hyperparameters were simply wrong. Every failure meant starting over. There wasn't anyone sitting beside me telling me what to do next. Most of the time, I learned by reading documentation, studying open-source projects, watching researchers share their work, and experimenting until something finally worked.
Eventually, I successfully fine-tuned my first small language model. It wasn't revolutionary. It wasn't smarter than GPT. It wasn't supposed to be. It proved something much more important: I could do it.
That small success completely changed my confidence. Training models no longer felt like something only huge AI companies could do. It became another engineering problem — a difficult one, but still solvable.
Once I understood the pipeline, I wanted to improve every part of it — the dataset, the prompts, the formatting, the evaluation, everything. I quickly discovered that training a model isn't mostly about training. It's about data. A model only learns from what you teach it. If the dataset is poor, the model will be poor. No amount of GPU power can fix bad data.
That realization completely changed how I spent my time. Instead of only focusing on models, I started focusing on knowledge — writing instructions, creating conversations, improving responses, removing low-quality examples, testing again, improving again. Over time, thousands of Bangla instructions and conversations slowly came together. Some were technical, some conversational, some focused on reasoning, others focused on writing naturally in Bangla without sounding translated. It was repetitive work, sometimes exhausting, almost never exciting. But I knew those hours would eventually matter more than any benchmark score.
Around that period, different internal model families started taking shape — some optimized for speed, some for reasoning, some for lightweight devices. Internally, they evolved into what later became known as RexiO Nova, RexiO Brain, and RexiO Mini. Each served a different purpose. But none of them represented the destination. They were stepping stones.
The real goal had another name: Prothom. "Prothom" means first in Bangla. The name wasn't chosen because it would be our first model. It represented something else — the beginning of an AI that wasn't simply translated into Bangla, but designed to think in Bangla from the very beginning. To understand how people in Bangladesh naturally communicate. To answer questions with local context instead of global assumptions. To feel less like software imported from somewhere else and more like something built at home.
That vision still isn't finished. In many ways, we're only getting started.
Training AI teaches you humility. Every time you think you've solved one problem, three more appear. Evaluation becomes harder. Reasoning becomes harder. Memory becomes harder. Hallucinations become harder. The deeper I went into AI research, the more respect I developed for the people pushing this field forward. Building a good AI isn't magic. It's thousands of small engineering decisions made consistently over a very long time.
And that's exactly how I see RexiO — not as a finished product, but as something that keeps learning. Just like the person building it.
By this point, RexiO finally had its own direction, its own architecture, its own philosophy, and slowly, its own intelligence. What I wasn't prepared for was the price of building all of it alone.
Chapter 11 — The Hardest Months
People often romanticize the idea of being a solo founder. You work from anywhere. You build whatever you want. You answer to nobody. It sounds exciting. Sometimes it is. Most of the time, it isn't.
Building RexiO was easily the hardest thing I've ever done. Not because the technology was impossible, but because there was nobody else to carry the weight. Every decision stopped with me. Every bug became my responsibility. Every delay was mine to explain. Every mistake belonged to me.
When people use a finished product, they rarely think about everything that happened before the launch. They see the polished interface. They don't see the thousands of invisible problems that had to be solved first.
There were nights when I stayed awake because I was genuinely excited about an idea. There were also nights when I stayed awake because a single bug refused to let me sleep. I still remember spending almost twelve straight hours chasing one issue. The strange part wasn't that the bug existed — every engineer expects bugs. The frustrating part was that everything looked correct. The code made sense. The logic made sense. The output didn't.
For hours, I questioned everything — the architecture, the implementation, even my own understanding of the problem. Eventually, I found the cause. The solution itself took only a few minutes. Finding it took half a day. Moments like that taught me something I never learned from books: programming isn't really about writing code. It's about learning how to think when nothing makes sense.
There were other nights that were even harder — not because of software, but because of uncertainty. I had no guarantee that anyone would ever use RexiO. No guarantee that people would care. No guarantee that all of these months would become anything more than another unfinished project sitting on my laptop.
That's probably the hardest part of building something new. You spend months, or sometimes years, working toward a future that doesn't exist yet. Every morning, you have to believe in something nobody else can see. That belief gets tested constantly.
There were moments when I wondered whether I was moving too slowly. Moments when I questioned my decisions. Moments when I thought maybe I should build something simpler, something safer, something easier. Every time that thought appeared, another question followed: if I give up now, will I regret it five years from today? The answer was always the same. Yes. So I kept going.
Being a solo founder also means accepting your limitations. I couldn't ask another engineer to review my architecture. I couldn't hand a feature to another developer. I couldn't tell someone else to investigate a production issue while I slept. Everything depended on one person: me. That forced me to learn much faster than I otherwise would have. Whenever I reached the limits of what I knew, I had two choices — stop, or learn. I always chose the second option.
One of the biggest advantages I had during this journey came from people I'd never met in person. Over time, I connected with developers, researchers, and engineers from different parts of the world — the United States, China, Europe, and other parts of Asia. Most of them had no reason to spend time answering my questions. Yet many of them did. Sometimes it was a short conversation. Sometimes it was advice that completely changed how I thought about a technical problem.
Those conversations reminded me of something important: the internet isn't just a place to consume information. It's a place where knowledge moves across borders every single day. A village in Bangladesh can learn from someone thousands of kilometers away. I am living proof of that.
Of course, not everything went according to plan. Launch dates moved. Features took longer than expected. Ideas that looked brilliant on paper sometimes failed completely once I built them. I deleted more code than I'd like to admit. But I've never believed that deleting work is failure. Keeping bad work because you've already spent time on it — that's the real mistake. Every version of RexiO existed so the next version could become better, even the versions nobody outside a small testing group will ever see.
Through all of this, one thing never changed: my faith. Whenever people ask me what kept me moving during the hardest periods, my answer isn't purely technical. I trusted Allah. Then I did everything within my ability. Not the other way around. Faith never replaced the work. It gave me the strength to continue doing it.
Looking back now, I don't think the hardest part of building RexiO was writing code. It wasn't training models. It wasn't debugging. The hardest part was continuing to believe in the vision on the days when there was absolutely no evidence that it would succeed.
Building software is difficult. Building belief every single day is even harder.
But somewhere in the middle of all those long nights, failed experiments, rewritten systems, and endless debugging sessions, launch day quietly became inevitable. After all the months of building, there was finally only one thing left to do. Press Deploy.
Chapter 12 — July 10, 2026
For months, July 10 existed only as a date on my calendar. A target. A deadline. A promise I had made to myself. As it got closer, that date started feeling heavier. Every unfinished feature became more noticeable. Every small bug suddenly felt much bigger. Every decision carried more weight than usual.
When you're building a product alone, launch day doesn't begin on launch day. It begins weeks earlier. You start checking everything twice, then three times. You test the same feature over and over again, hoping to find the problem before someone else does. You know the first impression only happens once.
The night before launch, I barely thought about celebration. I was still fixing small issues, improving tiny details that most people would probably never notice — adjusting animations, cleaning up responses, reading logs one last time, making sure deployments completed successfully. Even after all that, I still had the same thought every founder probably has before launching: "did I forget something?" The answer is almost always yes.
Every product launches with unfinished ideas. Perfection is a moving target. If you wait until everything feels perfect, you'll never launch anything. Eventually, there comes a point where you stop building and start listening. That's what launch day is — the moment your product stops belonging only to you. It begins belonging to its users.
When RexiO finally went live, I didn't feel the excitement people usually imagine. Not immediately. The first feeling was surprisingly quiet: relief. After months of carrying the entire project inside my head, it finally existed somewhere outside of it. Real people could open it. Real people could talk to it. Real people could judge it. That was both exciting and terrifying.
The internet doesn't care how many nights you stayed awake. It doesn't care how difficult the architecture was. It doesn't care how many months you spent solving invisible problems. Users only care about one thing: does it help me? And honestly, that's exactly how it should be. Products shouldn't be rewarded for how difficult they were to build. They should be rewarded for how useful they become.
As the first users started exploring RexiO, I found myself doing something I'd done countless times during development: watching. Not because I wanted praise, but because I wanted to learn. Every question users asked revealed something. Every point of confusion highlighted another improvement. Every suggestion became another item on my notebook.
Launch day wasn't the finish line. It was the beginning of a completely different phase. Now the product had to survive outside the environment where it was created.
One thought kept coming back to me throughout the day. I remembered that little kid who pressed the Internet button on a Nokia phone without understanding what it actually did. If someone had told him that one day he'd build an AI platform used by people across the country, he probably wouldn't have believed it. Not because the dream was too big, but because he wouldn't even have understood what artificial intelligence meant.
Life has a strange way of connecting moments that seem completely unrelated when they're happening. The Nokia phone. The two-taka data packs. TrickBD. The first broken website. The twenty-taka mobile balance. The first client. The nights spent debugging. The rewritten architecture. The failed experiments. The trained models. Every one of those moments quietly led here.
People often ask me whether launching RexiO was the proudest moment of my life. I don't think that's the right way to describe it. I'm proud of it, of course. But more than pride, I felt gratitude. Gratitude to my parents, who gave me opportunities they never had themselves. Gratitude to every teacher who believed I could learn. Gratitude to everyone who answered one of my questions over the years. Gratitude to every early tester who reported bugs instead of quietly leaving. Gratitude to the open-source community whose work made so much of modern AI possible. And above all, gratitude to Allah, because every opportunity I've had, every lesson I've learned, and every step that brought me here began with blessings I didn't earn on my own.
My parents still don't fully understand what RexiO is. If I start talking about orchestration layers, fine-tuning, embeddings, or model routing, the conversation usually doesn't last very long. But they understand something much more important: they know I've spent years working toward something I genuinely believe in. And that's enough. Seeing them smile after launch meant more to me than any number on an analytics dashboard.
July 10, 2026 wasn't the day I finished building RexiO. It was simply the day I stopped building it alone. From that moment onward, every user became part of its story too.
Chapter 13 — Why RexiO Exists
If you've read this far, you might still be wondering something: why build another AI? It's a fair question. Today, the world already has incredible AI systems — ChatGPT, Claude, Gemini, and many others. I use them. I respect them. In many ways, they helped me become the engineer I am today. So why spend years building another one?
Because I don't think the goal is to build another AI. The goal is to build the right AI for the people you're trying to serve. For me, those people are, first and foremost, Bangladesh.
One thing I've noticed over the years is that most discussions about AI focus on intelligence. Which model scores higher? Which benchmark is better? Which model writes better code? Those questions matter. But they're not the first questions I ask. I ask something much simpler: will this actually help someone?
An AI can be incredibly intelligent and still fail to understand the person using it. Understanding isn't only about language. It's about context, culture, habits, values — the small things that rarely appear in benchmarks. That's the difference I want RexiO to make.
I don't want someone in Bangladesh to feel like they're talking to software that was designed somewhere else and merely translated into Bangla. I want it to feel familiar, natural, comfortable — not because it speaks Bangla, but because it understands why Bangla speakers think the way they do.
That doesn't mean RexiO is only for Bangladesh. Far from it. My ambition has always been global. But every global product begins somewhere. Google began by organizing the web. Facebook began with one university. OpenAI began with a small research team. Every meaningful platform starts by solving one problem exceptionally well before trying to solve every problem. Bangladesh is where I want RexiO to earn that trust.
There's another belief that's shaped RexiO from the beginning. I don't think AI should exist to make people feel good. I think AI should exist to help people make better decisions. Those two things are not always the same. Sometimes the correct answer is uncomfortable. Sometimes the honest answer disappoints you. Sometimes the most helpful response is the one you didn't want to hear.
I've never wanted RexiO to become an AI that simply agrees with whoever is speaking to it. Agreement is easy. Truth is harder. If an AI tells you you're right when you're wrong, it hasn't helped you — it has only protected your feelings for a few seconds. I'd rather RexiO respectfully disagree than confidently mislead someone. Whether the topic is programming, research, business, or everyday life, I believe honesty creates more long-term value than empty reassurance.
That philosophy influences almost every technical decision we make. It's why we care about grounding answers in reliable information. It's why we're investing in better reasoning. It's why memory matters. It's why context matters. It's why our own models matter. Technology changes incredibly quickly. The principles behind it shouldn't.
Another misconception people sometimes have is that RexiO is trying to replace human thinking. It isn't. If anything, I hope it encourages more of it. The best conversations I've had with AI weren't the ones where it instantly gave me an answer. They were the ones where it challenged my assumptions, pointed out flaws I hadn't noticed, suggested ideas I hadn't considered, and made me think more deeply than I would have on my own. That's the kind of AI I want to build — one that works beside people, not above them.
When I started this journey, I wasn't thinking about market size, valuation, or headlines. I was thinking about a much simpler question: what kind of AI would I personally want to use every single day? Years later, I'm still answering that same question. Every feature we build, every model we train, every design decision we make, every line of code we write — they're all attempts to answer it a little better than we did yesterday.
RexiO isn't the destination. It's the beginning of a much longer journey. And if one day someone asks what RexiO was really built for, I hope the answer is simple: to help people think more clearly, learn more quickly, build more confidently, and solve problems they couldn't solve alone. If we can do that consistently, everything else will follow.
Chapter 14 — What Comes Next
If you've made it this far, thank you — not because you've read a long story, but because you've taken the time to understand the person behind the product.
People often talk about launch day as if it's the finish line. For me, it feels more like graduation. You spend years learning. You work toward one important day. Then suddenly, you realize the real work is only beginning. That's exactly how I feel about RexiO.
Everything I've written so far describes how we got here. What matters now is where we're going. The version of RexiO you see today is only the foundation — the first step toward something much larger than a chatbot.
When I imagine RexiO five or ten years from now, I don't imagine a website with more features. I imagine an intelligent companion — something that can understand your goals, remember what matters to you, help you learn faster, write with you, research with you, build with you, create with you, and, when necessary, disagree with you.
One of the projects I'm most excited about is Prothom. Internally, it represents much more than another language model. It represents independence. Every improvement we make to our own models brings us one step closer to building AI that isn't simply adapted for Bangla, but genuinely built around it. That journey will take years. I'm okay with that. Some things aren't supposed to happen quickly.
Beyond language models, I want RexiO to become a complete AI platform — a place where conversations naturally turn into actions. Where an idea can become a document, a document can become a presentation, a presentation can become a product. Where AI isn't just something you talk to. It's something you build with.
I also believe AI should become more personal without becoming intrusive. Remembering useful information is valuable. Violating someone's privacy is not. Those two ideas can coexist, and I think the future belongs to products that understand the difference.
As technology continues to evolve, RexiO will evolve with it. New models will arrive. New interfaces will replace old ones. Today's limitations will eventually disappear. That's the nature of this industry. But there are a few things I don't want to change. I don't want RexiO to stop being honest. I don't want it to stop putting users before hype. I don't want it to chase trends at the cost of trust. Technology changes every few months. Trust takes years to earn. If I ever have to choose between growing faster and protecting that trust, I already know which one I'll choose.
People sometimes ask me where I see SpritEX AI in the future. My answer is simple: I want it to become a place where world-class AI research can happen from Bangladesh. Not because we want to prove that Bangladesh is capable — I already believe it is. I want to prove that great ideas are not limited by geography. You don't need to be born in Silicon Valley to build meaningful technology. You don't need a famous university behind your name. You don't need a large office before you begin. You need curiosity, consistency, the willingness to keep learning after everyone else has gone to sleep, and the courage to continue when success still feels invisible.
If a child growing up in a village somewhere in Bangladesh reads this one day, I hope they don't remember my name. I hope they remember something much more important: that it's possible. Not easy. Not guaranteed. But possible. Because if a curious kid with a Nokia button phone, a two-taka internet package, and no roadmap could one day build an AI platform, then maybe they're allowed to believe in impossible things too.
RexiO is still young. There are countless mistakes ahead of us — features that will fail, ideas that won't work, problems we haven't even imagined yet. That's part of building anything meaningful, and I'm not afraid of that. In many ways, we're still at the beginning.
The story you've just read isn't the story of someone who reached the destination. It's the story of someone who finally found the road. And tomorrow morning, I'll wake up, open my laptop, and keep building — just like I did yesterday, just like I hope to do for many years to come.
Thank you for being part of the journey. See you inside RexiO.
RexiO — rexio.pro SpritEX AI — spritexai.pro.bd