It did not start as a product idea. It started with a month-end close, four invoices still unsent, not because the work was missing but because reconstructing what had been done for each client meant opening six different tools. The calendar, meanwhile, was a spreadsheet nobody had opened since the second week. GoFeed came out of joining those two things.
The month-end that started it
Before we wrote a line of code we ran social accounts for clients. The work looked like any small agency's: pieces filmed and written, scheduled, approved in a loose chat thread and published; comments answered from a phone at eleven at night; a report assembled on the last Friday by pasting screenshots into a deck.
None of that was done badly. It was done in separate places, which is a different problem and a worse one, because a mistake gets corrected and a dispersion gets inherited.
The trouble never showed up at publishing time. It showed up on the 28th. Sending four invoices meant answering a question that sounds simple, what was done this month for this client, and the answer was spread across a scheduler, a spreadsheet, three conversations and a shared folder. Each invoice cost half an afternoon of archaeology. Four unsent invoices were not four unpaid ones: they were four jobs done that nobody had finished counting.
The calendar told the other half of the story. It was accurate on the day it was written and fiction by the 12th, because one client moved a campaign, another asked for something urgent, and the sheet did not update itself. Past a certain point nobody opened it, and a plan nobody opens is not a plan, it is a document.
Six tools, and what fell between them
| What we had | What it was for | What it left out |
|---|---|---|
| A post scheduler | Getting pieces out on time | Who had approved them, and when |
| An analytics dashboard | Seeing the numbers of each network | What to put in a report for a client |
| One inbox per network | Answering comments and messages | Which ones were still unanswered |
| A spreadsheet | Planning the month | Finding out about changes |
| Invoicing software | Issuing with our series and our VAT | What had actually been done that month |
| A shared folder | Keeping the files | Who had the latest version |
The expensive part of a set like that is not the sum of its subscriptions, though that adds up too. The expensive part is the handover: the data you copy from one tool into the next so the next one can start, and the hours that disappear there and never appear on an invoice afterwards. If you are doing that arithmetic right now, the version with figures in it is in the social media stack cost guide.
There is a second order effect we were slow to see. When every tool has its own idea of what a client is, none of them can answer a business question on its own. The scheduler knows connected accounts, the invoicing software knows legal entities with tax numbers, and the spreadsheet knows names typed by hand. Three vocabularies for the same person, and no automatic way to cross them.
The first prototype, in fact, published nothing at all. It was a screen that answered the question from the 28th by reading what already existed in the other tools, and it lasted three weeks: every integration returned its data in a different shape and none of them knew which client the data belonged to. That is where we understood that the problem was not in the screens but underneath them.
The decision underneath: one list of brands
The first thing we built was not a calendar and not an inbox. It was the data model: a workspace, which is the thing you pay for; a client, which is the company you work for; and a brand, which is what you publish for and which the connected accounts, the link page and the monthly report mode all hang off.
It sounds like an internal detail and it is the opposite. Making the brand the unit is what lets the calendar, the analytics, the inbox and the quote all talk about the same thing without anybody retyping a name. The month of work and the invoice for that month stop being two stories somebody has to reconcile by hand on the 28th. Why that decision shapes the rest of the product is told in full in one workspace, many brands.
That is also the answer to the question we get asked most: why publishing and invoicing live in the same product. It is not a platform strategy. It is that both come out of the same month of work, and keeping them apart means retyping what the other half already knows.
What we decided not to build
The decision people ask about most is the one that took us the least time: GoFeed does not write your content. We do not generate captions and we do not generate images, and there is no button that drafts anything for you.
The reason is not purism. It is that text generated without the brand's context is text somebody has to rewrite, and a tool that creates work for its user is solving the wrong problem. What we did build instead is a door: your own assistant, Claude or ChatGPT, can work inside your workspace with the permissions you grant it, read what you can read and do what you let it do. The writing stays yours, and so does the judgement.
Everything in this article happens in one place in GoFeed.
Try it freeWhat the decision cost us
An origin story with no costs in it is not a story, it is a brochure. These are the four we paid and go on paying.
There is no free plan. The trial runs fourteen days, card required from the start and nothing charged until day 15. A workspace that does not continue goes read only: you can sign in and look, the connected accounts are released and whatever was scheduled is cancelled. Two weeks after that the Drive and the file library are purged, with a warning three days before and another the day before; the data, the history, the invoices, the reports and the link page stay. It is an ending with a date on it rather than a free floor, and along the way we lose everybody who wanted a tool for one account without spending anything, which is a lot of people.
Not every module is for everybody. The client portal, the monthly PDF report and the commercial documents only make sense when there is a third party contracting the work, so they belong to agency workspaces. A creator sees a smaller product. We could have shown those modules to everyone and charged for them anyway; not doing it costs conversions and avoids a much bigger disappointment two months in.
The platforms' limits are our limits. We publish and we read through the networks' own APIs, so their rules govern: a comment allows exactly one private reply, a message has to be answered inside the 24 hour window Meta imposes, demographics exist on two networks and nowhere else. When one of those rules changes, it changes for us the same day.
We are a young product. We do not have the decade of odd cases already solved that the long established tools have, nor the community that answers at eleven at night. What we have is a product that does something the others do not, and the honesty to say which part we are not competing on yet.
Who it makes sense for today
For an agency with clients, because that is the case it came out of: a calendar per brand, the client signing into their portal to approve, and the invoice going out afterwards with your own number series and your own VAT, the value added tax charged in Spain. For a creator running their own brands, who gets the top half of the product and none of the client machinery. And for a company with an in-house team, which has nobody to invoice but does have people who review before anything is published.
The workspace kind is chosen when the account is created and can be changed later. What changes with it is which modules that workspace can hold, because not all of them apply to all three. How that turns into tiers, and what each one carries, is on the pricing page, which reads the live catalogue; the reasoning behind charging per workspace rather than per seat is in how we set our pricing.