There are a number of ways to build your MVP, and each might have a different pricing structure. But here I try to lay out some rules of thumb on how to get budget ballparks for certain features.
Most apps are going to have a fixed cost to start the project and then incremental costs. You want to minimize the fixed cost to pay in order to focus on your unique value prop. Many dev shops have this fixed cost in terms of allocating a full time resource to your project, or potentially multiple resources (QA, UX, PM). They can't get started without allocating this. This leads to long term projects, months, where you might not see a single feature shipped until two months of payments. You'd like to see things move quicker, with small progress toward your personal features. Dev shops often have project minimums of $20,000 or more. And the first thing you see will be polished, before you're allowed to test the functionality is what you want. This is a recipe to burn a lot of money.
Building boilerplate is another enemy of your budget. Login screens, DMing, profile pages, are in every app, and while necessary for the beta launch, are often not necessary when on a tight budget. You want the team hyper focused on novel code. Hone in on your unique feature and only build that. Each of these components mentioned earlier can be a few thousand in budget. Just to set up for a first version. Ask yourself if it's really necessary for your investor pitch or to show your friends. The answer is probably "not right now".
The third category of budget creep is bug fixes and polish. You definitely want to have polish when you share your idea with others, and it shouldn't be breaking. But when looking at it yourself with your developer, understand there will be problems. There will be bugs, and you don't want to pay for 100% solid code in every delivery. This will artificially increase the budget, and make the developer forced to quote higher, because you have a high standard for delivery. You need a dev that will deliver high quality code, but not until features are agreed on, prototyped, delivered, and then settled on. This is a good rule of thumb to stay in a tight feedback loop with the developer, so that they feel comfortable sharing rough versions to get early changes if the requirements weren't clear or the requirements shifted.
There's a few sources for budget creep in an MVP, and here, we explored a few ways to mitigate them, and manage expectations to maintain a lower overall cost. It's a tricky balance. Reach out if you want some help navigating, or want someone who builds with these considerations in mind.