A Mediterranean restaurant runs on weekly specials. Mezze night Thursday, slow-roasted lamb Friday, a Sunday brunch built around shakshuka and labneh. Each one is a small post on a social grid, each one needs a dish name in Latin and sometimes Arabic or Hebrew script, each one needs a price and a date. The kitchen finalizes the line at 16:00, the manager has three hours to get the social posts out.

The data is already on the website. The mezze board is in the menu CPT. The price is in an ACF field. The hero photo of the fresh laffa coming off the saj is in the media library. The typing is done. The gap is between that data and a 1080x1080 PNG sized for Instagram.

SleekPixel renders that PNG on save. The mezze night post saves, the card lands in uploads with the dishes and the price already set, the front-of-house team downloads it from the Gutenberg sidebar at 17:55 and posts. The grid stays consistent across a season because the template doesn't change even when the line cook does.

A Mediterranean restaurant's social grid is one of the few places customers can confirm what the kitchen is doing this week. The mezze rotates, the brunch leans on whatever the farmers' market had on Sunday, the grill changes with the lamb supply. That should read as an active, considered kitchen, but it reads as scattered when the cards behind the posts are designed by whichever manager is on the floor that day.

The cards drift in type, in spacing, in how the dish names are punctuated. The way to keep the grid considered is to remove the design step. The kitchen types the mezze list into the menu post once.

The card falls out of that post when it saves. The grid looks like one restaurant across a year of changing dishes because the template never moves, even when staff turn over and seasons change.