The problem
A sponsorship pitch is a property's deck (a club, an event, a league) with a prospective sponsor's logo placed throughout: on the cover, on the kit, on the pitch-side boards. Every pitch meant copying the master by hand and placing the logo slide by slide. The logo files were spread across email threads, old decks and downloads folders, so every pitch began with a search, and the same placement came out slightly differently each time.
The key decision
Build the registry before the generator. The first version did one thing: it gave every sponsor logo a permanent URL that fits itself into whatever box a slide gives it. That went into real decks before anything else was built. Generation came a week later, and it was only possible because the logos were already in one place.
In demos, the library got a stronger reaction than generation, so the library leads.
The architecture
Five layers, each with one job:
- Registry (Firestore): sponsor brands and their permanent slugs, the properties being sold, which Slides.com deck is the master for each property and format, a log of every deck generated, and who has access.
- Assets (Vercel Blob): each sponsor's logo in three variants: colour, white and black.
- Render (Next.js on Vercel): logo URLs that look the brand up by slug, so no deck ever points straight at a file.
- Generation (Slides.com API): builds the sponsor's deck from the property's master.
- Measurement (Google Analytics): which decks were opened, and how far each viewer got.
The engine
A rep picks three things: the sponsor, the property and the format (a one-pager, a teaser or a full sales deck). The engine reads that property's master live from Slides.com, fills every placeholder with the sponsor's logo and name, and saves the result as a deck with one public link. Where the master puts a logo onto a photographed surface, the engine calculates the perspective so the logo sits on that surface at its own proportions.
Running it again for the same sponsor and property doesn't create a second deck. It updates the existing one and rewrites only the slides that changed, so the link the sponsor already has keeps working.
What's designed, and what's automated
The engine doesn't design anything. People design every master, and every logo placement (where it sits, which surface it wraps onto) is set once, on the master, in a placement editor. That's the decision that scales: every sponsor gets it without anyone rebuilding it.
Judgment calls
- Links never break. Renaming a brand keeps the old slug as a permanent alias. Decks point at the registry, not at the file, so a corrected logo reaches every deck already sent.
- Masters are read live, not copied. A cached copy goes stale without warning, and a rep has no way to tell. A master caught halfway through an edit is rare and fixed by running generation again.
- Logos are images, not embeds. Embedded logos broke in the PDF export once a rep had opened the deck. Images don't break, so the perspective is calculated at generation and saved as a plain image transform.
- Nothing unbranded reaches a sponsor. A master with no placeholders is flagged when it's registered and refused at generation.
- Two roles, approved one person at a time. Reps generate and send. Admins look after brands, properties and masters. Signing in only files an access request.
- Scoped to decks Elevate controls. Where a client needs editable PowerPoint, the deck stays manual. That was deliberate.
- Trained people, not just shipped a tool. The rollout workshop covered Slides.com basics before the engine itself.
Built on a moving platform
The Slides.com API is in beta, and it changed twice in the first two months of the build. The fields the app relied on were renamed on 17 August. On 17 September, the endpoint for writing a whole deck was removed. Decks are now written one slide at a time, within a limit of 30 requests a minute shared by the whole team. That's why regeneration compares each slide first and writes only what changed.
Outcome
Rolled out to the KSA sales team in September 2026 through a hands-on workshop, with leadership attending. [Once you have them: decks generated, active reps, time from request to sent deck.] After a deck goes out, the analytics layer shows which decks were opened, how far each viewer got, and which were sent but never opened. That last list is the one a rep acts on.
What it doesn't prove yet
It works in one market. Whether it scales across MENA, and who owns it beyond KSA, are still open questions. The analytics count views but can't say who viewed: each deck has one public link, so every viewer is anonymous, and anyone blocking trackers never shows up. The numbers are a minimum. It also depends on a beta API that has already changed twice. It was built alongside the day job.