Before we were Loomify, we were Patch, a team of four with varying backgrounds who entered the ASEAN-China-India Youth Leadership Summit 2023 with a gamified circular fashion app. That idea took us to Singapore, then after that competition we went through several pivots (game → marketplace → social seller tool) before we finally shut down the idea in September 2025.

Looking back, I'm proud of what we accomplished as a competition team. I say "competition team" deliberately because that's what we were, not a real startup. We spent our time pitching instead of testing our assumptions with actual users. Still, we learned to talk to people, build MVPs, and hire remotely. We competed and even won awards at Hult Boston 2024 and Startup QC, became a Shell Livewire top 10 finalist, and we were even considered for AIM's TBI cohort (but failed to get in). We're currently incubated at Benilde HiFi, but with a completely new product (I'll talk about it soon enough).

This post documents why we stopped building Loomify. My previous build logs glossed over the technical challenges, so I want to address those honestly.

Reflecting on the different points of failure

There's value in documenting startup failures, especially from student founders. Survivor bias means we mostly hear about funded startups that succeed, while student-led ventures rarely persist long enough to validate real market demand. Here's what we could've done better.

Falling in love with the solution than the problem

If I can summarize our mistakes as a startup in one line, it's this. It's so easy to say but difficult in practice. We have spent our nights and weekends brainstorming features, imagining our customers loving the app we would build, and validating our own biases with comprehensive market research. Winning competitions made this worse because judges validated our idea, but they weren't our customers. We were getting feedback from the wrong people.

Tech dependancy on Meta's APIs

As Loomify's main developer, I had to authenticate with Facebook and Instagram accounts to view comments and posts through our app. We started with a simple bidding tracker because Instagram sellers often close sales using keywords like "Mine," "Grab," and "Steal."

While I could vibe-code the UI, the backend was brutal. Meta's API required rigorous debugging. I had back-and-forth conversations from 3 different IDEs and LLMs to troubleshoot errors and work around deprecated methods. There was progress but it was slow.

Then, during a late-night call with one of my teammates, we took a tour in Meta's Business Suite. They were already building what we were building. Not exactly the same, but close enough. This was our failure of due diligence. Quite frankly, I don't believe any problem lacks a competitor. Even the most novel ideas always have a manual, often free, alternative. I guess this is what happens when you're not a business owner using Meta to manage your business. We actually got a sense of this tool because one of us was actually using the platform this year because she was managing her mom's bakery.

Some version of Loomify might still be worth building, but from that moment it felt like an uphill battle. What would stop Meta from replicating our exact features and flow? We took this discovery as a signal to stop and reflect what we're doing.

What now?

We've actually pivoted again! While it's not circular fashion anymore, we're building a service booking platform. We approached this product differently and started with asking what problem do we want to solve. I think we're doing better now and we're building faster because I crash-coursed my founders into becoming vibe coders. While it's an unpopular way of coding, I think this allowed my co-founders to have more agency in building the product rather than wait for me to build it like with Loomify.

If you want to check it out, do visit https://kaya.loomify.app! If you got any comments or feature requests, feel free to contact me.