How Stellify works

Production-ready Laravel, built surgically and reused — not generated from scratch every time.

Your agent builds real, full-stack Laravel — referencing proven code instead of regenerating it — and you own every line. The power of AI, without the mess.

Skip the build entirely with Constellation — or spend up to ~14× fewer generated tokens referencing what's already in your library

How do you want to build?

Point Cursor, VS Code, Claude Code or Windsurf at Stellify over MCP, and your agent builds the feature. Run several agents at once — surgical, structured edits mean they work in parallel without clobbering each other.

Any MCP-compatible editor works.

Then build, sync, and pull.

Ask your agent to build a feature using Stellify's MCP. When it's done, sync to GitHub and pull it down — standard Laravel, on your machine.

01

Ask AI to build it

Your agent works through Stellify's MCP — surgical, validated edits to your structured project, not whole-file rewrites.

02

Sync to GitHub

When it's done, Stellify assembles your structured code into standard Laravel and pushes it straight to your GitHub repo.

03

Pull to your desktop

Pull it down with git pull — conventional Laravel you can run, test and deploy anywhere. No dependency on Stellify.

Build directly with AI in the Stellify editor.

Hands-on, in the browser — nothing to install. The same structured edits and assembler, with AI built in, so you can build and refine without leaving the page.

AI built in · new or existing project · export to standard Laravel anytime.

Or skip the build entirely

Pull ready-made functionality — auth, billing, dashboards — from the Constellation App Store straight into your project.

Browse Constellation
Measured — read the benchmark

Referencing proven code costs the same whether it's 100 lines or 1,000. Writing it doesn't.

Every unit built on Stellify is indexed as structured code the moment it's authored. When the next build needs the same thing, your agent references it — one search, one reuse call — instead of writing it again. The reference costs a near-constant ~1.3K generated tokens no matter how big the module is; writing it yourself scales with the code.

Write it yourself

A file-editing agent writes a ~640-line payroll service — 27 methods of tax bands, NI, pensions and payslips — from the spec:

  • Generates every method, and the bill scales with the code: ~3.1K tokens at 130 lines, ~13.2K at 640
  • Pays that in full even though the same module was built before
  • ~13.2K generated tokens
Reference it from the library

The same module, already proven in the library — one search, one reuse call:

  • References the whole module — 27 methods, dependencies and all — nothing regenerated, nothing copied
  • Costs roughly the same ~1.3K tokens whether the module is 130 lines or 1,200
  • ~1.3K generated tokens · 10× fewer · up to 2× cheaper

Measured like-for-like against a plain file-editing agent, same model, same spec: at ~130 lines the reference generates 2× fewer tokens; at ~640 lines it's 10× fewer tokens and up to 2× cheaper; at ~1,174 lines it's ~14× fewer tokens and ~1.8× cheaper — and the gap keeps widening with size, because the reference cost stays flat while generation doesn't. Full methodology, evidence and the runs reuse lost in the benchmark write-up.

To be straight about it: on small modules the fixed overhead means the reference wins on tokens but not yet on cost — the crossover lands somewhere around 400–500 lines (interpolated), and beyond it referencing is cheaper outright. Generating brand-new code that doesn't exist yet costs more, not less, because of the structured overhead. The value compounds as the library grows: the bigger the functionality that's already been built, the more the next build saves.

The bigger lever

Pull a ready-made feature from the Constellation App Store and you skip the build entirely — the tokens an agent would have spent designing, writing and debugging it, you never spend.

That's where the maths flips hardest: when a feature already exists in Constellation, pulling it hands you working code and skips the build cost entirely — and every build that reuses it makes the next one cheaper still.

Secure

Secure as you build, and secure once you ship.

Security from two directions: what you export is standard, battle-tested Laravel, and what your agent builds is validated as it goes — so nothing malformed lands in your project.

Laravel security, built in

You export standard Laravel, so you inherit its defences — CSRF protection, SQL-injection-safe Eloquent, hashing, auth and validation. Years of battle-testing, not a bespoke stack to audit.

Bounded autonomy

