The first psychology test I built for Q-Fit was a love style test. The start was simple. I typed "make me a psychology test" to Gemini 3.0 Pro. No structure, no criteria — just threw it out there. And the result was actually better than I expected.
But There Was a Problem When I Actually Tried It
I tested it multiple times myself. But the results kept landing on the same type. There were four possible outcomes, and one of them came up about 50% of the time. The questions and choices looked fine on the surface, but the underlying logic was skewed toward one particular result.
I think this is a mindset unique to side projects. Finding a problem and moving on anyway. In a work project, I would have fixed that bug before anything else. But in a side project, confirming the direction comes before polish. The reason I kept making new tests despite knowing about the skewed results — honestly, at that point, seeing whether the whole thing worked was more important. Better to keep moving and get a sense of direction than to get stuck perfecting one piece and never finishing the whole.
The More I Built, the More Friction Piled Up
After that, I kept adding more — a zombie apocalypse survival test, a personal color test, a psychopathic tendency test. But as the tests accumulated, things started to bother me. Every test had a different tone. One might say "You tend to be the type who~" in formal, polite language, while another would say "You're totally the kind of person who~" in casual phrasing. Within the same service, some tests felt like a teacher talking to you and others felt like a friend. Because I was making fresh requests to AI each time, there was no baseline for keeping a consistent voice.
The AI-generated images had the same problem. I gave it the same reference documents each time, but each test came out in a completely different style. Some images looked like anime illustrations, others like watercolor paintings, and others like photo composites. It felt like multiple different visual worlds coexisting inside one service. Each piece of content looked fine on its own, but put them together and something felt off.
But I didn't think too much of it back then. The goal was to show coworkers "I can build something like this." Showing it off came before polish.
"Isn't This Only Possible Because You Know Frontend?"
When I shared it with my colleagues, one team member asked: "Isn't this only possible because you know frontend? I don't know frontend — could I even get something like this using AI?" I paused for a second. Oh, so that's how it looks. I thought AI had done all the work, but in my colleague's eyes, it was something achievable because of my frontend knowledge. That actually lit a fire under me. If a teammate sees it that way, I thought, then with more polish this could be a real product. I decided to get serious about building it properly.
Documentation: To Use AI More Effectively
As I started making real improvements, I watched how AI actually worked. Without any documents pointed out to it, it seemed to rummage through folders on its own, burning through tokens unnecessarily. In some cases, it couldn't find an already existing test file and ended up rewriting a similar structure from scratch. Watching AI fumble around made the problem clear: I hadn't given it proper guidance.
So I created documentation laying out the existing test list and the project's directory structure — so AI could reference only the files it actually needed. Once I had a clear, at-a-glance record of what tests existed and where each file lived, AI stopped wandering unnecessarily. Without the fumbling, it handled the same tasks faster and more accurately.
Quality didn't improve dramatically. But the time before hitting quota limits got pushed back. With the same workload, I could work longer without running out. Documentation didn't boost AI's capability — it just cleared a path so AI could stop wandering.
What I Felt Working with AI
Looking back at this period, AI made it possible for one person to do the work of many. I'm a backend developer. Frontend, design, content planning — none of that is my specialty. Work that would have required gathering a team of specialists in different fields, I was able to do alone. Skipping months of learning and having a working website in a single day — that in itself was remarkable.
But the fact that this is still an unsolved problem is, in a way, exactly why I keep coming back to this side project. Maintaining something that's already perfectly polished is boring. There are still problems to crack, and knowing I can do better is what keeps me returning. Q-Fit is still a work in progress — and that's what keeps me hooked.
