Thanks very much. Yeah, I may go back and just focus on the 1 user I know that specifically had the problem build out the application, and confirm its of some use and think about marketing.
The 2 examples you provided are great...thanks a lot. Think its going to take some time flesh things out!
I would be ecstatic with 1000 users, and would definitely give me motivation to continue to build. Out of curiosity what was the state of the 1000 user 1st month vs. 200 user 1st month? Were they both pretty much complete apps? Or still in a MVPish state?
I was torn between spending more time developing before releasing or get some sort of validation to avoid the “building a solution for no ones problem”, and really was getting drained spending hours on developing. Maybe a bit of burnout being a solo dev working on this. I wanted to be reinvigorated by some level of validation.
Generally feels like the bar for getting any validation/feedback is higher, as the general consumer wants a shiny, not buggy, fully functioning app before even dipping their toe in.
Agreed its not 10x better for most people, but do think there is a convenience factor and some price that someone might be willing to pay for that maybe not 6%, but the 6% covers stripe charges (processing & payouts to connected accounts)
With regards to the pushing fee to customers, my logic was that a possible user would be pushed off by the 6% charge, and not even try out the application (albeit everything else about the app is pushing them away anyway!)
The idea literally came up as I watched my wife split proceeds from a workshop she held with a couple of other instructors.
Seemed like a hassle to translate the % splits to actual amounts, figure out/confirm wiring details, and then decide when to wire...I would also think the other instructors were wondering when their share was going to hit.
So I stood there thinking, what if she could pre-set percentage share, and have software split the proceeds on a per payment basis so she doesn't have to worry about getting the split amounts right and the disbursement of proceeds. Her partners wouldn't have to wait either.
Felt like the software solution would be killing many birds with one stone.
A light bulb went off in my head, as I registered a problem, and as any sane individual would nose-dived into building an app!
My wife isn't using it at the moment as her yoga studio/business is in Japan, and Stripe doesn't allow for a platform to be in a different country then its connected accounts and I chose the US to release.
The users aren't being charged to use the application. The app will absorb the costs and lump it into a fee that is charged to the final consumer.
That all said, maybe this doesn't generalize outside this particular example and the problem is too specific to her situation...
In summary, the app is for any group that is receiving proceeds from the sale of a service or product, that wants to avoid the hassles of splitting proceeds after the fact.
Thanks for the clarity. Very true. Ive been getting good feedback on HN and reddit, but as you state its not feedback from the apps target audience. I am going to iterate on the feedback provided by others and see how the results pan out.
Thanks a lot for the detailed and constructive feedback.
Yes, I have been struggling in trying to communicate the functionality of the application in a few words & images. This resulted in including the “tiny” menu (LOL!), which is becoming more clear that it's probably not the correct medium for delivery.
All the ideas you mentioned with respect to the landing page, I am going to take into account for sure. They all make sense. One reason, I was trying to keep it as simple as possible was that I just don't have the skills to design and integrate a well-flowing landing page. The current landing page is only using React components and MaterialUI for styling which probably is very apparent to the professional eye. I think with more work I can get it into the right form, but was trying to balance timing of spending money for professional work and user acquisition. In other words, I wanted to see that the app was getting some sign ups before actually spending cash, but seems like I am dealing with a chicken and egg problem to a certain extent.
Your comment “as it stands I would not trust your app with doing checkout processing for me.” really resonates. Will put more work in for sure.
Core contributors to an OSS project can decide on percentage share allocation and create a credit card checkout that is accessible via a shield button. The donations/proceeds would be split on a per payment basis.
At the moment the application only handles those with a US-based account.
Thanks a lot for the response. Yes exactly, its using Stripe Connect and related APIs.
Basically just leveraging a lot of Stripes features which are great. Their support has been super helpful as well advising on what can and can not be done.
Noted on the onboarding issue. Will check whats going on there. When I signed up myself, gmail classified it as junk/spam, possibly rightfully so.
The hassle of splitting proceeds from a service/event/product sale after the fact related to sending/collecting your % share, timing and details of wiring the proceeds.
Solution:
Pre-set allocations and create a customized checkout so that splits happen on a per-payment basis. Members dont have to wait to get their share.
Idea kind of came about after watching my wife, who is a yoga instructor/ studio owner try to split proceeds from a workshop she hosted with a few collaborators.
Another example: allows you to create a shield to a checkout that will split proceeds on a per payment basis.
The 2 examples you provided are great...thanks a lot. Think its going to take some time flesh things out!