# zPlatform.ai: Founder Interviews

> Full text of every SaaS and AI founder interview - origin stories, product decisions and lessons learned.

This is one part of the zPlatform.ai full-content export, split so each file stays small enough to fetch and parse. The complete index is at https://zplatform.ai/llms.txt, the other parts are listed there, and the unsplit file is at https://zplatform.ai/llms-full.txt.

zPlatform.ai is an independent AI and software research, review and discovery platform run by Alston Antony, a SaaS SEO and AI Search expert with 15+ years of experience and 500+ SaaS tools tested personally. It is not an SEO agency or consultancy: broad SaaS SEO and AI-search consulting is Alston's own practice at alstonantony.com, and agency implementation is Maxinium's. What zPlatform itself sells is what it operates - hands-on reviews, directory distribution, tool and affiliate-program listings, and founder interviews. Unlike directories that list thousands of untested tools, zPlatform tests each AI tool hands-on, compares it against alternatives, and publishes an honest verdict. The site covers AI lifetime deals, SEO lifetime deals, discount deals and coupons, free AI tools, in-depth reviews, best-of lists by use case (writing, coding, marketing, SEO, design, productivity), AI affiliate programs, Black Friday AI deals, AI conferences and events, and a done-for-you directory submission service for startups, SaaS, and AI tools. All reviews are hands-on and editorial. Sponsorship is labeled and separated from rankings. Payment never buys a verdict.
## About the Founder

- Name: Alston Antony
- Role: Founder of zPlatform; SaaS SEO & AI Search Expert; Software Engineer (MSc, Distinction)
- Experience: 15+ years in SEO, 500+ tools tested, 30,000+ students taught
- Employer: Brainstorm Force (Senior Digital Marketing Manager)
- Professional Body: BCS, The Chartered Institute for IT
- Website: https://alstonantony.com
- YouTube: https://www.youtube.com/@AlstonAntony

## Verdict System

Every AI tool reviewed on zPlatform receives one of three verdicts:

- Buy: Strong value for the right user. Recommended for purchase.
- Wait: Shows potential but has issues worth monitoring before committing.
- Skip: Not worth the money for most people.

Each verdict includes a written explanation with specific reasoning, limitations, and who should or should not buy.

## Founder Interviews (6)

### DeltaReview Interview: Rida Rahim on Building an AI Code Reviewer With No Login, No Data, and No Team
URL: https://zplatform.ai/interviews/deltareview-rida-rahim-interview/
Updated: 2026-08-19
Interviewee: Rida Rahim | Role: Founder | Company: DeltaReview

TL;DR: DeltaReview founder Rida Rahim, a third-year computer science student at NYIT, explains why her AI code diff analyzer has no login and no persistent storage, why she is cautious about the GitHub and IDE integrations every rival is racing to ship, and why she wants to stay a solo founder. She also states plainly that she has no meaningful usage data yet, points at a placeholder-sounding suggestion in her own sample output, and says she has no burnout systems in place.

Most founder interviews arrive with a traction number attached. This one does not, and the founder says so in the first sentence of her answer to the question about it.

“Honestly, I don’t have meaningful usage data yet,” Rida Rahim says of DeltaReview. “Right now traction looks like me cold-outreaching developers directly, asking them to try it and give me real feedback, rather than any kind of organic user base yet.”

That is an unusual thing to lead with, and it sets the tone for the rest of the conversation. Asked for the most surprising piece of user feedback, she says she has not received enough feedback for anything to qualify as surprising. Asked what systems keep her from burning out across coursework, a services company, and a product, she says she does not have any and is still figuring that out. Asked where the product is weakest, she does not give a diplomatic answer about roadmap priorities; she points at a specific string in her own sample output, “review and refactor if needed,” and calls it placeholder-feeling.

What she does have is a set of product decisions that run directly against where the rest of the AI code review market is heading, and clear reasoning for each one.

DeltaReview is a diff analyzer. You paste a before version and an after version of a file, pick from 23 languages, and get back four scored risk categories, located findings, refactoring suggestions, and a commit message. There is no account. There is no GitHub connection. History exists only for the length of your session, and if you want to keep an analysis you export it as JSON or Markdown before you close the tab. Much of what the industry treats as table stakes, the PR bot, the CI check, the IDE plugin, the persistent dashboard, she has deliberately not built, and in the roadmap answer at the end of this interview she explains why she may never build it.

Rahim is also running TawakalStudio LLC, a web design and branding studio serving local businesses on Long Island, at the same time, while going into her third year of a computer science degree. She calls herself a “messy founder.” Here is the conversation.

#### From an Internship Application to Two Companies

##### Can you start by introducing yourself, your background, where you are studying computer science, and how you would describe yourself as a builder today?

My name is Rida and I’m a Computer Science student at NYIT, going into my third year this fall. My path into CS wasn’t the traditional “always wanted to code” story. I actually found my way into software engineering through an internship application that required me to build a website, and that was the moment it clicked. Since then I’ve been self-directed about it: I founded TawakalStudio, a web design, development and digital branding studio where I build sites for local businesses on Long Island, and I built DeltaReview, an AI-powered code diff analyzer that supports 23+ programming languages.

As a builder, I’d call myself a “messy founder.” I think that’s the honest version of building. I don’t wait until I feel fully ready or until something’s polished. I ship things, hit real problems, debug late into the night, and learn in public instead of pretending it’s clean from day one. That’s genuinely how I’ve grown the fastest.

##### As the first founder in your family and a young woman in tech, what initially drew you to entrepreneurship, and what was the moment you decided to actually start building products?

Being the first person in my family to go down this path meant I didn’t have a blueprint to follow. There was no one to ask “how do I start a company” or “is this normal to feel lost right now.” I had to figure that out myself, which made my early path pretty experimental. For a while, that looked like mass-applying to jobs without much direction, because I didn’t have a clear model of what building a career in tech was even supposed to look like.

The shift happened when I applied to an internship that required me to actually build something as part of the process. That was the first time I sat down and built something real from scratch, and something clicked. I realized I loved the feeling of creating. There’s something different about seeing something you built with your own two hands go from nothing to something that actually works, something someone else can actually use. That feeling is what pulled me toward entrepreneurship rather than just continuing to look for another internship or job.

As a young woman in tech, especially without anyone in my family or immediate circle who’d done this before, there were definitely moments where I felt like I had to prove I belonged in the room, or that my ideas were worth building. And if I’m being honest, in the short time since I started, there were multiple points where I wanted to give up on both TawakalStudio and DeltaReview and just go back to the traditional path, find a job, find an internship, because it genuinely felt delusional to keep going. But every time I got close to that decision, I realized what I was actually choosing: if you’re hired as a developer or engineer at someone else’s company, you’re technically helping build their vision, their name. And that didn’t sit right with me. I wanted my work to have my name attached to it. So instead of quitting, I kept building, and I kept putting myself out there.

That’s what led to TawakalStudio first, and then DeltaReview once I realized I wanted to build actual products, not just client websites.

##### Looking back, what were the earliest signs that you would end up creating both a developer tool and a services company in parallel?

Honestly, looking back, there wasn’t one clear sign pointing to “you’ll end up building both a services company and a developer tool.” A lot of what I’ve built has come from trying things and following what felt right at each step, not from a master plan. I’m young, and I know that gives me the freedom to experiment with direction instead of committing to one lane too early.

TawakalStudio came first. I registered it because I wanted to help local businesses on Long Island build their web presence and brand. I realized what I actually cared about wasn’t just “building websites,” it was helping someone build something that represented them. That intention is what shaped the service side from the start.

A little while later, I built a project for a Codex Challenge on Handshake called ReviewAI, an AI-powered code reviewer that analyzed snippets in real time, flagging bugs, security vulnerabilities, and performance issues, scoring overall code health, and suggesting one-click fixes with streaming output in a Monaco editor. It made the Showcase.

That project became the direct foundation for DeltaReview. Building ReviewAI, I noticed there wasn’t a dev tool that consistently supported 23+ programming languages, compared “before” and “after” code versions, and returned structured feedback across bugs, security risk, performance, and complexity. Something that turned a raw diff into a prioritized list of what actually needs attention before deployment, instead of just a wall of changed lines. That’s when it clicked for me: I wanted to build something for devs, by a dev.

So if there was an early sign, it’s this. Every project I built, whether aimed at a business or a developer, kept circling back to the same instinct: figure out what’s actually needed, and build the real thing, not just a version of it.

#### Why the Product Refuses to Ask You to Log In

##### What inspired DeltaReview specifically? Was there a personal frustration with the code review process that pushed you to build it?

DeltaReview came directly out of building ReviewAI, but the real personal frustration was friction. Every code review or analysis tool I tried required some kind of login, GitHub integration, workspace setup, this and that and the third, before you could even get to the part where it actually looks at your code. And a lot of the time, I just wanted to paste a diff and get an answer, not set up a whole pipeline for a quick check.

That frustration is what shaped DeltaReview’s core design: it’s frictionless. There’s no login, no GitHub connection required. You just paste or type a diff and immediately get structured analysis on logic issues, potential bugs, and code improvements. That makes it genuinely useful for fast iteration workflows, where setting up full tooling just to check one change would be way too heavy for what you actually need at the moment.

On top of that, I noticed there wasn’t a tool that consistently supported 23+ programming languages, compared “before” and “after” versions of code, and returned structured feedback across bugs, security risk, performance, and complexity. Something that turns a raw diff into a prioritized list of what actually needs attention, instead of a wall of changed lines you have to interpret yourself.

History works the same way, session-based, so it’s there as long as you’re active, and you can export it as JSON or Markdown before you leave. Once you leave, it’s gone. That was intentional too. No accounts means no persistent storage tied to you, which keeps it lightweight and frictionless by design, not just by accident.

##### How did you arrive at the angle of AI feedback on code diffs before formal review, as opposed to a full code reviewer or a pair programming tool?

ReviewAI was closer to a full code reviewer. It analyzed a snippet in real time and flagged bugs, security issues, and performance problems on its own. But building it taught me something: reviewing a snippet in isolation isn’t really how risk shows up in real development. Risk shows up in change, what got added, removed, or modified, not in a static block of code sitting on its own.

A pair programming tool is a different problem entirely. It’s about real-time collaboration and assistance while you’re actively writing code. That’s a much heavier, more integrated product, and it solves “help me write this” rather than “tell me if what I just wrote is safe to ship.”

What I kept coming back to was the moment right before formal review. You’ve made changes, you’re about to open a PR or push to review, and that’s the point where you want a fast, honest gut-check: did this diff introduce a bug, a security risk, a performance regression, before a human reviewer even sees it. That’s a narrower, more specific moment than “review my whole codebase” or “help me write code in real time,” and narrower, to me, meant I could actually go deep and be genuinely useful there, instead of being a shallow version of a dozen other tools that already do full review or pair programming.

So the diff-feedback angle wasn’t a downgrade from a full reviewer. It was a deliberate focus on the specific moment where I felt the most friction myself: right before you commit to formal review, when you want to know what actually needs attention, without needing an account, a pipeline, or another person in the room yet.

#### Inside the Diff Workspace

##### Can you walk us through the journey from idea to first working version, how long it took, what you built it with, and the biggest technical hurdles you hit early on?

The first working version came together within a few days. I had something functional fast. From there, it took a few weeks of prompt testing to get it reliable, and a full redesign, before it became the version it is today, moving from a plain interface to a real brand and UI/UX: dark navy, a proper logo, a workspace that actually feels like it belongs in a dev environment. The old version worked. This one looks like it means it.

The biggest technical hurdle by far was prompt reliability. The model would silently drop fields, findings, commit messages, suggestions, just gone, with no error thrown. That’s a dangerous kind of bug because nothing crashes, it just quietly returns incomplete data, and if you’re not checking closely, you’d never know.

I fixed it with a two-layer approach: an explicit JSON contract built directly into the prompt, so the model has a strict structure to follow, plus a Zod schema with hard fallback defaults on the backend, so even if a field comes back missing or malformed, the app doesn’t fail quietly. It catches it and handles it properly instead of just passing broken data through.

Now the tool consistently returns bug and security risk scores, specific findings with exact locations, refactoring suggestions, and commit messages you can actually use, all built with Next.js, TypeScript, the Groq API, and Vercel serverless functions.

##### Could you walk us through how DeltaReview actually works, from a developer pasting in a diff to the AI returning actionable feedback?

A developer starts in the Code Workspace. There’s no login, just two side-by-side panels: “Before Code” and “After Code.” You select the language from a dropdown covering 23 options plus an Other option, then paste or type your original code on the left and your modified version on the right. From there, you hit “Analyze Diff,” and DeltaReview sends that before/after comparison to the Groq API for structured analysis.

What comes back is the Analysis Dashboard. Not a wall of changed lines, but four scored categories at the top: Bug Risk, Security Risk, Performance, and Complexity, each rated by severity. Below that is a plain-language Change Summary, then Key Findings, each one tagged by severity and category, showing exactly which part of the code is impacted and a suggested fix, so you know precisely what to act on and where.

Past that, it generates Suggested Commit Messages you can copy directly, and Refactoring Suggestions for anything worth improving beyond the immediate fix. And if you want to keep the analysis, you can export the whole thing as JSON or Markdown before you leave. Since there’s no account system, nothing persists past your session unless you export it.

So the full loop is: paste or type before/after code, pick your language, hit analyze, and in seconds you get a prioritized, structured breakdown of what actually needs your attention before you ship, instead of manually combing through a diff line by line.

##### You support 23+ programming languages. How do you ensure consistent quality and depth of feedback across such a wide range?

The consistency doesn’t come from treating each language differently under the hood. It comes from standardizing the output structure, regardless of what language goes in. I built an explicit JSON contract into the prompt itself, so no matter if the input is Python, Rust, or a Dockerfile, the model is constrained to return the same structure: bug risk, security risk, performance, complexity, findings with locations, refactoring suggestions, and commit messages.

On top of that, I added a Zod schema with fallback defaults on the backend, so even if the model handles a less common language slightly differently, or a field comes back incomplete, the schema catches it and fills in safely instead of returning broken or inconsistent output to the user. That was actually the same fix that solved my early reliability bug, where fields were getting silently dropped, so depth and consistency across languages ended up being solved by the same underlying fix as reliability in general.

The tradeoff I’m honest about is that depth naturally varies a bit by language. Something like JavaScript or Python, which the underlying model has seen a lot more of, is going to get richer, more specific findings than a less common language. But the structure and quality bar, meaning you always get scored categories, located findings, and actionable suggestions, stays consistent no matter what language you paste in.

##### What is your current tech stack, and were there interesting tradeoffs between cost, speed, and review quality?

The current stack is Next.js and TypeScript on the frontend, the Groq API for the model layer, and Vercel serverless functions for the backend, all deployed on Vercel.

The tradeoffs so far have mostly been around cost versus scale, not cost versus quality. I chose Vercel because it’s free at this stage and handles serverless functions well, and Groq specifically because it’s fast and free to use right now, which matters a lot for a tool where the whole value proposition is speed. Nobody wants to paste in a diff and wait a long time for feedback. Groq’s inference speed lines up directly with the frictionless, fast-iteration experience I wanted DeltaReview to have.

Right now, free-tier hosting and a free API are the right call because I don’t have a large user base yet, so there’s no reason to pay for infrastructure I don’t need. But I’m treating that as a starting point, not a permanent decision. Once I see real usage and a larger user pool, the next step is looking into a dedicated domain and likely scaling up the hosting and API tier to match actual demand, rather than over-investing in infrastructure before I know it’s needed.

So the tradeoff, if I had to name one, was speed and cost now versus scalability later. I optimized for getting something fast, frictionless, and real into people’s hands first, and I’ll invest further once usage actually justifies it.

New to some of this? [Inference](/guides/ai-glossary/) speed, JSON contracts and schema validation get used as shorthand in almost every AI product pitch without being defined. Our AI glossary covers 264 terms with citations.

#### What It Catches, and What Still Reads Like a Placeholder

##### What kinds of issues does DeltaReview catch best today, and where does it still have room to improve?

Today, DeltaReview catches security risks and clear logic bugs the best. Things like SQL injection, where it correctly flags the vulnerability, identifies the impacted function, and gives a real suggested commit message. That category feels the most reliable right now because those patterns are relatively well-defined and consistent across languages.

Where it still has room to improve is depth on the more nuanced suggestions. Refactoring advice and some of the secondary findings can come back a little generic right now. Looking at my own sample output, I actually noticed “review and refactor if needed” showing up as a suggested fix in more than one finding, which is exactly the kind of placeholder-feeling response I want to tighten up. It’s not wrong, but it’s not specific enough to be genuinely useful yet, and that’s the bar I’m holding myself to.

Honestly, the only real way I’m going to close that gap is through actual user testing and feedback. I can guess at what “more useful” looks like, and I can improve the prompt engineering on my end, but I can’t fully predict what a developer actually needs to see in that moment without watching real people use it and hearing what falls flat for them. I wish I could read every user’s mind, but since I can’t, feedback is the only honest path to making the depth match the reliability I’ve already gotten on the security and bug side.

##### How is DeltaReview different from just asking ChatGPT or Claude to review your code?

If you ask ChatGPT or Claude to “review my code,” you’re doing a lot of invisible work yourself. You have to think of the right prompt, decide what you actually want it to check for, format the before/after clearly enough for it to understand, and then read through a free-form response and figure out what’s actually important versus conversational filler. Every time, you’re re-deciding all of that, and the output structure can vary depending on how you phrased the prompt that day.

DeltaReview removes all of that thinking. There’s no prompt to write. You just paste or type your before and after code, and you get the same consistent structure every single time: bug risk, security risk, performance, complexity, specific findings with locations, refactoring suggestions, and a ready-to-use commit message. You’re not prompting a general-purpose assistant and hoping it checks the right things. The tool is already built to check the right things, every time, in the same format.

So the value I’m adding isn’t the underlying model. Claude and ChatGPT are obviously powerful on their own. What I’m adding is the layer on top: a fixed contract for what gets checked, a consistent structure for how it’s returned, and zero setup cost to get there. You don’t need to know what to ask for. You just paste or type your code, look at the result, and move on with your day. The thinking’s already been done for you, baked into the product itself.

##### What has been the most surprising piece of user feedback you have received so far, and how did it change the product?

