Feasibility of appsheet project

[Kami_Barut]

Hello (newbie here),

I am considering using appsheet to build a mobile app prototype MVP to be shown to potential investors.

The app would allow hairdressers clients to (1) see the addresses and (2) see the contact infos of hairdressers (working both in salons and privately) as well as (3) comment and (4) rate performances.

The three spreadsheets and associated fields would look the following:

1. cities_tbl (i.e: spreadsheet):

associated fields: city_id (primary key), name

2. hairdressers_tbl (i.e: spreadsheet):

associated fields: hairdresser_id (primary key), hairdresser_type (store or private), name, address (can be null if hairdresser_type = private), phone_number,
opening_ days_hours, website_url, city (foreign key), services_list_prices, photo_1, photo_2, photo_ 3, photo_4, photo_5, photo_6, average_rating_grade, review_id (foreign key) , hairdresser_code (unique)

3. reviews_tbl (i.e: spreadsheet):

associated fields: review_id (primary key), hairdresser_id (foreign key), customer_lastname, visit_date, hairdresser_code (unique for each hairdresser_id), comment, rating_grade

I do not plan to use the sign in option at first, meaning that a customer’s comment and rating grade submitted through a form would only be validated if she has received the unique hairdresser code directly from the worker.

I would be grateful if someone could let me know the difficulties and stumbling blocks I am likely to face.

Thank you for your time.

KBW

[Kirk_Masden]

Hi @Kami_Barut! Welcome to the community!

I’m not an expert but I would expect your app to be fairly easy to build with AppSheet. Viewing data (1 and 2) should be quite easy to set up. In regard to collecting comments, I would guess that you should make one more table to collect comments and that each comment record would have data about what was being commented on but whom and when. Rating performances (4) should be very easy to do with AppSheet.

I often find that things are harder to do than I first imagine but your project seems quite doable to me.

[Kami_Barut]

Hi @Kirk_Masden,

Thanks for the warm welcome and taking the time to reply.

Much appreciated.

Kâmi

[Phil]

I completely agree with Kirk. You app seems very feasible.

I have some suggestions regarding your schema.

1. Move the Photos to a separate Photo table containing a PhotoId text field with an initial value of UNIQUEID() as the primary key. It should contain a single Image field to hold the photo. It should contain a Ref to the parent Hairdressers table. In general, when you have multiply occurring fields or the number of occurrences varies, you should almost always store those field values in a child table containing one field value per child record.

2. You should probably add a Services table that allows you to define the standard set of hairdresser services and their descriptions. It might contains records like “Cut Hair”, “Color Hair”, “Permanent”, “Facial”, etc. By having a standard set of services that apply across all hairdressers, you make it much easier to compare services and prices among hairdressers.

3. You should probably add a ServicePrice table that allows you to keep track of which services each hairdress provides and what they charge for that service. It should contain a ServicePriceId text field with an initial value of UNIQUEID() as the primary key. It should contain a Ref to the parent Hairdressers table. It should contain a Ref to the Services table. It should contain a Price field that indicates how much that particular hairdresser charges for that particular standard service.

4. I am not sure about the Reviews table. Would it make sense to make the reviews Service specific? For example, that might allow your users to compare haircuts reviews more easily because the reviews would be categorized by service.