Locking Down the Spec in 10 Minutes — A Decision-Making Framework with AI

 

The most painful moment in project planning is the act of choosing. What tech stack? Which features? How wide is the scope? When choices pile up simultaneously, it is easy to fall into a state where nothing gets decided at all. Decision paralysis.

This is the story of how three questions from AI locked down the entire project spec in 10 minutes. The key insight is that the AI did not "decide for me." It asked the right questions to draw out the answers that were already inside me.

Ambiguity Is the Enemy

In Part 1, I told Claude "I want to build a web page that does tarot readings." In Part 2, I grasped the basic structure of a tarot deck and the copyright landscape. Domain knowledge was in place. What remained was defining "what exactly am I building?"

The problem is that choices explode at this stage. Which reading modes? How should interpretations be delivered? Tech stack? Deployment? Do I need a database? Should it be a PWA? When these questions hit all at once, the default outcome is "let me think about it more" — and the project dies its second death.

What impressed me in the AI conversation was that Claude did not throw all these questions at me at once. Instead, it presented three core axes, one at a time.

Question One: What Reading Modes Will You Support?

The first question was about reading modes. Four options: one-card (daily fortune), three-card (past/present/future), Celtic Cross (10 cards, comprehensive analysis), and free selection (user picks the number).

It made logical sense for this to come first. Reading modes determine the UI layout and the shape of the data you need. But if I had been planning alone, I probably would not have started here. I would have agonized over the tech stack first or started listing every possible feature.

I chose three modes: one-card, three-card, and Celtic Cross. I dropped free selection. The reasoning was clear. For users unfamiliar with tarot, "how many cards would you like to draw?" creates confusion rather than freedom. "Choose from these options" always beats "figure it out yourself" in user experience. Three well-known, traditional layouts were enough.

Here is the interesting part. The reason for dropping free selection only became clear because the AI laid out the options side by side. When "which reading modes?" is floating vaguely in your head, the judgment is hard. But when four options are right in front of you, "I need this one, I don't need that one" becomes an instant call. It is the difference in cognitive load between being shown options and having to generate them yourself.

Question Two: How Will Interpretations Be Delivered?

The second question concerned the interpretation engine. Three options: pre-written static text, real-time AI API integration, or a hybrid of both.

I chose static text. Two practical reasons.

One was API cost. Calling an LLM API for every reading in a side project means costs that scale with usage. If traffic grows, it becomes a burden. A side project spending money before it earns any is not sustainable.

The other was response latency. The moment of flipping a card and seeing the result should feel immediate — that is the core of the tarot experience. A 2-3 second delay from an API call breaks that immersion. The card flip in tarot is a kind of ritual, and a loading spinner kills the magic.

This judgment would have played out differently without the options laid before me. If I had only been thinking "I should build a tarot app," I might have defaulted to "obviously AI should do the interpretation — that would be cool" and started with API integration. Then I would have discovered the cost and latency issues later and had to rearchitect.

When options are placed side by side and you consciously weigh the trade-offs, your own priorities come into sharp focus. This was the most valuable part of decision-making with AI.

Question Three: What Is Your Tech Stack Preference?

The third question was tech stack. Three options presented: React + Vite, plain HTML/CSS/JS, and Next.js.

This one was relatively quick. I picked React + Vite. I have spent most of my career in frontend development, and React has been my primary tool for the past several years.

A quick rundown of how I evaluated each option: plain HTML/JS is fast to start but managing state across multiple reading modes gets messy. Handling the sequence of selecting, flipping, and displaying cards in vanilla JS leads to tangled code. Next.js is overkill for this scale. Server-side rendering is not needed, and file-based routing offers no advantage for a single-page app.

React + Vite was the sweet spot for a side project. React's component model keeps the UI cleanly divided, and Vite's blazing-fast HMR (Hot Module Replacement) keeps the development feedback loop short. The bundle size is lighter than Next.js too.

Options Reveal Your Decision Criteria

