A PHP framework your coding agent can read in one go.
The whole request cycle is about 115KB of plain PHP — small enough to sit in an agent's context window alongside your task. One login, many apps, ordinary hosting, and several live products already running on it.
Prototype With Your Coding Agent
Point Claude Code (or any coding agent) at this framework and describe what you want. It already knows the conventions — auth, data layer, notifications — so it reuses them instead of building a new one-off stack every time.
A shared task tracker
Build me a kanban-style task tracker, inspired by Trello — boards, columns, and draggable cards — that lets me share task lists with other people and see who's working on what. Use the framework's existing login and multi-user account system rather than building new auth, and follow the model/controller conventions already used by other apps in this framework.
A property-alert scraper
Build me a tool that checks property listing sites near a postcode I specify and messages me when something new shows up within my budget. Use the framework's existing cron pattern for the periodic check and its notification system for the alert, instead of building either from scratch.
Language-learning flashcards
Build me a spaced-repetition flashcard app for learning a language — decks I create myself, a review queue that resurfaces cards I keep getting wrong, and simple progress stats. Use the framework's data layer for storing decks and review history, and its existing login so my progress is tied to my account.
A habit tracker
Build me a habit tracker where I log a daily check-in for a handful of habits and see a streak count and a simple calendar heatmap for each one. Use the framework's login so it's private to me, and its existing form and view conventions rather than a bespoke frontend.
A shared task tracker
Build me a kanban-style task tracker, inspired by Trello — boards, columns, and draggable cards — that lets me share task lists with other people and see who's working on what. Use the framework's existing login and multi-user account system rather than building new auth, and follow the model/controller conventions already used by other apps in this framework.
A property-alert scraper
Build me a tool that checks property listing sites near a postcode I specify and messages me when something new shows up within my budget. Use the framework's existing cron pattern for the periodic check and its notification system for the alert, instead of building either from scratch.
Language-learning flashcards
Build me a spaced-repetition flashcard app for learning a language — decks I create myself, a review queue that resurfaces cards I keep getting wrong, and simple progress stats. Use the framework's data layer for storing decks and review history, and its existing login so my progress is tied to my account.
A habit tracker
Build me a habit tracker where I log a daily check-in for a handful of habits and see a streak count and a simple calendar heatmap for each one. Use the framework's login so it's private to me, and its existing form and view conventions rather than a bespoke frontend.
Built On, Not Just Around
The fundamentals a new app actually needs on day one
-
A Real Data Layer
- A fluent query builder (parameterized by construction — every value goes through a bound placeholder) plus a lightweight Active Record ORM with real multi-database context switching built in.
-
A Documented Security History
-
Secure session cookies, AES-256-GCM encryption, login throttling, CSRF — and a dated log of the specific vulnerabilities found and fixed along the way, including the embarrassing ones. See
SECURITY_JOURNAL.md. -
Testing, Not Bolted On
-
An auto-discovery test runner picks up any
*_test.phpin the framework or any app — CLI or browser, no config. -
Forms That Match Your Stack
- One form definition renders as Foundation or Tailwind markup — switch CSS frameworks per app without rewriting every view.
And If You're Building More Than One Thing
Most frameworks assume one app, one install. This one can host several apps under a
single install with one shared login and session, and access granted per user, per app — set DEFAULT_APP and any
one of them serves from the domain root, no code changes required. Apps can also call
each other directly over a built-in API: in production, a mail app triggers actions in
a separate coffee-networking app the moment a matching enquiry arrives, no message
queue or shared database required.
This is the trade a lot of people are already making without a name for it — a coding agent makes a fifth self-built tool cheap, but each one still wants its own login, billing, and admin panel unless something ties them together.
Mail app (action rule fires)
└─► api_client::post('coffee', 'index/api?action=add_members', $key, $payload)
└─► POST https://yourdomain.com/coffee/index/api?action=add_members
Headers: X-API-Key: {key}
Body: {"members": [...], "group_name": "..."}
└─► Coffee app validates key, dispatches action
Where This Fits
Not a Laravel replacement — a smaller, more auditable tool for a different job. Honest on both sides, because the gaps are what make the strengths credible.
For
Solo builders and small teams running several small apps on shared or reseller hosting, with a coding agent doing most of the typing.Not for
Teams that need Composer packages, queues at scale, or a large ecosystem and hiring pool.Status
Single maintainer. In production on a handful of live products; no enterprise-scale track record.| This framework | Laravel / Symfony | |
|---|---|---|
| Query layer | Fluent builder + lightweight Active Record ORM, parameterized by default | Eloquent / Doctrine — far more mature, relationships, migrations, events |
| Dependency injection | None — direct instantiation, a known and documented trade-off | Full IoC container |
| Package ecosystem | None | Thousands of packages, Composer-native |
| Multi-app hosting | Native — shared login/session, one install, several apps | Not a built-in concept — one app per install by default |
| Security track record | A dated, specific public fix log for this codebase | Large, battle-tested install base — different kind of evidence, also real |
| Fits in an agent's context | Yes — the core request cycle is roughly 115KB, so an agent can read all of it before writing code | No — agents read selectively and rely on training data |
| Surface area | Small enough to read end-to-end in an afternoon | Large — that's the cost of the ecosystem |
What's Running on This Install
Ecosystem Showcase
This particular instance's own apps — a dev/showcase install, not what a fresh clone starts with.
Domain Finder
Discover available domain names through dictionary-based generation, swipe-trained preferences and bulk WHOIS scoring.
Budget
An intelligent Personal finance Assistant that learns your spending patterns and reconciles with your bank account.
Read the Code Before You Trust It
That's true of any framework, but this one is small enough to actually do it — clone it, point your coding agent at it, and see what's really there.
Read the Docs →