Answers about DynamicForm

DynamicForm by AG Studio Ventures is a cloud-based RAD platform for in-house IT teams and IT services companies. Its AI configures business applications (screens, workflows, menus and roles) from a requirement document, and the platform runs them on the web and on Android without code.

Two kinds of buyer: companies with their own IT team that builds business applications, and IT services companies that build business applications for their clients. In both cases, IT professionals configure instead of writing code.

Your IT team, or an IT services company working for you. They upload the requirement, review what the AI configures, connect your systems and run the application, configuring instead of writing code.

Yes. IT services companies use DynamicForm to deliver business applications to their clients faster: one platform, reused across client projects, with each client's data kept in that client's own database.

About 30 days for a complex, multi-stage system such as loan origination. A one- or two-step process, such as a request and its approval, can go live in hours. After go-live, changes take days or less, because nothing has to be coded or released as a new app version.

Up to 10 users, 30 days to build and 30 days live after go-live, hosted by us.

After the free trial, the Small plan runs on our hosted service and larger set-ups are agreed with sales. Contact sales.dynamicform@agstudioventures.com for a quote.

No. Loan origination is our worked example; the features suit any process with forms, approvals and field work.

Applications built from forms, approvals, documents, lists and field work: onboarding, requests and approvals, inspections and field visits, case management and lending. Highly specialised software whose core logic is the product itself is better written as code.

Yes, a cloud-based rapid application development (RAD) platform. AI is a tool inside the configurators: it proposes configuration that your team reviews and applies. The running application is the platform's engine executing saved configuration on a normalised relational database in third normal form, not AI output.

The requirement document is uploaded as it is. The platform splits it into stages and steps for your team to confirm, then proposes the screens, workflow steps, menus and roles for each stage.

No. Plain language works. The platform suggests how to split it into stages and steps, and your team confirms the split.

No. The AI only proposes changes; you review and apply them to a working copy and decide when to save.

No. It produces configuration: the same screens, workflows and menus your team could build by hand, so there is no code to maintain.

No. The running application is the platform's engine executing saved configuration. AI is used to build and change that configuration.

Yes. Describe the change in plain words; the AI proposes only the difference, and users get it after you save.

Yes. Applying a proposal is one step that can be undone, and nothing reaches users until the configuration is saved.

Tabs, sections that repeat (such as co-applicants or addresses), text, number, date and list fields, dependent dropdowns, lookups, uploads, OTP fields and action buttons, with rules that show, hide, require or lock fields.

Yes. A split starts several steps at once and a merge waits until all finish.

Yes. A reviewer can send a case back to an earlier step, and a remark can be made compulsory for that action.

A role, a named person, a shared queue, or a person chosen in a field of the form.

Yes. Each step can have a deadline in working days, and overdue cases are flagged and passed up.

Yes. Each section and field can be editable, read-only or hidden at each step, and the server enforces the same rules.

A blank screen for a new entry, a searchable work list, a report or a group of items, or it can create a case and start its workflow in one click.

Yes. Menus are given to roles, so each person sees only the items their roles allow, on the web sidebar and on the phone home screen.

Android today.

Yes. Forms are stored on the device and sent when the signal returns, with a receipt for each submission.

No. The same screen design runs in the browser and in the Android app, so nothing is built twice.

No. Screens are drawn from their saved design, so users get changes without a new app version.

Yes. Give it the third-party API document and it proposes the registered service: endpoint, method, security, the fields to send and the values that come back. Your team reviews, tests with a sample and applies it.

API keys, Basic authentication, bearer tokens, OAuth 2.0 client credentials with automatic token refresh, signed JWTs, HMAC request signing and mutual TLS client certificates. Secrets are stored encrypted on the server.

They are called by the server. Keys and passwords never reach phones or browsers.

In a dropdown filled live, a lookup that fills other fields, a button, a document upload, an automatic workflow step, or an incoming callback that moves a waiting case on.

Yes. Try the field matching with a sample response; unknown fields and bad paths are flagged, and every live call is logged with its time, status and result.

Yes. Models in PMML format or any scoring service can be connected and used at a workflow step.

Yes. The Document Analyzer reads identity documents and bank statements, fills the form and runs its checks.

SQL Server, Oracle and MySQL. Business data is stored in normalised relational tables (third normal form): a table per screen and a child table per repeating section, reachable with plain SQL. Case history is kept in a document store.

Yes. The data sits in ordinary relational tables in your own database, so any reporting tool can read it with plain SQL.

Yes. Screens and workflows export as a bundle that can be imported into another environment, configuration exports to Excel, and your data sits in your own database tables.

Yes. Every workflow move is recorded with who did it, when and the remark, and administrators can see where every case is.

No. It sits alongside them: it calls your services, uses your database and serves its screens and data over APIs.

Yes. DynamicForm is cloud-based and hosted by us as a service; larger set-ups are agreed with sales.

Yes. Dashboards and work lists are served from Redis as prepared results, saves return at once while the heavy writing happens in the background, and lists come page by page.

Dashboard figures are worked out in the background and kept in Redis, so opening a dashboard reads a prepared answer instead of counting millions of rows.

Dashboard figures are prepared in the background on a schedule, which keeps them instant. Case screens, inboxes and saves always work on current data.

Yes. Several servers can run behind a load balancer, sharing one Redis for data, sessions and real-time updates.