Building a startup as an international student, while job hunting on OPT and coding past midnight, isn’t the origin story most founders tell…but it’s an honest one. This is Abhishek Goyal’s first-hand account of how Unibridge came to life – a platform designed to solve the chaotic first month that every international student navigates alone, just like he had.

From choosing Lovable and Supabase over learning React from scratch, to debugging row-level security at midnight, to saying no to the most-requested feature on the roadmap. This is what building a real product actually looks like from the inside.

I landed in Houston, Texas with two suitcases, a half-working international SIM, and fifteen browser tabs open simultaneously. One had a Reddit thread about which bank accounts wouldn’t require a US credit history. Another had a YouTube video about apartment hunting near campus. A third had a WhatsApp message from a senior student I’d never met, telling me to avoid a specific apartment complex without explaining why. Nobody had given me a map for any of this.

Universities are excellent at explaining course registration, orientation schedules, and immigration paperwork. What they don’t do is prepare you for the forty-eight hours after you land. The scramble to get a working phone plan, figure out furniture, open a bank account, find temporary housing, understand which grocery stores are within walking distance…the list goes on. Plus, you’re doing it while both jet-lagged and slightly terrified.

Of course, the information I needed existed. It was out there, somewhere – but therein lies the problem, ‘somewhere.’ Every answer was buried…somewhere. A Discord server, a comment thread, a conversation with a senior who had stumbled through it six months earlier. It’s information fragmentation, and was no good for what I needed at the time: quick, easy-to-find answers and advice.

The lightbulb moment: when I decided to create Unibridge

After my own first month, I kept watching the same questions cycle through incoming student groups every semester. The same questions, the same scramble, and the same – as I eventually knew – avoidable mistakes. At some point, the thought stopped being “someone should fix this”. I decided to work on the solution myself.

That solution became Unibridge – a one-stop digital platform for international students arriving at US universities, consolidating housing guidance, banking, SIM deals, transportation, marketplace resources, and onboarding information into one place.

The goal: save students the confusion and cost of their first month, exactly as I experienced. (In practice, users save $500–$700 in that window alone.)

That’s what Unibridge is in a nutshell – and now I’ll explain how I got there.

I’m not a web developer – so chose to vibe code

Here’s the part most startup articles written by developers skip: I’m not even a web developer. My background is data science – Python, SQL, machine learning pipelines, statistical modeling….

I’m comfortable in that world. But building a production-ready web platform with roughly thirty pages, user authentication, a live database, and a halfway-decent UI is a completely different discipline. I could have spent four months learning React before writing a single line of product code. I could have also hired a freelancer.

But I was also an international student simultaneously job hunting on OPT (Optional Practical Training), so neither option was realistic.

Here’s what I did instead

In short, I used Lovable for the frontend and Supabase for the backend. It’s worth me being specific about how that split actually worked in practice, though, since the two tools solve completely different problems. Confusing that boundary early on would be costly.

So, in more detail:

Lovable generates React code from natural language – you describe a page or component, it writes the frontend. Supabase is an open-source backend on PostgreSQL that handles your database, auth, row-level security, and real-time subscriptions.

The appeal for someone with no DevOps background is simple: I didn’t have to build or manage any of that infrastructure myself.

The architecture split was clean by necessity. Twenty-eight of Unibridge’s roughly thirty pages – featuring housing guides, SIM card comparisons, etc – are entirely static. These are content pages that Lovable generates. They never even touch the database.

The remaining two pages (Find a Roommate and the Marketplace) are fully dynamic. Users must sign up to post listings, and live results are pulled directly from Supabase in real time. Those two pages required an entirely different level of architectural thinking than anything else on the platform.

The truth behind vibe coding

Here’s what nobody tells you about vibe coding: it doesn’t remove complexity, it just moves it. You stop debugging syntax and start debugging intent, such as, why did this generate something that technically runs but makes no logical sense for what I actually needed?

One early failure involved the navigation structure for the onboarding section. I wanted a sidebar that persisted across all category pages (Housing, Banking, SIM Cards, Transportation), with the active category highlighted, and a progress indicator showing how far through the content the student was.

My initial prompt was something like: “build a multi-section onboarding flow with a persistent sidebar and progress tracking.” Lovable generated something that looked right in a screenshot – clean layout, visible categories, progress bar at the top, etc. However, the moment I clicked between sections, there was a problem. The sidebar re-rendered from scratch on every page transition, resetting the progress indicator to zero each time. Each page was ‘stateless’, so it had no knowledge of what came before it.

The fix was changing what I was actually asking for. Instead of describing the UI, I described the state:

“Store the active section and progress count in a shared context that wraps all onboarding pages — don’t reinitialize it on each route change.”

That one prompt change fixed it. Lovable is genuinely good at generating UI, but it won’t guess your state management requirements. As with all good prompting, you have to spell them out. Be as specific as possible.

The challenges of Supabase – and how I tackled them

Supabase has good documentation and the free tier is genuinely useful. Unfortunately, though, it also has row-level security. If you don’t know what that is before you start building, you’ll lose days to it.

