Why a General-Purpose LLM Won't Cut It — Building the Wadiz Crowdfunding Story AI

Last Modified: July 9, 2026

Wadiz Data · Story-Generating AI

If you ask ChatGPT to “write a crowdfunding story,” it will generate a plausible text, but it won’t produce a story that’s ready to be posted right away. To bridge this gap, Wadizdeveloped its own story-generation AI—when a creator simply uploads a single product photo and a few lines of description, Wadizdelivers a complete product page tailored to the platform’s specifications, complete with body text and section images, all built on the framework of a story that has actually succeeded Wadiz. This article explores how this differs from general-purpose LLMs and where that gap comes from.

This isn’t just a technical overview. I want to document—with supporting evidence— how this differs from simply asking a general-purpose LLM, how to use it, and what trade-offs we considered during development—including a few architectural decisions, particularly those that make you wonder, “Why did we do that when it didn’t seem necessary?” If you’ve ever run an LLM application in production, these are likely issues you’ve encountered at least once.

Why Did They Create It? — The Real Challenge for Makers Is “Story”

If you ask makers preparing for a crowdfunding campaign, there’s one thing they dread just as much as actually making the product: writing the campaign description (story).

Just because you’ve created a great product doesn’t mean you’ll succeed in your crowdfunding campaign. You need to use text and images to convincingly explainwhy the product is needed, what problem it solves, and why people should back it at this price right now. However, this requires a completely different set of skills than product development. This is especially true for solo makers and small teams launching their first crowdfunding campaign.

• I don't know what order to write this in. (Where do I put the hook? Where do I put the reward?)
• I don't know what kind of tone works in this category. (Using emotional copy for tech products just feels out of place.)
• You'll need to either outsource the design of the images for each section or create them yourself.

As a result, writing the story becomes a bottleneck that delays the launch of a crowdfunding campaign by several days—and sometimes even causes creators to give up altogether. In fact, this is where many creators run into their biggest roadblock.

What we’ve created is a tool that breaks down these barriers. All you need to do is upload a single product photo orenter a few lines describing the product’s features and details—that’s all it takes—and it generates a ready-to-post storycomplete withcategory-appropriate layout, persuasive copy, and section images. Our goal is to transform a process that used to involve starting from scratch and spending days struggling into one where you simply refine a pre-written draft.

One Question the Planning Team Picked Up On

Once we decided to build this, the question that took up the most time during the planning phase was,“So, what should we automate, and what shouldn’t we automate?” It would be convenient to complete the entire story-writing process with a single click, but there were two issues that held us back.

• Hallucination: The product detail page is an advertisement. If the AI fabricates specifications, awards, or rewards that don’t exist, that’s not a convenience—it’s an accident. → This was resolved using the multi-layered hallucination prevention method, which will be covered in Chapter 7.
• Standardization: When a flood of identical stories that “look like they were written by AI” appears, it actually stifles the creator’s individuality. → This was mitigated by focusing on the categories and diversity axes (Chapters 5 and 6).

So, rather than setting the goal as “providing a finished product ,” we defined it as “immediately generating a validated draft to give creators a starting point they can refine in their own words.”This single sentence became the baseline for nearly all subsequent design decisions — from what to generate (Chapters 5 and 6), what to prevent (Chapter 7), the extent to which to ensure diversity (Chapters 5 and 6), to which editing paths to open (Chapter 1: Whitelist).

“Can’t you just ask ChatGPT to do that?” — How is it different from a general-purpose LLM?

This naturally raises a counterquestion. Since LLMs are so good at writing these days, couldn’t we just ask ChatGPT, “Write me a crowdfunding story”?

You’ll see once you try it. It generates plausible text, but it doesn’t produce stories that are ready to be published right away. There are three things that general-purpose LLMs lack but we have. Since these are the core of this project, I’ll highlight them first.

1) Write a story based on the structure of actual success stories Wadiz.

This is the biggest differentiator. General-purpose LLMs know the “general principles of crowdfunding stories.” Wadiz, we’ve curated reference templates based on the patterns of stories that have actually succeeded in raising funds, and we search for the one that best fits the product before writing the copy based on that framework. This is where we derive the proven flow—Hook → Problem Statement → Solution → Evidence → Reward—as well as the narrative structure and tone that resonate with each category. This is the difference between a “plausible story” and a “story that works on this platform.” (The detailed method is covered in Chapter 5.)