Honestly, I haven’t gotten a large volume of feedback yet, so I can’t point to one dramatic “surprising” moment. But the feedback I have gotten has been genuinely useful. A couple of people told me it looked promising and worked well with their language of choice, which was reassuring given how much I focused on keeping quality consistent across 23+ languages.

One person did flag a slight issue, and I fixed it immediately, which actually tied back into the prompt reliability work I’d already been doing. It reinforced something I already believed: the two-layer approach of an explicit JSON contract plus Zod schema fallbacks isn’t a one-time fix, it’s something I need to keep tightening as real users hit edge cases I didn’t think to test myself.

If anything, the most honest takeaway isn’t a specific surprising piece of feedback. It’s that even a small amount of real user feedback surfaces things I genuinely couldn’t have caught testing it myself. That’s exactly why I think broader user testing, even from just a handful of people, is going to matter more for improving DeltaReview than any amount of me guessing what might be wrong with it.

#### Beta, No Usage Data, and Cold Outreach

##### Who is the ideal DeltaReview user today, and where are you seeing the most traction?

Honestly, I don’t have meaningful usage data yet. DeltaReview is still in beta, and right now traction looks like me cold-outreaching developers directly, asking them to try it and give me real feedback, rather than any kind of organic user base yet.

But in terms of who it’s actually for, I built it to be open, not restricted to one type of developer. It works for a newer developer just starting to understand what makes code risky, a student who wants fast feedback without setting up a whole review pipeline, an engineer checking a diff before a PR, or even a senior engineer who just wants a fast sanity check before shipping. The frictionless, no-login design was intentional for exactly that reason. I didn’t want to gate it behind a persona or a workflow assumption. It’s there, it’s free to use, and if it helps you, use it, regardless of where you are in your career.

So right now my focus isn’t narrowing to one ideal user segment. It’s getting it in front of as many actual developers as possible through direct outreach, seeing who gets the most value out of it, and letting that real feedback tell me where the traction actually ends up forming, instead of guessing upfront and building for an assumption.

##### How are you currently approaching outreach and getting early users as a solo student founder without a big network or budget?

Right now, my approach is mostly LinkedIn and direct cold outreach. Reaching out to developers individually, sharing what I’ve built, and asking them to try it and give me honest feedback. As a solo student founder without a big network or budget, that direct, one-on-one approach is really the most realistic lever I have right now. I don’t have paid channels or an existing audience to lean on, so it’s been about consistently putting myself and the product in front of real people rather than waiting for organic discovery.

Going into fall 2026, I’m also part of NYIT’s NESTS program, where DeltaReview is approved as my project. I’m hoping that gives me more structured access to networking, mentorship, and potentially other early users I wouldn’t reach through cold outreach alone. It’s a resource I haven’t fully been able to tap into yet since the semester hasn’t started, but it’s a big part of how I’m thinking about scaling traction beyond just me individually reaching out to people.

So right now it’s founder-led, manual, and direct, and I see NESTS as the next stage of that, not a replacement for it. I don’t think outreach stops just because a program starts. I’m expecting it to add more surface area on top of what I’m already doing.

#### Lessons From Building Without a Blueprint

##### What are the biggest lessons you have learned from launching an early-stage software product without a traditional roadmap or mentor blueprint?

One of the biggest lessons has been realizing that the worst-case scenario I imagine in my head almost never matches the actual worst case in reality. When you don’t have a mentor or a traditional roadmap, every decision feels higher-stakes than it probably is. Should I reach out to this person, should I pitch this idea, should I put this out publicly. But I’ve learned that if you ask and the answer is no, you’re not losing anything, you just stay exactly where you already were. Nobody takes the ground out from under you just because you asked for something. So a lot of the fear around those moments turned out to be bigger in my head than in reality.

The other lesson is around failure itself. I think failure gets built up as this thing you’re supposed to avoid at all costs, but honestly, that’s where I’ve actually learned the most. What works, what doesn’t, what I assumed would matter that didn’t, and what I overlooked that turned out to matter a lot. Without a blueprint to follow, failure isn’t a detour from the path, it basically is the path. Every version of DeltaReview that exists today, including the parts that work well, came from something earlier not working and me figuring out why.

So if I had to sum up the biggest lesson from building without a traditional roadmap: the risk of trying and failing is almost always smaller than it feels at the moment, and the risk of not trying at all is the only one that guarantees you stay exactly where you started.

##### What is a mistake you made early on that you would warn other student founders or first-time builders about?

If I had to name one, it’s this: early on, I mistook doubt for a signal that I was on the wrong path. There were multiple points where I genuinely considered giving up on both TawakalStudio and DeltaReview and going back to the traditional route, just finding a job or an internship, because it felt delusional to keep going without a blueprint, without anyone in my circle who’d done this before, and without any guarantee it would work.

To be clear, I don’t think building someone else’s vision is a lesser path. Everyone has different dreams, and there’s real value and skill in helping build something bigger than yourself as part of a team. For me personally, though, I wanted my work to have my name attached to it. I wanted to build something from the ground up and be able to point to it and say, that’s my hard work, that’s mine. That’s just what mattered to me specifically, not a judgment on any other path.

The mistake wasn’t feeling doubt. I think every founder hits that phase, especially without a mentor or roadmap to reassure them it’s normal. The mistake was almost treating that doubt as proof I should stop, instead of recognizing it as just part of building something with no precedent to lean on. What actually got me through it wasn’t the doubt disappearing, it was reconnecting with that reason I wanted to build in the first place. That’s what kept me going instead of the doubt itself resolving.

So the warning I’d give other student founders or first-time builders is this: doubt is going to show up, especially in the early, unclear stretches with no map. Don’t mistake it for a verdict on whether you should keep going. It’s not a signal to stop. It’s just the actual texture of building something without a blueprint, and it doesn’t mean you’re wrong, it just means you’re doing something hard without anyone telling you it’s normal to feel that way.

##### How do you decide what to build next versus what to ignore, especially when user feedback pulls in different directions?

Right now, my honest answer is that I’m deliberately narrowing, not expanding. My main focus is grinding on TawakalStudio and DeltaReview and actually scaling them, rather than adding more to the plate. I’ve noticed the more you’re juggling at once, the harder everything gets. Attention gets split, and nothing compounds properly. So right now, when feedback or ideas pull in different directions, my filter is: does this actually move TawakalStudio or DeltaReview forward, or is it a new direction entirely?

My thinking is that once you actually have a base, whether that’s a user base or a client base, that’s when you can start compounding and layering more on top, because you have real signal and real momentum to build from. Trying to build that breadth before you have any base just means spreading thin without anything solid underneath it yet.

That said, I still build smaller projects on the side. I don’t think every single thing I make has to become a startup or a business. Some things are just for learning, for fun, or for exploring an idea without the pressure of it needing to scale. But when it comes to what I’m actually prioritizing and putting real weight behind right now, it’s TawakalStudio and DeltaReview specifically. Everything else stays lower-stakes and optional until those two have a real base to build from.

#### Coursework, Two Businesses, and No Boundaries Yet

##### How do you realistically balance computer science coursework, running TawakalStudio LLC, and building DeltaReview? What does a typical week look like?

Realistically, the honest answer is that these three don’t stay in separate lanes. They bleed into each other constantly, even though day to day it feels like they’re pulling in completely different directions.

DeltaReview asks me to think like a product founder: distribution, feedback loops, retention, figuring out if there’s even a real market for what I built. TawakalStudio asks me to think like a service provider instead. It’s not about retention or product-market fit, it’s about trust, communication, and delivering work a real client is willing to stake their business on. And school asks me to think like a student: consistency, depth, long-term discipline, showing up for material whether or not it feels immediately relevant to what I’m building.

What actually makes the balance work isn’t strict time-blocking so much as noticing that skills transfer across all three instead of staying siloed. Cold outreach for DeltaReview made me sharper at pitching TawakalStudio to potential clients. Managing client expectations at TawakalStudio taught me how to think about onboarding users for DeltaReview. Studying algorithms in school reminds me why clean architecture actually matters in my own products, not just as an abstract concept for a grade.

So a typical week isn’t really three separate buckets of time. It’s more that I’m constantly moving between three different mindsets: founder, service provider, and student, and treating each one as making me better at the other two instead of competing with them for my attention. The hard part isn’t the hours, honestly. It’s learning to move between all three without losing momentum, since none of them ever fully stop needing something from me.

##### What systems, routines, or boundaries have helped you avoid burnout while juggling all of this?

If I’m being honest, I don’t have strong systems or boundaries in place right now. I’m still very much in the phase of figuring that out rather than having it solved.

But there’s one thing that’s come close to serving that role without me planning it that way: TawakalPlayer. It’s a kiosk-mode Quran audio player I built on a secondhand Samsung Galaxy A10e, locked into Android’s Device Owner and Lock Task Mode so the app can’t be exited, mounted inside a wooden box from Amazon, built with Kotlin, Jetpack Compose, and Media3 ExoPlayer. It’s on my LinkedIn as something I built and talked about, but it was never a live link I shared for people to actually test or judge.

That distinction mattered more than I expected. With TawakalStudio and DeltaReview, and honestly, even most of my other smaller portfolio projects as a CS student and dev, there’s always some version of “what would people think” running in the background. Would this perform well on LinkedIn, is this good enough to show, does this make me look capable. TawakalPlayer didn’t have that pressure at all. Android was completely new to me going in, but I wasn’t worried about judgment, I was just genuinely problem-solving. Things like debugging a stale closure bug or a silent network failure entirely through Logcat, with no browser-style dev tools to lean on. It ended up being the most relaxing project I’ve built, purely because there was nothing riding on it except my own curiosity.

So if there’s an actual system in my life right now, it’s less a formal routine and more this: having at least one project running where nobody’s judging the outcome seems to be what keeps the rest from turning into pure grind. I don’t think I’ve built real boundaries yet, but I think I’ve accidentally found what one might look like.

##### Has being a CS student actively helped DeltaReview, or have school and startup mostly lived in separate worlds?

For most of the time I’ve been building DeltaReview, school and the startup lived in pretty separate worlds. Coursework was coursework, and DeltaReview was something I worked on outside of it, on my own time and my own direction. There wasn’t a lot of direct overlap for a while.

That’s actually changing this fall, though. I’m taking ETCS 350, an NYIT course called NESTS, “Necessary Eleven Steps to Tech Startups,” which teaches startup creation and ends with a pitch event, and DeltaReview has been approved as my actual project for that course. So for the first time, school and the startup are formally intersecting, instead of just running in parallel.

Even before that, there were smaller moments of real overlap. Studying algorithms, for example, reminded me why clean architecture actually matters in my own products. It’s one thing to learn complexity and structure in an abstract, academic sense, and a completely different thing to feel the cost of bad architecture when you’re the one who has to maintain and scale what you built. That’s the kind of classroom learning that quietly shows up in how I approach my own code, even when it’s not a direct one-to-one “I learned X in class and used it immediately.”

So I’d say it’s less that classroom material has been actively driving DeltaReview’s roadmap, and more that being a CS student has sharpened how I think about the code I write for it. And now, with NESTS, the two are starting to intersect much more directly and formally through the coursework itself.

#### First Founder in the Family

##### What has been the hardest part of navigating the tech and startup world as a young woman and the first founder in your family, and what has been more encouraging than you expected?

The hardest part is probably a combination of two things. First, CS is still a male-dominated field, so that’s a layer that exists regardless of anything else. But beyond that, I think the harder part has been being the only one in my family pursuing entrepreneurship at this scale, and not just one venture, but two at once, one service-based and one product-based. There isn’t anyone I can formally turn to for advice beyond “go get a job.” So a lot of the real questions I’m sitting with, how do I get users, how do I get clients, how do I actually scale this, how do I grow from being seen as just a student into being seen as someone building something real, I’m answering those in real time, without anyone ahead of me to check my thinking against.

The more encouraging part is this: the more I learn, the more I grow, and I’m hoping that eventually puts me in a position to be that person for someone else. I’d genuinely like to be able to show someone in my position that the path isn’t clean or straightforward. It gets messy. There are moments where you wonder, “am I actually playing founder, or am I doing something real?” And I think that question itself is part of the process, not a sign that something’s wrong. If I can get to a point where I can hand someone else a slightly clearer version of that path than the one I had, that would mean everything I’m figuring out right now actually mattered beyond just me.

##### What advice would you give other young women or first-generation founders who feel like they do not have a blueprint to follow?

If you don’t have a blueprint, my honest advice is: the doubt you feel isn’t a sign you’re on the wrong path, it’s just what building without a map actually feels like. I’ve hit multiple points where I wanted to quit and go back to something more traditional, because without anyone ahead of me to check my thinking against, everything can feel higher-stakes than it probably is. What helped was realizing the worst case almost never matches the version I imagined. If you ask for something and the answer is no, you’re not losing anything, you just stay exactly where you already were. Nobody takes the ground out from under you just because you asked.

I’d also say: let failure teach you instead of avoiding it at all costs. Without a blueprint, failure isn’t a detour from the path, it basically is the path. Every part of what I’ve built that actually works came from something earlier not working, and me figuring out why.

And genuinely, if it works out, great. If it doesn’t, it’s not like there’s no other choice. There’s still a 9 to 5, and I truly believe that everything you build along the way makes you a stronger candidate for that path too. The skills you pick up trying to get users, manage clients, solve problems with no one to ask, that doesn’t disappear if the startup doesn’t work out. It makes you more capable, not less, wherever you end up.

I think it’s okay to sit with the question “am I actually doing something real, or am I just playing the part?” too. That question doesn’t mean something’s wrong with you. It means you’re being honest with yourself, which is exactly what you need to keep building without pretending you have it all figured out.

Mostly, I’d want other young women and first-generation founders to know: the path won’t be clean or straightforward, and that’s not a sign you’re doing it wrong. It’s just what it looks like when there’s no one ahead of you to hand you the map. You’re the one drawing it as you go, and that’s genuinely enough.

#### Where TawakalStudio Fits

##### How does TawakalStudio LLC fit into the bigger picture? Is it a parallel business, a funding source for DeltaReview, or a learning ground that feeds into your product work?

TawakalStudio runs parallel to DeltaReview. It’s not a funding source for it, and it’s not purely a learning ground either. It’s its own thing, with its own purpose: helping local businesses on Long Island build a real web presence and brand. It runs on a different logic entirely: service-based, relationship-driven, built around trust and delivering work a client is willing to stake their business on.

That said, parallel doesn’t mean disconnected. Running TawakalStudio does feed into how I think about DeltaReview, just indirectly rather than financially. Managing client expectations and communication for TawakalStudio shapes how I think about onboarding and expectations for DeltaReview’s users. Cold outreach for one sharpens how I pitch the other. They’re two separate businesses, but the skills and instincts built running one show up in how I operate the other.

So if I had to place it precisely: TawakalStudio isn’t subsidizing DeltaReview, and it isn’t just practice for it either. It’s a real, standalone business I’m building at the same time, and the two happen to make each other sharper simply because I’m the one running both.

#### AI, Engineers, and the Integrations She Is Cautious About

##### Where do you stand on the AI replacing developers debate, and how does DeltaReview’s design reflect your belief about AI assisting rather than replacing engineers?

I don’t believe AI is replacing engineers. I think it’s raising the bar for what engineers need to bring to the table. AI still needs a human to prompt it well: someone who knows what to ask, how to structure the problem, and when the output is wrong even if it looks right. That skill didn’t disappear, it evolved. AI also trains on what already exists. It remixes and pattern-matches, but it doesn’t originate. It’s always catching up to human creativity, never ahead of it.

There’s also a real quality gap that gets ignored in the “AI replaces engineers” narrative. Research backs this up directly. A Cloud Security Alliance report from mid-2025 found that a majority of AI-generated code contains design flaws or known vulnerabilities, because AI doesn’t understand your specific risk model, internal standards, or threat landscape. It can skip security controls and repeat insecure patterns that look fine until they aren’t. AI can execute, but it can’t fully author with judgment.

DeltaReview’s whole design reflects that belief. It’s not built to write code or replace a developer’s decision-making. It’s built to sit at the exact moment right before a human makes a judgment call, and hand them structured signals: here’s the bug risk, here’s the security risk, here’s what changed and why it might matter. The engineer still decides what to do with that. I designed it as an assistant that sharpens a developer’s judgment before they ship, not a tool that ships instead of them. That’s the difference between a tool that needs an engineer and one that pretends it doesn’t.

Editor’s note: the figure checks out. Cloud Security Alliance research finds that [62% of AI-generated code solutions contain design flaws or known security vulnerabilities](https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-codegen-vulnerability-debt-20260406-csa/), even on current frontier models, with 45% to 70% failing security tests depending on the methodology used. Veracode’s separate 2025 GenAI Code Security Report put its own figure at 45% across more than 100 models and 80 coding tasks, with Java the worst performer at over 70%.

##### What is on the DeltaReview roadmap for the next 6 to 12 months, and what is the long-term vision for both DeltaReview and your founder journey?

Near-term, over the next 6 to 12 months, my focus is less about adding a long list of new features and more about deepening what already exists: tightening depth and specificity in the findings and refactoring suggestions, especially through real user feedback, since that’s the main gap I’ve identified so far. I’d also like to move toward automatic language detection instead of manual selection, to remove one more small piece of friction from the flow.

On infrastructure, once there’s a real, active user base, the next step is moving off free-tier hosting and getting a dedicated domain, so the product can scale properly instead of running on the free resources that make sense at this early stage.

As for deeper integrations like GitHub or GitLab, or IDE plugins, I’m genuinely cautious about that direction, because DeltaReview’s core value right now is being frictionless: no login, no setup, paste and go. Adding pipeline integrations risks recreating the exact overhead I built this to avoid. If I ever go there, it would have to be an optional layer on top, not a requirement. The core paste-and-analyze experience needs to stay intact no matter what gets added around it.

Long-term, the vision for DeltaReview is to become the tool developers reach for by default in that moment right before formal review, regardless of experience level or team size, because it removes friction rather than adding it.

As for my own founder journey, as far as I can go building this alone, I want to. That’s not a knock on team-based building. Plenty of great companies are built that way, and there’s real value in it. But personally, I don’t want a blame game. If something slips up, I want it to be a hundred percent on me, because it’s my name and my values on the line either way. With a team, if something goes wrong, someone can leave, get let go, or stay, but I’m still the one whose name takes the hit. And realistically, some people won’t want to admit fault if it puts their job at risk, so blame gets passed around instead of actually fixed. I’d rather own every mistake directly and fix it myself than have accountability get diffused across other people.