RLS controls which rows a given user can read or write. Enable it on a table without writing explicit policies and all access is blocked (by design). That’s correct for production, but easy to miss when you’re moving fast. I spent a full evening convinced my Marketplace query was broken. The frontend showed empty results, no error. The query was fine. The data was in the database.

As I later discovered, what I’d done was enable RLS on the listings table without a policy allowing anonymous reads. So, every unauthenticated query silently returned nothing.

The fix that saved the day

The fix was a single SQL policy: allow read access to all rows for the anon role. It was just two lines, but it took an entire evening to diagnose and resolve. All because the failure mode (empty results rather than an error) looks identical to a legitimate “no listings found” state from the frontend.

Indexing also caught me out. Where the listings table for the roommate feature grew – filtering by university, move-in date, and budget range at the same time – those queries got slow. After full table scans on every filter combination, a composite index on those three columns fixed it.

Any data scientist who’s worked with large datasets knows this instinctively, but it’s easy to forget that Supabase won’t automatically create multi-column indexes for your specific query patterns. You have to look at what you’re actually querying and build for it.

These were just database problems, though, rather than Lovable problems specifically. They required me to stop prompting and actually think through the data layer.

That pretty much sums up vibe coding: it handles a lot of the surface work well but, underneath, the engineering decisions are still yours to make. For data scientists specifically, the skills transfer more than you’d expect.

The feedback problem – what if people didn’t actually need what I was building?

The hardest part of building Unibridge had nothing to do with code. It was more about determining if I was building something people actually wanted and/or needed. To establish that, I’d need to show people – and therein lies the problem.

Show something too early in development and people fixate on the broken layout instead of the idea. Wait too long, on the other hand, and you’ve spent weeks building something that, in reality, you’re not certain there’s actually demand for. I sat in the middle of the two for longer than I should have.

Take financial content, for example. I’d simply underestimated how central money was to everything. Students weren’t primarily looking for general orientation information. They wanted specific answers tied directly to saving money and avoiding expensive mistakes. Which banks don’t charge conversion fees? Which SIM plan is actually worth it for a student? What about apartments – which ones require a US guarantor (and which ones don’t)?

Just having this (new to me) information, shifted an entire section of the product.

The power of asking the right questions

Further, the feedback quality improved the moment I stopped asking broad, vague questions. “What do you think of the platform?” produces the exact answers you’d expect. Polite? Yes. Useful? No.

On the contrary, something along the lines of, “Would this page have helped you in your first week?”, gets you something useful. Better still, asking “At what point would you stop reading this and go somewhere else?” leads to something actionable.

I also learned that incomplete products are actually fine to share, as long as you frame them correctly. Saying “I’m testing whether this section is useful — ignore the broken layout” changes the entire nature of the conversation. Just be honest, and people will engage with the idea more.

Without feedback, you’re building in the dark – betting your time on assumptions that feel obvious to you precisely because you’re too close to the problem.

The realization of it no longer being just a ‘side project’

For most of the build, Unibridge existed primarily inside my laptop. I was testing flows, refining pages, fixing layouts at odd hours, and quietly convincing myself it was coming together. In all honesty, though, it still felt experimental. It felt like something I was simply running for the sake of running, rather than something other people would depend on. That all changed when I started utilizing Google Ads, targeted towards incoming international students.

That led to a message – and just that, alone, was a real point of validation for me. A student from a different university reached out to say they wished something like this had existed when they arrived, because they’d gone through the exact same confusion I had. A few days later, another student from another university sent a near-identical message.

Those messages mattered in a way metrics don’t. A stranger taking time to write and say your product should exist at their university tells you more than just clicks or impressions. It really showed me that the problem isn’t specific to one campus, or one person’s particular bad luck. It’s far broader than that.

More ‘real’ users came in quickly after the ads and, again, unlike metrics, real people offer real, valuable feedback. They’ll ask questions, report anything broken, and tell you what’s missing.

That feedback loop – direct, specific, and sometimes blunt – is worth more than any amount of analytics. And it’s what shifted my mindset about the entire project, from side-hustle to something worth committing more time to.

How I kept the lights on without a paywall

One decision I made early and never reconsidered: Unibridge would stay completely open.

As a student desperate for quick answers like I was, scrambling around at midnight, the last thing I’d want to see is a registration screen. That meant no signup wall, locked-away content, or ‘freemium tier’. It had to be easily accessible.

Of course, any platform still needs to cover its costs, and that’s no different here. I just chose the least user-obtrusive path possible. The model I landed on was referral partnerships – direct affiliate links for the exact services the platform already recommends. The likes of housing listings, credit cards, SIM plans, utilities, etc. Every category on Unibridge is something an incoming student has to sort out regardless, so I’m not pushing products they don’t need.

I am, however, getting compensated for the trust my platform built with them, by helping them find products they were already going to sign up for.

What’s working – and what isn’t?

In Unibridge’s case, housing and credit cards turned out to be the strongest performers. Housing makes sense – it’s the highest-stakes decision a new student makes before they arrive, and a referral that saves them two weeks of searching is an easy conversion.

