We build web systems, and we keep them running.
IntrAgile is a development company. We write custom web applications, we containerise the applications and sites that already exist, and we take on the operational side of both. Not a campaign, not a rebrand. Just code that runs in production and stays there.
services: app: image: &app_image registry.example.com/app:1.4.0 restart: unless-stopped healthcheck: test: ["CMD", "php", "artisan", "up"] worker: image: *app_image command: php artisan queue:work --tries=3We automate whatever would otherwise be done by hand twice.
Why the three together
That is the thread running through all three services, and it is what makes them one company rather than three. If a task has a repeatable shape, we would rather write it down once for a machine than perform it a third time ourselves.
On the Docker side that becomes environments generated from code and a deployment that is a routine step. In custom development it becomes intrapp.io, so permissions, users and audit logging are not written by hand again in every project. On WordPress it becomes updates and backups that run on their own rather than off a calendar reminder.
A piece of software that nobody can deploy is not finished, and a server nobody can rebuild is a single point of failure with a countdown on it. Splitting the two across two suppliers is where most of the arguing happens: the developer says the environment is wrong, the operator says the code is wrong, and the client pays for the conversation.
If we write it, the deployment and the environment come with it. If you already have an application and it works, we can take over just the infrastructure side and leave the code where it is. Either half stands on its own; together they are cheaper than the argument.
Who we work with
Typically small and mid-sized companies, where the system serves a few dozen people rather than a few million. Where there is a process that already works somehow, just with spreadsheets, emails and one person's memory.
You do not need an IT department for this, but you do need someone who answers. Behind every project that went well there was a person on the client side who described how the work actually happens, not how it is supposed to.
What we do not do
We do not do campaign sites, brand identity or marketing. We do not write native mobile applications for the app stores. And we do not take on a project where an existing product would be the better choice.
We say that at the first conversation, not at the end. We are not the cheapest offer either: what costs more with us at the start is that we write it down, test it, and make it something you could hand to someone else.
Blog
What we write about
What we write about are the decisions made before the first line of code: framework or custom build, container or shared hosting, off-the-shelf tool or your own.
-
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.
Start with a conversation
Describe the problem in a few sentences: 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.