Turning a listing into a brochure without a ticket.

Kendal is a CRM for real estate brokerages in Dubai. Agents keep their listings in it, and Kendal pushes them out to Property Finder, Bayut and Dubizzle.

So the listing already lived in Kendal: price, permit, photos, who’s allowed to see it. The brochure didn’t. It got made somewhere else, by someone who had never opened the listing. I spent about ten weeks fixing that.

The agent asks the admin. The admin briefs a designer, in-house or at an agency, who opens Figma and starts from the brand guidelines. The designer doesn’t have the listing, so someone explains which details go in and how fancy this flat should look.

Drafts go back and forth. The admin keeps a master copy. Brokerage owners paid for all of it, on top of a CRM that already had every fact in it.

We already had brochure links for sharing online. Links are great until a client asks for a PDF. Plenty still do, and brokerages wanted that PDF to look like it came out of their own studio.

So the PDF lives where the link already did: in the listing’s Share menu. The agent picks whose details go on it before the editor even opens.

Before writing code I went through real Dubai brochures, cheap and expensive, and sat in on calls with brokerage owners, admins and managers alongside our customer success team. Then I designed like someone who lives in Figma.

Open a listing, hit Share, pick Download as PDF, and the editor arrives with everything filled in. Then you change what’s yours to change.

Price, rent, permit number, plot area, amenities and furnishing are locked. They come straight from the listing. If the price is wrong it’s wrong in the CRM, and that’s where it gets fixed. The description and photos start from the listing too, but once they’re in the brochure they belong to it.

Whose face goes on it

Version one always showed the listing owner. Then customer success explained how teams actually work. A senior agent owns the listing, and a junior agent runs the viewings and sends the brochure.

Now the owner is preselected and anyone allowed to share the listing can put their own photo and number on it. Ownership doesn’t move.

Offices, not free text

Brokerage details started as free text. Fine for version one, wrong soon after. One brokerage can run offices across the city under one organisation, so admins now set them up in settings and agents pick from a dropdown instead of typing an address from memory.

Someone had to decide what brochures look like. Agents are busy, and plenty of them treat the CRM like a gym membership. Admins love setting things up. So admins got the job.

The feature stays switched off until an admin saves at least one preset, a layout plus a theme. Before that, agents don’t see the PDF option at all. Brokerages got brand control, and nobody had off-brand versions of the same flat floating around WhatsApp.

It wasn’t frictionless. One person had to finish one setup before anyone else could start, so our customer success and training team walked the admins of the major brokerages through it during onboarding.

There are three layouts, each in a single-page and a multi-page version, with system themes and custom colours on top. Custom colours get a contrast check, because someone will always try yellow on white.

Single page made everything harder. Fewer photos, a tighter fact sheet, and the agent and brokerage squeezed into a band at the bottom.

My first instinct was a character limit. Then I switched themes. The same paragraph takes a different number of lines in every theme’s font, so a limit that fits one template spills out of the next. I tried letting AI split the copy into columns. It can’t see the page, so it guessed. React PDF was too stiff for the layouts I wanted.

So the rendered page measures itself, and the editor tells you what that means. On the overview page the description and highlights share one box. Write too much and the highlights get pushed out. The editor says so, and you decide which one matters more for this client.

Amenities had the same problem from the other side. A listing can carry up to 28, and the grid changes its rows and columns with the count, which changes how much room the paragraph above gets. The two are measured together so nothing overlaps or gets cut.

AI turns the agent’s saved description into brochure copy sized for the layout, writes highlights and captions the photos. I trusted it too much at first. Some pages were fully AI-controlled, and with a thin listing it filled the gaps with confidence it hadn’t earned.

Now everything it writes is editable, and pages still work when highlights are missing. The copy also has to suit the property. A studio by the metro shouldn’t come back as a breathtaking sanctuary of refined living.

My favourite bug: during testing we uploaded a completely black image. The caption came back “unlit room”. We laughed, then changed the system prompt.

The first time a brochure opens, preparing copy and captions takes 3 to 5 seconds. Nobody should wait that long twice, or pay for it twice. Finished copy is saved once per listing for the whole organisation, and only regenerates when the listing content it came from changes. Captions are stored per photo, so adding one photo captions one photo.

We shipped export through the browser’s print dialog. Chrome was fine. Safari, around 15 to 20 percent of our sessions, was not.

WebKit doesn’t do CSS multi-column in print, so the two-column overview collapsed into one clipped column. The soft gradient behind photo captions printed as a solid black box. Every photo came out black. Neither showed up in the on-screen preview.

Then there were people who couldn’t find Save as PDF in Safari’s print sheet at all. Fair: hardly anyone saves PDFs anymore. After enough confused messages I added a short guide that shows up only in Safari, right before the dialog.

Counting a download you can’t see

The print dialog belongs to the browser, so I never learn whether someone pressed Save or Cancel. Counting clicks would count every cancel. So each attempt carries a fingerprint of what’s on the printed page plus the editor session. Print the same brochure twice and the second is flagged as a repeat.

Taking the browser out of it

The real fix is to stop relying on the browser’s print engine. I’m working with our backend team on rendering the PDF in headless Chromium on GCP. The editor sends the settled brochure state, the server renders the same components, and you get a download link. Every browser gets the same PDF.

My guess is that the 2 percent that didn’t finish are browser print problems. I can’t prove it yet. Cloud rendering will tell me if I’m right.