The Rejection
On March 2, 2026, the Jocoding Hackathon preliminary round rejection result arrived. A working MVP had been built and submitted over 3 days, but it did not advance to the finals. No specific feedback on the rejection reasons was provided.
The absence of feedback means the direction for improvement is unknown. But it also means no specific product defect was singled out. Either way, the facts stand: a 3-day MVP was submitted, and it did not make the finals.
Analyzing Rejection Causes
Without official feedback, the only option was to reverse-engineer possible causes. Several hypotheses were formed by cross-referencing typical hackathon evaluation criteria with the submission’s characteristics.
Hypothesis 1: Market Fit Demonstration Challenge
GEO (Generative Engine Optimization) is still an early-stage market even by 2026 standards. The concept of AI search optimization is not yet as universal as SEO. There is a possibility that judges could not immediately be convinced of the market’s size and urgency.
Hackathon judging typically requires communicating “why this problem matters” within 3 to 5 minutes. Explaining GEO’s importance requires first establishing the premise that AI search is replacing traditional search, then building the argument that brand visibility measurement is necessary on top of that. Delivering both layers convincingly in 3 minutes is no easy feat.
Hypothesis 2: Demo Completeness
A working MVP was submitted, but “it works” and “it’s impressive” are different dimensions. Demos that score well at hackathons typically have visual impact or dramatically showcase a single core feature.
WICHI’s core value lies in a pipeline that collects and analyzes responses from multiple AI engines. This process is inherently a background operation and is difficult to present dramatically on screen. The report screen accurately displays data, but it was not the kind of demo that creates a “wow moment.”
Hypothesis 3: Competitive Dynamics
Hackathons attract diverse projects. Projects more intuitively understandable than a GEO SaaS — chatbots, image generators, education tools — may have held a structural advantage. Results varying based on judges’ backgrounds and interests is a structural feature of hackathons.
Hypothesis Summary
| Hypothesis | Likelihood | Controllable? |
|---|---|---|
| Market fit demonstration challenge | High | Partially (explanation approach can improve; the market itself cannot be changed) |
| Demo visual completeness | Medium | Yes (can be improved through UI/UX investment) |
| Competitive dynamics and judging criteria | Medium | No (external variable) |
| Product defect itself | Low | Yes (submitted with the full flow working) |
Two uncontrollable variables and one only partially controllable. The important conclusion from this analysis is singular: the rejection does not negate the product’s value.
Constraints the Hackathon Imposed
During the hackathon participation period, WICHI operated under several artificial constraints. These constraints were rational within the hackathon context but were unnecessary — even harmful — from the perspective of delivering the product to real users.
Technical Debt Created by Time Constraints
A 3-day deadline forces “the method that works right now.” There is no room for clean architecture design, and code gets written to the standard of “it runs, so it’s fine.” This is an intentional feature of hackathons. The problem is that the technical debt remains in the codebase after the hackathon ends.
Incomplete Product Created by Scope Limits
Features that did not directly contribute to hackathon judging were intentionally deferred. Items like multilingual support (i18n), SEO optimization, blog, and onboarding improvements are essential for product commercialization but do not contribute to hackathon evaluation scores. It was a rational prioritization decision, but the result was a product that was “working but incomplete.”
Distortion Created by Narrative Constraints
Hackathon submissions require a narrative. “We found this problem and solved it like this” — that kind of structure. In WICHI’s case, the project was actually under development before the hackathon, but submission materials had to be structured around achievements during the hackathon period. This narrative constraint made it difficult to convey the project’s actual context and depth.
Full Constraint List
| Constraint Type | Specific Content | Rationality Within Hackathon | Impact on Commercialization |
|---|---|---|---|
| Branch freeze | Maintain stable branch, no feature experiments | High (submission stability) | Negative (development speed decrease) |
| Submission format | Demo flow aligned with judging criteria | High (judging response) | Negative (gap from actual UX) |
| CTA distortion | Judge-friendly signup flow | Medium (impression management) | Negative (conversion rate optimization impossible) |
| Feature scope limits | Remove/defer features irrelevant to judging | High (focus) | Negative (incomplete product) |
| Tolerated tech debt | Speed priority, quality compromise | High (completion within time) | Negative (refactoring costs) |
| Narrative structure | Story centered on hackathon period | High (judging rules) | Negative (project context omitted) |
The Decision After Rejection
The hackathon was a tool for leveraging deadline pressure, and the rejection does not change the product’s value.
The decision did not take long. The hackathon product would be converted to a commercial SaaS. This decision was not an emotional reaction but the result of a condition check.
Decision Framework
Three options were evaluated immediately after rejection:
graph TD
A[Hackathon rejection] --> B{Option evaluation}
B --> C[Option 1: Abandon project]
B --> D[Option 2: Wait for next hackathon]
B --> E[Option 3: Pivot to independent SaaS]
C --> C1[Only sunk costs remain]
C --> C2[Working MVP discarded]
D --> D1[Development stalls until next hackathon]
D --> D2[Hackathon constraints reapplied]
E --> E1[Resume development immediately]
E --> E2[All constraints released]
E --> E3[Leverage market timing]
style E fill:#f0f0f0,stroke:#333
style E1 fill:#f0f0f0,stroke:#333
style E2 fill:#f0f0f0,stroke:#333
style E3 fill:#f0f0f0,stroke:#333Option 1 (abandon) was irrational — discarding an already-working MVP with a complete flow. Option 2 (wait) was close to a retreat — losing development momentum and re-entering hackathon constraints. Only Option 3 (independent pivot) maximized the resources already invested and the already-validated pipeline.
Three Rationales for the Pivot Decision
1. Market Timing
The GEO market is in its early growth phase. AI search engine usage is increasing, and real demand exists for measuring brand visibility in AI search. Capturing first-mover advantage in an early market requires moving quickly. Waiting for hackathon results or aligning timelines with other external events only delays market entry.
2. Value of the Existing Codebase
Though built during a 3-day hackathon, the core pipeline actually works. The full flow from signup to payment to analysis execution to report viewing is operational. Discarding this codebase is not merely a sunk cost fallacy — it is genuine asset destruction.
3. Product Value Independent of Hackathon
The hackathon was only a motivational device; the product’s reason for existence has nothing to do with the hackathon.
The problem WICHI aims to solve — measuring brand visibility in AI search engines — exists whether or not a hackathon exists. The hackathon was a tool for leveraging deadline pressure to rapidly build an initial MVP, and that role had already been fulfilled.
Sunk Cost vs Opportunity Cost Analysis
The risk of falling into “we’ve already invested, so we must continue” — the sunk cost fallacy — was consciously checked. The key question was: Excluding the time invested in the hackathon, would I build this product from scratch right now?
The answer was “yes.” Given GEO market growth, the working state of the existing pipeline, and the tech stack’s extensibility, the same decision would have been made even as a brand-new project. The existing codebase being in place means the starting line is ahead, but it is not a reason to continue.
Only after passing this test was the pivot confirmed.
Constraints Released
Immediately after the pivot decision, all constraints imposed during the hackathon were fully released.
graph LR
subgraph "Hackathon Mode"
H1[Branch freeze]
H2[Demo format compliance]
H3[Judge-friendly CTA]
H4[Feature scope limits]
H5[Tolerated tech debt]
end
T[Rejection / Pivot decision]
subgraph "Independent SaaS Mode"
S1[Free branching strategy]
S2[Real user flows]
S3[Conversion-optimized CTA]
S4[Full roadmap restored]
S5[Refactoring begins]
end
H1 --> T --> S1
H2 --> T --> S2
H3 --> T --> S3
H4 --> T --> S4
H5 --> T --> S5
style T fill:#f0f0f0,stroke:#333Specifically, the released items and their effects:
| Released Constraint | Hackathon Mode (Before) | Independent Mode (After) | Practical Effect |
|---|---|---|---|
| Branch freeze | Single stable branch maintained | Free feature branch creation/merging | Parallel development possible, reduced experimentation cost |
| Demo flow | Scenarios aligned with judging criteria | UX based on real user journeys | Conversion rate optimization can begin |
| CTA design | Signup flow conscious of hackathon evaluation | Independent design per marketing channel | A/B testing and channel optimization possible |
| Feature scope | Only judge-relevant features included | Full roadmap restored | i18n, SEO, blog, onboarding initiated |
| Code quality | ”It works” standard | Production quality standard applied | Refactoring and test addition begun |
| Narrative | Story centered on hackathon timeline | Communication centered on product vision | Marketing message freedom gained |
Execution Plan: From Hackathon MVP to Production
After deciding on the independent pivot, the gap between the hackathon MVP and production target was concretely defined.
Hackathon MVP vs Production Target
| Area | Hackathon MVP | Production Target | Priority |
|---|---|---|---|
| Language | English only | Korean + English (i18n) | P0 |
| SEO | None | Meta tags, sitemap, Search Console | P0 |
| Onboarding | Minimal explanation | Experience flow based on sample analysis data | P1 |
| Auth | Basic Supabase Auth | Social login addition, session management improvement | P1 |
| Payment | Single plan | Plan system revision, free trial period | P1 |
| Blog | None | GEO content marketing | P2 |
| Monitoring | None | Error tracking, usage logging | P2 |
| Analysis engines | Initial set | Engine additions and response parsing refinement | Ongoing |
Feature Unlock Timeline
The dependency relationships among features unlocked after the pivot:
graph TD
T[Pivot decision 3/2] --> A[Merge i18n branch]
T --> B[Register Search Console]
T --> C[Rewrite STATUS.md]
A --> D[Complete English UI]
B --> E[Submit sitemap]
D --> F[Configure global marketing channels]
E --> F
A --> G[Build blog with i18n foundation]
G --> H[Begin GEO content publishing]
C --> I[Set commercialization milestones]
I --> J[Sample analysis system]
I --> K[Plan system revision]
J --> L[Onboarding improvement]
K --> L
style T fill:#f0f0f0,stroke:#333What matters in this timeline is that i18n is a prerequisite for multiple downstream tasks. Immediately merging the i18n branch that had been on hold during the hackathon was about unlocking this dependency chain.
Same-Day Execution (March 2)
Execution began the same day the decision was made. For the pivot to become “fact” rather than “intention,” concrete changes had to be reflected in the codebase and infrastructure within the day.
1. STATUS.md Rewrite
The project’s status document was completely revised from the hackathon track to the commercialization track. Goals, milestones, blockers, and next actions all changed. Since STATUS.md is this project’s source of truth, changing this document constituted the formal declaration of the pivot.
2. Google Search Console Registration
The wichi.app domain property was registered with Google Search Console. This had been deferred during the hackathon because SEO was outside the priority scope. As an independent SaaS, search exposure is foundational infrastructure.
3. i18n Branch Merge
The multilingual support branch held back during the hackathon was merged to main. What this merge unlocked was not merely the English UI but the prerequisite for all subsequent work targeting global users.
The transition from “hackathon project” to “independent SaaS” was completed within a single day. Once the hackathon constraints were released, what needed to be done actually became clearer.
Retrospective: How to View the Hackathon
A Hackathon Is a Validation Tool, Not a Destination
The value of a hackathon lies not in winning but in structured pressure. The forcing function of having to build “something that works” within a short deadline elevates decision-making speed. It converts “there might be a better approach” into “the approach that works right now.”
For WICHI, initial MVP completion would have taken at least 2-3 extra weeks without the hackathon. The 3-day deadline pressure made it possible to punch through the entire flow — signup, payment, analysis, report — in one shot. This punch-through experience is an asset that remains regardless of the hackathon outcome.
Rejection Is Information, Not a Verdict
The information extractable from a hackathon rejection is limited but real:
- Market explanation difficulty is high (the GEO concept is not yet mainstream)
- Demo visual impact may be insufficient
- Judging criteria and product value do not always align
These are concrete items that can be improved in the next phase: improve the market explanation method, invest in UI/UX, and establish channels for directly communicating product value to users.
Mental Model: Hackathon → Validation → Fork
graph TD
A[Idea] --> B[Hackathon participation]
B --> C[MVP complete]
C --> D{Result}
D -->|Win| E[Prize + exposure + momentum]
D -->|Lose| F[MVP + learnings + freedom]
E --> G[Independent SaaS pivot]
F --> G
G --> H[Commercialization track]
style G fill:#f0f0f0,stroke:#333Whether you win or lose, the final destination is the same. Winning adds the bonuses of prize money and initial exposure; losing brings a different kind of bonus — immediate freedom from hackathon constraints. Either way, the working MVP and validated pipeline remain intact.
The difference is speed. Had we won, the exposure would have accelerated early adopter acquisition. Having lost, the path chosen was to first improve product completeness. Both paths are valid.
Pivot Cost for a Solo Developer
In a solo project rather than a team, pivot cost is structurally low. There is no one to build consensus with, and editing STATUS.md is the entirety of the direction change. The transition from hackathon to commercialization was mostly documentation changes, not code changes. The codebase stays intact; only the priorities and roadmap layered on top of it change.
This is a structural advantage of solo development. Since the communication cost of a direction change is near zero, the gap between “decision” and “execution” is minimized. Receiving the rejection notice on March 2 and completing the transition the same day was possible because of this structure.
What This Post Does Not Cover
This post documents the decision-making process. The following items are covered in separate posts:
- The 3-day development timeline during the hackathon (separate post)
- Detailed frontend hosting migration (separate post)
- Technical changes after commercialization
- Specific system architecture or internal implementation details
Related Posts
Solo SaaS Security — The Minimum You Must Do
Essential security checklist for solo SaaS builders. Defense against five critical OWASP Top 10 vulnerabilities and real-world security configuration cases improved for WICHI.
Lovable to Vercel — Frontend Migration Record
Migration from Lovable ($25/mo) to Vercel ($0) including build pipeline reconfiguration, documenting the frontend hosting transition process.
Build, Document, Share
Personal execution notes from a non-tech builder who started with AI FOMO and is now navigating the messy reality of production beyond the initial 'one-click' hype.