i have a situation that i assume is beyond the ability of inventory management to handle, at least out of the box, and i'm curious if it would make sense to try to fit it into Solidus or to build it in the app otherwise. in my case, i am modeling parking spots so at a high-level, the unit is a parking spot. folks can take out a contract on a parking spot for a variable amount of time and in general i only want to create one contract per parking spot at any time. however, in some cases, i do want to be able to create a second contract on a parking spot, for instance when the first contract-holder is out-of-town. i even want to be able to have a third contract in some cases. does this kind of inventory mesh with how solidus handles stock units or does it sound sufficiently incompatible such that building it outside of solidus and only using solidus to check out after the amount due has been figured out would be better?

I think this use case might be a bit of a stretch for the inventory system, which deals mostly with units of a product. You may want to model the spots separately in your app and that will give you a lot more flexibility around what business rules exist around them. You can probably turn off stock tracking altogether for your variants and possibly attach some metadata to your line item records to associate them with a specific spot if that needs to be assigned during checkout. There may be other ways to handle this of course 😄

That's what I was thinking too. Do you think there's any sense in creating a product for each spot either proactively or just before that spot gets a contract (charge), or should i just have a single product that is used in all the cases?

Hmm, that’s an interesting thought. It might be worth creating products/variants if there is any meaningful distinction you need to model between different kind of spots, but otherwise a single product may be enough.