[ A CONNECTED PLATFORM FOR WEB + MOBILE ]

FULL-STACK APPS.
ONE LANGUAGE.
BUILT FOR AI.

AxiomCore connects your frontend, backend and database in one language. Build for web, Android and iOS.

Explore the live demos ↓See the advantages ↗

Real applicationsIndependent databasesSame core workflows

orbit / application.acoreTYPED + CONNECTED

// One language. Connected layers.
model Task {
  title: String
  dependencies: List<String>
}

page Home {
  query tasks = Board.list_tasks(...)
  view { TaskBoard(tasks: tasks.data) }
}

APPLICATION MODEL ↗

UIAPIDATA

WEBANDROIDiOS

↳ Trace a field. Inspect its consumers. Review its impact.

TYPED CONTRACTSSEMANTIC CONTEXTSANDBOXED EXTENSIONSRUNTIME POLICIESNATIVE TARGETS

01 / TRY THE SAME APP

Same board.
Open all three.

Create a task. Add a prerequisite. Move it through the board. Search, filter and edit. Each demo runs its own implementation and persists to its own database.

ACORE ECOSYSTEM

Acore

Live demo

● ● ●acore-demo.axiomcore.dev↗

One typed application model

Acore UI · native API · PostgreSQL

13 authored files898 lines incl. tests

Visit website ↗

SAME APP / FLUTTER

Flutter + Serverpod

Live demo

● ● ●flutter-demo.axiomcore.dev↗

A shared Dart codebase

Flutter UI · Serverpod · PostgreSQL

18 authored files2,281 lines incl. tests

Visit website ↗

SAME APP / NEXTJS

Next.js

Live demo

● ● ●nextjs-demo.axiomcore.dev↗

A full-stack web application

React · Next.js API · PostgreSQL

12 authored files706 lines incl. tests

Visit website ↗

Public sandbox boards are shared between visitors. Use sample data. The embedded previews are interactive; open a full website for the complete viewport. Native targets are compiler-checked in this example; browser responsiveness is not a device test.

02 / WHY A CONNECTED MODEL MATTERS

What your team gets.
Built into one platform.

Acore connects UI, backend, data and policy in one application model. These six benefits give developers and agents a shared foundation for building, changing and reviewing apps.

Connected application model01

One language across the app

Define UI, backend contracts and database schemas in Acore. Shared types help catch mismatches between layers earlier.

Inspector · Alpha02

Give AI agents a map of your app

Agents can retrieve relevant nodes, properties and relationships, reducing the context they must reconstruct from files.

Inspector · Alpha03

See the impact before changing something

Follow recorded dependencies from a data field through APIs to consuming screens, text and buttons.

Runtime · host-dependent capabilities04

Write less routine plumbing

Shared runtime support handles declared validation, caching, errors, request lifecycles and supported streaming behavior.

Shared UI · target-specific support05

Build for web, Android and iOS

Share UI source across targets while retaining HTML-based web output and support for ordinary page metadata.

Inspector · Alpha / Sandbox profiles · Experimental06

Review behavior and access with evidence

Inspect permissions, source references and captured execution. Supported sandboxed extensions receive explicit, limited capabilities.

Other stacks provide many individual pieces. Acore connects their meaning across the application. Inspector is Alpha, sandbox profiles are Experimental, and supported behavior varies by host. Broader semantic editing is shown separately as planned work.

03 / DECLARE ONCE. EXECUTE CONSISTENTLY.

More behavior.
Less repeated work.

Your product defines the experience.
A shared execution layer carries the common behaviors.

WHERE AXIOMCORE FITS

WebAndroidiOS

USER ACTIONS ↕ RESULTS

SHARED EXECUTION LAYERAxiomCore runtime

Checks dataCoordinates requestsHandles results

TYPED SERVICE CALLS ↕ RESPONSES

YOUR SERVICESAPI + business logic

DatabaseExternal services ↗

Conceptual view. Shared behavior runs inside supported client and server hosts, using the rules in your application contract.

WHAT THAT LAYER CAN TAKE CARE OFCapabilities vary by host and profile. Orbit uses a subset.

Live updates without refreshing

Stream new information into a screen as it arrives, on supported hosts.

Helpful form feedback

Check declared field rules and explain what needs fixing before data is accepted.

Errors people can act on

Give the app a consistent way to show what went wrong and what can happen next.

Faster repeat visits

Reuse saved results when the app’s declared policy allows it.

Keep screens up to date

Refresh the relevant saved results after a successful change.

Clear loading and saving states

Let screens show when an action is working, has finished or needs attention.

Recover from temporary failures

Retry eligible requests under the app’s declared rules.

A limit on waiting

Stop requests that exceed their allowed time, so a screen can offer a next step.

Keep the latest search current

Coordinate supported request lifecycles so superseded results do not take over.

Access rules in one place

Check the declared sign-in and permission requirements at the operation boundary.

Safer add-ons

Limit supported sandboxed extensions to the specific capabilities they are granted.

Remember selected app state

Retain selected state where the chosen UI host supports persistence.

Consistent data between screens

Check incoming and outgoing data against the application’s shared contract.

Handle busy periods predictably

Apply supported capacity and queue limits instead of accepting unbounded work.

Follow what happened

Connect operations and failures with execution records that teams can inspect.

How the runtime works ↗Live update capabilities ↗Supported boundaries ↗

04 / THREE PRIMARY SOURCE LAYERS

A full-stack starting point.
Without three languages.

Small apps can keep their schema, API and UI in three primary source files. Typed manifests, tests and deployment configuration sit alongside them as the app grows.

01 / DATABASE

schema.acore

table tasks {
  title: Sqlite.Text()
}

Describe the data and supported constraints.

