Most of what you want does not need a developer.

Far enough that most respondents will not register it as a third-party form. Themes control typography, colour, spacing and layout, and custom CSS covers the rest, so a form can be made consistent with your site rather than merely tinted to match it. Two constraints are worth knowing before you promise a pixel-perfect match: the form still has to stay accessible and usable on a phone, and heavy visual customization is the thing most likely to need revisiting when the platform updates. We keep brand work in themes and documented CSS rather than scattered overrides for exactly that reason.

Yes. Form content — labels, help text, error messages and confirmation wording — can be maintained in more than one language, which matters most for organizations serving multilingual populations or operating across jurisdictions where the wording is a legal requirement rather than a courtesy. The part teams underestimate is maintenance: every later change to a question has to be made in each language, so we set up the translation workflow as part of the build rather than treating it as a one-off pass.

They cover Excel-style calculation on the form: totals, scores, eligibility flags, date arithmetic and derived values, using functions that will be familiar to anyone who writes spreadsheet formulas. They run in the browser as the form is completed, so the respondent sees the result immediately. The documented limits matter as much as the capability — calculations apply to text fields, formulas cannot be used inside connector repeating sections, and aliases from repeatable fields and sections cannot be referenced in a formula. Those boundaries decide whether a requirement is configuration or development, so we check them during scoping rather than discovering them mid-build.

We use it when a requirement is genuinely past what themes, logic and formulas reach — an interaction the builder does not offer, or a behaviour that has to respond to something outside the form. It is not something to avoid on principle, but it is something to account for: custom script is code your organization now owns, it needs retesting when the platform updates, and it does not transfer into connectors, so a JavaScript calculation cannot be relied on to shape what gets written to Salesforce. We say which side of that line a requirement falls on before the estimate, not during the build.

Yes, and for public sector, education and healthcare respondents it is usually a requirement rather than an improvement. FormAssembly supports accessible form construction and Section 508 considerations, but accessibility is a property of how a specific form is built — label association, keyboard order, error messaging, colour contrast and how conditional sections announce themselves to a screen reader. A heavily customized theme can undo it, which is why we test with a keyboard and a screen reader rather than relying on the platform's certification alone.

Both, and it is worth being clear which you are buying. A branding and accessibility pass across an existing form estate is a bounded project with an end date. Logic, wording and calculation changes are continuous, because the processes behind them change — a new programme, a revised eligibility rule, a regulator's new wording. Most organizations take the first as a project and keep a small retained arrangement for the second, which is cheaper than re-engaging for each change and keeps the estate coherent instead of accumulating exceptions.