If you're not sure if your thing is usable, find someone who you can watch use it in person.
If you can't find someone to use it in person, you can get user experience feedback with a session recording tool. I am the author of such software, which you can find at http://screensquid.com.
Being detail-oriented as most good software developers are, it is easy for me to just keep adding more details to the list and crunch them. It's going to make the product better, right?
WRONG! This is where I confront my issue. Perfectionism is merely a tool of the ego, engaging various games of self-righteousness, to only one end: giving me that charge that "I'm right".
But what works for me, though often right, isn't the point. It's what works for the user. The user is who gives my work life. They use the bits to accomplish tasks, rather than those bits sitting on a DVD on some shelf in my office, dead.
So how do I serve my need to be right and have a product that is living and breathing? Only one way. Get it into the hands of users. And be open to their input of the what sucks and what they'd rather have. They don't get to dictate the final form of the product, but they do inform my future decisions. See, the key to being right is learning, and all I learn from the bits resting on my shelf are lessons in organization and expense. To really learn, other people have to be involved. And I need to be open to not just their input, but to experiencing a range of uncomfortable feelings.
Let me apologize up front for this brutally honest comment. Since you have problems finding users for your product, chances are it won't be a huge success. Sorry for my brutality. Your project is still valuable. First, it has some value to you, so finish it and use it. But don't be afraid of being wrong in the process. Just tell that bitchy little part of your ego to shut the fuck up, and get your code into the hands of others. As developers we are often way too close to our work and benefit greatly from external feedback. Learning the process will make you a better developer.
So like I said at the start, this is my experience. If it might work for you, great. If not, scroll on by, there's a lot of other help here too. I admit what I've said here might be worth less than a nickel.
I use dokku for this and simply git push dokku master right after I got push origin master.
At any given time those who have the URL can see what I'm doing and ping back with feedback.
That, and Show HN her is great. Reddit has /r/startups which I also think is supportive and helpful.
What he didn't mention is that that cringeworthy MVP was public for almost two months before we started showing it to people. It was out there with broken features, placeholder text, etc.
That made shippin easy. It was done on day 1 and then we were very motivated to make it actually do something useful since it was already public.
(Who knows, maybe it does indeed requires a longer gestation period).
If I were you I would be really happy about her wanting to post the chosen images back to an other platform. This means your product would go viral on its own without any help. Think of a fair annual price, triple it and go live. There are many bored people out there with to much money in their pockets.
Why dont you embrace it instead of fighting it and trying to build your own social media?
That's not sarcastic or dismissive, it's just the best way I've found to get over the fear of shipping. By simply shipping it. The next time will be easier. And the next, and... etc.
I wish I knew a better word than feedback because I do not mean that people are necessarily going to engage you in good conversation and say "X is good and Y is bad." That almost never happens, and when it does, the feedback can be terrible and counterproductive.
But you need to find some way to get it out there in the wild such that you see how people respond and what they do with it, what gets used and what doesn't. If it isn't resulting in a lynch mob reaction, you need to not view the negative responses in a bad light. You want critique, and that means hearing both what works and what doesn't. You do not want nothing but fan boys, massaging your ego, saying nice things and not mentioning problems at all.
So, I don't know what path will work for you in specific. But you need to get some kind of engagement that puts useful information in your hands to inform the development. How people get that varies. But your fear of shipping is because it involves tossing it out there into a giant unknown void with zero idea of how that will go. The antidote to that is getting some engagement so you aren't just flying blind.
How people do that is very individual.
What I can tell you is that if your product is too innovative, you'll walk into walls, and that's fine. Most of the people I spoke to didn't get the service, and others seemed interested, but they were just polite. What you have to do is to launch and get out your product to the world, and then find the first customer, even if it's at 10% its price point—it will give you confidence and will validate that your product is valuable.
As for the feature creep, I think it will happen always, as each customer has its own view on your product, and since you're the one making it, they will tell you things, some are good ideas, but most of them are not very good, since most don't know what they want. You'll have to find balance.
The thing that helped me a lot is being in a big city. I'm from a way smaller place and I've been building stuff for 15+ years, and the big city mindset is way more open than the small city's, as they will use anything, but only once it has been proved.
I hope those pieces of advice help you in your journey. If you want to talk a little bit more, my email is in my bio.
I think, early fear of shipping is a symptom of uncertainty "will someone need this product?" You should try to find this someone as soon as possible, and get feedback from them.
'Shipping' means something much different for hardware projects of course, but nonetheless I think the advice to ship on day one is really foundational. I've always been fond of the idea that 'if something hurts, you need to do it more often'. Make the game about iterating and not shipping.
Make a backlog of tasks.
Set a time for your sprint (2 or 3 weeks).
Estimate how long you think the tasks in your backlog will take (don't focus on being 100% correct in your estimates).
Include what you can given the sprint time and the estimates.
Release at the end of every sprint.
Rinse and repeat.
fail fast -> fail more -> learn -> fail less -> maybe succeed -> repeat.
Somehow, you need to get comfortable with not knowing how it will all work and make sure you have given your best. Now best, would not mean the best product but something with the best fit. So it's not a step by step process here. The more and better you try, the more and better you understand the goal and how you may get there.
Learn to be just ok with failing and have someone to get you back up on your feet.
It was harsh. But it wasn't the end of the world.
Manage your expectations. See it as a process.
How do you create good stuff?
By creating lots of stuff, enjoying the process and some of it will turn out ok, some good, some bad. Like a musician.
Just focus on getting better. Your workflows for launching etc.
See it as feedback not a definition or critique of you.
a)you want to add enough features to attract/impress potential users. b)you want to ship it, so you can get feedback asap.
a) and b) are pulling to opposite directions, hence the paradox. There is no easy solution for this.
However, if you change the question to "what do I need to build to test my assumptions (about the market and user)", the answer will be more obvious.
The are tons of issues that show up only after you have shipped so striving for perfection before shipping is pointless.