In what way are you getting ripped off? What’s your role in this? Are you paying these people money out of your pocket? Then yes. Are you supposed to approve their expenses for the business? Then also yes. So, yes.
I’d demand a full business plan and technical design for review and approval with stakeholders. Are you going to buy this hardware and they will thumb with it for 5 months with zero product for the firm? What’s the expected outcome and value to the business? I’d get more eyes on this and ask tough questions, and get it documented. Maybe let them use a public AI first to make the design doc, and then stakeholders can use a public AI to review said doc, and then you all can confuse each other and shelve this project to Neverland.
Then I would absolutely share your concerns. If you can’t share the value proposition clearly with the owner in your own words, then it will reflect poorly on you when this goes sideways with negative results. IMO you don’t even need to say no. Just say, “there’s no way I can explain this clearly to <owner> with what you’ve told me so far. I can’t sell a plan I don’t understand and I don’t have enough details to understand the steps here. Let’s write this down in a document that we can go back and forth on to get the details right that I can share with others.” Then make some suggestions for them to do the leg work.
Before any hardware or software gets built or acquired it can be helpful to go through some exercises. Probably the most helpful here:
Business Requirements Document (BRD) - stakeholders, business constraints, goals. Should sell the idea “we need to do something here because it’s important to the business for XYZ reasons”.
Product Requirements Document (PRD) - Critical User Journies (CUJ), user stories, use case analysis. Should iron out how a solution should look like to achieve the stated goals of the business doc. Specify success criteria, what metrics are important for this to be a success “we saved staff X hours, we cut costs Y dollars, we brought in Z new clients”.
Technical Specification or Technical Design Doc (TDD). Should explain how to achieve CUJs through a technical design. Focus should be both “why” to do it this way AND “why not” do it some other way. Tradeoff analysis.
Then there are a dozen related drill-downs exercises: legal review, security/privacy/compliance review, internationalization, launch review, UX review, on and on. They all serve a common goal: get everyone on the same page. You don’t need to contort what your are doing into any of the above, but it’s just kind of evolved into these aspects because it’s so difficult to get everyone on the same page.
Again, I’m not saying adopt all of the above, but if you don’t have the technical knowledge then your role is closer to a project manager and that is its own set of skills. It’s very helpful when PMs have some technical background (so absolutely continue enjoying Homelab hobbies), but (from a random internet stranger’s POV) here you need to wear a project manager hat.
Good luck!