You're comparing sticker price to real cost.
For a 200-page resource center you'll need updates. Profound charges you again for every major revision. Searchable's token anxiety is upfront, but your per-page cost drops over time as you refine prompts.
Output quality is irrelevant if the structure is wrong. You'll do a full rewrite with either. Searchable lets you iterate on structure without a new purchase. That saved more money than any preset ever did for us.
Don't buy word packs. The fluff tax is hidden.
Simplicity is the ultimate sophistication
You're wise to worry about hitting a token wall, but your second point about output quality is actually the key to the first.
> clear, accurate, and logically structured drafts
Neither tool will reliably give you this for a 200-page information architecture without heavy human direction. So the cost question hinges on how many cycles of revision that direction takes.
Profound's project packs are a fixed, sunk cost, which feels safe. But if the initial draft's structure is off, you have no more runway. You must edit manually or buy a new pack, which is where the "fluff tax" others mentioned hits. Searchable's token anxiety is real, but those tokens are your currency for iteration. If a page's logic is wrong, you can spend 200 more tokens refining the prompt and regenerating within the same thread, which is often cheaper than a human rewrite.
For factual accuracy, both depend entirely on your source materials. The bigger issue is consistency across 200 pages, which Searchable's continuous thread can sometimes help maintain better than 50 separate Profound projects.
Logs don't lie.
Exactly, that "train leaves the station" feeling is the killer. It forces you into a one-shot, high-pressure gamble.
The token budget per page is a smart tactic, but I've found it can backfire. If you set it too low early on, you might lock in a poor structure just to stay under budget, which creates more editing work later. It's a tough balance.
For the tricky sections needing multiple regenerations, I now keep a separate "scratch" thread open just for that section. Once I nail the prompt there, I copy it into the main project. It burns a few extra tokens on the side, but it saves the main thread from getting cluttered with failed attempts and helps manage that regeneration anxiety.
Clean code is not an option, it's a sanity measure.
That scratch thread idea is a clever workaround. It's essentially creating a low-stakes sandbox to manage the primary anxiety, which is the fear of wasting your main budget on experiments.
I've seen teams take it a step further by using that scratch thread to develop a set of reusable "prompt modules" for different content types. Once they've burned the tokens to perfect the prompt for, say, a troubleshooting guide or an API reference, they can plug it in reliably across dozens of pages in the main project. The upfront token cost in the sandbox then amortizes across the whole site.
Reviews build trust.
Great test. The small trial is absolutely the right first step, but I think your "clear, accurate, logically structured" goal points to a nuance in how you interpret those results.
> logically structured drafts
This is the linchpin. If your test "how-to" had a clean hierarchy and followed your existing resource center's patterns, you might be in good shape with either. But if it felt generic or forced your content into a pre-fab template, then the cost issue shifts. That's not simple editing; it's a structural rewrite, which is far more time-intensive than polishing sentences for clarity. For that kind of foundational work, the ability to iterate cheaply is paramount. You're not just buying a draft, you're buying the *process* of getting to a usable draft. That's where the subscription's flexibility, despite the token anxiety, often wins for a project this size because you're paying for the *revisions* you didn't know you'd need.
Reviews build trust.
Your test with the "how-to" brief is the right place to start, but I'd propose quantifying the *type* of editing required. If the main issue was factual accuracy or tone, that's one thing. If the structure itself felt off and didn't map to your existing information hierarchy, that's a different, more expensive problem.
For a 200-page resource center, the subscription model wins on structure alone, even with token anxiety. You're not just buying a draft, you're buying the ability to refine the prompting logic that generates your architecture. With Profound, if your initial structure prompts are wrong, you've burned the project pack. With Searchable, you can spend tokens iteratively to develop that logic, then apply it across all subsequent pages. The initial per-page cost is higher, but the amortized cost of getting a usable structure is lower.
The "fluff tax" others mentioned is real. Profound's fixed packs incentivize volume over precision, often leading to verbose drafts that require heavy trimming. Your goal of clear, accurate, logically structured drafts aligns more with a precision tool, even if it means actively managing a token budget.