I didn’t set out to build a mobile app. I was heading to a networking event at UCLA (my alma mater), and I already knew how the conversation would go. Someone asks what I do. I say I’m an engineer. If they’re actually interested, the follow-up is always the same:

“Oh, what do you build?”

And then I’m scrambling 😬

I’ll send a portfolio link. Or a link to one specific product. Maybe my blog, which has a lot of my projects on it, but that’s overwhelming in a way that guarantees it’ll get bookmarked-never-opened.

None of it is comprehensive. None of it lives in one place. Most importantly, none of it feels like me in this room, right now.

So I spun up something. Quick. Just for the event.

That scratch solution turned into VersoID—a digital identity app now live on the App Store with real users, a Pro subscription, and a feature list I didn’t have on my bingo card when I started.

If you’re a solo dev, indie hacker, Flutter-curious builder, or a non-technical creator who’s tired of paper cards, you’re in the right place. I’ll walk you through why I built it, how it differs from Linktree, and how an event hack turned into a shipped cross-platform product.

Hey! There’s no code walkthrough, but plenty on product engineering like how to land on an idea, plan it, scaffold it, build it, and actually deploy it.

What I Was Actually Trying to Solve at UCLA

The thing about networking as a builder is that people don’t want your entire backlog. They want a clean answer to who you are in this context.

At that UCLA event, I wasn’t trying to launch a startup. I was trying to hand someone a coherent version of myself—engineer, builder, person worth staying in touch with—without reading my entire resume out loud. (Don’t even get me started on the resume; it barely covers a quarter of all I do 🙄)

What most people do: Send a portfolio URL, a blog link, or a Linktree page with twelve links and no clear priority.

The better way (for in-person networking): One digital business card tuned to the moment. A QR code they can scan. Links that matter for this conversation. A path to save you as a contact before the snack table conversation evaporates.

That’s the problem VersoID is built around. It’s not a mini storefront. It’s not a creator merch funnel. But it is a persona you can share in two seconds, at a meetup, conference, or coffee chat, with the links that fit that version of you.

Maybe that’s your day-job engineering identity. Maybe it’s a side hobby or a small business you’re testing on weekends. The point isn’t what you’re selling. It’s that you’re not handing over a paper card that ends up in a trash can outside the venue 🗑️

If you’re a hiring manager or recruiter reading this: that framing is intentional. Personas aren’t cosmetic labels—they’re first-class objects in the product. That decision shapes the database, the UI, and how offline sharing works.

Why Linktree Wasn’t the Answer (What I Tried First)

Link-in-bio tools exist. I’ve used them. I’ve seen them everywhere.

Linktree is good at what it does, especially if you’re a creator routing people to a shop, a Substack, a Tip jar, or a promo link. The platform has drifted toward that lane, and that’s fine. It’s just not the lane I was standing in at UCLA.

I needed a digital business card, not a link menu optimized for conversion funnels.

VersoID asks a different question. Linktree asks: what do you want people to click? VersoID asks: which version of you are you being right now?

You keep work, side projects, and social life in a persona stack—an ordered set of identity cards, each with its own bio, links, styling, and QR code. You share the one that fits the room.

Free users get three active public slots; Pro unlocks the full stack plus analytics, alerts, and export, with a 14-day trial and no credit card required. (I’m saving the subscription plumbing horror stories for a follow-up post; the free tier and trial logic were… a journey 🙈)

Related: This Is The Free Browser Extension Your Job Search Needs — another project that started from a specific personal frustration, not a product brief.

Concrete differences you’ll feel in the app:

• Persona stack, not one page — switch and share the right identity
• QR-first, offline-capable — sync once, share at events even when Wi-Fi is trash
• Home screen widget and app shortcuts — your active QR without opening the app
• Insights — real-time scan and link-click visibility, weekly recaps in your timezone (Pro)
• Contact-save flow — they walk away with you, not seventeen links in a grid

I’m not claiming Linktree is bad. I’m saying it’s adjacent. VersoID is for the engineer who doesn’t want to explain their entire blog archive when someone asks one polite question.

How VersoID Got Its Name (and What “One Profile, Infinite Personas” Means)

The name wasn’t random SEO bait. I needed something unique, but I also wanted it to mean something.

Verso comes from Latin. It’s the other side, the flip side, another version—that’s the product idea in one word. You are not one link list. You are multiple faces: professional, creator, personal, experimental. VersoID is the stack that holds them.

One profile. Infinite personas.

Each persona gets its own card. You reorder what’s “live” in your public stack. You share the one that fits. If you’re non-technical and you’ve made it this far: think of it like having multiple business cards in your pocket, except only one is face-up at a time, and you never run out of ink.

