Reply with your idea and I'll give you 1-on-1 feedback

@cridev, moving on to the next iteration of this here: https://www.indiehackers.com/post/sign-up-to-get-1-on-1-feedback-from-other-founders-e384714784

I can see wanting to protect IP, and a cloud workspace/IDE that limits access to a cloud workspace might be a solution.

I think there are a couple of challenges with this solution:

• If I want to limit access to a certain set of files to fix a bug or implement a story, I now have to spend a (non-trivial, and perhaps significant) amount of time figuring out what files to give access. As a developer, I can tell you I usually spend a significant amount of time planning how I'm going to implement a feature or fix a bug than actually making the changes. That planning means looking through the existing code base to figure out where changes should be made. This means I need access to the code. If you have to do this before handing it to a freelancer/contractor every time, I think that's a fundamental flaw.
• As a developer, if I had to deal with this, I think I would be turned off and reluctant to continue. I'm willing to sign IP agreements and work to build some trust in other ways instead of having to work in a way that slows me down significantly

Let me know if you want to talk about ideas to address these, or want to discuss further - send me an email.

I really like this, some of the teams I worked with do this kind of thing already on Slack by just manually updating on the #general and #random channels. I can see how combined with professional fitness coaches, this would be a great service. I think your work team can be really great motivation. Figuring out who to approach and how to find them/approach them is probably going to be your challenge - I don't think I can help too much there. Happy to talk more if you want to have a 1-on-1 conversation, send me an email at ravi@development.kitchen.

It looks pretty polished. I would say I do run into this in my daily job as a dev - understanding what product people mean by changes they'd like to see in the app. Generally though, it's usually just a screen share to show what they mean, together with a conversation about what they're pointing at or want changed. The difficult thing might be for someone to remember to use your tool in the moment. Might be about tracking decisions made about changes that need to happen.

I built something similar for tracking bugs - when a bug occurred, they could click on a little bug icon and they'd have a session replay that they could submit. But even with that icon directly integrated into the app, getting people to use that to submit a bug over just calling someone on a screen share and showing them was hard. They just thought to do the call.

I think the success for you is really going to be on selling teams to adopt your tool. Shoot me an email at ravi@development.kitchen if you want to schedule a call for more detailed feedback

Sent you a reply!

Sent you a reply!

Hi, just wanted to leave some brief feedback as well: I'm going to talk about Stripe because I've got experience with it. They've got pre-built solutions that sound similar to what you are describing. But Stripe is very dev-focused so I can see why someone looking for no-code wouldn't look at Stripe. I've also used Stripe to build custom integrations and generally, you can be up and running with a basic integration in a half hour or so.

Generally, the work is actually not with the payments itself but rather related stuff. For ex., this includes getting the model for pricing and usage within your domain model, tracking usage, figuring out taxes, invoicing, running jobs for monthly charges, cleanup for expired cards, etc. This took up most of the work in places where I've done this before. I think Stripe has since made some of this easy.

Overall I think one of the problems you may have with payments is that you're going to get people comparing this to existing solutions. And I think people are more likely to do this comparison in payments because of the amount of trust required to go with a particular provider. If someone is going to go with an unknown payment provider, it really needs to be clear why they should.

Again, if you want to talk in more detail, send me an email to schedule some time!

I find often what happens on sites like IH or PH, where you can get 1 to many, you get a few one liners from a few people. Unless you have a runaway success, this can often leave you almost as clueless as having no feedback. Instead, 1-on-1 conversations let you go into some depth that you otherwise can't in the usual communities. That's what I want to try and make available. Would love to give you feedback, shoort me an email at rchodava@gmail.com and we can schedule a call to trade feedback.

The focus on software has to do with where I came from in evolving this idea. And I think a focus will help in getting done traction. But I think the solution definitely applies to founders of all types of startups. Thanks for the feedback, if you do want to try it out and get feedback on what you're working on, give me a shout at rchodava@gmail.com or sign up and send a request in the site and I'll schedule a call to trade feedback.