# DaybydayCRM: a Laravel CRM modernised on a develop branch, with no licence file

> DaybydayCRM is a self-hosted customer relationship system for tasks, leads, invoices, time registration, absences, appointments and documents, and its development branch is years ahead of its last tag while the README, the agent instruction files and the tooling describe an active modernisation. Two facts decide whether you can use it, though, and neither is in the feature list: there is no licence file in the repository, and the top-level Dockerfile still pins a PHP version the current framework cannot run on.

**Bottelet/DaybydayCRM** — DaybydayCRM an open-source CRM, to help you keep track of your daily workflow.

- Repository: https://github.com/Bottelet/DaybydayCRM
- Website: https://daybydaycrm.com
- Stars: 2,329 · Forks: 767
- Language: JavaScript
- License: not declared
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/bottelet-daybydaycrm

## No licence file, in a project that calls itself open source

Start here, because it is the only finding in this repository that can stop an evaluation on its own. The project describes itself as an open-source customer relationship management system, available as an open-source self-hosted platform, and the site offers a hosted version of the same product. The repository's top-level file list contains no licence file of any kind, and no licence is identified for the project. That combination has a specific consequence that no amount of code reading changes. Without a licence, the default position is that the copyright holder retains all rights, so you can read the code and run it, and the default position on modifying it and on redistributing it is that you may not. Publishing source on a public forge is not a grant, and the word open source in a readme is not a licence. For a system that holds your client list, your invoices and your staff's time registrations, that is not a formality to be resolved by a lawyer later, it is a question to put to the author before you spend an afternoon setting it up. The funding model around the project is stated in the readme and is worth knowing in the same breath. There is a commercial hosted offering, a sponsor page, an invitation to send pull requests, and a sentence saying the project continues to ship features, releases, support and fixes through community and sponsor support. That is a coherent way to fund maintenance, and it does not change the licence question, but it does tell you that there is an organisation behind the repository to ask. The rest of this article assumes you have that conversation, because everything else is conditional on it.

## The default branch is develop, and the newest tag is from December 2021

The second structural fact is the version story, and it explains a great deal about the rest of the repository. The default branch is called develop, not main, so a clone gives you the branch where work happens. The most recent releases are 2.1.0 in August 2020, 2.2.0 in April 2021 and 2.2.1 on 2021-12-01, and there is nothing after that. The last push to the repository was on 2026-08-31. So the source is being changed weekly while the newest tag is close to five years old, and anyone who installs a release is installing code from the Laravel 8 or 9 era while the README describes Laravel 12. The repository is candid about this rather than hiding it, and that candour is the most useful thing about it. The contributor guide points at a modernisation roadmap, at an architecture document that explicitly carries technical debt notes, at testing and isolation standards, at a changelog for the current branch, and at an agent workflow guide. Five separate sets of instructions for coding agents are committed, which is not vanity, it is a signal about how the project expects maintenance work to be done in 2026. The current stack is listed as PHP 8.3 or later, Laravel 12, MySQL or MariaDB, Redis with queue support, Blade with Vue 2 and Vite, three test tools, and Docker Compose with Makefile-driven workflows. That is a current stack, and it belongs to the develop branch. The practical question for an evaluator is which of the two you want: the 2021 release, which is a different application with different dependencies and no documented upgrade path to the modern one, or the develop branch, which is undocumented as a deployable target. Neither the readme nor the wiki pages it links choose for you.

## One line of architecture, and six conventions that constrain every contribution

The architecture section is the most reusable part of the documentation, because it names both the layering and the rules that keep the layering honest. The chain is routes, then middleware, then controllers, then services or actions, then repositories or models, and finally views or a JSON response. Underneath that sit six conventions. Controllers are thin. Validation happens in form request objects rather than inside controllers. Business logic is extracted into services or actions rather than accumulating in the controller. Fixed value sets are expressed as enums and helpers instead of string literals scattered through templates. Model behaviour is attached through observers and traits rather than written inline in controllers. And the choice between an HTML response and a JSON response is explicit at every call site, which is what makes the same application able to serve a web interface and an API from one codebase. Two contributor rules show what the test suite has been fighting. Tests are to be self-contained and factory-driven, new HTTP and controller coverage goes in a specific feature test directory, dates are normalised before assertions, and users are refreshed after a permission change inside a test. Those last two are not style preferences, they are defences against an object graph model that caches state in memory across a test, and a project that has to state them has clearly been burned. The one rule to read twice is the last instruction before the guide ends, which says that if workflows are available all tests should pass on continuous integration, or failing expectations should be updated to reflect intentional behaviour changes. Updating an expectation is legitimate and sometimes correct, and it is also the easiest way to make a red test suite green without fixing anything, so it is worth asking for the diff when a pull request does it.

## Three frontend build systems, Vue 2, and a default test command that is not the unit tests

