Count the feed before you design from it: 64 clinic posts that rewrote a brief

If the brief is an Instagram account, read every post and count three things: which services appear, in which language, and what each post asks the reader to do. The count will disagree with the brief. When it does, our view is that the count should set the scope, because it is ten months of what the business actually did, while the brief is what it planned to do.

Here is the project where we learned to do this first, and what each tally changed.

The brief was a folder

A private clinic came to us without a spec. No sitemap, no feature list. The brief was a folder of Instagram videos and screenshots, plus the two services the owners named as their growth drivers.

That kind of material usually becomes a five-page brochure site. Before we drew a single screen, we read all 64 posts the account had published over ten months, and counted.

Three tallies

Feed: 64 posts over 10 months

By service (one post can name several)
  the two "growth" services ........  2 posts between them
  a service nobody had prioritised .. 40
  diagnostics ....................... 49

By language
  languages the account advertised .. 3
  posts in one of them .............. 62 of 64
  posts in the third ................ 0

By call to action
  posts asking the reader to book ... 29
  of those, with a link or a way to book: 0
  where the funnel ended ............ direct messages

None of these numbers needed software. They needed someone to read every post instead of the best ten.

What each count changed

Services. The two services the owners wanted to grow appeared in 2 posts between them. Diagnostics appeared in 49. The count did not decide for the owners what to push. It put a number on the gap between the plan and what the account had told patients for ten months. Thin input, a decision-grade read, and the call stays with the people who run the clinic.

Languages. The account advertised three languages. 62 of 64 posts were in one of them, and the third had no content at all. A translated site assumes the content exists in every language and only needs converting. It did not. So the scope became a bilingual content model, where each language is authored and managed on its own terms, instead of a site translated into three.

Calls to action. 29 posts asked the reader to book. Not one gave them anywhere to do it. Every booking conversation ended in direct messages. So the scope became booking against the clinic's real availability instead of a contact form, plus published prices.

The same assumption, inside a form

The feed was not the only place an unchecked assumption about the market was hiding. The original doctor profile had three hardcoded checkboxes for the languages a doctor speaks. Three boxes is a guess about who walks in the door.

We replaced them with a search over a shared dictionary of about 45 languages, labelled in both site languages.

before:  doctor.languages  = three fixed checkboxes

after:   doctor.languages  = any subset of a shared dictionary (~45 languages)
         on save           -> validated against the full dictionary
         public page       -> labels read from the same dictionary

One source of truth for the admin form and the public page. It is the same lesson as the feed count, one level down: the form was a market assumption nobody had checked.

What it cost

One day of reading. 1,917 lines of research across twelve documents, before the first line of code. We think that day was the cheapest one in the project, because every later decision about structure, languages and booking leaned on it.

Why this matters to a buyer now

The brief that arrives at a studio is changing. Under Upwork's August 2026 hiring report, an agency owner described what replaced the small fixed-price job: a much larger integration where the client opens by saying they are not sure what they need. Typing went to AI; specifying is now the work.

Buyers are also starting to test for this. In one public thread, a small-business owner with no coding background posted a brief and got about a dozen replies. The polite offers to talk in DMs went unanswered. The only enthusiastic thanks went to the replies that said the brief was wrong: build one multi-tenant system, not a separate agent for every organisation. Buyer guides from implementation firms now recommend asking a partner what it would challenge you on, based on what it has seen so far.

Our reading: counting the client's own feed is a way to push back on a brief with the client's own data, not with our taste. It is hard to argue with your own 64 posts.

The 15-minute version

You do not need us for a first pass. This is the rough version we would suggest to any owner whose brief is their account. Skim, do not read.

1. Open your account. Go back about ten months, or 60 posts.
2. For each post, write one line:
     service | language | what it asks the reader to do
3. Count each column.
4. Put the counts next to your brief and ask:
     - Are the services you want to grow the ones you actually post about?
     - Is every language you advertise one you actually publish in?
     - Every "book now": where does the reader land?
5. Any column that disagrees with the brief is a scope question.
   Answer it before a designer opens a file.

FAQ

Isn't the brief what the client wants? The brief is the plan. The feed is a record of what the business did for ten months. Both matter. The count does not overrule the owner; it makes the gap visible, and the owner decides with a number in front of them.

What if the account is new or small? Then the count says less, and we would say so. The method needs enough posts to show a pattern. Here, 64 posts over ten months was enough.

Does counting replace talking to the client? No. It gives the conversation something concrete to start from. "Your growth services appear in 2 of 64 posts" is a better opening question than "what are your priorities?"

Why not translate the site into all three advertised languages? Because there was no content in the third, and at most 2 of 64 posts in any language besides the main one. In our view a translated site would have shipped pages nobody wrote for and nobody would keep up. A bilingual content model matched what the clinic could actually maintain.

A related case

The same habit, applied to a dataset instead of a feed: RE Intelligence, our analytics product for the Dubai real-estate market, has its own module, the Pre-Launch Signal. It tracks developer land purchases of 3,000 to 100,000 m² as an early sign of future supply. The case is at iloblique.com/re-intelligence.

If you have something worth building, we'd like to hear about it.

Sources

• Our clinic portal project (client under NDA, unnamed): feed audit and research notes; doctor-profile language dictionary change.
• Upwork, August 2026 hiring report, and the public comment thread under it.
• A public buyer thread on finding someone to build an AI agent, and published implementation-partner buying guides (2026).
• RE Intelligence case page, iloblique.com.