I feel compelled to join this conversation once again.
The lack of documentation is a serious problem for especially new Wappler users.
I’ve gone through the pain to do as others said in this thread: figure it out, then create internal examples to reference… or even create my internal documentation.
@Daniel_Roziecki is absolutely right:
- Forum posts and specific questions are NOT documentation.
Documentation is the ability to look up how Wappler’s terminology translates. Like so:
We should NEVER have to reverse engineer this by testing every response code and checking which ‘dynamic event’ is triggered.
We also shouldn’t have to dive into the forums and hope to find the relevant post (HTTP Status Code to app connect name mappings - #2 by patrick)
- I think the following question is not the appropriate question to ask:
Wappler is a business. They make a product and sell subscriptions.
In my opinion (coming from someone selling SaaS) having documentation is a must for any software product.
Because otherwise:
- New users get scared away, takes so much time and investment to get around it
- You have a lot of pressure on your customer support inbox because you’re not preventing questions with proper documentation
In our business, we value a good customer experience very highly.
As we speak, our documentation is severely lacking as well.
We’re also tight on funds.
Nevertheless, our decision is:
We hire someone solely to identify which documentation needs to be written based on incoming questions, and write that documentation
That seems like the correct thing to do… else how can we scale?
If we want to help out all our (potential) customers, we’re stuck in giving customer support whole day.
If we choose not to provide great support, our customers will get frustrated and look for alternatives.
Anyway, the team played it well and builds up a bond with the community so the community gives back to the team by helping out with customer support. That’s great.
But I think it’s really overdue to hire someone and document everything.
Bonus:
Another examples of what should be documented properly…