2) Produce deliverables that meet the platform specifications.

The Wadiz editor (Froala) does not accept just any HTML. There are restrictions on allowed tags, class specifications, and inline styles. HTML generated by a general-purpose LLM requires a lot of manual editing to paste here. Our output is formatted to be pasted directly into the editor. This is the difference between “receiving an article” and “receiving a post.”

3) From a single photo to a post—all in one go.

If you were to use general-purpose tools, you’d have to switch back and forth between at least three different platforms: a chatbot for text, an image generation tool for images, and manual adjustments to meet specifications. We’ve automated this entire process into a single pipeline: input product photos (or short descriptions) → product analysis → template search → body text generation → section image generation → specification adjustments. This way, creators don’t have to switch between multiple tools.

To sum up, if a general-purpose LLM is a “writing assistant,” this is aWadiz Funding Story Generator.” Domain knowledge (success patterns), platform integration (specifications), and pipeline automation are what set it apart.

Same Input, Different Outputs — A Side-by-Side Comparison

Results speak louder than words. These are the results obtained when entering the exact same product details(360-degree home security camera, tech/home appliances, 6 features) into each system. The left side shows the result of asking a general-purpose LLM to “write a crowdfunding story,” while the right side shows the result from WAi’s story-maker.

The difference is immediately apparent. Generic LLMs simply list bland text paragraphs—they lack section images, feature baseless, generic copy like “Keeping your precious daily life safe,” and don’t even meet Wadiz editorial standards. In contrast, our content follows a proven structure— Hero → Problem Statement → Solution—and includes a spec table with organized data, images generated for each section, and specific, data-driven copysuch as “Minimizes blind spots with 90-degree vertical and 360-degree horizontal coverage.” It’s a complete story ready to be published as-is.

What makers receive isn’tjust a “draft,” but a “product page ready to be posted directlyWadiz.” In the rest of this article, I’ll explain where this difference comes from—the framework for success stories, platform specifications, and pipeline automation.

The image above shows the top portionof the actual output. The full document consists of 13 sections, ranging from “Here” to “Rewards,” “Funding Allocation Plan,” “Maker Introduction,” and “Risk Disclosure.”

Here's How to Do It — From a Single Photo to a Story

Before we dive into the technical details, let’s first see how makers actually use this. You don’t need to sign up on a separate website—just talk to WAi, WadizAI agent.

First, on Wadiz, click the AI Agent WAi button in the lower-right corner of the screen, no matter where you are on the site.

In the WAi chat window, select the "Story Generation AI" optionbelow the input field to enter the story generation flow.

After that, all you have to do is talk.

1. Use the story-generating AI to make a request. Simply say something like, “Create a crowdfunding story for me,” and the generation process will begin.
2. Provide a product photo or a few lines of description. If a photo is available, we’ll analyze the product and incorporate that information; if not, we’ll proceed based on the description alone. If any necessary information is missing, WAi will ask follow-up questions to fill in the gaps.
3. You'll receive the finished story shortly. A detailed page—complete with the main text, section images, and formatting—will be sent to you via a viewer link; you can publish it as is or make any necessary adjustments.

There’s only one entry point (WAi), but quite a few components are at work behind the scenes. That’s what we’ll be discussing now —why we built it this way and what decisions led to this result.

First, here’s a picture that looks a little strange

Here is the overall call flow.

If you're a developer, there's one thing that immediately catches your eye here.

Why does the worker (agent) call the creation engine in the middle of... mcp_serverDidn't you insert an extra layer? It's just that the worker connects directly to the Lambda engine invokeIf you do that, you'll get one step.

That's a valid suspicion. In fact, if you just look at the trend, mcp_serverIt seems like an unnecessary intermediate step. Half of this post is dedicated to answering that question. The other half covers other decisions that came along with it (asynchronous callbacks, image fallbacks, and Category RAG).

1. The MCP server is not a “relay” but a “layer that defines tools.”

To get straight to the point, mcp_serveris not a proxy that forwards requests. A layer that defines all tools in one placeThat's it. That's the whole difference in perspective.

The Innocent Version

Everyone draws like this at first.

worker ──▶ story-maker Lambda (직접 invoke)

