BriefStack
An AI tool for content briefs that refuses to write the content.
Product definition, product decisions, direction of an AI-assisted build
Self-directed
2026
Next.js, TypeScript, PostgreSQL, Prisma, DeepSeek
https://thebriefstack.vercel.app
I spent five years in content marketing and SEO operations. The recurring failure in that work was almost never the writing. It was everything that should have happened before the writing.
Briefs got made inconsistently, in whatever format the person making them preferred that week. They lived in scattered documents. The strategic decisions inside them — who this is for, what they are actually trying to find out, where they sit in the funnel, what the piece is supposed to achieve — were often made implicitly or not at all. Then a writer received something thin and filled the gaps with guesses.
BriefStack is that problem turned into software. It takes a topic, an audience, a content type and a funnel stage, and produces a structured brief: audience analysis, search intent, content goal, recommended angle, questions the piece must answer, suggested structure, and a call to action.
It does not write content.
That is the product's central constraint and I enforced it deliberately. The system prompt tells the model it does not write content. The build rules list AI article generation as a forbidden feature. The reasoning is that generating an article is the easy, crowded thing, and it solves the wrong half of the problem — the bottleneck in content operations was never producing words, it was deciding what the words were supposed to do.
The cost of the decision is real. It narrows the product to teams that already have a writer, and it means BriefStack cannot compete as a general content generator. I think that is the correct trade, but it is a trade.
Three areas, from specification to hardening.
Specification-driven build
Wrote a standing set of specification documents — product scope, forbidden features, required output structure, architecture, UI principles, tone rules — that the coding agent worked from throughout. When scope drifted, I corrected the document rather than the output.
Malformed JSON handling
The model returned malformed JSON often enough to be a real problem. Fixed it specifically: detect the truncation signature, retry once with a larger token budget, strip the fences, validate required sections before anything reached the user.
Production hardening pass
A month after the app was working, added rate limiting, a hard timeout on model calls, error boundaries, and a proper data access layer — then deleted two pages an earlier version of the flow had needed and the current one did not.
No user has tested it. There are no interviews, no beta group, no usage data — I built the analytics instrumentation and never built the endpoint behind it, so even if people had used it I would have captured nothing. The planning documents also drifted from the implementation in a few places. I would rather state that than describe the build as more controlled than it was.
Not that the system found a market. It was not built to.
What the project does demonstrate is the path from a problem I had lived to a working system that handles real failure modes — built through the same specification-driven method as the Multiphase platform, which suggests it's a way I work rather than a one-off.