What are you actually building?
“We only need a form” is one of those sentences that can be completely true on Monday and painfully false six months later.
Sometimes a form really is just a form. A few fields enter a database, an employee reads them, and nothing depends on a formal version or reusable interpretation.
Sometimes the form is the visible edge of a much larger system:
- a rule determines which questions appear;
- two dates must be compared;
- a warning must be acknowledged;
- a missing rationale blocks completion;
- the result is sent to another system;
- the exact version matters during an audit; and
- several customers want the same process embedded in their products.
At that point, the team is not building a form. It is building a small compliance runtime.
The build-versus-buy decision becomes easier when you name the parts honestly:
- Authoring: how rules, fields, conditions, and messages are defined.
- Rendering: how the participant experiences the process.
- Validation: where and how answers are evaluated.
- Versioning: what happens when the interpretation changes.
- Records: what is retained after completion.
- Delivery: how results reach email, webhooks, case systems, or data stores.
- Security: authentication, tenant boundaries, encryption, abuse controls, and audit access.
- Maintenance: who owns changes, incidents, compatibility, and support.
You may still decide to build. The point is to price the actual system rather than the first screen.
When is a custom form enough?
Build the simple thing when the problem is genuinely simple.
A normal application form can be the right choice when:
- the workflow is unique to one product;
- the rules change with the product and deploy on the same schedule;
- the participant is already authenticated in your application;
- there are few fields and little conditional logic;
- the output only matters inside your own database;
- historical versions do not need independent public identity; and
- your team already owns the relevant security and operations stack.
There is no virtue in adding infrastructure to a three-question internal survey.
Custom development is also attractive when the workflow is inseparable from the product’s core domain. A bank’s underwriting engine, for example, may require proprietary models, internal data, and deeply integrated human review. A generic schema platform should not pretend to replace that system.
The key test is not whether the first form is easy to code. Almost every first form is easy. The question is whether the surrounding lifecycle is ordinary product work for your team or a recurring compliance subsystem you will have to reinvent.
What does the first version hide?
The hidden cost appears when the form becomes important.
Version drift
A developer changes a question and deploys. Which version governed last month’s submission? Can an investigator reconstruct the old conditions and messages? A Git commit may contain the answer, but connecting it reliably to every completion is additional work.
Validation split across layers
Browser validation improves UX, but the server must repeat authoritative checks. If mobile, web, API, and partner integrations each implement parts of the logic, they can disagree.
Audit records
Storing raw answers is not the same as storing a reviewable record. The record may need evaluated decisions, timestamps, delivery attempts, warnings, publisher identity, schema version, and a proof that values were not silently substituted.
External embedding
An iframe is isolated but visually constrained. A native SDK feels integrated but introduces API keys, origin allow-lists, tenant binding, CSS isolation, remote validation, idempotent submission, rate limits, and compatibility requirements.
Security and privacy
Sensitive compliance answers may require encryption, strict organisation boundaries, controlled retention, and careful access. General secure-development guidance such as the OWASP Application Security Verification Standard is useful, but your team must still implement and operate the relevant controls.
Non-developer authors
If lawyers, compliance teams, or operational specialists own the process, every wording or rule change should not require a product sprint. Building a safe visual authoring experience is a separate product.
None of these problems is impossible. Together, they explain why the cost curve changes after the prototype.
When does a schema platform make sense?
A versioned workflow platform becomes attractive when the interpretation—not just the surrounding application—needs an independent lifecycle.
Look for these signals:
- the same workflow will be used by several organisations or products;
- non-developers need to understand or edit the model;
- the logic includes conditional fields, computed values, errors, and warnings;
- releases must be immutable and earlier completions must remain reproducible;
- the workflow needs both a hosted page and an embedded SDK;
- server-side validation must be authoritative;
- each completion must create a consistent audit record; or
- adopters need to inspect who published the interpretation before using it.
ProseID is composed around those signals. The schema is the product boundary. Rendering, validation, releases, hosted forms, embedding, and records all refer back to that boundary.
This is different from buying a broad GRC platform. Drata’s public compliance-automation product, for example, is organised around controls, evidence, monitoring, audits, and risk. A schema platform is the more direct comparison when your build plan contains a rules engine, form renderer, version ledger, and completion API.
What should remain custom?
Buying a workflow layer does not mean outsourcing the whole product.
Keep custom code where your differentiation lives:
- customer identity and account experience;
- proprietary data and scoring models;
- internal case-management interfaces;
- bespoke approvals and human-review queues;
- product-specific analytics;
- integrations unique to your customers; and
- final business actions after a validated result arrives.
Use the platform for the repeatable infrastructure around the published workflow.
An embedded model can therefore look like this:
- Your application authenticates its customer.
- The ProseID SDK renders the selected published form.
- A browser-safe publishable key identifies your organisation.
- ProseID loads the correct schema and co-branding.
- Responses are validated remotely.
- A valid submission creates the ProseID audit record.
- Your server receives the result and continues the product-specific process.
The compliance logic remains portable and versioned without requiring ProseID to become your entire application.
How do you make the decision?
Use a real workflow and score both paths.
Scope
- How many forms are planned in the next year?
- How much logic exists beyond required fields?
- Will several customers or teams use the same interpretation?
Change
- Who changes the process?
- How often does it change?
- Must old versions remain independently understandable?
Participants
- Are respondents internal, external, or both?
- Do they already use your product?
- Is hosted sharing, native embedding, or both required?
Records
- What must an auditor or investigator reconstruct?
- Are raw answers enough?
- Must the record show computed decisions, provenance, warnings, and delivery?
Engineering
- Can the team own the renderer, engine, authoring UX, API, security, and compatibility for several years?
- Is that work differentiating?
- What important product work will be delayed?
Exit and portability
- Can you export schemas and records?
- Is the model inspectable?
- Does the integration rely on a stable API rather than a private UI?
The answer may be hybrid. Build the product experience and proprietary decisions; use a versioned workflow service for the reusable compliance process. Or build the first workflow to learn the domain, then move the repeated infrastructure behind a schema boundary.
The wrong decision is not always “build.” The wrong decision is treating a long-lived compliance system as a weekend form because its first screen looked small.
For the broader architecture, read the modern compliance stack.