There are fewer steps and less code. The worker creates the payload lambda.invokeJust hit it, and that's it. In fact, the early prototype had this structure.

The problem stems from the fact that there is more than one client.

Reality: There are multiple entry points.

WAi isn't the only way to call the story generation engine.

• WAi Path: supervisor → worker → creation
• Claude Desktop Path: The MCP client connects directly and even uses editing tools
• Other MCP clients to be added in the future

Now, the drawbacks of the “worker directly invokes the engine” structure become apparent. The rules for invoking the tool—payload schema, argument validation, asynchronous calling method, and result retrieval method—must be implemented in duplicate for each client. If the story generation tool’s specifications change, all clients must be modified accordingly. This is a classic case of “shotgun surgery.”

The MCP layer eliminates this problem entirely. Functions such as story creation, editing, image replacement, and caption handling are defined on this server just once using standard MCP tools. Clients simply connect to this server and call the tools; they don’t need to know how the engine is invoked.

Bonus Benefits

When you gather all the tool definitions in one place, certain things naturally fall into place.

Exposure Control (Whitelist). The server controls which tools are displayed to which clients. WAi paths are whitelisted (_WORKER_ALLOWED_TOOL_NAMES) in the creation tool (create_crowdfunding_story) Exactly one type It is exposed. Editing, deletion, and partial regeneration are completely blocked by Runtime Guard. Although it’s the same server, the Claude Desktop path even uses editing tools. This control, which varies by client, is centralized on a single server.

Authentication and Caller Identification. Bearer token authentication and X-Caller The logic for identifying who is calling via the header only needs to be included here once.

State management and URL generation. Asynchronous callbacks, request state storage (DynamoDB), and the generation of upload and viewer URLs—all these pesky tasks are consolidated in this layer.

To summarize, mcp_serveris not an unnecessary step between the worker and the engine, but rather A single source of the contract shared by multiple entry pathsThat's right. While it may seem like a loss when you count the number of steps, the benefits outweigh the costs as soon as there are two or more clients.

If we were to distill this into a single design principle: Instead of implementing N clients × M tools N × M times, implement them only M times and control their exposure. MCP is the standard interface designed for this “only M times” approach.

2. It may look like there are “two agents,” but there is actually only one.

There’s another common misunderstanding I’d like to clarify. The diagram above shows LLMs appearing multiple times. Both the worker and the generation engine use LLMs to generate content. That’s why I’m often asked, “Is this a multi-agent system with multiple agents chained together?”

No. Only one worker acts as the agent.

The key point is that “using an LLM” and “being an agent” are not the same thing.

The generation engine uses an LLM to generatetext, butit does not determinewhere to send the request. Itis an executor thattakes a specified input and produces a result. In contrast, the worker determines, “What does the user want right now? Should I call the generation tool, or should I ask for clarification?” It is this judgment that makes an agent an agent.

WAi supervisor  →  story-maker-worker (에이전트)  →  MCP  →  생성 엔진 (실행기)

The structure is supervisor → single agent → executor. Agents are not chained together within our workflow. Since blurring this distinction also blurs the boundaries of ownership and responsibility (e.g., who changes the prompts, who handles deployment), we clearly define roles to establish clear boundaries.

3. Why use asynchronous callbacks instead of synchronous calls?

Since story generation takes several minutes, waiting for a synchronous call wastes money and causes timeouts. Therefore, we pass the task to the engine via an asynchronous (event) invocation and receive the results via a callback. Let’s start by looking at the actual measurement data (last 30 days, under normal load).

• Median time: about 2 minutes
• Top 75%: About 2.7 minutes
• The top 5–10% take 4–5 minutes, with some cases taking up to 7 minutes

The distribution tails are long. This is because the pipeline generates the main text (using GPT-4.1) in a single step, then uses a model to generate 5–6 images per section, and if that fails, it falls back to an alternative method.

What would happen if we waited for this time using a synchronous call? One Lambda calling another Lambda synchronously invokeIf you call it The caller also waits for that amount of timeThat's right. You're stuck waiting for 2 to 7 minutes with nothing to do. The costs (billed based on execution time) and the risk of a timeout just keep piling up. If you have an API Gateway in front of it, it will simply time out at the 29-second hard limit.

So I ended it like this.