Tip 🔥
When you’re naming a product, pick something you can explain in one sentence at a networking event. If the name needs a paragraph, you’ll lose people before the QR scan.

Breaking Down the Challenge: From Event Hack to Real Product

Once the UCLA event worked, meaning that I could share something cohesive, I had a choice. Shelve it, or see how far it could go.

I started with a question: Can I turn this into something I’d actually use every week?

That implied requirements I didn’t write down at first but felt immediately:

• Multiple personas, not one profile
• QR sharing that works even when you’re thousands of miles up in the sky
• Auth that doesn’t feel sketchy (Google and Apple sign-in)
• A mobile app, because the whole point is in your pocket at the event
• A landing page that explains the thing to people who aren’t in the room with me

I compiled an initial MVP plan with Claude and ChatGPT before touching production code: core flows, what “good enough” looked like, what could wait. That doc became the foundation, even when I later violated my own advice by scoping features mid-build 😬

Note: If you’re solo, an MVP doc isn’t overkill. It’s the thing you read when you’re tempted to add “just one more feature” at 11 PM on a Tuesday.

The Journey: How It Actually Got Built

This is the part that matters if you’re evaluating how someone thinks, not just what they shipped.

Initial Understanding: I Just Need a Card for Thursday

Phase zero was selfish in the best way. I was solving for myself first as a builder who needed one shareable identity for one room.

I wasn’t thinking App Store. I wasn’t thinking subscriptions. I wasn’t thinking Flutter because, quite honestly, I’d never written a line of Dart in my life.

The first win was simple: when someone asks what I build, I have one link/QR that doesn’t embarrass me.

The Plot Twist: Scope Creep With a Purpose

Every time I used the prototype, I found another gap. Stack ordering mattered. Notifications when someone scanned my QR mattered. Looking premium mattered since the whole point is first impressions in person.

So “event card” became “digital identity app.” That sounds dramatic until you’ve solo-built one and watched users treat your side project like a real product. They do. And then you’re on the hook.

I settled the visual direction in Google AI Studio before committing to a mobile stack as a quick way to mock up the glassmorphic dark UI (frosted-glass panels over a dark background) and see if the vibe felt right. Once the aesthetic locked, I had a concrete target for production Flutter work instead of re-skinning three times later.

Building in Dart When My Comfort Zone Is React

I’d been circling Flutter (Google’s cross-platform mobile framework with a single codebase for iOS and Android) and React Native. VersoID steered me toward Flutter because I wanted to use both platforms from a single codebase without maintaining two native apps as a solo dev.

There’s a second layer I didn’t fully admit at first: I wanted to ship my first mobile app, and I wanted to test whether structured AI workflow files could carry a project in a stack I didn’t have muscle memory for.

I know React well. I had never shipped Flutter or Dart. Could disciplined process replace years of framework familiarity? 🤨

Mostly yes. With caveats I’ll get to.

Explore: All You Need To Know About AI Workflow Files And How To Use Them

From early build through release, nearly everything from scaffolding and feature planning to execution happened in Google’s Antigravity IDE (an AI-assisted development environment). The loop:

1. Feature idea surfaces (often from using the app myself)
2. Research and plan generated
3. Execute against structured workflow files
4. Pull back, test, repeat

That push-and-pull is how “networking card” grew into home screen widgets, scan analytics, identity stack reordering, timezone-aware weekly recaps, and offline-friendly cached personas. Looking back at the build:

• infrastructure and auth came first
• then a long UI push
• followed by release hardening

Solo. Continuous. Not a hackathon weekend but a sustained build around a day job and life.

If you’re a Flutter dev reading this, I’m not claiming expert-level Dart idioms. I’m claiming you can ship without them if your planning loop is intentional.

Related: The Ultimate Guide To Re-Engineering My Portfolio’s RAG Chatbot — another build where process and tooling choices mattered as much as the feature list.

Picking Supabase, Stripe, Firebase, and Apple IAP (and Why That’s Boring on Purpose)

Okay, none of this stack is exotic, and that’s the point. I picked Supabase (hosted Postgres database plus auth, storage, and real-time APIs) because I’d used it on other projects. It’s familiar, fast to stand up, generous free tier while I still wasn’t sure this would become a real product.

Stripe was the natural fit for Android and web subscription flows when I got there.

Apple In-App Purchase (IAP) is Apple’s required payment system for digital subscriptions inside iOS apps. In case it’s not clear, it wasn’t a preference. It’s a requirement if you list on the App Store, so you don’t really get to philosophize about it.

Firebase covered push notifications, and Google sign-in alongside Apple auth, again on a free tier that mattered while I was bootstrapping uncertainty.

Tip 👇
If you’re evaluating stacks as a solo builder, optimize for what you’ve shipped before, plus what the app stores force you to do. Familiarity beats novelty on week six when you’re tired.

