Just like a person, Quick Base (and all database) applications age over time. Developers add fields, reports and relationships that become obsolete, but don't clean up after themselves. Eventually, there are all kinds of database elements that no one remembers and just confuse the user. The original developers leave the organization and their successors look at the app (originally so well-conceived!) and say "who designed this mess?"
There's no fountain of youth, but there are some things you can do to avoid database sprawl.
1. Isolate the chaos
If you have to create some strange temporary feature (like a double backwards relationship maintained by cascading automations), do it in its own application, separate from production. Use sync tables to create clones of your production tables, and then create as much chaos as you want, without contaminating the original app.
2. Label reports in an informative manner
If you are creating a report you only need for a week, don't call it "Q4 Metrics Report" -- that will persist forever and confuse people. Call it "Q4 Metrics - delete January 2020" or something like that so that even if you forget to delete it, someone else can.
3. Label fields in an informative manner
Complicated permissions in Quick Base often result in complicated field constructions. If you are creating a long string of fields to define someone's permission, don't call the field "User Accessible" -- no one will remember why it is user accessible. Call it "User is member of same business unit as current user" or something like that. Then your future users will understand.
4. Don't create things only you will understand
While you might be a whiz at automations, creating a string of 19 automations in a row will never be comprehensible to a future user. Likewise, multiple embedded formula urls that feature 5 levels of "rdr=" & urlencode(..." are bound to fail. Find another route (maybe coding, or, in the near future, Cloudpipes?) instead.
5. Put your documentation IN your database
Don't fail to document, and then regardless of where you store the documentation, make a copy of it IN THE DATABASE APPLICATION so even if the future user doesn't know to look in your personal WIKI, they can find it in a database page or a table of documentation.
Follow these instructions, and you will not only make future users happy, you will gain a little immortality for yourself, as your database will live on for many years.