mcp_server ──▶ story-maker Lambda        (async Event invoke, 즉시 리턴)
mcp_server ◀── /webhook/lambda-result    (엔진이 끝나면 콜백으로 결과 통보)

mcp_serveris a generation engine As an asynchronous (Event) type Throw it and immediately remove your hand. Once the engine has finished its task, the callback endpoint (/webhook/lambda-result) returns the results. The status of requests up to that point is stored in DynamoDB. This architecture eliminates the issue of “who is waiting for whom” during time-consuming creation tasks.

As LLM pipelines get longer, this approach becomes less of a choice and more of a necessity. When responses take minutes rather than seconds, synchronous calls simply end up wasting money and causing timeouts.

4. Image Generation: Why Was GPT Chosen as the First Option and Gemini as the Fallback?

Instead of using just one image generation model, I’ve set up a dual-model system with GPT-Image-2 as the primary model and Gemini-2.5-Flash-Image as the fallback. Each model is retried three times. I’m documenting this decision based on actual measurements, not personal preference.

Why is GPT the main one? In commercial product images, There are significantly fewer false positives in the safety filter. With the Gemini family (especially Imagen), the safety filter frequently malfunctioned and rejected even the most ordinary product photos, and there was no way to disable this filter at the API level. For a service that generates images for crowdfunding products, this is a critical issue. On top of that, support for reference images (images/edits(It incorporates up to 16 original product photos), has a similar generation speed (15–19 seconds per section), and even allows for the reuse of existing OpenAI keys—all of which led us to make GPT our primary tool.

But why didn’t we ditch Gemini and keep it as a fallback? It’s because the service can’t come to a complete halt if there’s a GPT API outage or we hit the rate limit. The whole point of redundancy is to switch over to the other system if one goes down.

What about the cost? Here's a rough estimate (based on 1024×1024).

Fallback is actually about 20% more expensive. However, since fallback is only triggered “when GPT fails,” it has almost no impact on regular costs; instead, it ensures availability.

Here’s one practical detail that’s easy to overlook: even if a single image fails, it doesn’t break the entire story. Only the image for that section will be left blank, while the body text and the rest of the sections will be generated normally. Isolating partial failures so they don’t spread to the whole—this is a step that’s surprisingly often overlooked in LLM pipelines.

5. Category Emphasis Strategy — How to Infuse Knowledge into Prompts

Earlier, I mentioned that “the biggest difference from general-purpose LLMs is that it writes the framework for Wadiz success stories.” Here’s how that’s implemented. Rather than relying on the assumption that “AI will figure it out on its own,” we search for category-specific descriptive knowledge verifiedWadizand incorporate it into the prompt. For developers, this is about RAG design; from a planning and marketing perspective, it answers the question: “Why is this story not just plausible, but compelling?”

102 Reference Templates + Soft Boost Search

We’ve added 102 reference templates—curated from the writing patterns (layout, narrative, and tone) of stories that have actually succeeded in raising funds Wadiz—to an Elasticsearch index for learning purposes. These templates cover all 21 categories (tech & home appliances, fashion, beauty, food, travel, etc.), and for each category, we established diversity axes—such as emotional appeal, trust, trendiness, credibility, and practicality—to ensure that even within the same category, templates with different tones are selected based on the nature of the product.

The search method is key. Categories are used as "soft boosts" (bonus points) rather than "hard filters" (candidate restrictions).

후보 = 전체 템플릿에서 벡터 유사도(KNN)로 추출
       + 같은 카테고리 템플릿에 가점

If you filter out candidates based on category first, even a slight discrepancy in labels (e.g., “Home” vs. “Home·Living”) will cause an entire set of good templates to be omitted. Soft boost always selects candidates from the entire pool based on semantic similarity, but gives them a higher ranking if their category matches. This is a common trade-off in RAG search that balances resilience to label mismatches with category accuracy.

Before / After — Does Knowledge Transfer Actually Change the Results?

We compared the results before and after implementing a strategy to emphasize the same product and the same image. Even just looking at the introductory copy, the tone is completely different.

After the update, the copy became more specific and evidence-based. Looking at tag usage frequency, for tech products (home cameras), the emphasis on numerical data (mint) increased from 26 to 41, while the emphasis on emotion (yellow) dropped from 18 to 0. This reflects how the category principle—“Tech persuades with concrete evidence rather than emotion”—was applied to the actual output.

The Limits of Being Honest

There are also drawbacks to a style that heavily emphasizes knowledge transfer. Stories in the same category may tend to converge in tone and structure. While the sentences themselves are rewritten for each product and thus aren’t identical, the “narrative texture”—such as section order, introduction style, and accent colors—can become similar. Although we’re mitigating this issue by focusing on diversity, it hasn’t been completely eliminated. I believe it’s better to acknowledge these trade-offs rather than hide them.

6. “There Were Only Two Beauty Templates” — The Story of How We Expanded the Number of Templates to 102

For the structure of Chapter 5 to work well, one prerequisite is necessary: there must be a sufficient number of good templates to reference in each category. Here, I’ll document the actual problems we encountered and explain why we ended up changing our search method while solving them. From a usability perspective, this also serves as evidence of “why our approach is better.”

Problem: Category Bias

We started with 50 templates, but they were unevenly distributed across categories. For example, there were only two templates in the beauty category. Whenever beauty products were featured, we had to choose from just those two templates every time, so the resulting stories inevitably ended up looking very similar. This was a situation where the “tone convergence” discussed in Chapter 5 was exacerbated by a lack of data.

Option 1 — Increase the data (50 → 102)

First, we expanded the template pool from 50 to 102 to comprehensively cover all 21 categories. Rather than simply increasing the number of templates, we allocated them across each category based on different diversity axes(emotional storytelling / information and trust / trendy visuals / reassurance and verification / value for money and practicality). Even within the same beauty category, “products that sell on emotion” and “products that build trust through ingredients and clinical evidence” require different frameworks.

As an aside, we were mindful of costs even when expanding these 52 items. Since we generated the template framework (spec) using our company’s OpenAI key (gpt-4.1) and filled it in via a script, it cost about $1.50 to create 49 of them. In a sense, we’ve incorporated a pipeline for “creating content with AI” into the process of “building AI” itself.

Option 2 — Changed the search method anyway (hard filter → soft boost)

Simply increasing the amount of data wasn’t enough. Even after doing so, there was still an issue where results would be completely excluded from the list if there was even a slight mismatch in category labels—such as “Home” versus “Home & Living.” The cause was that the search function was using categories as a hard filter (to limit results).

So, I switched to the soft boost methoddescribed in Chapter 5. Candidates are always selected from the entire dataset based on semantic similarity (KNN), and if the category matches, only a bonus score (boost = 0.15)is added. This number, 0.15, wasn’t just picked at random. Based on actual measurements on the dev index, the KNN cosine score was around 0.65 to 0.7; adding +0.15 to this represented a balance where “the same category is prioritized as the top choice, while subtle semantic distinctions within the category (score differences of 0.05 to 0.07) are not obscured.” With the large boost values we used previously (such as 6.0), scores within the same category all ended up clustering together, rendering the internal ranking meaningless. Even a single small constant has a solid basis.

To summarize, the “2 Beauty” issue was a case that required both data expansion and a change in the search methodat the same time, and the current structure of 102 features plus soft boost is the result of that.

It’s also worth noting that each template is more than just a simple example. Every template has a structured specification that includes tone keywords, writing style, color palette, narration mode, key phrases, and a section-by-section framework(Hero → Problem Statement → Solution …). The generation engine uses this framework as a prompt and fills it with product content.

That's why the results vary by category.

This framework—the “Structure and Diversity” axis—actually serves a single purpose: to adjust our writing strategy based on the category. General-purpose LLMs don’t recognize categories, so they write in a similar tone for every product, but we don’t.

• Tech & Home Appliances: We set aside emotional copy and persuade through numbers, specs, and evidence. (This is reflected in the home camera example above, where the emphasis on emotion dropped from 18 to 0, while the emphasis on numbers rose from 26 to 41.)
• Beauty: On the other hand, while prioritizing emotional resonance, we reinforce the brand by focusing on trust-building elements such as ingredients and certifications.
• Food: Focus on concrete evidence(ingredients, manufacturing, awards) as the main focus, and use social evidence (reviews, repeat purchases) as a supporting element.

Even when describing the same “great product,” the message comes across completely differently in the tech sector—where it’s “5-minute setup, 360-degree real-time monitoring”—versus the beauty sector. The category itself changes the structure, tone, and accent colors of the final output —this is precisely where the gap between “same input, different output” that I showed you in the introduction comes from. This is something that’s difficult to replicate with generic tools.

7. A Place That Prevents Hallucinations

Crowdfunding detail pages are advertisements. If an AI fabricates specifications that don’t exist, that’s simply false advertising. That’s why we’ve implemented multiple layers of safeguards to prevent such misrepresentations.

• Preventing numerical hallucinations: This prevents the model from inventing measurements—such as “9.8 mm”—by reading them from images. The root cause was that product features were missing from the image analysis path; this regression occurred because the features were present in the description path but absent from the image path.
• Preventing Reward and Delivery Hallucinations: While the information provided by the user is taken into account, the system prevents the LLM from inventing reward structures or delivery schedules on its own.
• Ad Review After Creation: Immediately after creation, the ad copy and images are submitted to our in-house ad review team, Lambda, to ensure compliance. Even if the ad is rejected, it is not recreated; instead, the rejection result is simply attached and logged (separating the responsibilities for creation and review).
• AI-Generated Notation: Metadata for the generated image (PNG tEXt / JPEG COM (Marker) AI-generatedWe are implementing measures to proactively address AI-generated content disclosure policies.

The advertising domain teaches us particularly hard that, in LLM applications, “what not to generate” is just as important as “what to generate.”

8. Who Should Own the Worker? — The Source of the Change, Not the Graph Location

Finally, here’s one point where organization and architecture intersect. Workers are invoked within the WAi graph. This raises the question: “Shouldn’t WAi own the workers?”

That is not our conclusion. The reason is that “called in the graph = ownership” does not hold true.

A worker isn't hard-coded into the WAi graph, but rather boto3.invokeThis is an external Lambda function that is called. WAi only knows the worker’s ARN; it has no knowledge of the code, prompts, or tools inside it. If “calling it means owning it” were true, that would mean WAi would have to own every external service it invokes, which is not the case.

Ownership is The Epicenter of ChangeLet’s decide on this. Events that trigger a worker change—changes to the category emphasis strategy, HTML specification changes, adjustments to section rules and hallucination policies, prompt tuning, and regression responses—all stem from story domain considerations. The party making those decisions must own them so that the deployment cycle isn’t dependent on them. In fact, the very purpose of separating the worker into a separate Lambda function was Changes are applied directly to the story branch without being held in the WAi deployment queueThat was the purpose (make deploy-worker-dev/prod).

The boundary is boto3.invoke This is the call site. The I/O contract is mutually agreed upon by both parties, while the implementation within the boundary is owned by each party. This is a textbook example of service separation, but when LLM agents are involved, the question of “Who owns this prompt?” can become surprisingly confusing. Drawing this line early on helps reduce deployment bottlenecks later on.

In closing

This service aims to solve one specific problem: helping creators overcome the biggest hurdle—writing a story—with just a single photo. And it does so not with a generic LLM, but by producing results tailored Wadiz—the framework for success stories, platform specifications, and pipeline automation are what bridge that gap.

Based on that, the decision made from a developer’s perspective is roughly as follows.

• MCP Tool Definition Layer: A single source of truth for contracts shared by multiple clients. Even adding a single step reduces the number of N×M implementations to M.
• Asynchronous callbacks: In tasks that take minutes to complete, synchronous waiting wastes money and causes timeouts.
• Image Redundancy: GPT as the primary option based on safety filters and availability, with Gemini as a fallback to isolate partial failures.
• Category RAG + Template Expansion: We infuse 102 proven success stories using soft boost and adapt the narrative strategy for each category to create “stories that resonate.”
• Preventing Hallucinations and Defining Ownership Boundaries: Incorporating the constraints imposed by advertising domains and organizational structures into the design.

And the guiding principle behind all these decisions was a single sentence established during the initial planning phase: “Rather than writing the final product for the maker, we immediately generate a vetted draft to provide a starting point that the maker can refine in their own words.” That’s why we use this approach instead of a general-purpose LLM. It’s not just any text—it’s a starting point designed to work specifically Wadiz.

It’s not the result of a single flashy technique, but rather the accumulation of results from weighing the question, “What is the cost of this decision?” each time. I hope this serves as a basis for consideration for others creating similar works.

If you have any questions or see a part that could be solved differently, please feel free to reach out.