• String
  • Posts
  • CherGPT: Product Development Logs

CherGPT: Product Development Logs

Enabling over 5000 interactions with AI through supporting 30+ teachers in one week

This document is a reflection but also an attempt to write product requirements document (PRD) in order to properly document the thought process behind it. This is easily one of String's more popular digital products and thought it was worth unpacking why it worked:

PRD infographic taken from productplan.com

From strangers to friends crazy enough to burn weekends and attend weekday 10pm+ meetings to build this. Pardon the singlet.

Speed matters. The telegram bot was deployed within the same day of this survey:

Beyond speed, polls were administered as a quick way to validate user needs and pain points. Given that the benefits of AI are rather abstract, I thought it was valuable to put AI in the hands of more teachers so they can come to appreciate and even integrate it in their line of work since we do a lot of repetitive and time-consuming content generation.

Objective and goals

  • Introduce more teachers (including my parents) to risks and strengths of artificial intelligence (AI) - namely large language models like ChatGPT by reducing friction in accessing it and providing a clear use case to ease adoption

  • Gain visibility over what students ask language models like ChatGPT - can knowledge of this improve teaching and learning? This is a genuine unknown but as per the survey above, there is some interest in this.


  1. Mobile friendly or optimized; immediately deployable/ low setup - end-users (teachers) should be spared any technical setups. Both teachers and students should be able to access it on mobile.

  2. Integrates well in current communications channels - Telegram works for older students who already use it as a core part of their communications. But for schools with personal learning devices or teachers who simply have never encountered telegram, CherGPT has to be platform agnostic and easily accessible.

  3. Synchronous training and support - not a product feature per se but there is going to be an entire segment of user education that is necessary in order to position the product appropriately

  4. Familiar backend - no need firebase or postgresql or sqlite. The end-user needs to be able to interpret and process interactions with a gentle learning curve. We chose Google Sheets and also csv export to empower the end-user.

UX Flow and Design Notes


Basic distribution and technical dependencies of the Telegram Web version. Writeup of the web version to come at a later date as a revision of this article.

Training workshop on how to design prompts in collaboration with UX designer, Sebastien Kun

System and environment requirements

The only main requirement is internet access which most schools are able to provide (and most users have their own data plan)

Assumptions, constraints and dependencies

A. Assumptions

  • Teachers care about using AI (validated by running Tech Talk for Teachers with a sustained focus on AI; the most recent one held on 19 Jan 8pm just purely focusing on prompts for ChatGPT had over 100 registrants and 60 eventual participants)

  • Telegram as a first-cut-MVP (minimum viable product) was able to gain enough traction and interest to buy time for product improvements. This was a gamble but I actively prioritized speed of development, having some familiarity with Telegram bot development myself. This paid off and enough interest was generated in the community.

B. Constraints

  • Server and speed. The development team is extremely conscious about load bearing of the free-tier or streamlit and how much concurrency a single telegram bot is able to support. Both the web and Telegram version involve some lag. We are a fully volunteer run team with no financial resources so we can't exactly get blazing servers.

  • Team and support constraints. Scaling any product involves some manual work. This involves addressing user tickets (emails), messages, requests, queries and all. I try not to drag in-service teachers into dealing with support requests and essentially handled all of it myself - from form signup, account creation and eventual programmatic email notification.

C. Dependencies

  • We are chronically reliant on openAI's API key and credits to the point where we concede, at the point of user signup, that at any point in which it is too expensive, our service may prematurely stop.

  • Streamlit and Telegram as a dependency is not as drastic as the reliance on openAI

On the whole, this was an extremely exciting start to the year and convinced me of a few things:

  1. Volunteer-based EduTech initiatives with teacher involvement are possible under very specific conditions. This is truly a right place right time moment to the point where I had to tell my fiance: I need an hour to build CherGPT telegram bot as a proof of concept.

  2. Having a realistic product development roadmap that anticipates user needs. The very first MVP on Telegram was a simple deployment. We let minor known issues sit (e.g. /start triggering gibberish as the first message). Web CherGPT was in the works because we already knew that not everyone used Telegram and especially younger students might appreciate just a low-barrier web access instead of having to be onboarded to Telegram.

  3. Collaborating, collaborating, collaborating. I could never have done this alone and would most likely have just choked and died deploying 50 Telegram CherGPT bots. Having a team meant I could also think ahead and plan for other products beyond a learning assistant; handle partnerships or just pushing various angles of the product instead of bearing the brunt of both technical development and community building. I can only express thanks, thanks and more thanks for all the support in spite of us having family commitments, work commitments and all.

What is next?

  • For web CherGPT users, we plan to introduce analytics within the dashboard of the web-app itself.

  • For Telegram CherGPT users, we will write scripts to process analytics using Google Sheets as the backend.

In both instances, analysis should be mostly automated and end users can then decide to act based on the interpretation of the insights rather than fretting about how to run their own formulas to process data. For advanced users, they can also then run their own analysis.

String started the year putting AI in the pockets of teachers and my own parents. This is a small win but I cannot be prouder.

Thanks mum and dad for being my beta users before releasing it to teachers in MOE.