I Solved the Wrong Problem First: What Auxiliare Taught Me

The first time I presented Auxiliare, a panel told me it didn't work. The last time, it won Best Capstone Project in our department.

I graduated with my bachelor's four months ago, and I've felt a pull to write down what happened in between. Writing is how I make sure I remember it honestly, including the parts that don't flatter me.

Some terms first, in case they're new. A startup is a young company trying to grow something new. Its founders are the people who started it. Investors put money into startups in exchange for a share of what the company may become.

Auxiliare comes from the Latin auxiliari, "to help." The idea is to help Filipino startup founders and investors find each other. Founders with a good business can't find investors, and investors can't find credible founders. Both sides end up relying on whoever they happen to know.

I loved this idea before it was ever a capstone. It began in an earlier course, the year before. In that first version, an investor could send money to a founder inside the platform. In my head it was clean: founder, investor, funding. I kept telling myself this could be the next big thing.

It was too good to be true, and I didn't see it.

At the pre-capstone review, the panel was disappointed. They hadn't expected the output to look the way it did. It was too complicated, with too much redundancy. They asked how we would verify the identity of a founder or an investor, and we had no answer. They noticed we had no statistical data on founders and investors, so the idea had no backbone.

Then they told me the part that mattered most. Moving money was not the problem. Payments already exist in the market, so there was no niche there. I had spent my effort on a problem that was already solved, and the real gap sat somewhere else. (The way I'd designed it also couldn't have been built without payment integrations and legal approvals we didn't have, but that was secondary.)

They were right. And the deeper mistake was mine: I was so focused on building that I never stepped back to audit it. I never asked my advisor whether the flow made sense. I never asked a real founder or a real investor whether this is how they would actually meet. I had an abstraction, and I mistook it for reality.

An abstraction can be inspiring. You can picture the product reaching the people it's meant for. But if the analysis behind it is thin, the picture is just a picture. That was my first lesson. The tool for learning it has a name in startup language: the MVP, the minimum viable product. Build the smallest thing that delivers real value, and find out early whether it does.

I survived that review, and the lesson speaks for itself.

I never thought I would get to continue it. But the panel's criticism did something to me: it made me want to keep going. The goal was still worth pursuing. The mechanism was wrong.

So before the capstone proposal defense, which came the following semester, my team and I went back to the architecture. We narrowed the scope as far as we could, fixed the flow, and asked a different question: not "is this exciting?" but "can this actually be made real?" And we kept the long term in mind, so the system could grow later.

I was no longer asking how an investor could send money. I was asking how an investor could even find a founder worth backing. The real problem was visibility: a good startup that no investor ever sees. But visibility alone isn't enough. A startup needs to reach an investor whose interests fit, and both sides need enough information to decide whether to keep talking. Fragmented networks, trouble finding the right counterpart, and thin information between the two sides were the problem I was actually trying to solve.

Narrowing the scope also meant saying out loud what the first version would not do. It would not process financial transactions. It would not do due diligence for investors. It would not use sophisticated AI personalization or advanced fraud detection, and it would not try to make money. AI matching, a native mobile app, and stronger fraud detection stayed on the list for later. A first version that tries to do everything is how I got my first review.

Each team could propose up to three topics. There were three of us, and we put Auxiliare first, because it was the only one we were confident in. The second and third were what we call "saling pusa" in Tagalog: ideas we filled in just to have something. If Auxiliare failed, we had nothing behind it.

We presented it well, and the panel accepted it, so we never had to present the other two.

This time they were happy with it. They saw a real purpose and value in it, something that could help people beyond the university. The problem underneath was real: in the Philippines, founders and investors are badly disconnected. They told us it was the first time they had seen a proposal like this. Startups are still new here and growing, and I think that unfamiliarity was part of what caught their interest. They also saw something that could attract investors, not only at the university level but professionally.

We celebrated. It was our first big win. And then we sat down to figure out what we had just promised.

The new version has the same goal and a completely different mechanism. The platform doesn't process any money. It's a networking and discovery platform. Founders record a short video pitch and say what they're looking for. Investors scroll through those pitches vertically, like on TikTok.

The scrolling is the easy part to explain. The matching is what makes it useful. It's preference-based: the platform uses things like industry, startup stage and location to decide what an investor sees. An investor interested in education, for example, sees education-related pitches earlier in the feed. It is basic matching, not a prediction of which startups will succeed, and it doesn't tell an investor a startup is a good bet.

A short video can't carry an investment decision. So founders can attach supporting documents, like a pitch deck, financial information, and cost projections, and investors can review them alongside the video. The video gets attention, and the documents give a reason to keep talking. When both sides fit, they connect and message each other inside the platform. The investor remains responsible for their own due diligence.

Then there was the question we couldn't answer the first time. To use the core features, a user submits a government-issued ID and a selfie. An administrator reviews the submission manually and can approve it, reject it, or ask for a new one. Until it's approved, the core features stay locked. Investors can also report content, and administrators can act on those reports.

That has a clear limit. It tells us who someone says they are. It doesn't tell us whether their business is good, whether an investor has the money, or whether every claim in a pitch is true.

The first time, I never asked anyone. This time we did, and we sat down with two people to talk through the project.

One focused on trust, transparency, getting people to actually use the platform, ease of use, and making the platform's purpose understandable. The other talked about onboarding, managing pitches, profiles and portfolios, UI and UX, and security. Across both conversations, the advice kept returning to one point: begin with a clear, less complex system.

That was the opposite of what I'd done in the first version. I'd like to say a single sentence from either of them changed everything, but I can't say that honestly. What I can say is that I was now putting the work in front of people who could tell me where it was weak, before a panel had to.

As the Research and Development lead, my job was partly technical and partly about the team. I kept reminding us about psychological safety, so that a half-formed idea could be said out loud without bias. Fragile ideas need that.

The technical side was harder. I was the only one on the team who knew Laravel, since I built the first version in it. Anthon and Zeus were new to it. So we held sessions where I taught the basics, and I taught them Git and GitHub. Anthon built the feed. Zeus built pitch creation. Splitting the work that way kept us out of merge conflicts, and when conflicts did happen, they learned to fix them themselves. They now use Git on their own projects. I'm glad I got to be part of that.

Managing people was one of the hardest parts of leading. Deadlines slipped when blockers hit, and some blockers couldn't be avoided. Sometimes two people's tasks collided, in the code and in the documentation. Then we had to choose one version, or build a hybrid of both.

I was also still learning. I was learning the stack while building on a deadline. The matching, the vertical feed, and everything between them were things we hadn't built before. The hardest part wasn't any single feature. Each piece worked alone. Joining them all at once was where it kept falling apart.

Some days, fixing one thing or optimizing it took 12 to 15 hours. Not 8 to 5. I cared more about quality than speed, because I knew that if we weren't consistent, the project would quietly disappear.

The first version never met a real founder or a real investor. This one did.

Five Filipino founders and five Filipino investors used the platform on their own, without us guiding them, and filled in a questionnaire for their role. It covered four things: how understandable the platform was, how easy to learn, how easy to operate, and how attractive it was.

We chose five of each following the Nielsen Norman Group's guidance on usability testing. That guidance is about finding usability problems with small groups. It doesn't make ratings from ten people statistically representative, and I don't treat them that way.

Participants rated the platform 3.76 out of 4 for founders and 3.55 out of 4 for investors. Both fall in the range our paper labels "Strongly Agree." I read that as positive usability feedback from a small group. It isn't proof that the market wants this, that people will keep using it, or that investments will happen.

Founders5 participants

3.76 / 4

Investors5 participants

3.55 / 4

1234

Scores run from 1 to 4. Higher means more agreement with the questionnaire statements.

Both overall ratings fall in the paper’s “Strongly Agree” range.

Five founders and five investors tested the platform independently. These are small-group usability results; they do not establish market demand or represent all founders and investors.

The more useful part was where the ratings were lower. Participants rated three things at 3.4 out of 4, which is "Agree" but below "Strongly Agree": the reliability and efficiency of founders' video uploads, how relevant the investor matches were, and the investors' tools for saving, tracking, or sorting pitches to follow up on. One founder also rated the upload item "Disagree."

A lower score tells you where to look. It doesn't tell you what's wrong. I won't pretend to know that one person's reason. But these were the places the platform still wasn't finished, and I was glad to have them in writing.

The technical work was the most urgent part, but the capstone paper was the most draining. Writing a team document means deciding how the first paragraphs should go, then how each idea flows into the next, and then finding the words. Then another block. Then a major revision.

What helped me most was embarrassingly simple: write the first thing that comes to mind, unfiltered. You wouldn't believe what raw thoughts reveal. You can fix it later, but you can't fix a blank page.

Over time that turned into a method. A lot of thoughts come into my head at once, and typing slows them down, so I use a dictation tool and say out loud whatever is in my head. It was especially helpful for the literature review, where I had to hold a lot of sources and ideas together. What comes out is messy and repetitive, and I don't mind that. The real writing comes afterward: I reread it, rework the wording, and cut the redundancies. Dictation gets the thoughts out, and editing makes them worth reading.

When deadlines got close and the work wasn't done, the chaos was real: fear of failing, disorder, confusion. The only option was to start the work, nothing else. Starting hurts, but not starting hurts longer.

But getting it done by the deadline isn't enough. If the only reason something is finished is the deadline, the quality shows. Rushing costs you later: sloppy code you have to maintain, stakeholders who lose trust, and time, which is the one thing you can't buy back. When pressure and your own sense of what's right disagree, pressure may win at first. It shouldn't win in the end.

Begin. Continue. Iterate.

To pass the capstone course, we had to clear a series of defenses: alpha, beta, omega, then the code defense and the final defense. We got through every one of them without failing.

I'm grateful for that, more than I'm proud. I'm grateful for my team and for everything we went through to get there, especially the documentation, which asked more of us than I expected.

I presented both the paper and the poster at UBIAN Legacy 2026. I was anxious, because there were a lot of people. But I had a mental model I could lean on: I knew this system end to end, because I had built it, and nobody else in that room could say the same. That gave me some relief. It's the one claim I allowed myself. Everything else belongs to the three of us.

The announcement came the same day. We won 2nd Best Research Paper and 2nd Best Research Poster. We were shocked. Friends from my department won awards too, so it felt like a good day for all of us.

Best Capstone Project and Best Capstone Presenter were announced later, at our department's year-end party. I couldn't believe it, and neither could my team. I knew how much was still missing from the system: the lower scores, the features we hadn't built, everything the first version taught me not to hide from. What we had was a working platform, tested for usability with real people, not a finished product. We were so happy about what we had accomplished and, more than that, about what we had become.

If I could go back to the pre-capstone review, I'd say: keep going. Keep presenting. You won't understand what's wrong until it fails in front of people, and that's okay.

I'd also say: ask real people sooner. Don't wait for a panel to tell you what a founder or an investor could tell you in one conversation.

The thing I'm proudest of isn't the awards, the paper, or the code. It's the team.

I think of Anthon, Zeus and me as three drops of water. When they join, you don't get three drops stuck together. You get one bigger drop.