The frontend configuration is where a long-lived project's history shows most clearly, and it is worth inventorying before you plan any interface work. Three build configurations are committed. There is a Vite configuration, a Webpack Mix file and a Gulp file, and the readme names Vite as the current one, which means the other two are generation one and generation two of the same application. The dependency list is from the same era. Vue is pinned to the 2.7 line with the Vue 2 specific Vite plugin and the matching template compiler, and the component library is Element UI, which is the Vue 2 library. The stylesheet framework is Bootstrap Sass at version 3, with jQuery at 3.7, jQuery UI, a caret plugin and a table library alongside. The charting dependency is Chart.js at version 2.9.4, two major versions behind the line the rest of the toolchain occupies. There is also a timeline component, a rich text editor and a file picker. So the picture is a current back end and a current build tool wrapped around a several-year-old front end, which is entirely workable and means any new interface work inherits those choices rather than making its own.

```json
  "scripts": {
    "dev": "vite",
    "watch": "vite",
    "hot": "vite",
    "build": "vite build",
    "prod": "vite build",
    "test": "npm run test:e2e",
    "test:e2e": "playwright test",
    "test:e2e:list": "playwright test --list",
    "test:e2e:file": "playwright test",
    "test:e2e:stop-on-failure": "playwright test --max-failures=1",
    "e2e:install": "playwright install chromium"
  },
```

Three things in that block are worth flagging to anyone scripting this repository. The same Vite command appears three times under three names and the build command twice, which is a compatibility shim for something rather than a design. The default test command runs the browser suite, not the PHP unit tests, so a bare test invocation in continuous integration is an end-to-end run. And the single file script is byte for byte the same as the full suite command, with no argument placeholder, so running one spec depends on how the caller passes the path. There is a lock file for two package managers and the documented quick start uses one of them while the documented test commands use the other, which is a small trap worth knowing before you file a bug about a version mismatch.

## The top-level Dockerfile pins PHP 7.3, and the documented Docker path does not use it

The top-level file list has a Dockerfile, and if you build it you will not get what the readme describes. Its first line is a PHP 7.3 image with the fast process manager, and it carries a maintainer declaration in the form that stopped being supported years ago. It installs the database client and a set of build libraries, then installs the mcrypt extension from PECL with a comment explaining that mcrypt was removed from PHP 7.2, which dates the file precisely. It installs a Node runtime from a distribution's setup script pinned to version 11, a package manager, a Python client for a cloud CLI, and it creates an unprivileged user with a fixed identifier. None of that can run the stack the readme lists. The current stack is PHP 8.3 or later on Laravel 12, and a framework of that generation will not start on a 7.3 runtime. The resolution is in the compose file, which does not use the top-level Dockerfile at all. It builds the PHP service from a Dockerfile inside a per-service directory and the web server from another one, with separate configurations mounted for each, so the documented container path is a different and newer set of images that the top-level file is a leftover of. The trap is specific: someone reading the repository root, finding a Dockerfile and building it, gets an image that cannot start the application, and the readme does not say that file is obsolete. Two other files in the root point at a deployment path the readme never mentions. There is a build specification, a deployment specification, a directory of deployment configuration and a Python extraction script, which together describe an AWS pipeline for building and shipping the application, and it is documented nowhere in the text you are reading. If that path matters to you it is worth finding out how current it is, and if it does not, it is worth knowing it is there before you assume the repository has no deployment story beyond Docker Compose.

## Two quick starts, two databases, and an environment file tuned for a developer

The readme gives two quick starts and they do not use the same database. The container path is three make targets whose abbreviations are not expanded anywhere in the text, so the wiki is the reference for what they do, and one of them drops you into a shell inside the running stack and another performs setup. The host path is a longer sequence: install the PHP and the JavaScript dependencies, copy the example environment file, generate an application key, run a fresh migration with seeding, build the front end and start the development server. All of that works from a clean checkout with a PHP and a database to hand.

```bash
composer install
yarn install
cp .env.example .env
php artisan key:generate
php artisan migrate:fresh --seed
yarn run build
composer dev
```

The mismatch is in the environment file, which selects SQLite by default and leaves the MySQL settings commented out, while the compose file runs MySQL 8 with its own credentials. So the two documented paths are not the same application configuration, and a problem that appears only on the host path is often a database difference rather than a code problem. The rest of the example environment file is a developer's file, and copying it to a server produces something that is not what you want. Debug mode is on, the log level is debug, the mailer is set to log so no mail is sent, broadcasts go to the log, sessions and the queue and the cache all go to the database, and a site-wide switch disables the onboarding tours, with a comment saying that is useful for staging and end-to-end environments. The compose file is a developer's file too. It publishes the database port and the fast process manager port to the host, sets the database root password to a single word, disables empty passwords, and uses a compose file version key that current tooling ignores. The health checks and the ordering conditions are good, since each service waits for its dependency to report healthy rather than sleeping, and that pattern is worth copying into your own setup.

```bash
make up
make dsh
make setup
```

For a production deployment, treat both files as scaffolding. The wiki's installation pages are the documented path, and the example environment is a starting point for a local machine rather than a template for a server.

## Three test tools, a static analysis baseline, and a syntax lint as the minimum bar