So the long-term vision, for both DeltaReview and TawakalStudio, is really an extension of what I’ve already been building: reaching a real base of clients and users that lets me compound from there, staying solo as long as I can, because I want my name fully attached to both the wins and the mistakes.

Working the other side of this problem? The integration layer Rahim is choosing to avoid is exactly where the rest of the market is moving. Our ranking of the [best MCP servers](/best-ai-tools/best-mcp-servers/) tracks how AI agents are actually being wired into repositories, CI and editors today, and our list of [AI tools every developer should use](/best-ai-tools/ai-tools-every-developer-should-use/) covers the rest of the stack.

#### About Rida Rahim

[Rida Rahim](https://www.linkedin.com/in/rida-rahim-a7b2652b5) is the founder of DeltaReview, an AI-powered code diff analyzer supporting 23+ programming languages, and the CEO of TawakalStudio LLC, a web design, development and digital branding studio serving local businesses on Long Island, New York. She is a computer science student at the New York Institute of Technology, entering her third year in the 2026 fall semester.

DeltaReview grew out of ReviewAI, a real-time AI code reviewer she built for a Codex Challenge on Handshake that was selected for the Showcase. The current product is built on Next.js, TypeScript, the Groq API and Vercel serverless functions. As of this interview in August 2026 it is in beta, free to use, and running on free-tier hosting without a dedicated domain, which Rahim describes as a stage-appropriate decision rather than a permanent one.

She is enrolled in ETCS 350, NYIT’s NESTS course (“Necessary Eleven Steps to Tech Startups”), for the fall 2026 semester, with DeltaReview approved as her course project. Her other work includes TawakalPlayer, a kiosk-mode Quran audio player built in Kotlin, Jetpack Compose and Media3 ExoPlayer, running on a secondhand Samsung Galaxy A10e locked into Android Device Owner and Lock Task Mode.

#### The Bottom Line

The most interesting thing about DeltaReview is not the product. It is the set of things Rahim has decided not to build, and the fact that she can articulate why for each one.

No login. No GitHub integration. No persistent storage. No IDE plugin. No team plan. No co-founder. Every one of those is a default that competing tools treat as obligatory, and she has a specific argument against each: the login is the friction she built the tool to escape, the pipeline integration recreates the setup cost she was trying to remove, the persistence follows from the missing account, and the co-founder diffuses an accountability she wants concentrated on her own name.

That is a coherent position, and it is also an expensive one, in a way worth naming.

A tool with no accounts has no retention loop, no email list, and no easy way to see which of the 23 languages people actually paste in. When Rahim says she has no meaningful usage data, that is not only because she is early. It is partly a structural consequence of the design she chose. She has built a product that is hard to learn from, and then correctly identified that the way to improve it is real user feedback, which is the one input the architecture makes hardest to collect at scale. Cold outreach on LinkedIn is not a stopgap here. Without a change to the design, it is close to the only channel the product supports.

The same tension runs through the roadmap. She wants to close the gap on generic refactoring suggestions through user feedback, and she wants to keep the surface that makes users invisible to her. Those two goals pull against each other, and the resolution is probably the optional layer she already sketched for integrations: an account for people who want history, staying entirely out of the way for people who do not. The argument she makes for keeping integrations optional applies just as well to storage.

What makes her worth watching anyway is the self-audit. A founder who volunteers, unprompted in an interview, that her own product returns “review and refactor if needed” as a suggested fix is applying a standard most early-stage founders reserve for competitors. The security and logic bug findings are the part she claims work, and those are the checkable ones. Paste a diff with an injection flaw in it and you can test her claim in about thirty seconds, which is more than most AI code review marketing lets you do.

So the thing to watch over the next twelve months is whether the specificity improves. She has named the gap, named the bar, and named the only method she thinks will close it. If DeltaReview comes back with findings that cite the actual variable, the actual line and the actual fix instead of a hedge, the narrow bet on the pre-review moment holds. If the suggestions are still generic, the friction advantage will not be enough, because what developers ultimately judge a review tool on is not how fast the answer arrived but whether it told them something they did not already know.

Want more of these? [Read more founder interviews](/interviews/) where builders explain the decisions behind their products, or [request an interview](/submit-interview-request/) if you are building something worth talking about.

### ConvertMyStore Interview: Thiago Nobre on Commerce Teams With Too Much Data and Too Few Decisions
URL: https://zplatform.ai/interviews/convertmystore-thiago-nobre-interview/
Updated: 2026-08-19
Interviewee: Thiago Nobre | Role: Founder & CEO | Company: ConvertMyStore

TL;DR: ConvertMyStore founder and CEO Thiago Nobre explains why he gave up a working US$29 to US$149 entry diagnostic to rebuild the company around what he calls a decision layer, now sold across ecommerce, DTC, social commerce and digitally enabled retail, why AI in his framework never gets decision rights, and why he refuses to publish a most common revenue leak, a diagnostic-to-engagement conversion rate, or a traction number until the sample justifies it. He also gives a dated, falsifiable prediction about agentic commerce in 2031 and names the condition that would prove him wrong.

Five separate times in this interview, Thiago Nobre declined to give me the better story.

Asked for the moment the thesis crystallised, he says there was no dramatic client conversation and that he does not want to invent one. Asked which of his seven revenue leak categories is the real culprit most often, he refuses on the grounds that naming one is exactly the shortcut his taxonomy exists to prevent. Asked whether he has lost a deal over refusing to guarantee rankings, he says he cannot point to one and will not manufacture it. Asked for the conversion rate from entry diagnostic to full engagement, and then for traction numbers, he declines both until the volume makes the figure useful rather than decorative.

That is a lot of unanswered questions for a founder interview, and it is the most informative thing in the piece. A company whose entire pitch is “we separate what we observed from what we inferred” either applies that standard to its own marketing or it does not.

ConvertMyStore started as something much smaller and much easier to explain: a Shopify-focused Revenue Leak Scan sold asynchronously at US$29, US$79 and US$149. It now positions as an AI Commerce Intelligence and Implementation company, with an entry assessment listed on the site from US$1,000, a four-stage Diagnose to Prioritize to Implement to Optimize framework, a seven-category Revenue Leak Taxonomy, and a Partner Network that executes delivery outside the company’s own payroll.

One clarification worth making up front, because it is the exact problem Nobre describes later in this interview when he talks about entity ambiguity: Shopify was where the original diagnostic started, not where the company sits now. ConvertMyStore today sells across ecommerce, DTC, social commerce and digitally enabled retail, and describes its current focus as spanning revenue intelligence, AI discovery and GEO, and governed implementation. Shopify remains one important commerce ecosystem among several rather than the company’s positioning or its service boundary.

The argument underneath the repositioning is worth taking seriously even if you never buy anything. Execution got cheap. Analysis got abundant. The number of defensible things a commerce team could do next exploded, and nothing in the stack owns the question of which one to do first. Nobre’s bet is that the scarce capability is no longer generating options but sequencing them, and that the sequencing has to stay human because nobody has worked out how to make a probabilistic model accountable for being confidently wrong.

He is operating from Brazil, under Thiago Nobre Franqueira LTDA, selling into the United States, United Kingdom, Canada and Australia. Here is the conversation.

#### The Founder Journey

##### Introduce yourself in your own words: your background before ConvertMyStore, and what you were doing right before you started it.

I spent more than two decades in commercial roles around technology, telecom and B2B solutions. The recurring part of the job was never just explaining technology; it was helping a buyer decide why a solution mattered, what should be prioritized, and what had to change after the purchase. Immediately before ConvertMyStore, I was working around B2B technology sales and partnerships while also building and testing digital AI ventures, including StackPilot AI. That combination made me increasingly interested in the gap between having more technology and making better decisions with it.

##### What in your career made this specific problem, the gap between commerce data and commerce decisions, the one you wanted to build a company around?

Across my career, I kept seeing the same pattern: companies could buy more software, collect more data and add more dashboards, yet still struggle to decide what deserved attention first. The bottleneck was often not access to information but the translation of information into a sequenced decision. Commerce makes that problem especially visible because acquisition, product data, conversion, operations and retention all interact. I wanted to build around that decision gap rather than around another isolated tool.

##### ConvertMyStore appears under a couple of entities in public materials. Can you clarify the structure for readers, and where you are personally based and operating from?

The current structure is simpler than some older public references suggest. ConvertMyStore is a commercial brand operated by Thiago Nobre Franqueira LTDA, a Brazilian company; Wellness Brands is the registered trade name of that legal entity, but it is not the customer-facing identity of ConvertMyStore. Nobre Ventures was an earlier venture identity I used while I was based in Portugal, and references linking it to ConvertMyStore are now outdated; it is not the current operating entity behind the company. I am currently based in Brazil, and ConvertMyStore is built to serve digital commerce businesses internationally.

##### Your LinkedIn also mentions building StackPilot AI. How do those fit together, and how do you divide your attention?

StackPilot AI is a separate project I built around AI software discovery and comparison. It is not a product line, parent company or shared commercial offering with ConvertMyStore, and I have deliberately kept the brands and infrastructure separate. ConvertMyStore is my current operating priority because it is closer to a service-led problem with a clearer path to revenue and client outcomes. StackPilot remains a separate project rather than something I try to bundle into the ConvertMyStore story.

#### The Repositioning

##### Walk us through the original proposition. What was the narrow ecommerce diagnostic you started with, and what did the deliverable actually look like?

The first public proposition was deliberately narrow: a Shopify-focused Revenue Leak Scan designed as a low-friction, asynchronous diagnostic. It was offered in entry tiers at US$29, US$79 and US$149, with deliverables ranging from a directional review and prioritized risks to a deeper action plan and annotated store review. The offer did exactly what an early validation product should do: it forced us to codify the diagnostic logic, build the operational workflow and test how buyers reacted to a concrete problem rather than a broad consulting promise. It was never intended to be the final shape of the company, and we are not treating a small early sample as a benchmark.

##### What was working about it, and what was not? Was it a demand problem, a pricing problem, or a “this does not change anything for the client” problem?

What worked was the clarity of the problem: merchants immediately understand the idea that revenue can leak between traffic and purchase, and the narrow offer forced us to codify how we inspect a buying journey. What became clear very quickly was that the valuable part was not the report itself; it was the decision logic behind it. A business does not ultimately need one more diagnosis, it needs to know which finding deserves attention, what should happen next and who will execute it. That insight is what moved ConvertMyStore from a diagnostic product toward an intelligence-and-implementation model.

##### When did you realise the real problem was not a shortage of dashboards or AI tools but not knowing what to fix, prioritize, or build next?

There was not one dramatic client conversation that created the idea, and I do not want to invent one. It crystallized while building the diagnostic, studying the market and looking at how many specialized tools a commerce team can already buy. The more tools you add, the more obvious the coordination problem becomes: one system flags conversion, another flags feeds, another generates content, another reports attribution, but none owns the question of what should happen next. That was the moment I started thinking of ConvertMyStore as a decision layer rather than a diagnostic product.

##### Repositioning from “diagnostic” to “AI Commerce Intelligence and Implementation” is a big leap in scope and in what you are asking a buyer to believe. What did that cost you?

The repositioning cost us simplicity in the short term. A Shopify diagnostic is easy to explain in one line; AI Commerce Intelligence and Implementation asks us to prove a broader operating model and a bigger point of view. We chose to make that change before scale made the old positioning expensive to unwind. The real investment has been building the methodology, production workflows, governance model and Partner Network required to support the broader promise. In other words, we decided to build the operating model before trying to manufacture the appearance of scale.

##### Looking back, was the diagnostic a wrong start or a necessary one? What did you only learn by shipping the narrow version first?

I see the narrow diagnostic as a necessary start, not a mistake. It forced us to turn vague ideas about conversion into a repeatable inspection process and exposed the limits of stopping at diagnosis. It also taught me a broader operating rule: do not productize or automate a new offer just because you can; prove demand manually first. The diagnostic still has a role as an entry point, but it no longer defines the company.

##### How do you now explain the company to a skeptical operator in two sentences, without leaning on the category name?

We help digital commerce teams find where growth is being constrained, decide what deserves attention first, and turn that decision into implemented work. We combine structured evidence, AI-assisted analysis, expert judgment and governed execution instead of handing over another dashboard or a generic list of recommendations.

#### The Decision Layer Thesis

##### Make the core argument for us: why do digital commerce businesses increasingly need a decision layer between data and execution?

Execution has become cheaper and faster while the number of possible actions has exploded. Commerce teams now operate across more channels, more data sources, more automation and AI-generated customer journeys, including search experiences where the buyer may never start on the brand’s website. That creates a paradox: teams can do more things, but the cost of choosing the wrong thing has also increased because everything is interconnected. In that environment, prioritization becomes an operating capability rather than a quarterly planning exercise.

##### Ecommerce teams already have analytics, session recording, CRO tools, feed tools, and now a dozen AI copilots. Be specific about what still fails.

Most tools are excellent at answering a narrow question, and that is also their limitation. Analytics can show a drop, session recordings can show behavior, feed tools can flag data quality, and copilots can generate recommendations, but none of those outputs automatically understands margin, team capacity, strategic timing and dependencies across the whole business. The gap appears when five tools produce ten valid actions and the team still cannot agree on the first two. That is where decision quality, not data volume, becomes the constraint.

##### Your framework ranks priorities against business impact, evidence strength, implementation effort, urgency, and strategic relevance. Which of those five do clients most often get wrong on their own?

The failure mode I designed the framework around is evidence strength. Teams can easily confuse a plausible explanation with a sufficiently supported one, especially when a dashboard or AI system presents it confidently. Implementation effort is the other discipline I think operators routinely underestimate: a theoretically high-impact idea can still be the wrong next move if it consumes scarce engineering or operational capacity. The point of the framework is to force impact, evidence, effort, urgency and strategic relevance into the same decision instead of letting the loudest metric win.

##### Your Revenue Leak Taxonomy defines seven categories of leakage. Which category is most commonly the real culprit and most commonly misdiagnosed?

I deliberately resist naming a universal “most common” category because that is exactly the shortcut the taxonomy is designed to prevent. The visible symptom is often not the origin of the leak: what looks like a conversion problem can begin in acquisition quality, product and offer clarity, discovery, checkout or operational decision-making. Once we have a defensible sample, I want to publish the distribution rather than turn intuition into a statistic. The disruptive idea here is that “conversion rate” is often the end of the story operationally, but it should be the beginning of the diagnosis.

##### Prioritization implies saying no. What is an example of a finding that was real, technically valid, and that you still told a client not to work on?

A technically valid finding is not automatically a priority. A store can have a measurable page-speed issue, for example, while a broken payment path or severe traffic-intent mismatch is destroying far more value. Fixing speed first would still produce an improvement, but it could be the wrong use of the next unit of engineering capacity. Prioritization is the discipline of protecting a business from valid but mistimed work, and that is often harder than finding the problem in the first place.

##### How do you know the decision layer worked? What do you measure to prove the sequencing itself created value, separate from the individual fixes?

We measure the decision layer by what it changes operationally, not by whether the framework looks sophisticated. The key signals are time-to-decision, the size and age of the unresolved backlog, implementation cycle time, acceptance against written criteria, and the business outcome attached to each implemented change. The sequencing is creating value when low-priority work stops consuming scarce capacity and high-confidence actions reach implementation faster. Over time, that operating evidence should become more valuable than any proprietary score.

#### Automation Plus Human Judgment

##### Draw the line concretely. What does AI do in your workflow, and what does a specialist do that AI does not touch?

AI does the high-volume mechanical work: collecting and normalizing evidence, comparing patterns, structuring first-pass findings, generating drafts and performing repeatable QA checks. A specialist interprets business context, challenges the model’s assumptions, judges evidence quality, weighs trade-offs, decides priority and approves what is safe to recommend or release. Partners or specialists can then execute approved work, while ConvertMyStore retains scope, quality and acceptance governance. The principle is simple: automation prepares, experts decide, specialists implement, and governance closes the loop.

##### You state that AI makes no autonomous decisions in your framework. What made you that firm about it?

It was an architectural choice, not a reaction to one incident. Generative models are probabilistic, can be confidently wrong and do not carry commercial accountability for the consequences of a decision. I am comfortable letting AI do more and more of the analytical work; I am not comfortable quietly transferring authority over pricing, customer experience, spend or release decisions to a model. Our view is that AI should make analysis abundant while decision rights remain explicit.

##### Where has AI-generated analysis been confidently wrong in your work, and what does your review process catch that a fully automated product would ship?

The failure mode I pay the most attention to is causal overreach: incomplete evidence gets converted into a confident explanation. A model can see weak conversion and a slow page and jump to “speed is the cause,” even when traffic quality, offer fit or checkout friction could matter more. It can also treat absence of evidence as evidence of absence or rely on technically accessible but outdated information. Our review layer exists to challenge causality, downgrade confidence and ask what evidence is missing before a plausible narrative is allowed to become a business decision.

##### As models improve, does the human layer shrink? What part of expert judgment stays human, and what are you already comfortable handing over?

The human layer should shrink dramatically around mechanical work, but not around accountability. Collection, normalization, first-pass pattern detection, drafting and deterministic QA are exactly the kinds of work I want models and agents to absorb. What remains scarce is context, trade-off judgment, exception handling and ownership of consequences. My view is that AI will make expert judgment more valuable, not less, because analysis and execution will become abundant.

New to the terminology? Terms like [inference](/guides/ai-glossary/) and agentic workflow get used constantly in commerce AI pitches without ever being defined. Our AI glossary covers 264 of them with citations.

##### Every finding is “documented, dated and traceable to observable evidence.” Why the emphasis on traceability, and how much extra work does that discipline cost per engagement?

Traceability is what turns advice into an auditable operating record. If every finding is dated and tied to observable evidence, we can see what was known at the time, what changed, why a decision was made and whether the recommendation still holds. That discipline does add overhead, which is why we are automating evidence capture wherever the rules are deterministic. I would rather spend compute on documentation and give the expert more time for judgment than save a few minutes and lose the ability to explain a decision later.

#### No Magic Scores, No Guarantees

##### You deliberately avoid automated “magic scores” and guaranteed outcomes. That is a harder sell than a competitor promising a number or a ranking. Why hold the line?

Because false precision is still false, even when it is easier to sell. A single number can look objective while hiding assumptions, weights, stale data and uncertainty, and a guaranteed ranking or revenue outcome claims control over systems we do not control. I would rather make a narrower promise about the quality of the process: documented evidence, explicit confidence, defined scope and accountable implementation. That may be a harder sale, but it is a healthier basis for a long-term service.

##### What is wrong with scores specifically? What do they hide, and what bad client behavior do they create?

Scores compress complexity into a number and then invite people to optimize the number. They can hide whether a problem is high-impact or merely easy to measure, whether the underlying evidence is current, and whether two very different businesses arrived at the same score for completely different reasons. The bad behavior is treating movement in the score as the objective instead of improvement in the business. A score can be useful when its construction is explicit and bounded; what I object to is a proprietary magic number presented as truth.

##### Have you lost deals over refusing to guarantee rankings, citations, or revenue?

I cannot point to a closed deal we lost specifically over that stance, and I will not invent one for a better story. But the commercial line is already set: if a buyer requires a guarantee over an external platform’s ranking, an AI system’s citation behavior or a revenue number we do not control, we are comfortable walking away. That is not caution for its own sake; it is part of the product philosophy. I would rather build a smaller base of buyers who value evidence and accountability than create demand with promises that become liabilities later.

##### How do you give a buyer confidence to sign without a guarantee? What replaces the promise in your sales conversation?

Confidence has to come from process rather than prediction. We define the scope, show what evidence will be used, make acceptance criteria explicit, document what changes, and separate what we observe from what we infer. For implementation work, the buyer should be able to see what was approved, who executed it and how completion was verified. The replacement for a guarantee is transparency plus accountability.

#### AI Search, GEO and Generative Discovery

##### Explain in plain terms how AI answer engines and generative discovery are changing ecommerce visibility. What is materially different from classic SEO?

Classic SEO largely optimizes the conditions for a page to be crawled, indexed and ranked in a list of links. Generative discovery adds another layer: an answer engine may retrieve information from multiple sources, synthesize it, omit the brand entirely or describe it inaccurately without ever showing a conventional results page. For ecommerce, that means product facts, entity clarity, retrievable buying information and external corroboration matter alongside technical SEO and content quality. GEO is not a replacement for SEO; it extends the problem from “can you rank?” to “can a system retrieve, understand and represent you accurately?”

If the retrieval side of that is new to you, our guide to [how AI search engines work](/guides/how-ai-search-engines-work/) covers the mechanics Nobre is describing here.

##### You define AI Search Visibility as whether a brand is mentioned at all, and how accurately. How do you handle the fact that AI answers are non-deterministic and vary by user, session, and model?

We treat AI visibility as observation, not as a universal ranking score. For an approved set of prompts, we record the provider, date and context, whether the brand appeared, how it was described, which sources were cited or relied on when visible, and whether important facts were accurate. Because answers are non-deterministic, a single response is not treated as truth; the value comes from repeated observations and changes over time. The output is a dated baseline with known limitations, not a claim that we have reverse-engineered the model.

##### What is the most common way brands are currently misrepresented or invisible inside AI answers, and how much of the fix is technical versus editorial?

One recurring risk is entity ambiguity: the brand has changed, but search engines and AI systems are still seeing older descriptions, third-party references or inconsistent facts. ConvertMyStore itself has been a useful example. After our positioning evolved beyond a Shopify-focused diagnostic, older Shopify-centric descriptions and previews continued to surface in search and AI interfaces for a period. The fix is rarely only technical or only editorial; it can require crawlability, canonical facts, structured data, updated owned content and stronger external corroboration. That experience made the idea of “accurate representation” very concrete for me.

##### Most GEO advice on the internet right now is guesswork. What is genuinely knowable today, and what are people asserting with far more confidence than the evidence supports?

What is genuinely knowable is what a specific system returned for a specific query at a specific time, what sources were visible, whether the brand’s facts are accessible and consistent, and whether technical barriers are preventing retrieval. We can also observe changes across repeated tests. What I think is overstated is the idea that anyone knows a universal GEO score, the exact weighting of a proprietary model, or a guaranteed recipe for being cited. People are often turning a small set of observations into deterministic laws about systems that are changing underneath them.

##### Where does social commerce fit into discovery? Is TikTok Shop a channel, a search engine, or something else in your model?

I see TikTok Shop as a discovery environment, distribution channel and transaction surface at the same time. It is not a search engine in the classical web sense, but search, recommendations, creator content, affiliate distribution and checkout are compressed into one experience. That matters because the path from discovery to purchase is no longer a neat funnel that starts with Google and ends on a store website. Social commerce is part of the broader fragmentation of discovery.

##### What should an ecommerce leader do about AI discovery in the next 90 days, and what should they explicitly not bother with yet?

In the next 90 days, an ecommerce leader should establish a baseline: define the questions buyers are likely to ask, test how the brand and products are represented, fix obvious crawlability and entity inconsistencies, make product and buying facts retrievable, and improve the quality of evidence on owned and credible external sources. Then repeat the observations rather than judging success from one screenshot. I would explicitly avoid mass-producing AI content, buying low-quality citations, chasing a mysterious “GEO score,” or rebuilding the entire stack around a single answer engine. The first job is to make the brand clear, accessible and evidence-backed.

#### Business Model, Delivery and Competition

##### How do engagements actually run, from entry diagnostic to assessment to strategy to implementation?

The engagement path is modular rather than a mandatory funnel. Entry diagnostics are asynchronous and typically delivered in 24 to 72 hours; a broader AI Commerce Opportunity Assessment is usually scoped around two to three weeks; strategy work is typically two to four weeks; and implementation sprints vary by workstream, commonly from roughly one to six weeks. The operating model is intentionally service-led, tech-enabled and partner-scaled: automation prepares the evidence, experts interpret and prioritize it, approved specialists execute defined workstreams, and ConvertMyStore governs scope, QA and acceptance. Much of that collaboration is designed to work asynchronously in writing, which lets us bring the right specialist into the work without turning every engagement into a meeting-heavy consulting process.

##### Your entry diagnostics are described as “a way in, not the main scope.” What is the conversion pattern from diagnostic to full engagement, and where do prospects drop off?

The entry diagnostic is intentionally a lower-friction way to experience the thinking, not a disguised requirement to buy a larger project. The commercial hypothesis is that the best expansion trigger is not a sales script; it is evidence that a higher-value problem exists and that the client is ready to act on it. We are instrumenting the funnel to learn which entry points create qualified demand and where expansion actually happens. I am deliberately not publishing a conversion percentage until the volume is large enough to make the number useful rather than decorative.

##### You implement through your own team or approved delivery partners. How do you keep quality consistent when execution sits partly outside your walls?

The Partner Network is already part of the operating model, not a future slide in a deck. We have specialist partners who can originate opportunities, contribute expert review or execute defined delivery workstreams, while ConvertMyStore retains the methodology, scope governance, QA, acceptance criteria and release authority. The point is not to build a traditional agency payroll; it is to expand specialist capacity without diluting accountability. A partner gets a structured commercial and delivery framework, and the client still experiences one governed operating model. My shorthand is: partners can own the opportunity, but ConvertMyStore governs the experience.

##### Who is your real competition, agencies, consultancies, in-house teams, or SaaS tools, and where does each of them beat you?

All four are competitors in different moments, and I think pretending otherwise would make the positioning weaker. Agencies can beat us on specialist depth and execution scale; large consultancies can beat us on enterprise procurement and transformation capacity; in-house teams will always understand their own politics and customers better; and SaaS wins on speed and unit cost for a narrow repeatable task. The white space I see is the layer between them: cross-functional decision intelligence connected directly to governed implementation. The next commerce bottleneck will not be access to AI or another tool, it will be deciding which AI-generated action deserves authority.

##### State your USP in one sentence, then tell us the moat.

The USP in one sentence is: ConvertMyStore turns fragmented commerce signals into prioritized, evidence-backed decisions and governed implementation. The moat is not one algorithm, because algorithms get copied and foundation models improve. It is the combination of proprietary frameworks, judgment, traceability, partner-scaled delivery governance and the feedback loop that forms when recommendations are actually implemented and measured. Intelligence generation will become cheaper every year; disciplined decision-making and accountable execution are much harder to commoditize.

##### Who is the ideal client, and who is a bad fit? Be honest about the second one.

The ideal client is an established ecommerce, DTC, social commerce or digitally enabled retail business that already has traffic, data and multiple possible initiatives, but lacks a clear sequence for what to do next. They need enough operational maturity to implement decisions and enough openness to challenge assumptions. A bad fit is a very early store with no meaningful demand signal, a buyer looking for guaranteed revenue or AI rankings, or a team that wants a report but has no intention or capacity to act on it. We are building for operators who have complexity; if the problem can be solved by buying one more dashboard, we probably should not be in the engagement.

##### Any traction, scale, or team details you can share?

ConvertMyStore is in the commercial validation and early-scale stage, but the operating foundation is already in place. We have built the core methodologies, production workflows, governance infrastructure and a Partner Network with specialist partners so delivery capacity can expand without requiring a large fixed team. The model is deliberately service-led, tech-enabled and partner-scaled, with international commercial focus across the United States, United Kingdom, Canada and Australia. I am not interested in publishing vanity traction numbers before the sample is meaningful; the milestone that matters now is turning this infrastructure into a repeatable body of evidence-backed engagements and measurable implementation outcomes.

#### Forward View and Lessons

##### What will AI-driven commerce operations actually look like in three to five years? Give us a falsifiable prediction rather than a safe one.

My falsifiable prediction is that within five years the major commerce platforms will expose first-party agent action layers that can create or change products, promotions, content and operational workflows under policy controls, and teams will increasingly manage those policies rather than initiate every action manually. Routine commerce operations will move from “open a dashboard and do a task” to “set constraints, review exceptions and audit what agents did.” The ecommerce stack spent the last decade producing more dashboards; the next decade will be about deciding what deserves to happen. If most established digital commerce teams are still manually moving information between dashboards for the majority of daily operational work in 2031, that prediction will have been wrong.

##### Which parts of commerce operations do you expect to be fully agentic, and which will stubbornly stay human-owned?

I expect data hygiene, catalog enrichment, tagging, routine reporting, anomaly detection, content variants, first-line support triage and many repeatable workflow steps to become highly agentic. Human ownership will persist around economic policy, brand and offer strategy, capital allocation, high-risk exceptions, major partner decisions and final accountability for changes that can materially affect customers or revenue. The dividing line will move, but it will be based less on whether an agent can perform the task and more on the cost of being wrong. We are not trying to automate judgment; we are trying to make judgment faster, better evidenced and easier to execute.

The plumbing behind that shift is already being standardised. Our roundup of the [best MCP servers](/best-ai-tools/best-mcp-servers/) tracks how agents are actually being wired into commerce and operational systems today.

##### What is the hardest lesson you have learned building this, and what would you do differently if you started again today?

The hardest lesson has been that building something and proving that people will pay for it are completely different activities. I have a natural tendency to see a system, improve it and add capability; that becomes dangerous when distribution and demand are not being validated at the same pace. If I started again today, I would sell the manual version earlier, put buyer evidence ahead of product depth, and refuse to automate a workflow until repeated demand justified it. That lesson became a rule inside ConvertMyStore: technology should scale validated value, not substitute for validation.

##### What is on the roadmap for the next 6 to 12 months?

The next six to twelve months are about proving and compounding the operating model, not multiplying SKUs. The priorities are deeper implementation evidence, AI discovery and visibility monitoring, selective AI automation and agent work for commerce operations, and continued expansion of the Partner Network for specialist delivery. Commercially, the focus is international, with the United States, United Kingdom, Canada and Australia as priority markets. We will productize where repeated demand creates leverage, but the company will remain service-led at the core because judgment and implementation are where the highest-value problems live.

##### What advice would you give a founder positioning a company in a category that does not have a settled definition yet?

Start with the problem and the operating behavior, not with the category label. Publish a precise definition, say what the category does not mean, and make the workflow concrete enough that a skeptical buyer can judge it without agreeing with your terminology. Then let evidence, use cases and outcomes sharpen the definition over time. In an unsettled category, the founder has a rare advantage: you are not only competing inside a market, you can help define the language the market will later use to understand itself.

#### Quickfire

##### One belief about AI in ecommerce that you hold and most of your industry would argue with.

AI will make expert judgment more valuable, not less. Analysis and execution will become abundant; the scarce capability will be deciding which action deserves authority, budget and accountability.

##### Anything we did not ask that you want readers to know.

AI commerce is not about adding an AI feature to a store. It is about redesigning how evidence becomes a decision, how that decision becomes execution, and how the result becomes intelligence for the next decision, a continuous operating loop rather than another isolated tool.

##### Where should readers go to reach you or start with ConvertMyStore, and what is the most useful thing someone could do for you right now?

Readers can reach me through [convertmystore.com](https://www.convertmystore.com/) or start with the AI Commerce Opportunity Assessment on the site. The most useful thing someone could do right now is introduce us to an established digital commerce operator with a real prioritization or implementation challenge, or to a specialist who sees a strong fit with the Partner Network. The next phase of ConvertMyStore is about putting the operating model against more real business constraints and turning that evidence into repeatable advantage.

#### About Thiago Nobre

Thiago Nobre is the founder and CEO of [ConvertMyStore](https://www.convertmystore.com/), an AI Commerce Intelligence and Implementation company serving ecommerce, DTC, social commerce and digitally enabled retail businesses. He spent more than two decades in commercial roles across technology, telecom and B2B solutions before starting the company, and he is based in Brazil.

ConvertMyStore is operated by Thiago Nobre Franqueira LTDA, a Brazilian legal entity, and sells internationally with the United States, United Kingdom, Canada and Australia as priority markets. It launched as a Shopify-focused Revenue Leak Scan at US$29 to US$149. That narrow entry offer was a starting point rather than the current service boundary: the company now sells across ecommerce, DTC, social commerce and digitally enabled retail, and describes its focus as spanning revenue intelligence, AI discovery and GEO, and governed implementation. The current model is organized around a four-stage Diagnose, Prioritize, Implement and Optimize framework, a seven-category Revenue Leak Taxonomy, and a Partner Network of specialist delivery partners. Its entry AI Commerce Opportunity Assessment is listed on the site from US$1,000 (checked 18 August 2026). Nobre also separately builds StackPilot AI, an AI software discovery and comparison project he keeps deliberately unconnected from ConvertMyStore.

#### The Bottom Line

Take the refusals seriously, because they are the product.

Nobre would not name a most common revenue leak category, would not produce the client conversation that supposedly triggered the pivot, would not invent a lost deal, would not publish a diagnostic-to-engagement conversion rate, and would not give a traction number. Every one of those was an easy win in an interview, and he passed on all five for the same stated reason: the sample is not big enough to make the number mean anything yet. A company selling “we separate what we observed from what we inferred” that then inflates its own figures in press would be worth ignoring. This one does not, at least here.

The strategic argument is genuinely contrarian in a market currently selling autonomy. Nearly every AI commerce pitch right now is some version of “the system will decide for you.” Nobre’s position is that analysis is about to be free and therefore worthless as a differentiator, and that the scarce, defensible thing is deciding which of ten valid actions gets budget and engineering capacity first. That is why he will not let a model hold decision rights, and why he is building governance, traceability and acceptance criteria instead of a score.

The obvious risk is that a decision layer is much harder to buy than a diagnostic. He said so himself: a Shopify scan sells in one line, and AI Commerce Intelligence and Implementation requires a buyer to believe in an operating model. He gave up a working, cheap, self-explanatory offer for a US$1,000 entry point and a category name that does not exist yet. Whether that was conviction or a demand problem in the making is exactly the question his own missing conversion numbers would answer.

So the thing to watch is the distribution he says he wants to publish. If ConvertMyStore comes back in twelve months with the real spread across those seven leak categories, a conversion rate from entry diagnostic to engagement, and implementation outcomes tied to dated findings, the evidence-first positioning holds and the refusals in this interview look like discipline. If those numbers never arrive, the refusals were just a nicer way of not having them.

Want more of these? [Read more founder interviews](/interviews/) where builders explain the decisions behind their products, or [request an interview](/submit-interview-request/) if you are building something worth talking about.

### XRP Healthcare Interview: Kain Roomes on AI Health, Africa, and Rebuilding After the Crash
URL: https://zplatform.ai/interviews/xrp-healthcare-kain-roomes-interview/
Updated: 2026-08-13
Interviewee: Kain Roomes | Role: Founder & CEO | Company: XRP Healthcare

TL;DR: XRP Healthcare founder and CEO Kain Roomes explains how the XRPH AI app has delivered $1.2 million in prescription savings to 77,000+ cumulative users across 217 countries while still being pre-revenue by design, why the company bought a pharmacy chain in Africa, and how a $2.5M raise splits across six areas. He also confirms the AAJ Capital 3 listing transaction did not complete, and draws a hard line between the one monetisation path with a modelled forecast behind it and the two that are still target scenarios.

“Crypto plus healthcare plus AI” is the kind of phrase that makes you close the tab. Three of the most over-promised categories in tech, stacked. Roomes knows it, and says so in this interview before I could.

What makes the conversation worth reading is where he stops selling. Asked about the TSX-V listing path through AAJ Capital 3, he does not spin it: the transaction did not complete and both sides walked away. Asked which of three monetisation paths becomes the biggest revenue engine, he separates the one with an actual modelled forecast, subscriptions at $10 a month, from enterprise partnerships and AI licensing, which he calls target scenarios rather than signed contracts. He even corrects the premise of my first question, which had him in debt in 2018 when he was simply broke with a Rolex in a safe.

The numbers he does claim are specific enough to check: $1.2 million in prescription savings, 77,000+ cumulative users across 217 countries and territories, up to 80% off at more than 68,000 US pharmacies through a partnership with United Networks of America, and a token that hit a $194 million peak valuation within three months of launch before the market took it back.

Roomes founded [XRP Healthcare](https://www.xrphealthcare.ai/) in 2022 with his father Laban as co-founder, after losing most of a crypto fortune in that year’s crash. In this interview he walks through the XRPH AI app and wallet, the Proof Of Health™ rewards framework, the first African pharmacy acquisition, the compliance posture across three very different regulatory environments, and what long-term success looks like to someone who has now made and lost and remade the same money twice.

#### The Founder Journey

##### Take us back to the moment before 2018, how deep in debt were you, and what was going through your mind when you decided to sell your Rolex Submariner as your last resort?

I wasn’t in debt at this time. I was broke, with no income, just the Rolex Submariner sitting in my safe. It was actually after losing most of the money I’d made in the 2022 crash that the debt really piled up, to the point I owed my girlfriend at the time, who I was living with, over £15,000, plus around £20,000 to the mortgage company, with my property close to being repossessed. Deciding to sell the Rolex was an easy call. I wasn’t even wearing it, it was just sitting in the safe. I knew I wanted to get rich, and that watch was the tool that would get me there.

##### Why crypto, and why that specific moment in 2018? What did you see that made you willing to put your last money into it?

I was on holiday in Jamaica with my family and saw my dad by the pool one day reading a book about Bitcoin. I was excited and curious, and about a week later, once I was back in England, I fully locked in on crypto, day and night, sometimes sleepless nights, and from there the rest is history.

##### What was it like going from that debt to becoming a millionaire, and then losing it all? What did each of those extremes actually teach you?

I’m someone who said my affirmations every day, to the point I actually believed I was a millionaire before I became one. I fooled myself into believing I already had millions, so when it materialised, it wasn’t a surprise, it was as if it had always been there and reality just caught up. Then when I lost most of it, I needed that lesson, honestly. It woke me up, made me more alert, stopped me taking things for granted. I got greedy and comfortable, and comfort isn’t good. We constantly need to stay alert, and I lost focus. I believe nothing happens by chance, obstacles are there to teach and develop us. I was meant to lose that money so my character could become stronger and wiser. I’m glad it happened sooner rather than later, we all need these moments to shake us up and sharpen us. It also taught me I need to secure profits sooner and not be greedy.

##### A lot of founders would have quit after losing a fortune. What made you keep going, and how did that experience shape the founder you are today?

I’m a born winner, I’ll always find a way to win, maybe not straight away, but eventually. I’ve been like that since I was a child. I’d already tasted what it’s like to materialise millions, so I knew I could do it again. And I did. Since starting XRP Healthcare in 2022, I’ve made more than double what I lost in that crash.

#### The Origin of XRP Healthcare

##### How did you go from crypto trader to founding XRP Healthcare in 2022, why healthcare, and why on XRP Ledger specifically?

I just wanted to change my situation, really. I needed money, needed a new direction. It was my dad who recommended I start a crypto project, and from there it was in motion. Even though I’d said I’d never want a crypto project, given the crazy stick and abuse founders get, this time felt different, and it worked.

##### Your father Laban is your co-founder. What’s it like building a company with your dad, and how do you split responsibilities day-to-day?

It’s beautiful, really. We have a natural connection and we both aim for perfection. We sharpen each other’s iron and always want the best out of a situation, even if we disagree at times, we always land on the best conclusion. It’s an honour to be working with my dad, I’m truly blessed.

##### The XRPH token reached a peak valuation of $194 million within its first three months. How did you handle that speed of validation, and what did the market volatility that followed teach you?

It was encouraging to see, it showed there was big interest in the project. But I didn’t get excited, I just continued with what needed to get done in the moment, because I’ve seen many projects hit high valuations and come down hard when the bear market arrives.

#### The XRPH AI App & Platform

##### Could you walk us through what the XRPH AI App actually is today, the core user experience from download to daily use?

Someone downloads the app and lands in what’s essentially an AI-powered healthcare engagement platform. Day to day, that means an AI Health Advisor for guidance, daily health check-ins, CalmXRPH for stress and breathing support, a Prescription Savings Card, and Proof Of Health™, where genuine healthy engagement earns XRPHAI rewards. The wallet then sits alongside it as the infrastructure layer, so the whole thing works as one connected ecosystem rather than a set of separate tools.

##### Can you tell us more about the AI Health Advisor, what problems it solves for users, and how it’s different from generic AI health chatbots?

Most AI health chatbots are built as a bolt-on to something else. Ours was purpose-built for this specific job, not adapted from a general-purpose model. It’s there to give people personalised guidance, multilingual support, and a genuine sense of navigation through their own health journey, rather than a generic Q&A box. The difference is it’s tied into the wider ecosystem, so the guidance connects to real actions, like prescription savings or Proof Of Health™ rewards, not just information sitting on its own.

##### How does the prescription savings feature work in practice, up to 80% off across 68,000 US pharmacies? Who are the pharmacy partners and how did you build that network?

This runs through our partnership with United Networks of America, UNA, a US healthcare network solutions provider that already serves over 120 million members through more than 240,000 participating healthcare providers. Through that, our Prescription Savings Card gives users up to 80% off eligible medications at more than 68,000 pharmacies, including Walgreens, CVS, Walmart, Kroger, and thousands of independents. We didn’t have to build that pharmacy network from scratch, we built the right partnership instead, and integrated it properly into the app rather than leaving it as a separate coupon.

##### Proof of Health™ rewards is a really interesting concept. Can you explain how it works, what actions users take, what they earn, and how it ties back to the XRPH token?

The idea is simple, we reward people for genuine engagement with their own health, not vanity metrics like step counts. That could be using the Prescription Savings Card, completing a health check, or engaging with the AI Health Advisor. Eligible actions earn XRPHAI rewards, which can then move through to the XRPH Wallet. It’s the first framework of its kind, as far as we’re aware, that ties verified AI-driven healthcare engagement directly to a blockchain reward.

##### Where do features like CalmXRPH and Doctor Finder fit into the bigger picture, and which features are driving the strongest engagement so far?

CalmXRPH is actually our highest engagement feature right now, it speaks to how much people want simple, accessible support for stress and wellbeing, not just medical information. Doctor Finder fits in as part of the wider navigation piece, helping people actually act on the guidance they get from the AI Health Advisor, rather than leaving them stuck after a conversation.

##### How do the XRPH Wallet and XRPH AI App work together, and how important is the crypto/token layer to the end-user experience vs. purely being an economic layer?

They’re two distinct products that function as one ecosystem. The App is the healthcare engagement layer, where people actually interact with their health. The Wallet is the infrastructure layer, non-custodial, built on the XRP Ledger, handling self-custody and settlement. Healthcare information stays off-chain, intentionally separated from blockchain transactions, so the token layer adds real value through rewards without ever compromising the privacy of someone’s health data.

#### Traction & Numbers

##### You’ve delivered $1.2M in prescription savings across 77,000+ combined cumulative users, all pre-revenue. What do those numbers actually tell you about product-market fit right now?

To me, it says people are actually using this for something real, not just downloading it and forgetting about it. $1.2 million in genuine prescription savings is money back in people’s pockets, that’s proof the product does what it says. We’re pre-revenue by design at this stage, the priority has been proving real usage and real value first, monetisation is the next chapter, not the first one.

##### Are the 77,000+ users concentrated in a specific geography or demographic, and how do you plan to bridge from cumulative users to 1M+ monthly active users?

We’ve reached users across 217 countries and territories since launch, so it’s genuinely global, though the US is our top market given the Prescription Savings Card. Getting from where we are to 1M+ monthly active users comes down to a few things working together, direct acquisition through creators and paid channels, deepening healthcare partnerships that bring users in at scale, new exchange listings that reach existing token communities, and continuing to lead on the AI product itself so people stay, not just download and leave.

#### Africa Expansion & M&A Strategy

##### You’ve just completed your first retail and wholesale pharmacy chain acquisition in Africa. What’s the strategic thesis behind Africa specifically, and how does it connect back to the AI app?

Africa carries a disproportionate share of the world’s disease burden relative to the number of health workers available, so the need is real, and I think the continent has been treated as an afterthought by health tech built elsewhere for too long. Our thesis is simple, build something that actually meets people where they are, not a stripped-down version of a product designed for someone else’s market. That’s why XRPH AI became Africa’s first HIPAA-grade health app, not because anyone told us to, but because African users deserve the same data protection standard as anyone else, not a watered-down one. The app itself, the AI Health Advisor, the prescription savings, Proof Of Health™, all of it is built to work the same way for someone in Kampala as it does for someone in Dubai or New York.

##### XRP Healthcare M&A Holding Inc. suggests M&A is a core part of the strategy. What’s the acquisition playbook, what kinds of targets, what integration model, and how do you fund it?

The playbook is about acquiring real, functioning healthcare infrastructure and technology partnerships that extend what the app can offer, rather than trying to build every single piece from zero. Alongside that we’ve got Letters of Intent with Isansys Lifecare, an NHS collaborator in AI-enabled remote patient monitoring, and Spiritus Medical, giving us access to their NASA-designed VITALITY ventilator technology. Funding runs through the current $2.5M raise and ongoing revenue as the platform scales.

#### The $2.5M Raise & Path to Enterprise Value

##### You’re currently raising $2.5M in growth capital. How is that broken down across product, distribution, M&A, and marketing?

It splits across six areas: 26% into global user growth, mainly marketing and acquisition, 24% into digital asset and exchange expansion, getting XRPHAI onto higher-tier exchanges, 20% into strategic healthcare partnerships, deepening what we’ve already got with UNA, Isansys, and Spiritus, plus new ones, 12% into institutional readiness, audit, compliance, governance, 10% into working capital and reserve, and 8% into AI product leadership.

##### Your monetisation paths are freemium + premium subscriptions, enterprise healthcare partnerships, and AI licensing. Which one do you believe becomes the biggest revenue engine long-term, and why?

Subscription is the clearest path right now, it’s the one with an actual modelled forecast behind it, priced at $10 a month, projecting toward $12M in annual recurring revenue by 2030 as we scale toward a million users. Enterprise partnerships and AI licensing represent bigger long-term upside on paper, but I want to be straight, those are target scenarios based on the size of the opportunity, not signed contracts today. Subscription is the one I’d point to as the near-term engine, the others are where I believe this goes over time.

##### You’ve mentioned public markets and strategic acquisition as potential exits. How are you thinking about the TSX-V listing path via AAJ Capital 3, and what does that unlock for shareholders?

The transaction with AAJ Capital didn’t complete, as they weren’t the right fit for us in the end, and we mutually agreed to part ways. We’re currently raising a further $2.5 million to fund three main things: growing our user base, expanding where our token is traded by getting listed on more exchanges, and strengthening our AI capabilities, with the option of doing an RTO and becoming a publicly listed company.

#### AI, Trust & Regulation in Healthcare

##### Healthcare AI faces serious trust, safety, and regulatory challenges. How are you approaching clinical safety, data privacy, and compliance across the US, Africa, and other jurisdictions?

We’ve built with HIPAA-grade security standards in mind for protecting sensitive health information, encrypted communications, secure authentication, role-based access, privacy-by-design from the ground up rather than bolted on afterward. On the token side specifically, we’ve taken formal legal opinion, including from GS Legal in Singapore, on how XRPHAI is classified under securities and payment services law. Compliance isn’t a single jurisdiction problem for us, it’s something we’re building to be modular enough to meet different standards as we expand.

##### What’s your position on where AI should and shouldn’t be in the patient journey, assisting the user, augmenting a doctor, or something more autonomous?

For me, AI’s role is to assist and guide, not replace clinical judgement. It’s there to help someone understand their own health better, point them toward the right next step, whether that’s a pharmacy saving or finding a doctor, not to make an autonomous medical decision on someone’s behalf. That’s also why we keep healthcare information intentionally separated from the blockchain layer, the technology should support trust, not complicate it.

New to the terminology? Terms like [non-custodial wallet](/guides/ai-glossary/) and inference come up constantly in AI health products without ever being defined. Our AI glossary covers 264 of them with citations.

#### Competition, Market & Positioning

##### Companies like GoodRx (savings), Ada/Babylon (AI symptom checkers), and various Web3 health projects touch parts of what you do. Where do you clearly win, and where are you still building the moat?

Most of those companies do one piece of what we do well, savings, or AI triage, or a token layer, but not all three connected together. Our moat is that combination, a proprietary AI platform that was purpose-built rather than adapted, Proof Of Health™ as the first framework rewarding verified AI-driven engagement specifically, and a wallet that gives those rewards real, usable value. Where we’re still building is scale, turning that combination into the kind of user numbers and enterprise partnerships that make the moat undeniable rather than just structurally true.

##### What’s your response to skeptics who see “crypto + healthcare + AI” and immediately worry it’s a mashup rather than a focused product?

I understand the instinct, that combination can sound like buzzword bingo if you haven’t looked closely. My response is always to point to what’s actually real, a genuine partnership with UNA reaching 68,000+ pharmacies, a Letter of Intent with an NHS collaborator in Isansys, real users saving real money on prescriptions. The crypto and AI pieces aren’t there for the sake of being trendy, they’re the mechanism that makes the healthcare engagement and rewards model actually work. Once people see the real partnerships and real numbers behind it, that scepticism tends to soften.

#### Roadmap & Vision

##### What’s on the XRP Healthcare roadmap for the next 12 to 24 months, covering MAU milestones, enterprise deals, AI licensing customers and further African expansion, and what does long-term success look like for you personally, after everything you’ve been through to get here?

Over the next 12 to 24 months, it’s about pushing hard toward that 1,000,000+ monthly active user mark, and building toward our first real enterprise and AI licensing customers rather than just the target scenarios we’ve modelled. Africa is a huge, genuinely underserved market, industry analysts project the African healthcare market will reach $259 billion by 2030, so the need and the opportunity are both real. XRPH AI is a global platform though, and the roadmap is about continuing to grow across all our markets, not just one. Personally, long-term success isn’t really about a number for me anymore. After selling that Rolex with nothing left, then losing it all again in 2022, and then building it all back up once more, what matters most now is that this company is still standing, still growing, still genuinely helping people, that’s the win that actually means something.

#### About Kain Roomes

Kain Roomes is the founder and CEO of XRP Healthcare, an AI healthcare platform built on the XRP Ledger, which he started in 2022 alongside his father Laban Edward Roomes as co-founder and COO. He entered crypto in 2018 after selling his Rolex Submariner to fund his first positions, built and then lost most of a fortune in the 2022 crash, and says he has since made back more than double what he lost.

The company now operates the XRPH AI app and the non-custodial XRPH Wallet, holds a prescription savings partnership with United Networks of America covering more than 68,000 US pharmacies, has completed its first retail and wholesale pharmacy chain acquisition in Africa, and carries Letters of Intent with Isansys Lifecare and Spiritus Medical. He can be found on [LinkedIn](https://ae.linkedin.com/in/kainroomes).

#### The Bottom Line

The most useful answers in this interview are the ones that cost Roomes something.

He could have left the AAJ Capital 3 question alone and let the TSX-V listing path stand as a live plan, since that is how it had been reported. Instead he says plainly that the transaction did not complete and the two sides parted ways. He could have put enterprise healthcare partnerships and AI licensing forward as revenue engines, because both sound larger than a $10 subscription. Instead he flags them as target scenarios based on opportunity size, not signed contracts, and points at the subscription line as the only one with a real forecast behind it. In a category where projections routinely get presented as pipeline, that distinction is worth more than the projections.

The rest of it is a bet on sequencing. Prove real usage first, at $1.2 million of prescription savings and 77,000+ cumulative users, then monetise. Buy working healthcare infrastructure in Africa rather than build it. Keep health data off-chain so the token layer never becomes the privacy problem. Every part of that is defensible, and none of it is proven yet, because the company is still pre-revenue by its own description and the 1M+ monthly active user target is roughly an order of magnitude away from where cumulative users sit today.

So the number to watch is not the token price or the raise. It is whether subscription revenue actually arrives at something close to $10 a month per user, because that is the only monetisation claim in this interview with a model attached, and everything else in the plan is funded by it.

Want more of these? [Read more founder interviews](/interviews/) where builders explain the decisions behind their products, or [request an interview](/submit-interview-request/) if you are building something worth talking about.

### CostLoop Interview: Milosh Mladenovski on Tracking SaaS Waste Without Bank Access
URL: https://zplatform.ai/interviews/costloop-milosh-mladenovski-interview/
Updated: 2026-08-01
Interviewee: Milosh Mladenovski | Role: Founder | Company: CostLoop

TL;DR: CostLoop founder Milosh Mladenovski explains why his subscription tracker deliberately refuses bank connections, how a two-person bootstrapped team in Oslo competes against funded enterprise platforms, and why he corrects his own marketing claims mid-interview. The product tracks $430,000+ in software spend across 8,200+ subscription records, with a free tier for 5 subscriptions and Pro at $9 per month.

Most founder interviews are an exercise in careful inflation. You ask about traction, you get a number stripped of context. You ask about compliance, you get a list of acronyms.

This one went differently, and that is why it is worth reading. Three separate times, Milosh Mladenovski walked back a claim that would have made CostLoop look better. He rejected the framing that his product is certified against eight privacy regulations. He refused to give me a customer segment breakdown because his dataset is not yet reliable enough to support one. He labelled his own 18% savings statistic a reference point rather than a guarantee.

That is unusual, and it made the rest of the answers more credible, not less.

CostLoop launched in May 2026 out of Oslo, built by two founders with no outside funding. It sits in a specific gap: too small for Cledara or Zluri, too serious for a spreadsheet. The product’s most interesting decision is what it refuses to do, which is connect to your bank. In this interview, Milosh explains that tradeoff, the economics of bootstrapping from one of the most expensive cities in Europe, and which marketing channels actually moved the needle for a two-person team.

#### Founder Story & Origin

##### Can you introduce yourselves and give us a brief overview of CostLoop, when it was founded, the team behind it, and the fact that you’re building out of Oslo?

CostLoop is a subscription tracking and SaaS spend management platform for freelancers, agencies, startups, and small to medium-sized businesses.

We started the company in Oslo in 2025 and launched it in May 2026. I am Milosh Mladenovski, the founder, and I lead the product, user experience, and technical direction. Aleksandar Antevski is the co-founder and focuses primarily on business operations and growth.

We built [CostLoop](https://costloop.app/) because smaller businesses often have the same software-spending problems as larger companies, but they do not have procurement teams, finance departments, or budgets for complex enterprise platforms.

CostLoop gives them one place to see what software they are paying for, how much it costs, when it renews, who owns it, and where it can be cancelled. Users can add subscriptions manually, import them from a CSV or bank statement, or use the Chrome extension to surface subscriptions from Gmail or Outlook.

We are building from Oslo, but the product is intended for a global audience.

##### You’ve said CostLoop came from a problem you experienced yourselves. Can you share that “aha” moment and the specific bill that pushed you to start building?

There was not one cinematic moment involving a single enormous invoice. It was more frustrating than that, because it was the accumulation of smaller charges.

I sat down to review our statements and found three services that had continued billing even though they had not been actively used for months. None of the individual charges looked catastrophic, which was exactly why they had remained unnoticed.

Once we cancelled them and calculated the annual cost, the waste became obvious. The money was part of the problem, but what frustrated me more was that it was completely preventable.

We had invoices in different inboxes, annual and monthly billing cycles, different currencies, and no single place showing the complete picture. We were managing parts of it through memory and spreadsheets, which worked until the number of tools increased.

That was the real “aha” moment. The problem was not forgetting one subscription. The problem was not having a system that made forgetting impossible.

##### What made you decide to turn a personal frustration into an actual SaaS product rather than just fixing it with a spreadsheet or a one-off script?

A spreadsheet can solve the inventory problem temporarily, but it does not solve the ongoing management problem.

It can list a subscription, cost, and renewal date. It does not automatically remind the responsible person, calculate costs across different billing cycles, highlight missing ownership, store cancellation links, or warn you that multiple tools may be solving the same problem.

A script would have created a similar limitation. It might have solved our specific setup, but it would not have created something understandable and maintainable for a freelancer, agency owner, or operations manager who is not technical.

The more we looked at the market, the clearer the gap became. At one end, people were using spreadsheets, Notion, or calendar reminders. At the other end, there were enterprise platforms with procurement workflows, corporate cards, SSO discovery, sales calls, and enterprise pricing.

There was very little in the middle for someone who simply needed clear visibility and reliable reminders without handing over their banking credentials.

That gap looked much larger than our personal problem.

Recognise the pattern? If you have never audited your own stack, run the numbers first. Our free [SaaS vs lifetime deal calculator](/best-ai-tools/) shows what a recurring tool actually costs you over 24 months, which is usually the moment people start cancelling.

#### Building a Bootstrapped SaaS

##### Why did you choose to bootstrap instead of raising funding, and how has that shaped the product?

CostLoop did not need millions of dollars to prove whether the core problem was real.

Raising funding too early can create pressure to increase headcount, expand the scope, and chase growth before the product has earned it. We wanted the freedom to build around real user problems rather than an investor narrative.

Bootstrapping forced us to be disciplined. Every service we pay for, every feature we build, and every marketing experiment has to justify its cost.

It has also influenced the product itself. CostLoop is deliberately simple because we cannot afford to build features that look impressive in a pitch deck but are rarely used by customers.

The downside is speed. A funded competitor can hire separate teams for development, marketing, sales, support, security, and partnerships. We cannot pretend that two people can match that output.

The advantage is focus. We can change direction quickly, speak directly with users, and say no to features that would move CostLoop away from the problem it was created to solve.

##### What does the team look like today, and how are you splitting time between building, marketing, and support?

We are a two-founder team.

I lead product development, UX/UI, technical decisions, website strategy, and much of the content. My professional background is in enterprise UX/UI design, so I spend a lot of time making complicated workflows understandable and reducing unnecessary steps.

Aleksandar focuses more heavily on operations, commercial activities, partnerships, and helping us evaluate where the business should spend its limited time and resources.

In reality, the responsibilities still overlap. When you are bootstrapped, nobody gets to say, “That is not my department.” We both test the product, answer users, review analytics, evaluate marketing channels, and discuss roadmap priorities.

The hardest part is not doing the work. It is deciding which work deserves attention. There is always another feature, article, marketplace, integration, directory, partnership, or support improvement available.

Our job is to identify the small number of things that can materially improve the product or distribution and ignore most of the rest.

##### What have been the biggest tradeoffs of bootstrapping compared to a funded competitor?

The largest tradeoff is that we cannot build several major product areas simultaneously.

Enterprise competitors can develop SSO discovery, procurement, corporate card infrastructure, contract negotiation, employee lifecycle management, mobile applications, and dozens of integrations at the same time. We have to choose a much narrower problem.

We have therefore said no, at least for now, to becoming a complete expense management platform, accounting platform, virtual card provider, or enterprise IT management suite.

We have also moved slower on integrations, mobile applications, large-scale outbound sales, and formal partnership programs.

Another tradeoff is that founders become the bottleneck. Marketing work can delay product work, and a technical issue can pause content or outreach.

But limitations can be healthy. They force us to ask whether a requested feature strengthens the main product or merely makes the feature list longer. CostLoop should not become a smaller, weaker copy of an enterprise platform. It needs to be excellent at the narrower job it was designed to perform.

##### Building from Oslo, do you see advantages or challenges compared to founders in SF, London, or Berlin?

Oslo has influenced how we think about privacy, product quality, and sustainability.

European users are generally more cautious about how products collect and process data. Building here made us question whether broad access to someone’s bank account or full email content was truly necessary. That led us towards data minimisation from the beginning.

The timezone is also useful. We can communicate with Europe during the normal working day and still overlap with North America later in the afternoon.

The challenge is that Oslo has a smaller software founder ecosystem than San Francisco, London, or Berlin. There are fewer specialised SaaS events, investors, journalists, partnership opportunities, and potential early adopters within immediate reach.

Norway is also an expensive place to build a company. Bootstrapping from Oslo means watching infrastructure, software, legal, and operational costs closely.

However, being outside the largest startup centres can also protect you from copying whatever is fashionable. It makes us focus more on whether users genuinely need something rather than whether other founders are talking about it.

#### The Product

##### Walk us through what CostLoop actually does, from signup to a clean view of every subscription.

The process begins by creating an account. No credit card is required for the Free plan.

The first job is building an accurate subscription inventory. Users can add tools manually, import an existing spreadsheet or bank statement CSV, or use the Chrome extension to scan billing-related metadata from Gmail or Outlook.

Every potential subscription is reviewed and confirmed by the user. CostLoop does not silently decide that every recurring-looking transaction or email is definitely a subscription.

Once confirmed, the subscription record can include the cost, currency, billing cycle, renewal date, owner, number of seats, category, invoice or contract link, cancellation URL, and internal notes.

CostLoop then normalises monthly and annual costs so users can see their total software spending in one dashboard, even when some tools are billed monthly and others annually.

Renewal reminders notify the user before the next charge. The Health Score and savings tools help identify missing ownership, unused seats, duplicated categories, and subscriptions that require attention.

The goal is to move the user from scattered information to one maintained source of truth.

##### You offer an inbox scanner and manual entry, deliberately avoiding bank integrations. Why that specific approach?

No single discovery method is complete.

Manual entry gives the user maximum control and works for any vendor in any country. The downside is that people often forget subscriptions they are already paying for.

The inbox scanner helps fill that gap. Almost every software company sends a receipt, renewal notice, invoice, or price-change notification. That makes an inbox a valuable record of subscriptions without requiring access to a bank account.

Bank statement CSV import covers another part of the problem. It can identify recurring charges that may use unexpected vendor names or may not have sent an easily detectable email.

We deliberately chose file-based bank statement import rather than a persistent live connection. The user exports the statement, decides what to upload, reviews the result, and remains in control.

This approach is less automatic than a permanent banking connection, but it reduces privacy concerns, removes dependence on regional open-banking providers, and allows CostLoop to work with banks and card providers worldwide.

##### Tell us about the Bank Statement CSV import and the Health Score. What problems were you solving with each?

The Bank Statement CSV importer solves the cold-start problem.

Asking a user to manually enter 20 or 30 subscriptions is a terrible onboarding experience. Many people will add the first three, become distracted, and never complete the inventory. Importing a bank or card statement lets CostLoop surface likely recurring charges so the user can review them much faster.

It also catches vendors that may have been forgotten completely or that bill under a parent company name.

The Health Score solves a different problem. Having a complete list is useful, but a list does not tell you what deserves attention.

The Health Score provides a 0-100 view of the condition of the subscription portfolio. It considers signals such as missing owners, unused seats, duplicate categories, overdue or upcoming renewals, and incomplete records.

The score itself is not the final goal. Its value is that it converts an unstructured list into an actionable review. Users can see why the score is low, fix specific issues, and watch it improve.

##### How does the Chrome extension work under the hood, and what was the response after launching it?

The extension connects through Google or Microsoft OAuth. Users do not give CostLoop their email passwords.

It works with limited, read-only access and examines billing-related metadata such as the sender, subject line, and date. It does not need to read message bodies or attachments to surface likely billing and renewal emails.

The scanner reviews the previous 12 months, looks for patterns associated with invoices, receipts, renewals, subscriptions, and recurring charges, and presents possible matches to the user. Nothing is added to the CostLoop dashboard until the user reviews and confirms it.

The launch reinforced that discovery is one of the hardest parts of subscription management. People often know they need better tracking but do not know what their complete list actually contains.

It also showed us that permission explanations matter enormously. Users do not simply ask whether a scanner works. They ask exactly what it can read, what is stored, and what happens after the scan. That trust question has influenced both the product and our communication around it.

#### Privacy-First Positioning

##### “No bank connection, no password sharing, no financial data access” is a strong stance. Is that a product decision or a values decision?

It is both.

As a values decision, we do not believe a subscription tracker should automatically receive the broadest possible access simply because that access is technically available.

As a product decision, reduced access removes several sources of friction and risk. We do not need to maintain live banking connections, support different open-banking systems in every market, or ask users to trust us with credentials that are not necessary for the service.

The tradeoff is that CostLoop is not completely passive. Users must import a file, scan their inbox, or add information manually, and they must confirm what is saved.

We consider that a reasonable tradeoff. Full automation is not automatically better when it requires permanent access to highly sensitive information.

When explaining the difference from tools such as Ramp or Cledara, we are also clear that they solve broader problems. They may provide cards, procurement, expense controls, or payment infrastructure. CostLoop is for users who want subscription visibility and renewal control without replacing how their business pays for software, at a considerably lower cost.

##### You list compliance with GDPR, UK GDPR, FADP, PIPL, APPI, PIPA, PDPA, and DPDP. What did that take operationally as a small team?

I would be careful with the wording here. We do not claim that CostLoop has received eight separate government certifications.

What we have done is design our product, policies, and operational safeguards around the major privacy principles represented in those regulations.

The practical work includes data minimisation, explicit consent, clear purposes for processing, user data export and deletion, documented subprocessors, a Data Processing Agreement, EU-based data hosting, encryption in transit and at rest, restricted access, and transparent privacy and cookie documentation.

For the inbox integration, we intentionally limited access to metadata needed for detecting likely subscriptions and avoid storing email bodies or attachments.

The difficult part for a small company is not writing a privacy policy. Anyone can generate legal-looking text. The difficult part is making sure the product architecture and everyday operations behave consistently with what that policy promises.

We still review this as the product evolves. Compliance is not a document you publish once and forget.

##### Is privacy-first positioning a lasting moat, or something bigger tools will eventually adopt?

Privacy alone is not a permanent moat. A larger company can rewrite a policy, add consent controls, or release a lighter integration.

The stronger advantage comes from architecture and incentives.

If a product’s discovery, card, procurement, and analytics systems depend on broad financial or identity access, changing that model is more difficult than adding a privacy-focused paragraph to the website.

CostLoop has been designed around user confirmation, limited data access, portability, and no persistent bank connection. That affects how features are built from the beginning.

The other part of the moat is trust. Trust develops through consistent behaviour, clear explanations, and not quietly expanding permissions over time.

Bigger tools may absolutely improve their privacy practices, and I hope they do. Our responsibility is not to assume they will remain weak. It is to keep proving that a useful subscription management product does not need to become invasive.

#### Market, Competition & Positioning

##### Your positioning is sharp: “too small for Cledara or Zluri, too serious for spreadsheets.” How did you land on that wedge?

We arrived at it by looking honestly at who was being poorly served.

A business with three subscriptions probably does not need CostLoop. A simple spreadsheet may be enough.

A company with hundreds or thousands of employees may need automated SSO discovery, employee lifecycle management, procurement workflows, corporate cards, and dedicated SaaS operations. An enterprise platform makes sense there.

The underserved group sits between those extremes. It includes freelancers with a serious software stack, agencies, startups, and small businesses paying for 10, 20, or 50 tools without a dedicated procurement team.

They have outgrown a spreadsheet, but they do not want an enterprise sales process, a long implementation, or pricing that costs more than the subscriptions they are trying to manage.

That wedge shapes our pricing, onboarding, and roadmap. We optimise for fast setup, understandable workflows, and practical renewal control.

It also helps us say no. We are not trying to rebuild every feature offered by Cledara, Zluri, Zylo, or Vendr.

##### Where do you clearly win against spreadsheets and enterprise tools, and where do you honestly still lose?

Against spreadsheets and Notion, we win on automation and structure.

CostLoop automatically normalises monthly and annual spending, sends renewal reminders, provides a renewal calendar, assigns owners, stores cancellation links, identifies possible duplicates and unused seats, and calculates portfolio health. A spreadsheet can imitate parts of this, but somebody has to build and maintain the system manually.

Against enterprise tools, we win on simplicity, speed, pricing, and privacy. There is no implementation project, procurement call, SSO requirement, card migration, or bank connection.

Where do we lose? We do not currently offer the depth of enterprise SaaS discovery, identity management, employee onboarding and offboarding, vendor negotiation, corporate card controls, or complex procurement approval that larger platforms offer.

Our discovery also depends more heavily on user review. We consider that good for accuracy and privacy, but it is less automatic than a deeply integrated enterprise system.

We should not pretend CostLoop is the best product for every company. It is intended to be the right product for a specific type of company.

##### Your 2026 SaaS Waste Report cites 18% average savings after a first audit. What’s the story behind that number?

The report was created because we kept finding that small businesses understood they probably had waste, but lacked useful benchmarks.

It combines external research from established SaaS management sources with patterns observed through subscription audits and user-reported waste categories. It looks at problems such as zombie subscriptions, excessive seat counts, duplicate tools, forgotten annual renewals, and the rapid growth of AI software spending.

It is important to describe the methodology accurately. This is a synthesis report and benchmark, not a controlled scientific survey of every CostLoop customer. The 18% figure is an average reference point, not a guaranteed outcome.

From a marketing perspective, the report gives us something more useful than another promotional page. It creates data and frameworks that founders, operations teams, journalists, and other publications can reference.

#### Users & Traction

##### Can you share how CostLoop is doing today? What’s the split across freelancers, agencies, startups, and SMBs?

The current aggregate product figures show more than $430,000 in software spend tracked and more than 8,200 subscription records managed through CostLoop.

Those figures should not be confused with CostLoop revenue, annual recurring revenue, or the number of paying businesses. They represent activity and subscription data managed through the platform.

Our strongest user groups are freelancers, agencies, startups, and small to medium businesses. The common pattern is not a specific industry. It is that one person or a very small operations team has become responsible for software spending without having a dedicated procurement system.

We do not currently publish precise percentages for each segment because our dataset is still developing and user-type classification is not consistent enough for us to present a split confidently.

I would rather say that honestly than publish percentages that look precise but are not reliable.

What matters strategically is that the original target group is showing up: people with enough subscriptions for the problem to hurt, but not enough organisational complexity to justify an enterprise platform.

##### Could you share specific customer stories where CostLoop found meaningful savings?

One example is a freelance designer who had subscriptions spread across both personal and business cards. After creating a complete inventory, she found two tools that were no longer being used and cancelled them. She also set reminders for her annual plans and used the advance notice before one renewal to review the plan instead of letting it charge automatically.

Another example is a 12-person marketing agency managing more than 30 software products across several cards. Their audit identified subscriptions with no clear internal owner. Four tools were cancelled and two were moved to lower plans. More importantly, the agency introduced named ownership and a recurring review process, which reduced the chance of the same problem returning six months later.

A third case involved an operations manager who discovered that the company’s estimated monthly software spending was significantly below the actual amount. Importing and reviewing statement data surfaced several subscriptions that were not recorded in any internal system. Some were cancelled, while others were reassigned to active owners.

The recurring lesson is that savings usually come from visibility first, not from complicated optimisation.

#### Marketing & Growth Lessons

##### What marketing channels have actually worked, and which underperformed?

SEO has been one of the most strategically useful channels because the problem has many specific search intents. People search for how to track software renewals, find hidden subscriptions, replace a subscription spreadsheet, compare Cledara alternatives, or control SaaS costs for a small team.

The Chrome Web Store is also useful because it places CostLoop close to the moment when somebody is actively looking for an inbox-based solution. It functions as both a distribution channel and a trust signal.

Founder interviews, product listings, and relevant partnerships help with credibility and search visibility, although they do not always produce immediate conversions.

Broad social media promotion has been less predictable. A post may receive impressions or likes without bringing qualified users. Generic startup communities and directories also tend to underperform unless the audience is already experiencing the exact problem CostLoop solves.

Our lesson has been that distribution channels with strong intent usually outperform channels with broad attention. Ten visitors actively searching for a renewal tracker can be more valuable than thousands of passive social views.

##### You have a lot of “vs. Cledara / Zluri / Notion” pages. What have you learned about ranking against much bigger competitors?

It is very intentional, but the goal should not be to publish hundreds of thin comparison pages.

Comparison searches happen near a decision. Someone searching “Cledara alternative for a small team” or “subscription tracker versus spreadsheet” already understands the category and is evaluating an approach.

The opportunity for a smaller company is specificity. We are unlikely to outrank a major competitor for a broad term simply by repeating the same generic product language. We can compete by answering narrower questions more directly and honestly.

That means explaining where CostLoop wins, where the competitor wins, which type of company should choose each one, and where the products are not genuinely comparable.

We have also learned that publishing the page is only the beginning. Search performance depends on internal linking, technical SEO, authority, updates, and whether the page actually satisfies the question.

A comparison page that reads like dishonest advertising may attract a click, but it will not build trust or survive long-term search quality changes.

##### What’s the most counterintuitive marketing lesson you’ve learned?

People rarely wake up wanting “SaaS management software.”

They notice a $400 renewal they forgot about. They realise the company pays for both Slack and Teams. They discover three unused AI subscriptions. An accountant asks for a list of recurring software costs and nobody has one.

The marketing works better when we begin with that concrete moment rather than with the product category.

Another counterintuitive lesson is that being global does not require pretending to be American or hiding that we are based in Oslo. The location can support the story when it is connected to product quality, privacy, and a practical European approach to data.

What does not work is talking endlessly about being a founder, being bootstrapped, or building in public without connecting it to a customer problem. Other founders may enjoy that content, but they are not automatically buyers.

The product story has to remain about the money and operational friction the user can avoid.

#### Pricing, Business Model & Roadmap

##### Walk us through the pricing model and how you decided what to charge for.

The Free plan allows users to begin tracking up to five subscriptions without a credit card. We wanted it to be genuinely useful rather than a dashboard that becomes unusable after a few minutes.

The Pro plan costs $9 per month and is designed for an individual user who needs to manage an unlimited number of subscriptions and use the deeper auditing, automation, import, reminder, Health Score, and savings capabilities.

The Business plan costs $39 per month and is aimed at teams that need shared workspaces, administrative views, subscription request and approval workflows, and integrations such as the REST API and webhooks.

Our pricing principle is that basic visibility should be accessible, while we charge for scale, deeper automation, collaboration, and integration.

We also wanted the price to be easy to understand. A subscription management tool for a small business should not require a sales call or a custom quote.

At $9 per month, catching one unnecessary annual renewal can pay for CostLoop for several years. That is the economic comparison we want users to make.

Paying monthly for tools you barely open? That is exactly the subscription bloat problem. Browse the [AI lifetime deals directory](/ai-deals/best-ai-lifetime-deals/) for one-time-payment alternatives worth checking before your next renewal.

##### Your June 2026 update mentions a public REST API and webhooks. Does this hint at a bigger platform play?

The API and webhooks are primarily aimed at operations teams, finance teams, developers, agencies, and businesses that already have reporting or workflow systems.

The REST API allows them to pull subscription records, spending totals, and other CostLoop data into tools such as Power BI or an internal dashboard.

Webhooks work in the opposite direction. They can notify another system when a subscription is created, updated, deleted, approved, or declined. That could trigger a Slack notification, create a task, or update an internal financial workflow.

It does create opportunities for accountants, consultants, resellers, and integration partners, but I would not describe CostLoop as making a broad platform pivot.

The immediate purpose is practical interoperability. Customers should not have to manually copy data out of CostLoop just because another system needs it.

Over time, we can learn which integrations are genuinely valuable and build the platform in that direction without losing focus.

##### What’s on the roadmap for the next 6 to 12 months, and what does long-term success look like?

The roadmap is focused on making discovery, auditing, and renewal decisions faster.

That includes improving inbox-based detection, making price-change detection more useful, strengthening bank statement and CSV imports, expanding team workflows, and improving the recommendations behind the Health Score and savings panel.

We are also interested in Slack notifications, calendar integration, and connectors for tools such as Zapier or Make. These make CostLoop fit into the workflows people already use rather than forcing them to check another dashboard constantly.

The API and webhook layer will continue to mature based on how operations teams and partners use it.

Long term, success does not mean turning CostLoop into accounting software, corporate banking, expense management, and enterprise procurement at the same time.

We want to remain focused on the recurring software lifecycle: discovering what is being paid for, understanding its cost, assigning responsibility, reviewing it before renewal, and removing waste.

The company can grow significantly within that scope. Staying focused and bootstrapped does not mean staying small. It means expanding because users need the next capability, not because a pitch deck needs a larger market category.

#### About Milosh Mladenovski

Milosh Mladenovski is the founder of CostLoop, an enterprise UX/UI designer, and a digital product specialist based in Oslo, Norway. He leads CostLoop’s product direction, user experience, and technical development.

Alongside building CostLoop, he works as an enterprise UX/UI designer on complex digital products and public services in Norway. His experience includes contributing to digital systems within the Norwegian defence sector, as well as designing applications that support the building permit process for municipalities across Norway.

His work focuses on simplifying complex regulations and workflows, improving usability, and creating reliable digital services for organisations with demanding operational, security, and accessibility requirements. He can be found on [LinkedIn](https://linkedin.com/in/miloshmladenovski), alongside co-founder [Aleksandar Antevski](https://www.linkedin.com/in/aleksandar-antevski-82672a254/).

#### The Bottom Line

The most useful thing in this interview is not the product. It is the number of times Milosh declined to make CostLoop look bigger than it is.

He rejected the idea that listing eight privacy regulations means eight certifications. He refused to publish a customer segment breakdown because the underlying data is not yet reliable. He described his own headline savings statistic as a reference point rather than a promise, and he named the specific things enterprise competitors do better. Any of those would have been easy to fudge, and none of them were.

That matters more than usual in this category, because subscription management is a trust purchase. You are handing a tool visibility into what your business pays for. A founder who overstates his compliance posture in an interview is not someone I would trust with inbox access, however limited that access technically is.

The strategic bet is also clear and defensible: refuse bank connections, accept that discovery will be slower and more manual, and win the users who were never going to hand over banking credentials to a two-person startup. That tradeoff is real and stated plainly rather than hidden behind automation language.

If you are paying for 10 to 50 tools with no single source of truth, the free tier costs nothing and five subscriptions is enough to see whether the workflow fits. If you are managing three subscriptions, Milosh will tell you himself that a spreadsheet is fine.

Want more of these? [Read more founder interviews](/interviews/) where builders explain the decisions behind their products, or [request an interview](/submit-interview-request/) if you are building something worth talking about.

### Aura++ Founder Praneet Brar on Building Launches That Outlast Launch Day
URL: https://zplatform.ai/interviews/auraplusplus-praneet-brar-interview/
Updated: 2026-07-22
Interviewee: Praneet Brar | Role: Founder | Company: Aura++

TL;DR: In this interview, Aura++ founder Praneet Brar explains how the launch platform turns a single submission into months of compounding SEO value: a DR 71 domain, a guaranteed dofollow backlink on paid tiers, and a one-time $17-$34 price instead of a subscription. Over 4,100 founders have launched through the platform since 2025.

Most product launch platforms sell you one good day. You submit, you get upvotes, traffic spikes for 24 hours, and by the following week the listing is buried under the next batch of launches. Aura++ was built on a different bet: that the backlink, the blog post, and the SEO-friendly launch page matter more six months later than they do on launch morning.

That bet is now backed by a DR 71 domain, more than 4,100 founders who’ve launched through [the platform](https://auraplusplus.com/), and a pricing model that charges once instead of monthly. In this interview, we sat down with Aura++ founder Praneet Brar to unpack why the platform started as a listing site and turned into a full launch toolkit, how the badge-backlink-blog-post-social bundle actually works, what separates a $17 launch from a $34 one, and where he sees the increasingly crowded launch-platform space heading in 2026.

#### Company & Background

##### Can you share a brief overview of Aura++, when it was launched, who founded it, and the story behind the name?

Aura++ launched in 2025 to help startups turn a product launch into long-term growth rather than a one-day event. Brar founded the platform around visibility that compounds: SEO, backlinks, and increasingly, AI discoverability.

The name carries a deliberate double meaning. “Aura” represents a startup’s digital reputation, the intangible sense of credibility and buzz around a product. The “++”, borrowed from programming syntax, symbolizes continuous improvement and momentum rather than a one-time boost. Put together, the name is the pitch: your online aura should keep incrementing after launch day, not reset to zero.

##### What gap in the launch/directory space did Aura++ set out to fill, and what was the founding insight?

The founding insight was simple: most launch platforms are built around launch day, while founders actually care about growth long after it. [Product Hunt](https://www.producthunt.com/), BetaList, Uneed, Peerlist, and Open-Launch all deliver solid initial exposure, but Brar noticed they typically provide limited long-term SEO value or discoverability once the launch-day traffic fades.

Aura++ was built to close that specific gap, bundling the launch itself with lasting assets: SEO, backlinks, launch content, and AI discoverability, so a launch keeps driving visibility well past the first 24 hours.

##### How did the idea evolve from a simple listing site into a bundled offering with badges, backlinks, launch blog posts, and social distribution?

It started as a straightforward product launch platform. Conversations with founders quickly revealed they wanted more than a listing; they wanted lasting visibility and tangible outcomes from every launch. That feedback loop led directly to adding launch badges, high-quality backlinks, launch blog posts, and social distribution, turning what started as a directory into a complete launch toolkit.

##### Aura++ won Top 1 Daily on [Open-Launch](https://open-launch.com/). How did that early validation shape the direction of the product?

Winning Top 1 Daily on Open-Launch was an important early milestone because it validated that founders saw genuine value in what Aura++ was building. It reinforced the belief that there was real demand for a launch platform focused on long-term visibility rather than launch-day traffic alone, and that momentum gave the team confidence to keep investing in SEO, backlinks, launch content, and broader distribution.

Curious whether Aura++ delivers on that bet? [Read the full zPlatform review of Aura++](/ai-reviews/aura-plus-plus-review/) for a hands-on look at what durable discoverability looks like once the launch-day spike fades.

#### Product & How It Works

##### Could you walk us through the end-to-end launch experience on Aura++, from submission to going live and beyond?

The process is designed to stay simple. Founders submit their product, and Aura++ uses AI to help generate and optimize the listing itself. Once approved, the product goes live with its own launch page, discoverable by the wider community. Beyond that initial launch, founders keep receiving lasting value through launch badges, SEO-friendly pages, backlinks, launch blog posts, and social distribution, so the launch keeps driving visibility well after day one.

##### What exactly does a founder receive with a launch? Can you break down the badge, backlink, blog post, and social posts?

Every launch on Aura++ is built to deliver value beyond the listing itself. Founders receive a launch badge they can display on their own site for credibility, a high-quality backlink that supports SEO, an SEO-friendly launch blog post that helps the product surface in search, and ready-to-share social posts to amplify the launch across multiple platforms. Together, Brar frames these as the tools that let founders build visibility and lasting discoverability instead of relying on a single day of exposure.

##### How does the daily/weekly launch cadence work, and how do you decide featured slots and homepage visibility?

Aura++ runs a curated daily launch model specifically to give every product meaningful visibility instead of burying it among hundreds of same-day listings. Products get organized into relevant categories, while featured and homepage placements come down to launch quality, completeness of the submission, relevance, and the value a given product brings to the community. That curation is deliberate: it’s what lets every launch get focused attention rather than getting lost in volume.

##### Is the launch blog post AI-generated, human-written, or a hybrid, and how do you keep it high quality and SEO-friendly?

The launch blog post follows a hybrid approach. AI handles the initial draft and structure, and that draft then gets refined and optimized for accuracy, readability, and SEO best practices. The goal isn’t speed for its own sake. It’s producing a genuinely high-quality, search-friendly article that keeps generating organic traffic long after the launch itself is old news.

##### How do you handle social distribution across X, LinkedIn, Bluesky, and Pinterest? Automated, curated, or manual?

It’s also a hybrid workflow. Automation generates platform-specific content and keeps distribution timely, while curation makes sure every post actually matches the product’s story and the tone of each individual platform. That combination is what lets founders get broad reach across four different platforms without the posts feeling generic or off-brand.

#### SEO, Backlinks & Traffic Value

##### What makes an Aura++ backlink “high quality”? Domain metrics, indexation, and dofollow policy across plans?

Aura++ currently runs on a Domain Rating of 71, and every launch page and blog post is fully indexable, SEO-friendly, and built to stay discoverable over time, a detail independently echoed in the platform’s own founder testimonials citing the same DR 71 figure.

Link attributes scale with the plan. Free launches receive a nofollow backlink by default, but a product that finishes in the Top 3 gets that backlink upgraded to dofollow. Premium and Premium Plus launches skip that competition entirely: both tiers include a guaranteed dofollow backlink regardless of how the launch ranks.

##### What traffic can a founder realistically expect from a Free vs. Premium vs. Premium Plus launch?

Brar is upfront that traffic varies by product, category, and how actively a founder promotes their own launch, so Aura++ deliberately doesn’t promise specific visitor numbers. What the team has consistently observed is that Premium and Premium Plus launches outperform Free launches, mainly because they come with guaranteed homepage placement, social distribution, a launch blog post, and a guaranteed dofollow backlink stacked together.

The bigger differentiator between tiers isn’t launch-day exposure at all. It’s the long-term SEO and referral value that keeps compounding well after the launch itself has ended, which lines up with the platform’s current published figure of 25,000-plus monthly views across the site.

##### How do you protect the quality and trust of the platform? Do you vet submissions or filter spam?

Quality sits high on the priority list. Every submission goes through a review process against Aura++’s own quality standards, actively filtering spam, duplicate listings, low-effort submissions, and misleading or inappropriate content. The goal is a curated platform where founders can trust that what’s featured is genuinely worth discovering, not a firehose of unvetted listings.

Want a second opinion on where a launch platform’s backlink actually ranks? [Run any domain through this free DR checker](/best-ai-tools/) the way I do before taking an SEO claim at face value.

#### Users & Community

##### Who is the ideal Aura++ user today, and where are you seeing the strongest traction?

Aura++ is built for anyone launching a digital product, but the strongest traction is coming from AI startups, [SaaS founders](/interviews/cosupport-ai-alex-khoroshchak/), indie hackers, and solo builders. These are teams that move fast, launch frequently, and specifically value long-term visibility through SEO, backlinks, and AI discoverability. No-code makers and agencies use the platform too, but Brar describes the core community today as early-stage founders building and shipping internet products.

##### How large is the current community, and what’s the growth trajectory looking like?

Aura++ is still in its early stages, but Brar calls the growth “very encouraging.” The platform has already earned the trust of 3,800-plus founders and makers, with new launches and community members joining every week, a figure that has since climbed toward 4,100-plus based on the platform’s current public numbers. Growth is coming organically through founder referrals, SEO, social media, and partnerships within the startup ecosystem.

The stated priority isn’t raw numbers. It’s building a high-quality community where every single launch creates real value for the founder behind it.

##### What’s the most surprising or creative way founders have used Aura++ to grow?

One pattern stood out to Brar: founders treating Aura++ as one piece of a broader launch strategy rather than a standalone event. They combine an Aura++ launch with Product Hunt, social media, newsletters, and other directories, using the Aura++ launch page, blog post, and backlink as long-term assets inside that bigger campaign. It’s a concrete example of founders thinking past launch day toward lasting visibility instead of chasing a short-lived traffic spike.

#### Technology & Differentiation

##### What’s the tech stack behind Aura++, and are there any interesting engineering decisions worth highlighting?

Aura++ runs on Next.js, chosen specifically for the performance, scalability, and SEO capabilities a product discovery platform needs. The team has also invested heavily in automation, from AI-assisted submissions to generating launch blog posts and social assets, so founders can launch with minimal manual effort while still getting SEO-friendly results on the other end.

##### What are the top USPs you’d emphasize to a founder comparing Aura++ to Product Hunt, BetaList, Uneed, or Open-Launch?

Brar points to five things specifically:

- Long-term SEO value through indexable launch pages, blog posts, and high-quality backlinks, not just launch-day exposure.
- Everything bundled into one launch: badges, backlinks, launch blog posts, and multi-platform social distribution, rather than piecing those together separately.
- An AI-powered launch experience that helps founders create an optimized listing quickly.
- Flexible launch options, including a free tier with a path to a dofollow backlink by ranking Top 3, alongside guaranteed dofollow backlinks on Premium plans.
- Built for modern discovery, meaning visibility across AI-powered search and answer engines, not just traditional search results.

##### Why keep parts of Aura++ open on GitHub, and how does that fit your broader philosophy?

The focus has always been on solving real problems for founders rather than open-sourcing the platform itself. GitHub gets used extensively as part of the internal development workflow, but Aura++ as a product isn’t open source. Brar frames the underlying philosophy as transparency about what gets built, closely listening to founder feedback, and continuously improving based on real usage rather than a roadmap set in stone.

#### Pricing & Commercials

##### Can you walk us through the Free, Premium ($17), and Premium Plus ($34) tiers, and which one tends to be most popular?

Aura++ pricing stays intentionally simple. Free suits founders who want to launch and reach the community, carrying a nofollow backlink by default that becomes dofollow if the product ranks Top 3. Premium at $17 is the most popular plan, bundling a guaranteed dofollow backlink, a launch blog post, social distribution, and enhanced visibility at an accessible price. Premium Plus at $34 is built for founders chasing maximum exposure, adding further promotional benefits and priority visibility, and per the platform’s own current pricing page, spotlight homepage placement and the tightest re-launch cooldown of the three tiers.

All plans support re-launches, letting founders come back after a major update or new feature release to reach a fresh audience instead of being limited to one shot.

##### How did you land on a one-time price point instead of a subscription, and are enterprise plans on the roadmap?

The one-time model was a deliberate choice. Founders already juggle enough recurring subscriptions, and a product launch is a milestone, not a monthly service, so Brar wanted pricing that stayed simple, affordable, and free of long-term commitment.

Enterprise and agency plans are on the roadmap, aimed at teams managing multiple product launches. The goal is bulk launches, team collaboration, and centralized management, while keeping the core platform founder-friendly for everyone else.

Weighing a $17 launch against a free one? [See how I evaluate one-time-payment tools](/ai-deals/best-ai-lifetime-deals/) before you decide whether a paid tier earns its cost for your specific launch.

#### Market & Competition

##### The launch platform space has gotten crowded. How do you see Aura++ positioning itself long-term?

Brar treats the growing competition as validation rather than a threat. The long-term focus isn’t on being just another place to launch, it’s on becoming the platform that delivers the most value after launch. While many competitors optimize for launch-day attention, Aura++ is built around long-term visibility through SEO, high-quality backlinks, AI discoverability, and reusable launch assets, and that’s the direction the team plans to keep investing in.

##### What trends are you seeing in how founders launch products in 2026, and how is Aura++ adapting?

Founders are no longer relying on a single launch platform. In 2026, Brar sees them combining launches with SEO, social media, backlinks, and AI-driven discovery to build visibility that compounds. They’re also thinking beyond Google, actively optimizing for AI search and answer engines where a growing share of users now discover new products.

Aura++ is evolving alongside that shift, aiming to give founders more than a listing: SEO-friendly pages, high-quality backlinks, launch content, social distribution, and AI-optimized visibility designed to keep products discoverable well after launch day.

#### Praneet Brar’s Founder Story & Vision

##### Could you share a bit about the founder’s story, and what the team looks like today?

Aura++ was founded by Praneet Brar, whom the platform describes as a builder focused on creating products that help other founders grow. The idea started from a simple observation: most launch platforms generate a short burst of attention but very little lasting value, and that gap led directly to building Aura++ around SEO, backlinks, and AI discoverability instead.

Today, the platform is built by a small, fast-moving team working closely with the founder community, shipping improvements quickly based on real user feedback rather than a rigid quarterly roadmap.

##### Could you highlight a few standout success stories from products that launched on Aura++?

Several founders have shared testimonials about gaining better visibility, valuable SEO backlinks, and sustained traffic after launching on Aura++, and the team has featured case studies of products using the platform as part of a broader launch strategy to amplify reach.

One of the strongest signals, in Brar’s view, has been the response from the community itself: many founders who launched once have come back to partner with Aura++, recommend it to others, or use it again for a future launch. That repeat engagement is the clearest indicator that the platform is creating value beyond a single launch day.

##### What’s on the roadmap for the next 6-12 months, and what’s the long-term vision?

The near-term focus is growing the platform, strengthening the SEO and AI discoverability offerings, and building the features the community actually asks for. Aura++ is also expanding into featuring selected products on its YouTube channel, giving founders another avenue to reach builders, early adopters, and potential customers.

Long term, Brar’s vision goes beyond a launch platform entirely: a complete growth ecosystem where every launch creates lasting value through discoverability, SEO, content, community, and continuous visibility, rather than a single transaction that ends the moment the launch page stops trending.

#### The Bottom Line

Aura++’s pitch holds up under its own numbers: a DR 71 domain, 4,100-plus founders, and a pricing model that charges once instead of every month for a service most founders only need a handful of times a year. What stands out most from this interview with Praneet Brar isn’t any single feature. It’s the consistent framing that a launch is a growth asset, not an event, which is exactly the discipline that separates a platform people use once from one they come back to for their next release.

If you’re [weighing Aura++ against Product Hunt](/best-ai-tools/), BetaList, or Open-Launch for an upcoming launch, the practical takeaway is to match the tier to what you actually need: free if you’re testing demand, Premium if you want the guaranteed backlink and blog post without gambling on a Top 3 finish. [Read more founder interviews](/interviews/) before you commit your next product launch to any single platform.

### CoSupport AI’s Alex Khoroshchak on Building Zero-Hallucination AI Support
URL: https://zplatform.ai/interviews/cosupport-ai-alex-khoroshchak/
Updated: 2026-08-07
Interviewee: Alex Khoroshchak | Role: CEO | Company: CoSupport AI

Most AI support tools promise the same thing: deflect more tickets, cut costs, scale without hiring. CoSupport AI promises something harder to fake - answers that are correct, [traceable to a source document](/ai-reviews/cosupport/), and backed by a refund if the AI does not reach a 60% resolution rate within 60 days.

That guarantee rests on a USPTO-approved architecture built to stop the one failure mode that quietly kills AI support deployments: confident, wrong answers. [We sat down with CEO](/interviews/) Alex Khoroshchak to unpack the technology behind the claim, the real numbers from customer deployments, how the pricing actually works, and why he believes the support inbox is the most underused data source in the company.

#### Company & background

##### When did CoSupport AI start, who founded it, and what was the original mission?

In 2020, Daria Leshchenko had spent more than a decade running support operations, and every tool on the market gave her the same result: generic bots, slow replies, no memory of the customer. So she founded CoSupport AI to build the product she couldn’t buy. 3 years of R&D and hundreds of tests later, that product drafts ready-to-send replies for support teams.

The company was formally established in 2023. In 2024, Alex Khoroshchak joined as CEO, leading the platform’s evolution into a fully customizable AI solution for customer service. The company is headquartered in the US and serves BPOs, [SaaS companies](/interviews/auraplusplus-praneet-brar-interview/), ecommerce platforms, fintech firms, and education providers globally. The mission has stayed consistent since day one: build AI that resolves support tickets accurately using a company’s own data, not generic training sets.

##### What problem in customer support did you originally set out to solve, and how has that vision evolved?

In 2020, the tools that existed were not solving the problem; they were superficial. The vision from day one was to build AI that goes beyond basic automation - something genuinely intelligent, helpful, and human-like. The first product was an AI assistant that generated ready-to-use reply suggestions for support agents. That was the starting point.

In 2023, the team set a bigger mission: build AI solutions that deliver immediate, measurable business results while setting a new standard for customer service. By 2025, under Alex Khoroshchak’s leadership, CoSupport AI had grown from that single support tool into a full platform covering autonomous ticket resolution, agent assistance, multilingual support across 40+ languages, and conversation analytics. The goal has not changed: make AI not just a tool in the support stack, but a trusted partner that handles the work intelligently and turns every customer interaction into actionable insight.

##### Who is your ideal customer today?

CoSupport AI fits companies with medium to high ticket volume, where a significant share of incoming requests are repetitive and well-documented. Specifically:

- Industries: SaaS, ecommerce, fintech, education, BPO, and contact centers

- Support team size: 5 to 500+ agents

- Ticket volume: 500 to 100,000+ tickets per month

- Tech stack: teams using Zendesk, Freshdesk, Intercom, Zoho, HubSpot, or Salesforce Service Cloud

The fit is strongest when three conditions are present: high repetitive ticket volume, an existing helpdesk with historical ticket data, and a support leader who measures success by resolution quality and cost, not just deflection rate.

#### Product & capabilities

##### Walk me through the core products in the suite.

CoSupport AI is a unified platform with four core components:

- AI Agent - fully autonomous. Handles incoming requests end to end across email, chat, helpdesk, and social channels, and resolves up to 90% of routine queries without human involvement. Trained on the company’s own tickets, knowledge base, and internal documentation.

- AI Assistant (Copilot) - agent-facing. Sits inside the helpdesk and drafts suggested replies using full conversation context. Agents review, edit, and send. Built-in translation and ticket summarization cut ticket-handling time by 40 to 60% on non-automated tickets.

- AI Business Intelligence (AI BI) - an internal assistant that answers questions about support operations, products, services, and customers. It connects to customer correspondence, the knowledge base, and internal docs to provide data-driven insights and analysis on request. Used by support, business analysts, product, and marketing, and integrated with Slack and MS Teams.

- AI Translator - handles 40+ languages natively inside the existing workflow. Detects language, translates, and responds in the customer’s language without a separate tool or multilingual agents.

##### Which channels does the AI support today?

CoSupport AI operates across email, chat, and helpdesk ticketing. On the helpdesk side it integrates with Zendesk, Freshdesk, Freshchat, Zoho Desk, Zoho SalesIQ, Intercom, and Salesforce. For internal workflows it connects to Slack and Microsoft Teams, and ecommerce and billing integrations include Shopify and Stripe. The most commonly deployed combination is email plus chat plus helpdesk, typically Zendesk or Freshdesk. For teams with custom CRMs or legacy systems, a flexible API enables custom integration.

##### How does the AI handle multilingual conversations, and how many languages are supported?

The AI Translator component supports 40+ languages out of the box. Language detection is automatic: the system identifies the customer’s language from the incoming message, retrieves the relevant answer from the knowledge base (which can be in any language), and generates the response in the customer’s language. A single AI instance handles every locale without separate training per language or separate routing by language. That is especially valuable for BPOs and global ecommerce operations serving multi-regional customers.

##### What does a typical onboarding and go-live timeline look like?

The standard timeline is 15 days from signed contract to live AI on real tickets:

- Day 1: requirements scoping - use cases, success metrics, data sources, integration touchpoints.

- Days 2 to 4: AI training - the AI learns from the company’s tickets, help center content, web content, and internal docs.

- Days 4 to 14: shadow mode - the AI runs alongside agents without responding to customers while accuracy is tuned, confidence thresholds are calibrated, and escalation logic is tested against real ticket patterns.

- Day 15: go-live - the AI handles real tickets and performance tracking begins immediately.

Client requirements are minimal: access to historical ticket data, helpdesk credentials for the integration, and a knowledge base or documentation source. No engineering involvement is required for standard helpdesk integrations. Custom integrations with proprietary helpdesks or CRMs typically take 30 days.

#### Technology & differentiation

##### Your site mentions a USPTO-approved AI architecture. What does the patent cover, and why does it matter?

The patent covers the architecture that controls how AI responses are generated. In practice it enforces three things that separate it from generic LLM deployments:

- Knowledge grounding: the AI generates responses only from a defined, verified set of company data sources - tickets, help center articles, internal documentation, product data. It cannot draw on its general training data or fabricate information outside those boundaries.

- Controlled generation: output logic is deterministic within defined parameters. The system does not produce open-ended responses; it retrieves and synthesizes from approved sources.

- Confidence thresholds with mandatory escalation: when certainty falls below a defined threshold, the system escalates to a human agent with full context rather than producing a low-confidence answer. This is enforced at the architecture level, not through prompt engineering.

Why it matters: hallucination is the primary trust failure in AI support. A customer who gets a confident but incorrect answer about a refund policy, account status, or product spec loses trust faster than they would over a slow reply. The patent addresses that structurally, not through workarounds.

##### How is CoSupport AI different from solutions built on generic LLMs?

CoSupport AI uses a hybrid architecture that combines proprietary retrieval and generation controls with underlying large language models. The key distinction is in what the model is allowed to access and say. Generic LLM tools generate responses from broad training data; they may be accurate for general questions but frequently hallucinate on company-specific policies, pricing, product details, and account information. With CoSupport AI, responses are generated exclusively from the company’s own verified data. The LLM handles language understanding and generation; the patented retrieval and control layer determines what it can access and when it must stop.

The platform is not fine-tuned on a single model. It uses retrieval-augmented generation (RAG) with a proprietary control layer that enforces knowledge boundaries, which produces more consistent accuracy than fine-tuning generic models, particularly in compliance-sensitive environments.

##### What are the top USPs you would highlight to a prospect?

- Patented AI architecture: responses from verified data only, no hallucinations, every answer traceable to a source document.

- Performance guarantee: 60% AI resolution within 60 days or a full refund. No other platform in the category ties commercial terms to a measurable outcome benchmark.

- Unified platform: autonomous resolution, agent copilot, multilingual support, and conversation analytics in one place - no per-module billing, no extra vendors, no integration maintenance overhead.

- Fast deployment, no engineering required: standard helpdesk integrations go live in 15 days, with no code and no rip-and-replace of existing infrastructure.

- Outcome-linked pricing: three models all tied to actual AI activity rather than per-agent seats, with resolution-based pricing at $0.19 per resolved ticket.

##### How do you handle data security, privacy, and compliance?

- ISO 27001 certified

- GDPR and CCPA compliant

- Data anonymization and encryption - AES-256 at rest, TLS in transit

- Role-based access controls and audit logs on all interactions

- Dedicated server options for customers requiring full data isolation

- No data sharing with third parties, and no use of customer data for model training outside the client’s own environment

For regulated industries such as fintech, healthcare, and legal, dedicated infrastructure deployment is offered as a standard option, not an enterprise add-on.

#### Performance & results

##### What KPIs do customers typically see improve, and what is realistic in the first 3 to 6 months?

Based on documented customer deployments:

- AI resolution rate: 60 to 90% of repetitive ticket categories automated within 60 to 90 days. The guarantee threshold is 60%; top deployments reach 80 to 90%.

- First response time: from hours to seconds. Average AI response time is 1.5 seconds, and human-queue response times typically fall 40 to 70% as volume is redistributed.

- Cost per ticket: typically drops from $3 to $15 (human-handled, fully loaded) to $0.19 (AI-resolved). Monthly savings range from $5,000 to $515,000 depending on volume and operation size.

- CSAT: maintained or improved in well-configured deployments, with AI-resolved tickets averaging 4.1 to 4.6 out of 5 where measured. The risk to CSAT comes from poor escalation design, not from automation itself.

- Agent handle time: 40 to 60% reduction on tickets handled with AI Assistant in copilot mode.

##### Can you share a few detailed customer case studies?

SupportYourApp (BPO, USA). A US-based BPO with 1,500+ professionals serving SaaS, ecommerce, and fintech clients globally, founded in 2013. The challenge was managing 7,000+ monthly internal support chats and emails with a growing agent team. CoSupport AI built a custom integration with their in-house helpdesk in 30 days, starting with a pilot team of 22 agents (live since May 2022). By month two, 80% of internal requests were deflected automatically, saving $14,000 monthly, with 40+ languages supported in the same deployment.

‘After launching CoSupport AI, 80% of our incoming requests are handled automatically. We have saved thousands of dollars while keeping support quality high.’ - Axel Barrionuevo, Account Manager, SupportYourApp

ProjectFitter (AI-driven hiring platform). ProjectFitter first tried to build its own AI support model on OpenAI’s API, but integrating it with Freshdesk and Freshchat proved too resource-intensive, and training on historical tickets produced inconsistent responses from outdated information. CoSupport AI integrated with Freshdesk and Freshchat in 15 days. The result: roughly 70% of support tickets resolved autonomously, with the AI handling 75% of incoming chats and 76% of email inquiries, and resolution time cut from hours to minutes - a 93% decrease for chats and 77% for email (August to October 2024).

‘CoSupport AI streamlined our support operations with its advanced customer service AI tools, automating the resolution process for about 70% of support tickets and shortening the resolution time from hours to minutes.’ - Yaroslav Burgman, Project Manager, ProjectFitter

Softorino (software development). Softorino [evaluated six AI vendors](/ai-reviews/) but found that competing solutions frequently hallucinated, producing outputs they could not trust for support, marketing, or HR. They needed accuracy across three departments - Customer Support (Zendesk), Marketing, and HR. CoSupport AI integrated the AI Assistant with Zendesk and connected CoSupport BI to Slack for marketing and HR, completed in 1.5 months. The result: a 53% drop in full ticket resolution time, a 45% drop in first response time, a 30% increase in resolved tickets, and roughly $2,500 saved monthly.

‘Setup took one API key. In three months, resolution rates grew from 69 to 82 percent. We tested six other tools before. Nothing performed as well as CoSupport AI.’ - Bogdan Dzhel, CEO, Softorino

#### Market & competition

##### Who do you consider your main competitors, and where does CoSupport AI win or lose?

The landscape splits into three categories:

- Native helpdesk AI (Zendesk AI, Freshdesk Freddy AI): built into the helpdesk UI with no separate vendor contract for teams already on those platforms. In practice, though, Zendesk Advanced AI is an expensive add-on on top of an already costly subscription. CoSupport AI wins on accuracy - the patented architecture is specifically designed to prevent hallucinations, a documented weakness in generic add-ons - and for teams running multiple helpdesks or wanting to avoid dependence on one platform’s AI roadmap.

- Purpose-built AI support platforms (Ada, Forethought, Decagon, Sierra): these vary in architecture, pricing, and target segment, and several skew mid-market to enterprise with longer implementations and higher entry prices. CoSupport AI wins on pricing structure and a performance guarantee no competitor currently matches.

- General-purpose AI repurposed for support (ChatGPT integrations, custom LLM wrappers): low barrier to entry, but two compounding problems - the engineering effort to integrate and maintain them is substantial, and hallucination rates without a grounded architecture create real accuracy and compliance risk. CoSupport AI wins on accuracy, integration simplicity, and enterprise readiness.

##### What are the most common reasons prospects choose CoSupport AI over another vendor?

- The performance guarantee is unique: prospects burned by a previous AI deployment respond strongly to a vendor willing to put a refund on the table at 60 days.

- Deployment speed: 15 days to go-live is consistently faster than alternative enterprise platforms.

- Pricing model: resolution-based pricing at $0.19 per ticket is more economical than per-seat models for teams with high automation rates.

- Accuracy through grounded architecture: regulated industries and teams with previous hallucination incidents choose CoSupport AI specifically for patent-backed knowledge boundary enforcement.

- Unified platform: teams managing separate tools for translation, analytics, and automation consolidate and reduce overhead.

#### Pricing & commercials

##### Can you explain your pricing models, and which is the most popular?

CoSupport AI offers three pricing models, all tied to actual AI activity rather than agent seat count:

- Response-based: $0.04 per AI response. Best for variable ticket flow, with a predictable per-interaction cost whether or not the ticket is resolved.

- Resolution-based: $0.19 per resolved ticket. Best for teams that want pricing aligned with outcomes - the AI only charges when it successfully closes a ticket without human involvement.

- Server-based (fixed tier): from $99 per month for fixed tiers covering 1,000 to 30,000 tickets. Best for steady-volume operations that prefer predictable billing.

The resolution-based model is the most frequently chosen by new customers because it aligns vendor and customer incentives directly. There are no setup fees, the 30-day free pilot means the first month costs nothing regardless of the model chosen, and there is no long-term contract requirement on entry. Enterprise deployments with dedicated server infrastructure are priced separately based on volume and configuration, and custom pricing is available for BPO partnerships where CoSupport AI is resold as a premium service tier.

#### Support, roadmap & company direction

##### What does post-sale support look like?

- A dedicated implementation team for the first 30 days covering setup, training, data preparation, integration, shadow mode, and go-live.

- A customer success manager assigned to each account after go-live, responsible for performance review, optimization recommendations, and scope expansion.

- An SLA of 4 business hours for standard accounts and 1 business hour for enterprise, with a dedicated Slack channel for enterprise and BPO accounts.

- Training resources - documentation, onboarding guides, and knowledge base content at go-live, plus ongoing access to the support team for configuration questions.

##### What is on the product roadmap for the next 6 to 12 months?

While specific release timelines are not disclosed publicly, the directional priorities include:

- Proactive AI: moving from reactive resolution to proactive engagement - AI that identifies high-risk accounts from support signals and reaches out before a cancellation request arrives.

- Deeper AI BI integration: structured feedback loops from conversation analytics directly into product team workflows, with configurable alerts when signal thresholds are crossed.

- Expanded voice capabilities: building on current voice deployment for BPOs with more sophisticated intent classification and resolution.

- More helpdesk integrations: expanding the native integration library based on customer demand.

- Model accuracy improvements: continuous refinement of confidence calibration to reduce false escalations while maintaining zero-hallucination standards.

##### Any recent milestones to highlight, and what is the long-term vision?

Recent milestones include the USPTO patent granted for CoSupport AI’s core architecture, ISO 27001 certification enabling deployment in enterprise and regulated environments, live deployments across BPO, SaaS, ecommerce, fintech, and education verticals in multiple countries, recognition on G2, Capterra, and Crozdesk as a top performer in AI customer support, and AWS partner recognition.

As for the long term: CoSupport AI is building toward a world where support is not a cost center but an intelligence layer. The goal is not just to resolve tickets autonomously, but to make every customer interaction a source of structured business intelligence that feeds product, sales, and operations decisions in real time. The support conversation is one of the richest data sources a company has, and most organizations are not using it. CoSupport AI is building the infrastructure to change that.