Use Sanity as our CMS of choice for supporting editable content in the app.


Aug 23, 2023

DRAFT

[FlashLab]

#[mobileapp]

Technical Story: [https://linear.app/flash-pack/document/feature-kickoff-b89be987da40]

Context and Problem Statement

Tineri contains information for customers about trips which isn't stored in the adventure manager. We need a place for CX to enter this information where it can be served to our application.

Decision Drivers

  • Data input is a solved problem already - no need to reinvent wheels
  • We have to be careful with what the AM becomes if we keep adding to it
  • We want to be able to switch / tear this down quickly if we need to

Considered Options

  • Put it in the Adventure Manager
  • Use an external CMS (Sanity)
  • Build our own CMS

Decision Outcome

Chosen option: "Use an external CMS - Sanity", because overloading the AM with information seems like the wrong thing to do - we would need to support a whole new user base on this platform.

We decided to use an adventure-level document system in Sanity for simplicity.

We decided to have adventure images be hosted in Sanity without the concept of an Accommodation - this will come from the AM and use the Ratehawk ID as a foreign key. New image documents will be uploaded on each new use of a Ratehawk accomm in the AM.

Positive Consequences

  • Better UX in a short timeframe for CX users
  • Not re-inventing the wheel building a CMS
  • Not duplicating our entire data model into a CMS
  • We can delete this and use a different CMS whenever we want

Negative Consequences

  • We have to learn how to use Sanity
  • This data doesn't live inside the same system as the AM data

Pros and Cons of the Options

[Put it in the Adventure Manager]

  • Good, because all of our data is in the same place
  • Good, because we have control over what we build
  • Good, because the AM already contains concepts like our Adventures, departures, accomms, ect.
  • Bad, because a good CMS / data entry system is hard and time consuming to make
  • Bad, because it distracts from the current vision of the AM

[Use an external CMS]

  • Good, because extremely fast to get going
  • Good, because the user experience is great out of the box
  • Good, because we don't have to think about designing it
  • Bad, because the data doesnt live inside of the AM system.
  • Bad, because it's not entirely free. (but not expensive either)

[Build our own CMS]

  • Good, because we have full control
  • Bad, because time consuming
  • Bad, because great CMS already exist