WebEdify, MACRIM's .NET application platform, provides a running .NET host, a markdown command engine, more than fifty declarative template tags, embedded client assets, and a set of application modules that projects register as needed. The shipped Starter resources add admin and CMS surfaces; Billing adds invoices and ledger operations; Analytics engagements add the AI workspace. Writable repository implementations cover Cosmos DB, SQL Server, Snowflake, Supabase, and Turso, while the SQLite hybrid provides read-only SQL over reference files. Commands, templates, CSS, and configuration remain plain files that work with Git, code review, and CI.

What is the architectural foundation?

Six design choices define the platform and are hard to replicate piecemeal:

Velocity with no ceiling. Markdown command files are what executes — not configuration wrapped around hidden generated code. When declarative processors genuinely cannot express something, you drop into C# in the same project with real debugging. A list command, a save command, and an HTML template are enough to ship a CRUD screen in an afternoon.

AI that defaults to structure, not values. The assistant receives field names, hierarchy, and counts — not your customers' data. It writes markup; your server executes it; results render in the user's browser. Four explicit data-access tiers exist, defaulting to the most conservative.

An AI workspace, not a chatbot. The assistant reads and writes real command and template files under a plan-confirm-write discipline. What it builds is the same markup a developer would write — readable, editable, committable.

Dashboards users arrange themselves. A console component drives an entire grid of widgets from one filter set. Users pick widgets, drag layouts, and save per person. The analyst who wants monthly instead of quarterly stops filing a ticket.

Extension without forking. New tags, processors, data providers, AI tools, and transforms are each a single interface registered in DI and discovered at startup. Your extensions live in your libraries on your versioning schedule.

Production changes with isolated review. When a Platform versioning implementation is registered, a developer edits in an isolated lane, previews against the configured data connections, and promotes through that implementation's explicit release flow. Production users see the current content until promotion.

These six are architecture — how the platform thinks. Three more capabilities ship as product features most platforms sell separately or expect you to integrate afterward.

What ships for multi-tenancy?

If what you are building serves your own customers, tenancy is already a database construct. segment:catalog is the default primary key format — the tenant identifier is half the composite key on SQL tables and the partition key path on Cosmos containers. Configuration resolves per tenant too, so one customer can share a database while another sits in its own. Nobody hand-rolls a discriminator column and hopes every query remembers it.

This is the data-layer foundation for multi-tenant SaaS. Application-level auth scoping per segment follows your command and role configuration — the partition exists by default; how you expose it is yours to define. See how tenancy works for the full answer.

What ships for content management?

The shipped Starter CMS provides articles, media, taxonomy, draft and publish workflow, and public content routing when those resources are enabled in a WebEdify site. The marketing blog you are reading uses that capability; the CMS article in this series walks through authoring, media, routing, and publishing in detail.

What ships for payments and invoicing?

Invoices, pledges, receipts, and donations are first-class records over a full ledger with charge, void, refund, and correction operations. Authorize.Net is the gateway that ships today, sitting behind a single IPaymentGateway contract so adding another processor is a package and configuration change rather than a re-integration.

Customer-facing payment pages tokenize card details through Accept.js on the client and send only the payment token to the server.

Scheduled billing operations run through external timer HTTP APIs (Logic Apps, cron) calling platform endpoints — the platform exposes the APIs; something outside invokes them on a schedule. Recurring giving includes staff-facing pause and cancel commands.

For the full billing surface, see how the billing engine works.

What template and client capabilities are included?

More than fifty tags cover the full application surface without npm:

The client layer — forms with validation, server-paged tables, dialogs, charts, file upload, autocomplete — ships as embedded JavaScript loaded by the platform. No React, no jQuery dependency, no webpack config. Rich behavior comes from tags and data attributes, not from a framework you chose and must upgrade.

Processors in the command pipeline handle list, get, save, merge, join, aggregate, send, and dozens more operations declaratively. A typical save screen is a markdown command, not a controller class.

What data backends and hosting stack are first-class?

Cosmos DB, SQL Server, Snowflake, Supabase (PostgreSQL), and Turso (LibSQL) each have a writable INodeRepository implementation — not a generic REST wrapper labeled as a data provider. The SQLite hybrid is a read-only INodeRepository that loads CSV or encrypted reference files into an in-memory SQLite database for querying. REST clients exist separately for calling external APIs from commands.

The host is standard ASP.NET Core on .NET 10. Azure is the primary deployment target; the application is plain .NET you can self-host under the terms of your agreement. Commands, templates, and extensions are files in Git — not artifacts locked inside a proprietary designer database.

What is optional versus always present?

Every WebEdify application gets Core, Rendering, Web, and the embedded client assets. Starter admin and CMS templates are available when the Starter assembly is referenced and configured.

Two platform libraries add production-grade versioning when you register them:

• WebEdify.Platform.Database — version-stamped commands, files, and configuration in a shared store with promotion by pointer bump.
• WebEdify.Platform.Git — sparse Git overlays where version lanes map to branches, giving developers copy-on-write isolation with explicit conflict reporting.

Applications using only base Core services use simpler, non-versioned file and command resolution. Projects register the versioning platform when isolated lanes and promotion are part of the workflow.

Additional libraries — Billing, AI, Integrations.Google, Transforms.Pdf, Reporting — register when the project needs them. Which assemblies and services are enabled follows the application's scope and agreement.

What do you receive in the first week?

A WebEdify engagement starts with a dedicated environment — yours alone, not a row in a shared pool. Hosting, certificates, backups, monitoring, and accounts are configured and handed over working. Your data model becomes a command file analysts can read. Screens are templates, not build artifacts. Analytics engagements include the AI workspace; other engagements receive the capabilities in their selected band.

That is the four-step path from conversation to running application. The onboarding fee covers standing up the environment; monthly hosting and automation bands are published on pricing.

Which shipped capability should you test first?

Start with the features page for the six architectural differentiators with code samples, then design strategies for eight working layout reference architectures you can preview in the browser. When you are ready to see the box opened against your requirement — your data model, your first screen — talk to us. We measure that first milestone in days.