The team behind Dotkernel
Dotkernel started as an internal tool for handling complex architectures, built because we needed it ourselves. We released it under MIT because the PHP community gave us the components it stands on. Everything here is made by a team that has to live with its own decisions.
A team that shares the whole codebase
Nobody here owns a private corner of the code. Every module follows the same structure, every handler is named the same way, and every application is assembled from the same explicit wiring - so any developer on the team can open any part of the platform and know where they are. That is a deliberate design choice, and it is what makes reviewing each other's work possible rather than polite.
Getting better at this is part of the job, not something we hope happens after hours. Our developers read the upstream source of the components we depend on, write the documentation the next person will need, and turn every repeated mistake into a written rule instead of a reprimand. When a review catches the same thing twice, that is a gap in what we have written down - and we fix the writing.
Every change reviewed by someone else
One structure across every application
Learning time counted as real work
Decisions written down, not remembered
Six things we are not willing to trade
None of these are aspirations we printed on a wall. Each one shows up somewhere you can check - in a repository, in a license, in a config file, or in the way a release is handled.
Better together than alone
The codebase is the team's, not a collection of territories.
Work is planned out loud before it is written, reviewed before it is merged, and documented before it is called done. Consistency is what makes that cheap: because a module in one application looks like a module in every other, a reviewer spends their attention on the decision being made rather than on finding their way around.
Developers who keep growing
Nobody stays where they started.
Our developers learn by reading the source of the components they build on, by writing the guides and reference docs the rest of the team relies on, and by taking the review notes that come back to them as material rather than criticism. Every breaking change we publish ships with the article explaining it - writing that explanation is how we make sure we actually understood the change.
Giving back to PHP
MIT licensed, and answered in public.
Dotkernel stands on Mezzio, Laminas and Doctrine, so our work goes back out under a permissive
license with nothing held behind a paid tier. The team answers questions on our own components
and on the Laminas ones underneath them, publishes the support status of every
dot-* package instead of leaving it to guesswork, and keeps the discussion where
anyone can read it.
Every need you can imagine
The unglamorous requirement is the one that decides a project.
Our skeletons come out of real client work, which is why they answer questions nobody asks in a demo: sharing a database with an application that was there first, running several connections at once, anonymizing an account instead of deleting the row, hearing about a bug that never threw an exception. We would rather carry that detail for you than let you discover it in your second sprint.
AI with guardrails on
Adopted everywhere, trusted nowhere by default.
AI assistance runs through every part of how we work, under rules we wrote down first. Secrets are never loaded rather than merely redacted, so credentials and signing keys stay out of the context window entirely. Sessions start by proposing a plan instead of editing files. Linters report and never rewrite. A package is never named from memory - it is verified against what is actually installed. And a human reviews every diff, because accountability does not delegate.
Best product, best tools
Chosen for what they will still be worth in three years.
We build on interfaces from the PHP Framework Interop Group so a component from one vendor can be replaced by another, keep static analysis at a strict level, ship the test suite with the skeleton rather than promising it later, and stay current with the PHP versions our dependencies support. When a tool stops being the right answer, we say so - publicly, with a migration path.
Where you can check any of this
The QA gate
Coding standards, static analysis at a strict rule level and the test suite all run before a change is merged - and "make the checker quiet" is never an accepted fix.
Documentation as a deliverable
A feature is not finished until the next developer can pick it up from what is written, which is why docs.dotkernel.org is maintained alongside the code.
Deprecations, not surprises
Endpoints announce their own retirement through response headers, so a client finds out from the API rather than from a changelog nobody read.
Support status in public
Every package publishes where it sits in its lifecycle, so choosing one is never a bet on whether it is still maintained.
Secrets stay out of the tooling
Local configuration, environment files and OAuth keys are unreadable to our AI tooling by configuration, not by convention.
Supported by JetBrains
Our open-source tooling is supported through the JetBrains open source programme - one of the ways this work stays sustainable.
Built by a team that has to live with its own decisions.
Dotkernel is developed and led by the dev team at Apidemia. If you are weighing up a platform, hiring a team, or just want to argue about middleware, we would rather have the conversation than the brochure.