There are a number of ways to talk about essentialist MVPs. Minimum Viable Tests and Minimal Minimum Viable Products are popular. Here I want to explore this concept a bit further and compare a standard approach to focused one.
As an entrepreneur, you want to test your assumptions, find out what's hard, find out what's impossible (today), and see what users respond to. To do this, you can start with a tech demo. Not a website. A single webpage. A webpage that does one thing, solves a single problem, and see if it's effective. A great place to look for success here is Justin.tv. The first version (released to the world in all its simplicity) was a homepage with a streaming video broadcasting a single person. A webcam hooked up to a livestreamed video feed on one webpage. Any user navigates to the page and sees the activities of Justin eating soup, sleeping, or playing video games. Clearly the last of these was the hook. And it eventually became Twitch. But users following each other, emotes, paid subscriptions, security, all of that was unnecessary, and frankly probably not even in conception, because the laser focus was on seeing if the concept had merit.
Now let's examine the opposite approach, the standard dev shop way of thinking. Let's build a fully fledged app with all the bells and whistles, all the pleasantries we've come to expect of our products. Take clarity.fm for example. It's a marketplace for experts and advice seekers to buy advice on a minute by minute phone call. A standard first version would include login, password recovery, two factor auth, direct messaging, rating calls, bespoke scheduling and more. Instead, focus on the novel, what are we doing that hasn't been done before: minute by minute phone billing. So, build that. Get your twilio integration set up for two people to join a call using unique identifiers, and track the length of the call where both members are online. Then bill the advice seeker. Scheduling can be off site, with a calendly integration, billing can be a stripe integration, and dms aren't necessary. Even logins and passwords are not. Giving each member a unique login string is a sufficient minimalist approach. With this setup, you can test the market and see if there's interest in this sort of platform. Don't be convinced to build more than you need, just to pad the pockets of the dev shop. They want to write a bunch of code they've already written, and then when they recognize that the custom work is more than they understood, charge you more. This is a good way to go over budget.
Minimalism is a tough road to walk. But deciding what's unique and valuable is the most important task early in a product's lifecycle. Reach out if you want help determining that and then executing on the mission.