The testing setup is the most modernised part of the project and the easiest to appreciate, because the commands are all documented in the readme rather than hidden in a wiki. On the PHP side there are make targets to run the suite with stop-on-failure behaviour, to filter to a subset by test name, to run in parallel, and to stop at the first failure. On the browser side there is an install target that fetches the driver, a target to run everything, one to list the discovered tests, one to run a single spec file given as a path variable, and variants that stop at the first failure for both. Both layers are also reachable directly through the package manager. Two browser stacks are installed, a Laravel browser testing tool with its own configuration file and a standalone runner, which is one more than most projects need and suggests the newer one is replacing the older. The static analysis configuration is the other thing to note. There is a configuration file and a baseline file, and the existence of a baseline means the project has formally recorded the static analysis errors that already exist so that new code has to be clean while old code is grandfathered. That is the honest way to introduce analysis to a large codebase and a better approach than turning it off, and it also tells you the debt is known rather than hidden. Alongside it sit a code style configuration for automatic formatting and a refactoring configuration for automated code transformations, which is the tool you would use to carry out the modernisation in bulk. The minimum bar before a push is stated as a syntax lint over every tracked PHP file, which takes seconds and catches the class of error that a parse-level check exists to catch.

## The feature list is complete for a small team, and the readme is written for contributors

The functional scope is easy to state and worth stating precisely, because for a small team it may be complete. Tasks and leads, invoice management, time registration so people can log hours against work, absence and vacation registration for staff, appointments for both clients and internal users, roles and permissions, a global search, a client overview screen, and document upload with per-client file tracking. That is the everyday surface of a small office, and the readme is candid that it defers to the website for a broader feature overview, which is an admission that the list here is a summary. A demo is available, which is the fastest way to judge whether the workflow matches yours. Two observations about the readme as a document. It is written for contributors, not for evaluators. There is no system requirements list, no statement of which databases and versions are supported, no upgrade or migration guidance between versions, no security policy in the top-level files, and no reference to the changelog from the getting started section even though one is committed. The installation instructions are three wiki links. And the last thing the readme says is that feedback is welcome, which is a reasonable place for it to end but it means the questions an evaluator needs answered are in documentation this page does not link to. Given the licence position and the version gap, that is where I would spend the next hour anyway, and the project does publish a demo, a site and a sponsor page, so there are people to ask.

## Conclusion

DaybydayCRM is worth evaluating if you want a small, self-hosted CRM covering tasks, leads, invoices, time registration and document tracking without assembling one, and the domain coverage in the feature list is complete enough for that. Two things have to be settled before anything else, and neither is a technical question. Ask the author for a licence, because the project is described as open source and the repository contains no licence text, so there is no grant to rely on and no way to decide whether you may modify it, and that conversation is the first gate. Then work out which code you are actually deploying, because the default branch is the development branch, the newest tag is 2.2.1 from 2021-12-01, and the top-level Dockerfile builds against a PHP version the current framework does not support, so a clone plus build is not a supported path. If both of those clear, the modernised stack is genuinely current, with Laravel 12, PHP 8.3 or later, Vite and Playwright, and the architecture is documented precisely enough to contribute against.

## FAQ

### What licence is DaybydayCRM under?

The repository contains no licence file and no licence is identified for the project, although the readme describes it as open source. Without a licence text there is no grant to rely on, so the question has to be put to the author before you modify or redistribute it.

### Which version should I install, and what is the default branch?

The default branch is the development branch, and the newest release is 2.2.1 from 2021-12-01, while the last push was on 2026-08-31 and the documented stack is Laravel 12 on PHP 8.3 or later. Installing the release gives you code from 2021 with a different framework generation, and there is no documented upgrade path between the two.

### Can I build it with the Dockerfile in the repository root?

That file is a leftover. It starts from a PHP 7.3 image and installs extensions and a Node runtime that are too old for the current framework, and the compose file does not use it. The documented container path builds the PHP and web services from per-service Dockerfiles inside a per-service directory.

### What do the two quick start paths use for a database?

Different ones. The example environment file selects SQLite by default with the MySQL settings commented out, while the compose file runs MySQL 8 with its own credentials and publishes the database port. A problem that appears on only one of the two paths is often that difference rather than a code fault.

### How do the tests run?

Through make targets for the PHP suite, including filtered and parallel runs, and through make targets for the browser suite, including a single spec given as a path variable and a list-only mode. The default test command in the JavaScript manifest runs the browser suite rather than the unit tests, and a static analysis baseline records the pre-existing errors so new code is held to a clean standard.

## Sources

- [Bottelet/DaybydayCRM on GitHub](https://github.com/Bottelet/DaybydayCRM)
- [Issues](https://github.com/Bottelet/DaybydayCRM/issues)
- [Project website](https://daybydaycrm.com)
- [README](https://github.com/Bottelet/DaybydayCRM/blob/develop/README.md)
- [Releases](https://github.com/Bottelet/DaybydayCRM/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bottelet-daybydaycrm