The architecture,
before the sales pitch.
If you are the technical lead being asked whether this is real, this page is written for you. Isolation, data access, extensibility, the exit path, and straight answers to the questions we get asked hardest.
Your environment is yours
WebEdify is delivered as managed hosting, and every client gets a dedicated environment. This is the answer to the isolation question before you have to ask it — there is no neighbouring tenant whose data sits in your database, whose traffic shares your capacity, or whose incident becomes your outage.
- Your own data stores.
Not a shared schema with a tenant discriminator column. - Your own release timing.
What you need gets built for you, not queued behind what is safe for everyone else. - Your own configuration.
Including which AI provider you use, or whether you use ours at all. - A real exit path.
Commands and templates are plain text files in source control, running on standard .NET against standard databases. If you leave, you leave with something that runs.
Why this matters more than it sounds
Multi-tenant SaaS is cheaper to operate, which is why almost everyone builds it that way. The cost is passed to you as constraints: shared release cycles, feature requests weighed against every other customer, and a data-isolation story that is ultimately a promise about someone else's query filters.
We took the more expensive path because the customers we want are the ones for whom that trade does not work — regulated data, real integration surface, and requirements that are genuinely theirs.
Where does your data go when your users talk to your AI?
For most AI implementations the honest answer is: into a context window, governed by a contract you hope the provider honours. WebEdify has four explicit levels of data access, and the default is the conservative one.
Structure only
The assistant can execute a command and receive back only the shape of the result — field names, hierarchy, record counts. No values. Ever.
results ($) [15 children] contact [id, name, surname, email, taxid, dob, status]
Fifteen records. Every field name. Zero actual data.
Render without sharing
The AI authors markup. Your server executes it. The rendered result travels from your server directly to your user's browser.
The user sees their data. The AI never did. This is not a privacy feature layered on top of the rendering system — it is the rendering system.
User-confirmed sharing
When the AI genuinely needs to reason over values — to summarise or compare — it must ask. The user sees a confirmation prompt before anything is transmitted.
The framework also applies its own filtering to commonly sensitive fields, even inside a share the user approved.
Explicit developer grant
When a developer deliberately wants the AI to have direct access to a specific, scoped result — a safe aggregate, a pre-filtered summary — they declare a tool that does so.
Intentional, scoped, visible in the markup, and auditable. Not a default that leaks by accident.
The part most vendors leave out
WebEdify cannot infer every possible security risk for every application, and we are not going to claim otherwise — no framework can. You and your deployment team remain responsible for assembling the right combination of controls for your context. What the platform does is make the conservative path the default path, and make every step away from it deliberate and visible in the configuration. This is a compliance architecture, not a compliance guarantee, and anyone telling you differently about their own product is overselling.
Extend the framework. Never fork it.
Every low-code platform demos beautifully and then hits a wall the first time a real business requirement shows up. The wall is what you are really evaluating. WebEdify does not have one, because underneath the declarative layer is the full .NET platform and every major behaviour is a named interface with a clean contract.
Extension means implementing an interface and referencing the assembly. A factory service scans referenced assemblies at startup and registers what it finds — no wiring, no registration code, no configuration file to update.
| Interface | What it adds |
|---|---|
ITag | A new template directive, available everywhere immediately |
IProcessor | A new named step in the command pipeline |
IRestClient | A custom HTTP integration |
INodeRepository | CRUD and search against any new data source |
IAiChannel | A new AI provider, including one you host yourself |
IAiTool | A new tool library for the assistant |
A processor built for one client today keeps working against future platform versions, as long as the interface contract holds — which it will. Extensions live in your own libraries, on your own versioning, and never create upgrade conflicts.
## process-eligibility ### Steps **get** patient from default **eligibility** check with payer - plan: `` - retries: 2 **save** patient to default
One custom processor turns a payer API call, response validation, record update, and transaction log into a single readable line — reusable across every client in that vertical, maintained in one library. This is how a team packages its own domain expertise instead of rewriting it per project.
Changes without a deployment window
File resolution is version-aware. A developer works against their own isolated version, previews it in the live environment against real data, and promotes when it is right. Production users see nothing until then. There is no environment swap and no release pipeline standing between a fix and the people who need it.
Nothing to build, nothing to upgrade
- No React, no jQuery, no npm.
HTML is rendered server-first and hydrated by the platform's own lightweight script. - Rich primitives included.
Forms, tables, charts, dialogs, and live relays are tags, not libraries you assemble. - Plain files, plain Git.
No proprietary visual designer holding your application hostage in a database. - No framework churn.
There is no bundler config to maintain and no major-version migration waiting for you in eighteen months.
<@relay path="patient-detail" rename="p" id="" /> <form action="/api/command/save-patient" method="post"> <input type="hidden" name="id" value="" /> <input type="text" name="name" value="" /> <button type="submit">Save</button> </form>
What you are probably comparing us to
Each of these is the right answer for someone. Here is who.
Staying where you are
A content platform or legacy application with a hosting provider bolted underneath.
Right for you if the application is essentially finished and your roadmap is maintenance.
Where we differ: content management is included here as well, but it lives in the same application as your data, dashboards and transactions instead of beside them. The cost of the other choice is paid later, in customisations that get harder every year and a security surface you inherit rather than choose.
A custom build with an agency
Bespoke React or MVC, delivered by a partner and then handed to you.
Right for you if your product is genuinely novel and the interface is the differentiator.
Where we differ: you get most of that flexibility without funding the scaffolding — auth, CRUD, tables, charts, dashboards and AI — from scratch, and without owning a build pipeline afterwards.
A BI or low-code platform
Tableau, Power BI, Domo, or a drag-and-drop app builder.
Right for you if you need broad general-purpose analytics spread across many departments and nothing more than reporting on top of it.
Where we differ: integrations built against your system rather than picked from a gated catalog, self-service that reaches past reporting, and a dashboard that can become a transactional feature tomorrow without changing platforms.
The hard questions, up front
A comparison that only flatters one side is not worth reading. These are the objections we get most often, answered here rather than in month three.
| What you will ask | Where we actually land |
|---|---|
| "You are smaller than Microsoft or Salesforce." | Considerably. The platform is newer than theirs; the company behind it is not. MACRIM has built and run mission-critical .NET systems for over thirty years, and the same organisation that writes the framework hosts and supports it. You would be buying from a long-standing operating business rather than a funding round. |
| "There is no pool of developers who already know this." | True, and it matters far less here than it would elsewhere. The declarative layer exists precisely because an LLM writes it reliably — substantially more reliably than it writes equivalent MVC or React. The assistant is not a help widget bolted on afterwards; it works in the same files your developers do, proposes changes they can read and check, and teaches the idiom while it builds. Teams get productive in days, not after a certification track. |
| "Your connector catalog is small." | We do not keep one. Integrations are built against your actual system instead of a lowest-common-denominator connector written for a generic version of it — usually short, AI-assisted work, and never billed as a per-connector subscription. Where another vendor points you at their roadmap, we build it. |
| "Who trains our analysts?" | The platform does, in the flow of the work. An analyst describes the view they want, gets a working one, and can see the markup behind it. It is a different curve from an incumbent BI tool: shallower at the start, and without the wall at the end, because the same skill keeps paying off as the requirements get harder. |
| "Is the chart builder as polished as Tableau?" | Not in pure drag-and-drop chart-design ergonomics — they have spent two decades on that single problem. What ours does that theirs cannot is become a transactional feature the next day, in the same application, without changing platforms. |
| "Are you SOC 2 certified?" | Certification is in progress rather than complete, and we would rather say so now than at signature. The underlying practice is not new — the same team performs security and compliance work across 50+ managed environments today — and we can walk your security team through the controls and architecture under NDA in the meantime. |
All things done for edification.
We exist to build up developers, teams, and organizations through faster, cleaner, more maintainable software. That includes telling you when we are the wrong answer.
Talk to us