Gishty is a newsletter platform with content that focus on the "Global Majority" or "Global South". The goal was to create a stand-alone newsletter platform for journalists who cover these regions (e.g. no dependencies like Substack, WordPress etc).
This project spanned a relatively long period (12+ months) however the core of the product, design, migration and engineering phases took place over around 6-months. It was launched in December of 2025.
Platform copy and content were provided by Sham Jaff. Design consultations (including the initial style and motif) were provided by Zlatko Najdenovski.
I defined the product scope, supported design, completed engineering, migration and scaling tasks, and took Gishty through to launch.
I'll go into detail on the product, engineering and UX challenges that I needed to balanced.
Product
Gishty was the next iteration of a previous newsletter entitled "What Happened Last Week". This newsletter, written by Sham Jaff, had accrued 20k+ subscribers over a period of 10+ years. However it was limited by it's branding, framing and that the entirety of the product took place through a Mailchimp subscriber list.
Some of the core product challenges were:
- How create a new brand, that expanded on the single newsletter
- How to create a platform that allowed for flexibility on the content types (newsletters, issues, interviews, posts etc)
- Maintaining a feeling of Gishty being an "independent" platform. This included extensive callouts to provide feedback, contribute to newsletters, or to say hello to the founders.
- How to deal w/ the disparate data (Patreon subscribers, Substack subscribers, Mailchimp subscribers, PayPal subscribers)
- How to paywall content in a respectful way
- How to come up with a UI that felt like an extrapolation of the previous newsletter, but left room for new newsletters
- How to ensure the entirety of the platform was GDRP compliant
- A hyper-focus on UX, due to the nature of the readership (less digital product experience, older demographic)
- SEO and SERP considerations, specifically around indexing, funneling and speed
Engineering
Due to the fact that the newsletter was started 10+ years earlier, the initial challenge was consolidating all the data. This required 3+ weeks, and included:
- Mailchimp subscriber and campaign data importing (+webhooks)
- Patreon subscriber and payment history importing (+webhooks)
- Substack data importing (only via CSV)
- PayPal subscription and transaction data importing (+webhooks)
Beyond the migration and consolidation challenges, here's what stood out from an engineering pov:
- Vendor data syncing (Mailchimp, PayPal etc)
- Linked Data and Google Rich Results considation, since the content is "news-worthy"
- Comprehensive admin area that allows for deep control of the site (including changing drip email sequence delays, internal analytics architecture, etc)
- Emailing architecture to allow for 1m+ emails to be sent monthly using AWS SES
- Transactional email redundancy (Postmark + AWS SES)
- Feature-flag system for control of more advanced and technical facets
- PayPal checkout for subscriptions and one-time payments
And I'll include a few gotchas:
-
The PayPal webhooks would periodically fail due to
unclear errors where PayPal claimed they couldn't verify
SSL/TLS handshakes. As a result, I had to build a
polling system to query for subscription and transaction
data. Ugly (and changes the "real time" nature of the
admin section), but the right trade-off considering
the amount of time that was invested into investigating
the issue.
As a side note: I'm guessing that the handshake failed once due to an incorrect Cloudflare security setting, and then that request was cached by PayPal's servers. - Mailchimp's API is quite inconsistent. Somtimes it returns relevant data, othertimes it'll simply respond with a 204 status code. This cause a lot of headaches, and required a fair-bit of abstraction.
And the biggest gotcha of all:
- Newsletters were being sent weekly to a batch of 20k+ Mailchimp subscribers. As a result of this, hundreds (if not thousands) of mail clients would "pre-crawl" links in the newsletter. This meant, hundreds - thousands of simulatenous requests (often within 30-seconds of one another).
This took the server down twice. To deal with this, two different solutions were implemented:
- Aggressive caching by Cloudflare (for non-logged-in users only), with systematic cache-release (hourly, upon specific CRUD operations, etc).
-
Support for hash-based paths with distinct URLs. e.g.
instead of website.com/upgrade/onassar@gmail.com,
website.com/upgrade#e=onassar@gmail.com
This was a new learning for me, and essentially allows the following: DNS edge-caching of certain pages (e.g. distinct upgrade paths like above), while allowing for the distinctiveness of the request to be interpreted on the client-side.
While there were many other gotchas, I'd say the three above were the most impactful.
UX
Gishty straddles a few different concepts: email newsletters, content site, news site. Because of this, there were a number of conceptions that users could have. Specifically, how do they "join" a newsletter platform? Do they subscribe? Join? Sign up? This was one of the challenges, and while it seems small, it was important to get both the copy, and flows that the copy suggest, right from the start. A decrease in conversion rates due to unclear copy or abrupt user-flows would have large issues down the line.
Here are some of the other UX challenges and considerations made:
- There were 20k+ existing subscribers in Mailchimp. How would they be "onboarded"? I defined an "alumni" flow that would take them through this process, including (but not limited to) legal agreements, newsletter subscription suggestions, password defining, and name submitting.
- Supporting one-click newsletter subscriptions in addition to conventional "sign up" flows. While both result in the same data structures (a user record, etc), they allow users to identify with the concept that feels most familiar to them: to either subscribe to the newsletter they're there to read, or to create an account on the platform (with the intention of reading authentication-walled content).
-
GDPR compliance: due to the locale of the platform,
strict GDPR compliance was prioritised. This included
(but was not limited to) "just-in-time" cookie prompting
(see here), a cookie
policy, static asset importing (e.g. no Google Font
hotlinking), a minimum-reliance on 3rd party vendors
(and ensuring those vendors were either GDPR compliant
or had publicly available DPAs), etc.
While on the surface, this may not seem like a UX topic, adherence to this principle resulted in specific UX flows, UIs and broadly data privacy & collection considerations. - "Geographic Entity Layers": These are UI layers that provide information and context about different countries (see here). The UX framing of this is that we wanted to provide more context for the countries that readers were reading about, but not require the user to leave the site. This required quite a bit of engineering (including finding reliable sources of data, compiling that data, creating an architecture for exceptions / overrides and ensuring GDPR compliance).
Summary
The intention with Gishty was to build a newsletter and journalism platform that covers stories and regions that are historically under-represented.
The initial challenges were focused on going from "0 to 1". Namely, nothing existing, to having this first version (and all the data integrity needs met). Now that this initial version has been launched, Gishty can be iterated on quicker, and hopefully provide readers with an alternative source of news and information.
Feedback
If you've got any questions or ideas, feel free to reach out at: onassar@gmail.com.