Welcome @tombraul! One thing about Ecto, which is Elixir’s default tool for integrating with databases, is that it tries to stay close to the database. Therefore, your question can be generalized to “what is the best way to model my problem at the database level”.

If you haven’t done this before, it may require getting used to, but it is totally worth it as you won’t have impedance mismatch between your app and the database in the long term.

From my experience the biggest thing people struggle with when building survey services is the differenciation between a survey and a survey response.

When rendering the form for creating a survey response a survey record defines what fields appear in the form, but you wouldn’t use a Survey changeset with the form. It would need to be a SurveyResponse changeset, because that’s what is getting created (or updated). The survey record might also be an input for a SurveyResponse changeset to validate any submitted inputs.

So for the survey response form handling a survey record will be a parameter, but the form is not about the survey record.

Generally I’d suggest starting without a survey record, hardcoding the markup for an example survey. Then hardcode details about a survey for that route, but dynamically rendering the markup based on that hardcoded data and from there it should be simple to use a survey record loaded from the db instead of hardcoded data.

A package that can help with this kind of approach is polymorphic_embed - it can provide some structure beyond just “a JSON field”.