On Tuesday, we are pressing the public launch button on HeyNews.
We have been writing this paragraph in our heads for almost a year. The version we kept practicing always sounded like a product announcement. There is something more honest to say about what the past twelve months have actually been.
Cagri and I have been using the platform ourselves. Our team has produced more than 550 newsletter issues with it before letting any outside writer try it. 10+ formats. Different voices. Different cadences. Different industries. The system has been generating drafts every week, and our team has been editing them every week, and we have been watching for the exact moment when the voice would slip and break the trust we had with our own readers.
That moment is what this post is about.
Sit with that number for a moment. 550 issues is what most newsletter operators publish over many years of consistent work. The median time for a newsletter launched in 2025 to earn its first paid subscriber dollar, according to beehiiv’s State of Newsletters 2026 report, was 66 days. A year of dedicated work is the difference between curiosity and conviction in this medium. It is the period during which most creators decide whether the publication is something they will keep doing.
We did the year first. Then we built the launch around what the year showed us.
Why We Built HeyNews for Ourselves First
Paul Graham wrote an essay called How to Get Startup Ideas that has shaped how a generation of founders thinks about what to build. The line everyone quotes is the obvious one. The way to get startup ideas is to look for problems, preferably problems you have yourself. The line that takes longer to absorb sits a few paragraphs later. The best startup ideas are something the founders themselves want, that they themselves can build, and that few others realize are worth doing.
Newsletter operators were the founders the line was about. We were already running newsletter publications in 2025. We had spent thousands of hours doing the work. We knew what the production load felt like at week thirty, when the energy that started the publication had quietly drained out, and the issue still had to ship.
The original idea was small and selfish. We wanted a tool that would let our own team publish at the cadence the audience was used to, without burning the people doing the writing. We needed a tool that protected voice across fifty issues, then a hundred, then five hundred.
There is an ancient paper in software engineering by Donald Knuth, the computer scientist who built the typesetting system used to publish most of the world’s mathematical research. In 1989, a paper called The Errors of TeX, Knuth recorded ten years of bugs and design changes in the software he had built. The conclusion he drew at the end is the one our team kept coming back to. The designer of a new system, Knuth wrote, must also be the implementor and the first large scale user. If those roles separate, the system loses something it can never recover.
The principle has a name in the software industry. Dogfooding. The term goes back to a Microsoft email written in 1988 by Paul Maritz, who asked his test team to start using the products the company was selling. Apple banned typewriters from its offices in 1980 to force its employees onto the computers they were building.
The principle is unfashionable now in a way it was not then. Most software gets shipped before the team has used it for a single real workflow. Demos are produced. Investors see a working prototype. The product hits beta with a polished onboarding flow and a closing chord. By the time the first real user arrives, the team has already moved on to the next feature.
A tool that promises to write in your voice can only be tested across the issues your readers carry in memory.
That is the real test of any AI writing system. Demos are episodes. Newsletters are series.
What We Were Afraid Of
The fear was specific.
Every newsletter creator who has touched generative AI knows the fear. The reader who has been with you for forty issues will open the next one, read the first paragraph, and feel that something is off. They will not be able to name it. They might not even consciously decide to unsubscribe that week. But the bond they had with the publication will quietly weaken, and on one Tuesday three months later, they will see the issue arrive in their inbox and decide it is no longer worth opening.
We were afraid of being the people who did that to our own audiences.
I know you’ve been there too. Every creator we have talked to about generative AI describes some version of this fear. It is the reason most operators try a generic tool once, paste in a few notes, read the output, and quietly close the tab. The output sounds competent. It also sounds like nobody in particular. And nobody in particular is exactly what readers do not subscribe to.
So we built the system around the assumption that this fear was correct, and the only way to address it was to design from the archive outward. The voice profile is built from past issues. The tone, the vocabulary, the sentence patterns, the section structure, the signature phrases. None of it must be filled in by hand. None of it must be described in a style guide. The system reads what the writer has already published and learns about the writer from the work.
The choice was simple. The risk of being wrong about it was what kept us awake.
That is why we ran the year ourselves first.
What 550 Issues Actually Taught Us
Three things surprised us. None of them appeared in the early product roadmap. All three came out of using the system on our own publications week after week, watching where it worked and where it slipped.
1. The Voice Got Stronger Over Time
We expected the opposite. The intuition was that AI assisted writing would converge on a flatter average over a year of use, the way a copy of a copy of a copy gets paler each cycle.
The opposite happened. The voice profile got more specific over the months, because every new issue we shipped became another data point the system could learn from. By month six, the drafts being generated for our own briefings were tighter to our patterns than the drafts from month two. The system was learning forward.
This is the inverse of what most generic AI tools do. A generic model has the same statistical center on Tuesday that it had on the Tuesday a year before. A voice trained system pulls toward the writer over time, while a generic model pulls every writer toward the same shared average.
There is a paper by researchers at Carnegie Mellon, Microsoft, and Stanford called Not Just Novelty: A Longitudinal Study on Utility and Customization of an AI Workflow, published in 2024, that examines whether AI tools retain their value past the initial novelty effect. The authors describe the standard pattern. New technology adoption is initially high, then diminishes. Some technologies overcome the novelty effect through familiarization. Some don’t.
What the year showed us is that the AI Writers we trained on our own archives moved in the right direction across the months. We didn’t intend it to be a feature on the original roadmap. It became one only after we noticed it happening to our own publications.
2. The Editorial Decisions That Mattered Were the Smaller Ones
We thought the big calls would be the test, like which lead story makes the issue, which one to publish, which week to skip, whether the model would propose something we would actually want to send…
Those calls happened. Most of them went smoothly. The model surfaced candidates from the source intelligence engine, and our team picked the three or four we wanted to cover.
The places we kept editing were smaller. A specific phrase that did not sound like us. A transition that worked grammatically and felt structurally wrong. A subject line option that was technically optimized and emotionally flat. Our edits were rarely structural. They were almost always tonal.
This is what taught us how to design the editing layer. AI chat that takes plain language instructions (“make this section shorter,” “rewrite the opener in a more curious tone”). One click transforms for shorten, expand, formalize, simplify, persuade. Hot takes that generate a bold two or three sentence opinion on any story. The smaller editing operations had to be fast, because the smaller editing operations are where the year of work actually lived.
It surprised us how much creative satisfaction the writer maintained across all those edits. The relationship was collaborative in the way it had to be. The system did the labor. The writer made the calls. The work that arrived in the inbox felt earned.
The work felt earned because it was. Voice fidelity was the floor. Editorial judgment was the ceiling. We never crossed it.
3. The Mechanical Layer Was Larger Than the Math Suggested
Cagri made the dollar version of this case in his post on the real cost per issue of running a DIY newsletter. He’s right on the numbers. The craft side of the same observation was sharper, and it took a year to feel it.
The mechanical layer extends past the work that happens at 11 pm on Sunday. It runs through the whole week as the cost of being the kind of writer who shows up every Tuesday. Source monitoring. Image search. Subject line iteration. The little decisions about how to format a callout, where to break a paragraph, whether the third example should stay or get cut. None of these is meaningful work in isolation. All of them together is the difference between a publication that lasts a year and a publication that ends quietly at issue twenty.
The platform doesn’t intend to write your newsletter. We built it to absorb the mechanical layer so the writer could stay above it. The voice training is the foundation. The source intelligence engine is the discovery layer. The compose workspace is the editing surface. Underneath all of it is one assumption: the writer’s most expensive currency is the energy that goes into the next issue, and the system has to protect that energy if the writer is going to keep showing up.
Sit with that for a moment. Newsletter publishing is a long game. The operators who win it are the ones whose tools let them remain the writer they started out being.
Why a Year of Use Matters More Than a Demo
The newsletter industry is full of tools that work for thirty days.
Pendo’s 2025 SaaS retention benchmark report measured user retention across software products and found that the median software keeps about 39 percent of new users after the first month and roughly 30 percent after three months. For every hundred users who try a tool, around seventy stop using it within the first quarter. The category of newsletter tools is no different. You have probably tried five or six in the past two years. You’re likely still using one or two.
Most tools fail to stick because they were built around the demo. The year was somebody else’s problem.
The demo is a specific test. It selects for tools that look impressive in five minutes. It doesn’t select for tools that are still helping you on issue forty when the energy is low and the deadline is tight. The year is the test that matters, and the year is the one that does not happen until the user is already past the trial period.
We ran the year before the trial period existed. That’s what the past twelve months were for. The system has been edited and re-edited based on the things that broke, the things that surprised us, the things our team kept saying out loud during weekly reviews. Every feature on the platform was earned by some moment when one of our writers was about to ship a draft and saw something that needed fixing.
You can demo any AI writing tool in fifteen minutes. The honest test is whether you would still be using it in fifteen issues.
The trial we opened is built around exactly that question. Connect your archive. Generate one draft. Read it the way your most discerning subscriber would. If it sounds like the next issue you would have written yourself, the trial has answered the question. If it falls short, the trial has answered a different question, and you should walk away.
The proof step is yours. Your own publication, judged against your own editorial ear, is the only test that has ever mattered for this category.
What We Are Launching on Tuesday
On May 12, HeyNews will be officially launched. There is a Product Hunt page going live the same morning.
The mechanics of the platform are public on the features page. The short version is the version that came out in the year.
You connect your newsletter through the API for beehiiv, through OAuth for Kit, or through any public archive URL for Substack, Ghost, Mailchimp, Medium, or other platforms. The system imports your past issues and builds a voice profile in the background. While that is running, you can add the sources you trust through RSS feeds, social profiles, the Chrome extension, or by pasting any link into the source desk. When the AI Writer is ready, you generate a full draft in your voice. You refine through plain language instructions. You edit. You ship.
The trial is fourteen days or five generated drafts, whichever comes first. The full launch pricing is Starter at $49.5 per month for solo creators publishing up to 10 issues, Pro at $149.5 per month for 30 issues across 2 publications, and Team at $249.5 per month for 60 issues across 5 publications. Launch prices saves 50% on any plan until June 30; therefore, these prices will double after the launch pricing period ends on June 30. Add-ons cover unlimited revisions and additional issue or publication packs if your volume runs above the standard tiers.
The writer keeps editorial control. Always. On every plan. On every draft. We don’t send your emails for you. We don’t approve your subject line on your behalf. We don’t decide which story makes the issue. The system surfaces a candidate. You decide whether it ships.
How to Test This With Your Own Publication
If you publish a newsletter, the trial is designed as a single proof step. Three things happen.
First, you connect your archive. The connection takes under a minute for beehiiv and Kit. For other platforms, it takes the time required to paste the URL of your public archive into the import field. The system reads your past issues and starts learning your voice. You do not configure the voice profile by hand. You do not fill out a tone sheet. The archive is the configuration.
Second, you add the sources you trust. The platform extracts what it can from URLs already referenced in your back issues, and you can layer in additional RSS feeds, social profiles, or saved articles from the Chrome extension. The source intelligence engine scores incoming stories for relevance against your editorial patterns.
Third, you generate one draft. You read it the way your most attentive reader would. You decide whether it sounds like the next issue you would have written yourself.
That is the test. There is no other one.
If the answer is yes, you keep going. If the answer falls short, you tell us why. We have built the platform to absorb feedback at speed, because the year of dogfooding taught us that every issue is an opportunity to make the system more specific to the writer using it. We are reachable through the in-app feedback mechanism, the support email, and through a setup call if you would like to walk through your particular publication with a member of our team.
The launch is on Tuesday. The trial period starts whenever you are ready.
What This Year Has Actually Been
Calling the year a beta would miss what it actually was. The platform was ready. The year was a different kind of project. We were testing whether the system could hold up across the specific kind of relationship that newsletter publishing requires. The relationship between a writer and a reader, sustained over many months, mediated by an inbox, and dependent on a voice the reader carries in memory between issues.
That relationship was the real subject of the year. Every issue we shipped on the platform was a small bet on it. Some bets paid off. Some did not. The ones that didn’t led to the changes that made the platform what it is now.
You have been building the same relationship with your own readers. You know what it costs. You know how easily it can break. You know what kind of system you would trust to sit inside that relationship with you.
The trial on Tuesday is your invitation, especially if you have built something specific that your readers would notice if the voice slipped, and you want to keep publishing without burning out.
Connect your archive. Generate one draft. See whether the system you have just spent a year reading about can pass the only test that matters for your publication.
Start your 14-day free trial. Your archive. Your voice. Your judgment, on every draft.
It All Comes Down To…
- The platform has been used internally by our team to produce more than 550 newsletter issues across 10+ formats, every week, for over a year, before opening to outside operators on May 12. The system has been tested across the kind of long horizon that demos cannot reach.
- The principle behind the year is older than the term. Donald Knuth’s 1989 study of TeX argued that the designer of a new system must also be its first large scale user. Software industry practitioners have called this dogfooding since 1988. Most software companies have abandoned the discipline. We treated it as the only way to validate a tool that has to listen to a writer’s voice.
- Three things the year taught us became the design of the platform. Voice trained AI improves over time as the writer keeps publishing, while generic AI converges on a flat statistical average. The smaller editing decisions matter more than the big ones, which is why the platform invests in fast revision tools at the editing surface. The mechanical layer of newsletter production is what crushes operators, while the editorial layer is the part that has to stay with the writer.
- Most software products lose 70% of new users within ninety days, according to Pendo’s 2025 retention benchmarks. The reason is that most tools were designed around the demo cycle, while the year of real use was somebody else’s problem. The trial we are opening is built for the year, and the proof step we are asking for is whether the first draft sounds like the next issue you would have written yourself.
- The launch happens on Tuesday, May 12. Connect your archive. Generate one draft. Make the call yourself. The relationship you have spent years building with your readers should be the only authority on whether a system belongs inside it.
550 issues taught us this. The newsletter industry is full of writers who started something they loved, ran out of energy keeping the production layer alive, and quietly stopped publishing. The publication ended at issue twenty, fifty, or a hundred and ten, on a Sunday night that nobody outside of one inbox noticed. We didn’t want to be those writers. We didn’t want anyone reading this to be those writers either.
Tuesday is the launch. The platform is ready because we made it ready by living inside it ourselves. Come live inside it with us.
