Issues that assemble themselves
It is just scattered across forty tabs and a notes app. Press Factory keeps the articles worth sending in one place and assembles them into an issue you can review on one screen, instead of rebuilding the whole thing every week.
Station 03 of the Factory Suite · Built on the stack running funnelfactory.ai
The cost of starting from scratch
A newsletter assembled by hand costs you the same three things every time you sit down to send one.
Cost · The week
Copying links, pasting summaries, fixing the formatting that broke again. The part only you can do, deciding what is worth someone's attention, gets whatever is left.
Cost · The good material
The best thing you read all week was in a tab you closed. With nowhere for candidates to live, the issue gets built from whatever you can still remember on the day.
Cost · The habit
When every issue is a blank page, the cheapest option is always to not send it. Two skipped weeks is how most newsletters quietly end.
A blank page every week · the issue you did not send
What you get
Candidates
Material collects against your profile as it is found, so the issue starts from a list instead of a blank page and an hour of searching.
Curation
Every candidate carries a status. You move down the list once, and what survives is what the next issue is built from. No second inbox to maintain.
Assembly
Drag the accepted articles into an issue and the formatting is already handled. The builder shows the pool and the issue side by side.
Profiles
One source pool, more than one newsletter. A profile decides what gets collected and who the issue is for, so a second audience is not a second tool.
Sources
Domains you do not want are excluded at the source, so the same aggregator noise stops arriving instead of being skipped by hand every week.
Export
A finished issue comes out as HTML you can paste into the tool you already pay for. Nothing here holds your list hostage.
Who built this
Press Factory started as a tool for one publisher who kept finding good material all week and then, on send day, could not find any of it. The pattern was always the same: plenty of raw material, no place to put it, and an hour of reassembly standing between the reading and the sending.
So the first version did one thing. It gave candidates somewhere to live, and it made the decision to keep or drop take a single click. The assembly stopped being the job.
It is now station 03 of the Factory Suite, built on the same stack as funnelfactory.ai , which is in production and serving real traffic today.
The same Terraform, the same deploy pipeline and the same isolation model already carrying funnel-factory in production.
Articles, issues and subscriber profiles live in your own Postgres instance, and an issue exports as plain HTML you can take anywhere.
Press Factory assembles the issue. Where you send it from stays your decision, and the export is designed for the tool you already use.
The plan
No template to design, no importer to configure, no migration off the tool you already send from.
Step 01
Set up a profile describing the audience and the subject. That is what decides which candidates are worth collecting for you.
Step 02
Work the candidate list once. Accept the good ones, drop the rest, and the accepted pile becomes the material for the next issue.
Step 03
The issue is already assembled from what you kept. Read it once, reorder anything, then export it to the tool you send from.
In plain terms
Press Factory is a curation and assembly tool for people who send a recurring newsletter of things worth reading. It keeps a pool of candidate articles, gives each one a status you control, and builds an issue out of the ones you accepted. The writing that is yours stays yours. The part that is clerical stops being your problem.
The pieces are kept separate on purpose. An article is one thing, the profile that decided to collect it is another, the issue that includes it is a third, and the export format is a fourth. That sounds like an implementation detail, and it is the reason you can restructure an issue without losing the article history behind it, or add a second audience without duplicating a single source.
An issue is data before it is a document. It is a list of articles in an order, which is what makes it safe to reassemble, re-export or re-order without anything being retyped. The HTML comes out at the end; it is not the thing you are editing.
Everything lives in your own Postgres database, provisioned per deployment rather than shared, and every issue exports as plain HTML. There is no proprietary format holding your back catalogue and no export fee for leaving.
Sign in if you have an account. If you do not, ask for one and we will set your first profile up with you.