I don't feel like you have given enough information for anyone to answer without making many assumptions.

My take (and hence assumptions) is you want to build a product where other engineers utilize your stripe account while charging fourth parties. I believe standard stripe accounts only allow for end use, not intermediary use. e.g. you can not "repackage" stripe to a third party and allow them to charge on your stripe account. If I understand things properly too, this actually wouldn't even be a Stripe only restriction, this is a restriction by many (most) card networks.

Definitely not a lawyer and not an expert on all things credit card. I did work on a project that tried to do something like this. Our client was wanting to allow their resellers to charge for unrelated products through the companies merchant account. This is essentially repacking and they got smacked by the bank and told this is not allowed by card networks. Now, whether it was just that bank and they lied about the reasoning or not I cannot say. But I know the networks are super touchy about knowing who is charging, for what and the risk profiles etc

Thanks for the feedback! I do apologize for the lack of information in my original post. Here's some additional color that hopefully clarifies my use case a bit more:

Stripe offers a service called Stripe Connect (https://stripe.com/connect) which enables platforms to have intermediary sellers / merchants which collect money from end customers. Ultimately, this can lead to a scenario where an end customer pays a connected account without ever realizing that the primary account (me) is taking a percentage as well (this is allowed and is a primary use case for Stripe Connect).

Ideally, for my scenario, I want connected accounts to have connected accounts of their own. Here's the hierarchy:

My product -> Connected account owned by developer -> Connected account owned by merchant -> Customer paying the merchant

Note: The developer is building tools for the connected merchant account, thus taking a percentage of profits.

Unfortunately, this multi level tree hiearchy is not possible. My proposed workaround is to flatten the Connected account tree (since connected accounts can't have connected accounts of their own), and then allow the "Developer Connected Account" to reach my API so I can piece the two together.

One crucial piece of information here is that the end customer who is entering the credit card information will ultimately be paying the connected account that they are interacting with, so the bank statement will show the correct company.

Also, my API would have checks to ensure that only Connected accounts can interact with it, so Stripe ultimately knows who their customer is.

My security system is pretty basic but super reliable and isolated/safe overall.

I use BlueIris for the NVR software (it is cheap) and I buy various cheap IP cameras that support OnVIF (almost all try to phone home, some directly to china IPs). But what I do is I put all the cameras on an isolated LAN that does not have access to the internet. My BlueIris server has two NIC's one for the video lan and the other for my data network. BlueIris has a static IP and is locked down as well to what it can access externally.

Two ways you can make BlueIris work outside your home, use a VPN on your mobile device (absolute safest), or use their free DDNS to point to your box. Their system seems fairly decent, and I've done both methods. I also log all the requests on both LANs and check them every so often to see what is happening.

It seriously doesn't cost much to set this up, especially for just a couple of cameras.

Care to share the brand/model of those cameras? Thanks!

I have two different ones in the system right now (around 14 cameras total). Amcrest and SV3C are the brands and both are available on Amazon pretty cheap. I have a mix of 5MP and 4k cameras where it makes sense for better details etc. I also have a mix of the bullet cameras and the bowl versions.

I am pretty sure the SV3C brand is just a rebranded Dahua or similar, just a little different software.

FWIW: I also never use their mobile app to set them up, I just plug them into the isolated network and use the web interface to configure them.

Out of ~20 engineers, we have about 4 that have unrestricted access to production. A couple more have read only I believe to one of the databases.

I also have direct knowledge of a couple of other startups, similar size of 20-30 people in engineering, and they are about the same, no more than ~6 people.

In most cases, people really shouldn't be accessing production, it should mainly be deployment tasks that do. But you need a certain number of people to have access to cover failures etc. For example, having at least 4 people provides coverage if one person is on vacation, and then another gets sick etc.

I've read other companies basically have every engineer has production access to what they deploy, not sure I agree with that approach but I can see the argument.

I have worked in a number of hardware based startups, still do, and most have been product led or at least try to be. There isn't a one size fits all answer for what I think you are asking, and without more details it is unlikely anyone can give you great insights.

Generically, most hardware based companies today are really software services or data companies that have a hardware "interface" product. e.g. pick a consumer wearable product, what's really the product there? the hardware? or the users data? The answer is generally the user's data and insights that can be pulled from that data. So product led there generally starts with the insights and data, the hardware is just a means to acquire it.

My main point is unless you are selling primarily disconnected hardware, e.g. a non-connected toaster, you almost always are focused on the software services and data around the product and the hardware is just the bow you wrap it in to get what really is your product. So being product led for hardware isn't so different than SaaS or others. The one key difference is part of the user experience is the hardware, so you spend more time around optimizing the hardware and convincing customers why your shiny object is the one they need to buy. In the end though, usually those reasons to buy still boil down to the insights that come from the software. Hence you are still looking at all those growth metrics, engagement etc that most SaaS or software based business are watching.

If you are a truly non-connected or have severely limited software in the product then I'd have some different comments, but those are pretty rare in today's market.

Thanks for your answer. I am just trying to understand how that works in the field but seeing such companies as software companies with a hardware aspect makes a lot of sense.

My main interest in this case is B2B hardware, e.g. some kind of robot (mobile or stationary). What I see is that the main problem that is being solved is done by the robot and the software on top isn't all that interesting to many users and therefore it's not as easy to track.

When they log into a (web) app it becomes much easier track usage.

Nope, I've actually had it opened for multiple days and just walked away and come back and it has been fine. I've had a few occasions where I restart it cause of something, but not like you are describing. I have two machines I run the intellj IDE's on, m1macpro and a intel based macpro, neither has any issues.

I am also not doing Java, primarily either node.js or C/C++, or I am using DataGrip.

Unless you two had discussed it in some prior conversation, it is a red flag IMO and I'd be cautious with this person in any capacity. Doing this without having a chat about it, is disrespectful IMO as well. It also shows a lack of foresight into what might cause team issues too. So it is a warning sign on multiple levels, at least to me.

Thanks

be careful, this sounds like the type of guy who will take your pitch deck and start pitching it to others without you and then claim that you never got him to sign any NDAs or anything so it was perfectly legal to take the idea and run with it...

Technically competent is a big grey zone IMO. For example, I am sure Musk knows the details, limitations and technical aspects of the welding that takes place at SpaceX, but my guess is he isn't competent to do it.

That same example could be used for most of technology. I am sure Musk understands ML at a pretty solid level, but ask him to build or train a model and my guess is he wouldn't show "competence".

I think technical competence is also different then "could do it", e.g. I think Musk, Zuck could sit down and figure out most software related tasks. But it isn't a good use of their time. They have a good enough understanding of the technical limitations and requirements to lead people in product creation which has proven immensely valuable.

Why do you think Musk knows anything about welding or ML? I’m not saying he doesn’t, maybe he does, but that would be surprising to me.

Ive watched a few YT videos where Musk does a walkabout of spacex facilities. He seems to have an impressive knowledge of the engineering detail at so many levels. Given welding must be critical for strength and weight I'd be surprised if he didn't have reasonable knowledge from a technical point of view.

I think the channel was 'Everyday Astronaut'.

I'm not an expert so perhaps it's a case of I'm easily impressed.

Building is easy, naming is hard. In this case though, you're overthinking it. Pick one and move forward. Attributes is super common to use in these scenarios. Properties is also common and wouldn't be out of place.

I like to always build a project dictionary early on, as it just is helpful for everyone coming along later, and also if concepts change over time the original intent is clear. So like in this case, I'd just pick "attributes" and then have a markdown file or wiki etc that has common terms, and attributes would be described with examples. A quick 1-2 sentence write up is way easier then trying to spend a lot of time picking the perfect word/phrase.

tl;dr; I think both C and C++ be around a long time. Just look at COBOL.

I learned C in the 80's and C++ in the late 80's/early 90's. I have heard every few years since probably 1996-97 how C/C++ were dead or dying languages and had no place in modern development. Yet they both have continued to grow in usage, especially with the IoT push.

I happen to still love working in both C and C++, not that they are the most productive or best tool for every job, but for high performance or low level, embedded etc they are still a great fit.

FWIW I feel most languages have a purpose and when used for those purposes they excel. However, when you use a shovel to pound in nails, it isn't the tool that is the problem. I do see languages like Rust replacing a lot of things C/C++ have been used for, but not everything.

Jobs are a little more selective for C/C++ in general, but there are tons out there and good C/C++ devs do well.

My 2 cents, don't aim for full stack from the start. Decent full stack engineers take many many years to become truly full stack, and even then they'll still have an area of specialty.

I've seen people calling themselves full stack but in reality they don't even have an area they know well and so they are just weak across the board which makes it hard to even give them a chance. Pick an area, spend your time there first and once you are fairly solid there you can start branching into more parts of the stack. I do think it is smart to branch wide across many areas, but you need some depth in an area first to help you land a job and be productive for a team.

Okay, yeah you're right. I am not gonna become fullstack right away, but this course will at least provide me a descend knowledge about web-dev. And this way I can build portfolio which will be helpful to get me at least junior position, because, see I am completely new in the field.