Credit cards surprised me at first, but a little less once I thought about it. After all, international students with no US credit history have very few options, and knowing which cards actually approve them is genuinely useful information. Those two categories now cover hosting costs and a portion of the ad spend on Unibridge, with a couple of referral conversions a week. It’s not a business – yet(!) – but is self-sustaining enough to keep the platform running…and, most importantly, free.

One thing I’m not doing is using any affiliate networks. Every partnership is a direct link through the company’s own referral program. That means less infrastructure to manage and a more transparent relationship – the link goes where it says it goes. I’m not routing anyone through a third-party tracker they didn’t consent to.

The broader point for anyone building something similar: a paywall is not the only way to make a free product sustainable. If your platform genuinely helps people make decisions, there are usually products adjacent to those decisions that will pay for the referral.

The key is that the recommendation has to be honest first. The moment you start recommending something because the commission is good rather than because it’s actually the right option for your user, you’ve broken the only thing that made the referral worth anything in the first place.

The one feature I haven’t built (and why)

The most-requested feature for Unibridge is simply a way for users to connect directly with one another (students, alumni) before their arrival. It’s also the one I’ve decided not to build – at least not yet.

Obviously, the concept makes sense. Incoming students want real, verified guidance from people who’ve recently navigated through the same process. And they want an actual connection with a real person – not just a blog post or FAQs page.

It’s straightforward in theory but, in practice, not so much. For a start, it’s 2026, and there are so many security and privacy measures in place (for good reason).

Real-time communication between users requires identity verification, moderation infrastructure, abuse prevention, privacy controls, reporting workflows, and notification systems. The moment you allow direct messaging between strangers, you inherit responsibility for everything that can go wrong inside it. I’m talking spam, misinformation, harassment, safety – the list goes on. You just can’t de-prioritize these nowadays; they’re the core operational reality of running a communication platform.

I could have attempted it, sure, but I didn’t have the bandwidth to do it responsibly. One poorly-moderated communication feature would have done more damage to trust in the platform than not having the feature at all.

That decision was genuinely difficult. Founders become emotionally attached to feature requests because every request feels like an opportunity. Saying ‘no’ to something people are explicitly asking for requires a kind of discipline that doesn’t come naturally early on.

Deciding what not to build is just as important as deciding what to build. In fact, it’s usually harder.

The alumni connection system is still on the roadmap. I don’t consider delaying it a failure. It was the right call, and recognizing that distinction early probably saved the platform from collapsing under complexity it couldn’t support.

Building at 11pm…(the dual life nobody talks about)

Most startup stories leave out the part where the founder is also applying to jobs, studying for interviews, and checking their visa status every other week. I built most of Unibridge between 10pm and 1am.

During the same months I was refining onboarding flows and debugging Supabase configurations, I was also tailoring resumes for specific roles, preparing for technical interviews, tracking application deadlines, and managing OPT timelines.

For international students, OPT is far more than just administrative paperwork. It’s the direct link between your visa status and your professional future. There’s a constant background awareness of that clock – and it doesn’t stop because you’re trying to build something!

Oddly, though, these constraints helped. I actually found benefits in working for two hours a night. First, it kills a lot of bad habits: no more debating button colors, or focusing on features nobody’s asked for. You just decide and move, because there’s no time for anything else. Honestly, some of my clearest calls came from not having the luxury of overthinking them.

If you’re a student reading this with an idea and a full course load: you are not at a disadvantage. As I discovered, you’re operating in the exact conditions that force good prioritization.

Looking back: what I’d tell myself on day one

Ship something ugly in week four, not something polished in month six.
Most of my fears about imperfection disappeared the moment real users start using the product. The version you’re embarrassed to show is almost always more useful than no version at all.

Your first ten users matter more than your first thousand page views.
Analytics can create the illusion of progress, but what you need is real feedback. A direct conversation with someone using your product reveals what you actually need to know.

The hardest part of vibe coding is not the tool.
As with all AI tool usage, the trick is in good prompting. Learning to communicate precisely enough that the tool produces what you actually mean. Ambiguous thinking creates ambiguous software. The same principle applies whether you’re prompting an LLM or briefing a developer.

Cutting features is not weakness.
The alumni connection feature was the most requested thing I didn’t build – and is a decision that protected the platform. A focused product that works reliably beats an ambitious one that doesn’t.

Don’t wait to ‘feel’ ready.
The most important things I learned about building a product only became visible after I actually started. You can’t just ‘think’ your way to them from the outside.

Conclusion: it’s still early

Unibridge is live today. Students are using it. The platform is still evolving almost every week — new content, refinements, features that users asked for and I actually had the bandwidth to build. The alumni connection system is still on the roadmap.

My own situation is still unfolding, too. My job search is ongoing, and learning is continuous. A lot of startup stories get written after everything already worked out, but this one’s being written from the middle of it. To me, it certainly feels more honest, and probably more useful, too.

The problem Unibridge solves is real. I know that because I lived through it, and because strangers from universities I’ve never visited told me so unprompted. That’s enough to keep me going!