Improve "Guided Tour" page in the docs

[Martinsos]

TLDR:
We should update “Guided Tour” page in docs to:

1. Better explain the situation in which you are left after creating your open-saas app on the disk.
2. Provide good ideas (possibly a checklist) on how to proceed from here.
3. Warn them that once they change the name of their app, they will have to restart wasp db start.

Below follows my thinking and ideas on what this could look like.

---

After creating my open-saas app on my disk, flow is a bit broken by taking me to the live demo app, and then explaining features → there is no moment where I go to the app I just created locally on the disk and do something with it. Also, the situation in which I am in right now is not explained, and that is that the app on my disk is not really working because it is missing API keys, and I should want to provide those. It should somehow warn me about this → hey, Stripe payment will fail, and this and that will fail, your app is only partially working / set up.

“Guided Tour” page ends with “And that concludes our guided tour! For next steps, we recommend …” → feels like something is missing? What are the next steps really? This is maybe the right place to warn them about missing API keys again (what I mention above). Also, give them some idea how to proceed: they can go through the codebase of the app they just created on their disk, delete some parts, modify some parts, check out the guides when not sure about something, … . Should they read all the guides first? Maybe make it clear (again?) they should check Wasp framework docs for any details on stuff? What I can expect from my app now that I go for it → what will not work or will work? I am again thinking about those API keys I think. We need to explain what is missing, and how much work each step will be: configure Email Sender (30 min, requires domain, free), configuring Stripe (45 min, requires bank account), get a domain, … . Yeah, so I am thinking about similar things here like in the paragraph above.

What we could do is give them a checklist of ideas on what they could do from this point on:

• Go through main.wasp and make it yours: rename stuff, remove parts you know you won’t need (e.g. redundant auths).
  • Change the name of your app (when they do this, wasp start will crash though: TODO: let them know they need to restart wasp start db for stuff to work again (because db is given a name based on app name, and app looks for that name)).
• Go to demo-app part and start coding your core business logic there.
• Take a look at src/client/App → that is your root component, you might want to edit that.
• Maybe point them how they can do some global styling.
• Fill in the API keys in the env vars, those that you need. Delete those you don’t need.
• Let them know again that Wasp is the framework and they can check the docs if they need to learn anything.

I made this checklist up quickly, I am sure we can do it quite better.

Here is a list that I made for myself, for Work Diary, so maybe we could have something like this, but adapted:

• Make a new Github repo with this project.
• Decide if I am going with email & pass or with Google login, or both.
• Go through main.wasp file and delete redundant stuff + rename stuff.
  • piece of advice: even if you don’t have a custom domain yet, in some places it will be needed. Just put some domain you would like to have, it won’t be an issue to get started with development.
  • update meta tags in head
  • change app name (+ restart wasp start db after that)
  • remove auth methods I won’t use, configure ones I will.
  • adjust the info in [emailSender.defaultFrom](http://emailSender.defaultFrom.name) , if you are using emailSender.
  • Delete “PasswordReset” routes and also “EmailVerification” route if you are not using email + pass auth.
• Go through .env.server and delete redundant stuff. Also delete it in .env.server.example.
• Delete S3 logic, Plausible logic.
• Update Landing Page.
• Reorganize files by functionality.
  • Btw it might be worth it to port this back to actual open-saas codebase.
• Implement some MVP logic in DemoApp.
• Implement summarization of day / week / month via GPT. Comparison of this week vs usual weeks. Possibly also answering some questions about the work, like how much time did I spend doing this kind of work, what was unusual, ... .
• Set up Google Analytics.
• Buy the domain.
• Deploy the app.
• Get e2e tests going.
• Look into unit tests.
• Get CI working.

[Martinsos]

TODO: We should also, at the early enough point in the Guided Tour, warn user about Dummy provider and how it sends emails into the console. We should do this before they try to sign up, which should probably be quite early, certainly before we tell them to start tinkering with the app, or before they might decide to do so on their own. Which is likely very early, because they might be like "ok this is a lot of text, I just want to try it a bit first, let's see I will sign up here and bam".