Answering these three questions taught me something. The value of AI presenting options is not that "choosing is easier." It is that your own decision criteria become visible.

When I chose static text, I recognized "immediacy of user experience" and "minimal operating cost" as my project priorities. When I dropped free selection, I declared that "user-friendliness" outweighs "feature richness." When I picked React + Vite, I confirmed that "speed with familiar tools" beats "learning something new."

These criteria would have remained unconscious without the AI's questions. I would never have had the chance to ask myself "why did I pick this?" Seeing options, picking one from among them — that process itself is a tool for sharpening your own priorities.

Naming the Project: "Tarot Master"

After the three key decisions were made, the project name naturally fell into place. I asked "How about just going with Tarot Master?" and the feedback was that it was clean and intuitive.

The naming took under five seconds. I believe time spent agonizing over a side project's name is nearly always wasted. Rather than burning energy on the perfect name, pick a decent one and start moving. You can always change the name later, but once you lose the energy to start, it does not come back.

"Tarot Master" describes the function intuitively, is easy to remember, and works well in both Korean and English. Whether for a domain name or a repository name, it poses no issues. Good enough.

Spec Locked: About 10 Minutes

To summarize, here is what was decided in a single conversation session.

Reading modes: one-card, three-card, and Celtic Cross. Interpretation method: pre-written static text (with future AI API extensibility). Tech stack: React + Vite + TypeScript. Project name: Tarot Master. Data scope: all 78 RWS cards, upright and reversed interpretations included.

Time from initial idea to this spec? About 10 minutes, by my estimate.

What would the traditional approach have looked like? Half a day researching tarot card structure, half a day benchmarking similar services, half a day on a spec draft, half a day evaluating tech stacks. At least two days. Sure, you might think more deeply during that process. But in a side project, two days is a fatal amount of time. There is no guarantee your enthusiasm will be the same two days from now.

The Risk of Fast Decisions — and the Safety Net

"You decided everything in 10 minutes" might raise the question: "Isn't that too hasty?" A fair concern. Fast decisions risk being wrong decisions.

But in a side project, the cost of a wrong decision is different from a company project. If you pick the wrong tech stack, you can just switch — no stakeholders to report to. If the scope is too broad, trim it. The privilege of a side project is that the cost of failure is low.

The cost of not deciding is actually higher. Without a locked spec, nothing starts. Without starting, the project dies.

Still, safety nets help. Mine were twofold. First, lock down only the "core axes" early and adjust details as you build. Three reading modes are locked, but the detailed UX of each mode gets figured out during implementation. Second, decide in an "extensible" direction. Choose static text now, but architect it so an AI API can be added later.

This approach is not perfect, but for a side project, it is more than enough.

A Word of Caution on AI-Assisted Decisions

One thing I want to be explicit about. Just because AI presents options does not mean you should let AI decide.

If you ask "React or Next.js, which is better?" AI will give you a balanced comparison of pros and cons. But the answer to "which is right for my project?" is something AI cannot provide. The judgment that synthesizes your experience, your time constraints, and your priorities must come from you.

The value of AI is not "giving the right answer." It is "structuring the question so that I can judge more easily." Recognizing this distinction is, I believe, the first principle of AI collaboration.

What I Learned

First, the hardest part of decision-making is knowing "what needs to be decided." AI excels here. It decomposes a vague idea into decision axes and presents options for each.

Second, when options are presented, your own judgment criteria crystallize. Amorphous thoughts turn into concrete priorities when placed before a set of choices. You become consciously aware of "why I picked this."

Third, in side projects, "fast decision + flexible revision" beats "slow decision + perfect plan." A spec locked in 10 minutes has overwhelmingly better execution power than a two-month planning document.

Next Up

The spec is set. Reading modes, interpretation method, tech stack — all locked. The temptation to start coding is strong, but there is one thing to do first: decide how to structure the data for 78 cards. In Part 4, I will cover why data comes before code, and the design principles of a content-centric project.