Your agent works with bounded autonomy — the MCP tools are the guardrails. Bad parameters, missing dependencies and wrong types are caught the moment it acts, so nothing malformed makes it into your project.

Layered monitoring

Layered quality checks run on a schedule you choose — security smells and regressions are surfaced long before they reach your users.

Yours

Export or sync standard Laravel. No lock-in.

Your GitHub repo stays the source of truth. Stellify keeps an editable copy of whatever you choose to work on, and syncs it back as standard Laravel whenever you like.

Standard Laravel

PHP, Vue, Livewire and Blade — PSR-4 autoloading, conventional structure, idiomatic patterns. Open it in any IDE and deploy anywhere PHP runs.

Synced to your repo

Push to GitHub or export on demand, whenever you want. Your repo stays the source of truth.

Zero runtime dependency

Stellify is a tool, not a tenancy. Your shipped app carries no trace of us — adoption is fully reversible, so you can walk away and keep a working application.

Questions

How building in Stellify works, and what you walk away with.

Why not just let my agent edit my repo directly?

You can — and for a quick one-off change that is perfectly fine. Stellify works on structured records instead of raw text, so edits are surgical, the agent gets precise context instead of a wall of code, and every tool call is validated and points it to the next move. Same agent, sharper tools — and less back-and-forth. The measured saving is in reuse: when something already exists, you can reference ready-made functionality from the Constellation App Store straight into your project instead of paying to build it again. Either way you get standard Laravel, synced back to your repo.

What is code-as-data architecture?

Code-as-data architecture stores source code as structured database records (files, methods, statements, clauses) with UUIDs and relationships, rather than plain text files. Each code element is a queryable record the AI can read and modify directly, without parsing text or generating diffs. This is what lets a tool change one statement and leave the rest untouched — and serve the agent precise context instead of a wall of text.

What happens when I export or sync from Stellify?

The assembler reads your structured data, resolves dependencies between files, and generates standard Laravel — PHP, Vue, Livewire and Blade — like a bundler resolving an entire application. The output is a complete Laravel project (composer.json, package.json, routes, controllers, models, components) that you can sync to GitHub or export and deploy anywhere PHP runs. It has zero runtime dependency on Stellify.

Where does my code live — in Stellify or my repo?

Your GitHub repo is the source of truth. Stellify keeps an editable copy of whatever you choose to work on, so your agent and your team can make surgical edits, then syncs it back as standard Laravel whenever you like. What you keep in Stellify is up to you — it is there for editing, not as the only home for your code, and there is no lock-in either way.

Why Laravel?

Laravel's expressive syntax maps cleanly to structured representations — Eloquent relationships, route definitions and validation rules are inherently structured. Its strong conventions constrain the AI to generate consistent, idiomatic code, so the output is battle-tested framework code rather than a one-off pattern.

Can I use my existing Laravel knowledge with Stellify?

Yes. Stellify generates standard Laravel — Eloquent models, controllers, migrations, validation, routing. If you know Laravel, you can read and understand everything it creates. The structured storage is an internal representation; the output is conventional Laravel with PSR-4 autoloading, a standard directory structure and idiomatic patterns.

What happens when a Constellation app I've referenced gets updated?

Constellation apps are living code. Improvements to the canonical app flow through to the parts of your project that reference it unchanged — you'll be notified before changes land. Anything you've forked is yours and is never touched. If you want to keep any part of the app exactly as it is today, fork it — that preserves your version permanently.

Can I keep my version of a referenced app?

Yes. Forking preserves your version at whatever granularity you choose — a single statement, a method, or a whole file. Forks live only in your project and are unaffected by any future changes to the original.

Who maintains and updates Constellation apps?

Currently the Stellify team, working in the open with the platform's own maintenance tooling — audits, dependency updates, and integrity checks run against the canonical apps. Community contribution and a public say in changes are where this is heading as the platform grows.

Can an app's author see or change my project?

No. References point one way — your project reads from the canonical app; nothing reads back. Your code, your forks, and your data are private to your project, and you can export everything as standard Laravel at any time.

Point your agent at Stellify.

Build full-stack features from the editor you already use — surgical, secure, and synced straight back to your repo.

No credit card required