02 / BACKEND

application.acore

model Task {
  title: String(maxLength: 120)
}
endpoint create_task(...)

Declare typed operations, failures and policies.

03 / FRONTEND

main.acore

page Home {
  query tasks = Board.list_tasks(...)
  view { TaskBoard(...) }
}

Connect the same contract to web and native UI.

Illustrative excerpts, not a runnable three-file bundle. Orbit includes additional models, persistence code, migrations and tests. Generated files and setup are excluded from the authored-source counts.

05 / HOW AN AGENT FINDS AND CHANGES THINGS

One sign-in feature.
Very different context.

Adding Google sign-in means understanding identity, sessions, account linking and every screen that depends on them. The work begins before the first edit.

Illustrative existing-project scenario. Acore auth inspection is available; the provider-level semantic editing workflow shown here is planned.

ONE REQUEST / THREE WORKFLOWS

“Add Google sign-in.
Keep existing accounts and sessions working.”

AUTH + DATA + UI

INSPECTOR + PLANNED STUDIO AUTH EDITS

Acore

Start from the declared auth model.

TYPED AUTH NEIGHBORHOOD

Auth policy

Session rulesProtected operationsUI consumers

Follow declared relationships

SOURCE + ECOSYSTEM TOOLS

Flutter + Serverpod

Reconstruct the client–server auth flow.

INTEGRATION TOUCHPOINTS

server.dartgoogle_idp.dartclient.dartsign_in.dartauth schemaplatform config

Connect server, client, data and targets

SOURCE + ECOSYSTEM TOOLS

Next.js

Reconstruct the provider–session flow.

INTEGRATION TOUCHPOINTS

auth.tsauth routecallbackssign-in pageaccount adapterroute guards

Connect provider, accounts and consumers

THE CONTEXT COST

The hard part is connecting the provider to existing users, sessions and protected screens. Acore’s connected model gives agents a structured starting point. In source-oriented projects, agents assemble that context across integration files and library conventions.

Illustrative touchpoints, not mandatory file counts or a measured agent run. Auth.js and Serverpod provide Google sign-in integrations. Acore authentication profiles describe credential transport; Google provider integration and provider-level semantic edits are separate work. Every stack needs provider setup and security checks. This animation does not enable sign-in on the demo boards.

Acore auth declarations ↗Serverpod integration ↗Auth.js integration ↗

06 / UNDERSTAND THE IMPACT BEFORE YOU EDIT

Change one column.
See the ripple.

A database change can reach much further than a query. Follow its recorded dependencies through the API, application state and the pages and buttons people use.

Axiom Inspector · compiler-derived impact paths · available in Alpha

EXAMPLE / RENAME A STORAGE COLUMN

tasks.titletasks.name

Trace the consumers before deciding which parts need to change. A storage rename may keep the public API field unchanged.

01 / DATABASE

CHANGED COLUMNtasks.titleRename storage field

02 / PERSISTENCE

TYPED MAPPINGTask storetitle ↔ tasks.titleReads and writes this column

03 / API

SHARED FIELDTask.titlePublic task data

READ OPERATIONlist_tasksReturns task data

WRITE OPERATIONScreate / updateAccept task input

04 / UI STATE

QUERYBoard.tasksLoads the board

FORM STATEEditor.draftHolds task input

05 / EXPERIENCE

Start with the changed database column. Recorded dependency · review candidate

FOLLOW ONE CONSUMER

Select a page, text or button above to see the path.

tasks.title→Task store→Task.title→update_task→Editor.draft→Save task

CONNECTED APPLICATION MODEL

Ask for the impact.

Follow compiler-recorded relationships and review the source evidence, affected targets and coverage limits together.

axiom inspect impact <column-id> .

SOURCE-ORIENTED PROJECTS

Assemble the impact.

An agent connects schema references, queries, API shapes, state and UI usage across tools and files. Dynamic SQL and indirect bindings make completeness harder to establish.

Illustrative map, not a captured impact report for these boards. Requires recorded typed persistence mappings and UI bindings. Highlighted consumers need review; they do not necessarily break. Opaque SQL, external code and missing mappings stay unknown. Other stacks can add static analysis and dependency metadata; AxiomCore provides a shared application evidence model.

Explore Inspector change impact ↗

07 / THREE APPROACHES, SIDE BY SIDE

Compare the
building blocks.

All three demos implement the same product. Compare how each stack organizes UI, data, runtime behavior and tooling. AxiomCore connects those declared relationships in one application model.

Capability	Acore CONNECTED MODEL	Flutter + Serverpod	Next.js
Application source	Acore across declared layers	Dart UI + Dart server	TypeScript UI + server
Web + Android + iOS	Shared UI; native target hosts	Shared Flutter widgets	Web; native needs a separate approach
Web presentation	DOM-based web host	App-centric Flutter renderer	HTML, React and server rendering
Application impact	Compiler-derived cross-layer evidence	Project tooling and application conventions	Project tooling and application conventions
Agent editing	Typed node tools in Studio preview	Source and ecosystem tools	Source and ecosystem tools
Caching	Declared policies and invalidation	Serverpod cache + application logic	Framework and application caching
Extension authority	Sandbox + explicit capability grants	Application and platform choices	Application and platform choices
Release evidence	Pinned, signed contract artifacts	Build and deployment pipeline	Build and deployment pipeline

ABOUT THE NUMBERS

Source counts use the same retained-authored-code boundary, including tests. Generated code, dependencies, assets and project setup are excluded. File count and line count describe footprint; they do not establish development speed or token savings. Broader semantic editing is a Studio preview/roadmap capability, rather than a claim that this benchmark used every tool.

Read the detailed benchmark and methodology ↗

START BUILDING