You should ask any platform vendor the questions that determine whether you can operate, extend, and leave before signing. This checklist is vendor-neutral in shape and platform-specific where published evidence exists. WebEdify, MACRIM's .NET application platform, provides one concise answer and a canonical link for each question, alongside why it matters and the proof to request.
How is our application hosted — shared pool or dedicated environment?
Ask: Are we a tenant in a shared database and release train, or do we get isolated infrastructure?
Why it matters: Hosting architecture affects isolation, capacity, release timing, and how operational changes are coordinated.
Proof to request: An architecture diagram showing application hosts, data stores, tenant boundaries, capacity ownership, and who controls release timing.
WebEdify's answer: WebEdify is delivered in a dedicated client environment while supporting applications that serve multiple customer segments; see Is this multi-tenant?.
Can we build a multi-tenant product for our own customers on this platform?
Ask: Do we hand-roll tenant ids on every query, or is tenancy a database construct?
Why it matters: Tenant discriminators and query filters can spread across an application unless the data model establishes a consistent boundary. Backup, restore, and per-tenant configuration also need a deliberate design.
Proof to request: A working data model, repository declaration, and query that demonstrate how tenant identity participates in storage and configuration.
WebEdify's answer: WebEdify makes tenant identity part of its declared primary-key and configuration model; see Can you build a multi-tenant product on it?.
Where does our data go when our users talk to the built-in AI?
Ask: By default, does the model see field values, or only schema? Is that default per tool or one admin toggle?
Why it matters: Regulated buyers need mechanics, not "we take privacy seriously."
Proof to request: A captured request that separates the model payload, server execution, browser output, consent event, and relevant audit lines.
WebEdify's answer: WebEdify separates structure discovery, server rendering, and scoped value sharing by tool; see Where does your data go when your users talk to your AI?.
What happens to our code and data if we stop using you as host?
Ask: Do we leave with plain files and standard runtimes, or with exports from a proprietary repository?
Why it matters: Exit cost is the hidden line item in every SaaS contract.
Proof to request: The contract language, runtime dependencies, source-control deliverables, data-export process, and a documented handover procedure.
WebEdify's answer: WebEdify applications use standard .NET, standard databases, and plain command and template files, with platform-library terms governed by the agreement; see Could we run it ourselves if we wanted to?.
What does it cost — including the costs that usually appear later?
Ask: Are monthly fees published? What moves the number? Where do onboarding, implementation, connectors, and AI usage show up?
Why it matters: "Call for pricing" hides the second invoice.
Proof to request: A written estimate that separates recurring service, onboarding, implementation, model usage, environments, support, and likely expansion costs.
WebEdify's answer: WebEdify publishes current ranges and scope drivers, with implementation and usage shown separately; see What does it cost?.
How do integrations actually work?
Ask: Catalog and marketplace, or engineering against our API?
Why it matters: The integration model determines lead time, maintenance responsibility, recurring fees, and whether a connector can match your actual API.
Proof to request: A working connector example, its authentication and error-handling design, the maintenance owner, and the commercial terms for changes.
WebEdify's answer: WebEdify integrations use declarative commands, HTTP clients, or scoped .NET extensions according to the target API; see the integration explanation on Why WebEdify.
How quickly will our team get productive?
Ask: Certification tracks, proprietary designers, or files our developers already know how to review?
Why it matters: Time-to-first-useful-change dominates ROI for internal tools and operator dashboards.
Proof to request: Ask a team member to change one real command and one real screen in a pilot, then review the resulting files and promotion process.
WebEdify's answer: WebEdify uses readable markdown commands and HTML templates that developers, analysts, and the assistant work on together; see How it works.
What security controls ship by default — and what is your compliance posture?
Ask: Is secure configuration inherited from the platform, or a per-project hardening checklist?
Why it matters: One missed CSRF rule or open command endpoint becomes your breach story.
Proof to request: A control walkthrough covering command roles, application permissions, ownership configuration, antiforgery behavior, unsafe HTTP methods, rate-limit configuration, headers, and production error handling.
WebEdify's answer: WebEdify supplies platform security mechanisms that each application configures for its routes, commands, and ownership model; see Closed by default for the canonical posture and current compliance status.
Will our requirements sit in a shared product roadmap queue?
Ask: When we need a change, is it days of configuration or quarters of platform prioritization?
Why it matters: A shared roadmap can put a regulated or integration-heavy requirement behind priorities unrelated to your deadline.
Proof to request: Classify one of your requirements as configuration, application implementation, integration work, or new platform capability and ask for the corresponding delivery path.
WebEdify's answer: WebEdify scopes client configuration and implementation against the dedicated environment while identifying reusable platform work separately; see the dedicated-environment explanation on Why WebEdify.
What should we ask that is specific to our industry?
Use the generic list above first. Then add:
| If you… | Also ask… |
|---|---|
| Handle PHI/PII | Default AI data path; per-tool consent; server-side field blocklists; whether "show data" and "send data to model" are the same code path |
| Run billing or benefits admin | Migration without rewrite; nested legacy JSON vs normalized billing; dry-run/commit; identity rules on financial documents — see our payments and migration posts |
| Sell multi-tenant SaaS | Primary-key tenancy model; per-tenant configuration; backup/restore per tenant |
| Must self-host or exit | File ownership; runtime stack; library licensing in contract — not a FAQ promise |
Your evaluator should run the checklist on your data, not on marketing adjectives.
How should we use this list in procurement?
- Send the questions verbatim to every finalist.
- Require links or demos, not adjectives — especially for AI data paths and exit.
- Reject answers that contradict the vendor's own published pages (a sign internal teams are not aligned).
- Put anything that matters in the contract, not the slide deck — licensing, isolation, and data handling included.
We put pricing on the website and hard architecture answers on /why because evaluation should not require a sales call to learn whether the product fits. If the checklist surfaces a gap you care about, that is a useful outcome before signature.
Use a pilot to collect the requested proof against your own requirement, or review published pricing before deciding whether the scope belongs on your shortlist.
