Don't wait for users to report defects. You have to constantly use the software you write. Stress the hell out of it and really try to make it fail. Write tests to ensure the edge condition is covered against future regression.

Attempt to automate everything. Adding new options and features in the previous version of my application was a pain in the ass. Now they are all listed in a single JSON file. The build adds the options into the supported interfaces as well as the documentation. Now all I have to do to add a new option is update the JSON file, add the desired result into the application logic, and write tests.

Ensure your documentation is well structured. You want to ensure all the features are mentioned, but its helpful when reading the docs if there is a uniform organization that explains the purpose, data type, compatibility, and options of each feature.

The challenge with supporting many features is that collisions of various features can result in unexpected outcomes. You have to really look for these things before your users do.

Honestly this is more "how do I keep from having to perform maintenance" but just spitballing...

Do you have defined Service Level Objectives (SLOs) for your APIs? Do you have unit tests so you can both prove changes do what's needed and that nothing else broke (regression testing). Do you have good error handling and readable error messages or is that all #todo? Are your processes idempotent? Is there a documented and automated recovery procedure if not? Add all the features you want, but if you build them to have a high uptime and resilient up front you're really combining a view into maintenance (or more importantly - not needing it) while still delivering features. And if those things aren't true then I guess making them true first before adding features is sort of what the original poster meant?