Nobody was going to prioritise this feature. I fixed it myself.

The context

Tempo organises clients' financial and day-to-day admin over WhatsApp: payments, purchases, quotes, bookings. The people doing the work are human assistants, backed by AI.

When a request had several options for the client to choose from, like products, quotes or flights, the assistant pasted the link into a template feature and it generated a PDF with the options.

When the link came from a site that allowed scraping, the technique of pulling price, image and description off a page automatically, it worked straight away. Trouble started when the site blocked it, and plenty of them did.

A PDF almost nobody could edit quickly

With scraping blocked, the assistant opened a generic PDF editor and built the template from nothing. Create each text box, paste the information, pick the font, position everything. If the product name ran long, the layout broke and she rearranged it all over again. A simple template could take more than 30 minutes of pure formatting labour.

And the worst of it wasn't the annoyance. That time came out of the part that matters to the client: researching the right product, comparing options, understanding what he needs. The assistant sat there formatting text instead.

Looking at the roadmap, this feature was nowhere near a priority. Improving the old system meant real engineering effort for something that moved no metric the team watched.

What I chose not to do

There were two obvious routes and I dropped both.

The first was fighting for a slot in the engineering queue. I'd have lost that fight, and rightly so. A team of 12 has better things to do than incremental work on a feature that moves nothing.

The second was improving the old system. Also no. The problem lived in the format, and the format was PDF. Fixing the manual assembly of a static document still leaves you with a static document.

So I threw the feature away and built a new one myself in Lovable. The only engineering dependency was a single ask: have the feature's icon in the Cockpit redirect straight to my app.

The price of that choice: maintenance became mine. When a bug turned up after launch, I was the one going into the code, fixing it and shipping. That works while I'm here, and it's a dependency the company took on along with me. If it had been a critical system, I wouldn't have done it this way.

From paste a link and pray to a real builder

The new version handled the easy path and the hard one, and went past what the old feature could do.

• Automatic layout

  The app repositions and resizes everything on its own, even with long text. The assistant only fills in the data. No text boxes, no fonts, no manual rearranging.

• Link or fast manual entry

  Pasting the link still works when the site allows it. When it doesn't, filling it in by hand stopped being a half-hour punishment.

• Multiple photos per product

  Paste the address of each image and a full carousel comes out in very little time.

• Custom fields

  For specific quotes, like "does this car wash include X or not?", you can add a field just for that question. The old PDF had no such flexibility.

• CSV import in table format

  For long lists, like flight options, you can paste a CSV and generate the template as a table, which reads faster than cards.

And the output stopped being a PDF. It became an interactive link: the client picks the option right there, and the choice comes back to Tempo's WhatsApp on its own. The assistant sees the decision without having to ask again.

What changed for the people using it daily

Small on paper, large at scale

Saving time on one template sounds like nothing. Except each of the 30 assistants generated around 2 templates a day, which lands at roughly 300 templates a week across the whole operation.

What I'd do differently

I instrumented almost nothing. I know how many templates get created. I don't know how many clients opened the link before deciding, or how many purchases came out of it, and I have no direct before-and-after comparator. It's the same failure I made on the payments case, and it's the thing I'd most change in my own routine: ship the tracking on the same day the feature ships.

I should have measured both paths before building. One week counting how many templates fell into the manual flow would have turned the number above from an estimate into a measurement, and it would have cost almost nothing.

My strongest evidence here is qualitative, and I'd rather say that than inflate. The assistants' recurring complaint about this feature simply stopped, and unprompted praise showed up in the internal channels. That's a signal. It isn't proof.