On a high level, decide what you want to do. What's the essence of your product? The skeleton. This should never change. A business model canvas is one technique, but there are others. I can literally go on for hours and hours on this, feel free to drop an email.
The pro way would be to tackle the riskiest. Is it hard to make money? Hire a designer, mock the UI, show the dummy app to the customer. This is what I'd do as a freelancer being paid hour to hour.
The casual way is tackle whatever you feel is easiest. I like UI and colors, so I start there. Some people like data structures.
Build a system. Systems are not about the components but how they connect. Components can be swapped in and out. So an API is actually one way to start.
Abstract out components as much as possible. I replaced my caching system with a memory cache (aka put everything in variables) even though the proper way would be a disk cache. It does the job.
Build interconnections first though, then you swap the parts in and out.
"I can't decide what steps to take after I have an MVP."
This probably means you won't have a MVP, lol. MVP means minimum. You need to promise something to someone and then deliver on that promise. The purpose of a lot of UI, UX, juice, etc, is to make them intrigued enough to make them a promise.
A lot of people aren't mindful of what the customer expects. You can get this from reviews and customer research. One group is price sensitive and don't care what organs are in their hot dogs. Another wants calorie count. Another only cares about carb count.
Those features should be in the marketing. Screenshots are marketing. Figure out what they want, promise them the thing, have QA gates to check that the thing meets the promises, then sell the product that does what is promised.