The technical build was, honestly, the easiest part of the whole endeavor. I’m not saying mobile is easy; I’m saying the product problems (who is this for, what’s free vs paid, what happens offline) generated more rework than the widgets did.

Why the Landing Page Lives in React (Not Flutter Web)

I wasn’t interested in Flutter Web for marketing. I wanted the landing site to be fast, SEO-friendly, and easy to iterate, so I built it in React + Vite, same visual language as the app (glass cards, dark theme, motion), hosted at thehelpfultipper.com/versoid/.

Mobile app in Flutter. Marketing surface in React. Backend in Supabase. Notifications and Google auth via Firebase. Payments split by platform rules.

Boring on purpose.

Related: A Smart Free Chrome Extension That Upgrades AI Prompts — if you like reading about tools built from a specific personal itch.

What Product Engineering Looked Like Solo (The Shape of the Work)

Since this isn’t a tutorial, I’ll describe the shape—the overview I’d want if I were evaluating how someone approaches product engineering.

The MVP doc defined personas, sharing, auth, and link management before I locked the stack, and that planning pass paid off.

What didn’t pay off was planning features only when they surfaced mid-build. I improved, researched, and scoped on the fly for stack ordering, notification routing, and subscription edge cases, and that created rework.

If I started over today, I’d spend another week fleshing out the full feature map and acceptance criteria before implementation.

Explore: You Need To Work Smarter, Not Harder, With AI

AI Studio wasn’t procrastination. It prevented re-skinning the app three times in Flutter, saving my free quota (did I mention the majority of the app was done on a free account?), and provided the aesthetic constraint that made later decisions easier.

Antigravity plus structured workflows let me execute in Dart without being a Dart expert on day one. Each day was: feature → research → plan → execute.

That’s how a React dev shipped a Flutter app 🥲

I shipped iOS first and listened to real users. Android is in progress now. iOS is live with people actually using it, and it’s validating and terrifying in equal measure. I’m integrating requests now, which means I ideate, build, test, verify, and respond alone. That phase shifts the question from can I build it? to did I build the right thing?

Note 👀
I’m deliberately not unpacking App Store listing specs, Play Store tester requirements, or free-tier implementation here. Those deserve their own post since several were harder than the UI, and I didn’t research listing requirements early enough. Assumptions came back to bite me.

A follow-up post is in progress on App Store/Play Store surprises and subscription plumbing. Subscribe if you want it when it drops!

What I’d Plan Differently If I Started Over Today

If you’re here for the product engineering angle more so than the Flutter angle, the lesson I’d steal is simple: the plans matter more than I gave them credit for.

I wish I’d broken every feature into explicit phases before coding (not just MVP vs “later”). I wish I’d researched where I’d list the app—Apple vs Google requirements, IAP vs Stripe, tester groups—and folded that into the initial plan. And I wish I’d mapped auth providers and subscription rules upfront instead of discovering platform constraints mid-sprint.

The building was fun. The re-planning when assumptions broke was not.

That doesn’t mean over-plan forever. It means plan the unglamorous parts, like payments, store policies, free vs paid boundaries, with the same energy you plan the hero screen.

For my non-technical creators, you don’t need to understand IAP on day one. You do need to know that “free trial” is a product decision with backend teeth, not a toggle in a settings panel.

Where VersoID Stands Right Now

VersoID is live on iOS, and you can download it here. Android is in progress; the landing page says that honestly because I’d rather under-promise than run a ghost launch.

The latest release added the home screen widget, app icon shortcuts, 7- and 30-day analytic views, timezone-aware weekly recaps, and offline-friendly cached personas. Basically, the stuff I kept wishing for while beta-testing the original UCLA build.

Real users. Real feedback. And real feature requests landing on my solo queue 🥲

If you’re anyone tired of paper cards and bloated link pages, this is the thing I built because I needed it at UCLA and couldn’t find something that fit.

Try it. Break it. Tell me what’s missing.

It’s a Wrap

VersoID started as me not wanting to fumble through portfolio URLs while someone politely waited for an answer.

That personal itch—one shareable identity for this room—turned into a persona stack I actually use, a mobile app on the App Store, and a subscription model I’m still tuning.

If there’s one thing solo-building VersoID taught me, it’s that the code was never the hard part.

The hard part was everything around it, things like who this is for, what’s free, what happens when the Wi-Fi dies. These are the decisions no framework makes for you.

VersoID isn’t Linktree. It’s the digital business card I wanted in my pocket when someone asked, “What do you build?”

Your move: grab VersoID on the App Store (it’s free), spin up a persona, and see if it fits your next networking event better than a link dump.

Happen to be building something similar solo? Drop a comment with what you’re stuck on—I read them.

I’ll see ya on the next one 😉