How we actually build things
Writing about the decisions behind a project before the first line of code, from framework or custom build to Docker or a shared host.
Earlier posts
Everything we have written
-
The backup you never tried to restore
The alert arrives on a Tuesday morning. The primary server is unresponsive. The hosting provider reports a hardware failure on the underlying physical...
-
Anatomy of a webshell breach: from upload to root
On a shared VPS, four days passed between the webshell being uploaded and the actual attack. The entry point was an uploader that also ran PHP.
-
Off-the-shelf system, framework, or custom build: which one, and when?
The question isn't which technology is better, but how far the process you're trying to support diverges from the process a ready-made system assumes.
-
Dockerising Laravel: what's the difference between the development and production container?
A development container is built for fast feedback, a production one for stability. They are not one file with different variables, but two layers.
-
Why does it pay off to dockerise an existing WordPress site?
A WordPress site on shared hosting takes on risk with every update. In a Docker container the update is reversible, and rolling back is routine.
-
What does a company framework save on a custom build?
Half of every custom project is the same as the last one. The question is whether you rewrite that half for every client, or build it once.
Have a project that needs this kind of thinking?
Describe the problem in a few sentences, covering what the system has to do, what exists today, and by when you need it. You will get an honest answer, including the answer that we are the wrong company for it.