The first deploy from our new portal did absolutely nothing.
At least, that is what it looked like from the server's point of view. The pipeline reported success, the upload landed where it was supposed to, and every status indicator suggested the deployment had worked. But the server kept running the previous build, calmly ignoring the fact that we had just pressed Deploy.
We will come back to that bug, because it turned out to be one of the more useful parts of the whole project.
This post is about why we let Claude Code help us build internal operations tooling, what we learned from the process, and why we have decided to open-source the result.
Maretha has always been intentionally lean. We are a small team of senior engineers and architects focused on making our clients the smartest people in the room when it comes to content management software. That is the work clients hire us to do, and it is where we want most of our time and attention to go.
The downside is that internal projects have always had to compete with client work. Like a lot of small technical teams, we accumulated operational shortcuts over time. They worked well enough, so they stayed. They were not broken enough to force the issue, even if everyone knew they could be better.
Our lab environment was a good example. Deployments involved a CI pipeline, an SSH session, and a handful of steps that mostly lived in one person's head. The process was reliable, but it was not especially accessible. We would never have recommended that setup to a client, but we tolerated it internally because improving it meant taking time away from billable work.
For a long time, that trade-off made sense. Then the math changed.
After enough implementations and migrations, you start to notice that the same operational questions appear everywhere. The product names change, the APIs change, and the architecture changes, but the underlying questions are remarkably consistent.
What is deployed right now? Who changed it last? What exactly changed? Can we roll back quickly if something goes wrong? Can someone who is not the specialist run a release safely?
We have asked those questions on every DAM and ECM platform we have worked with. During migrations, they become even more important because, for a while, you are often answering them for two systems at the same time.
That was the real motivation behind the portal. We were not trying to build a big platform. We were trying to make a few operational answers easier to find, and a few risky actions safer to perform.
The result is our new ops portal.
It is intentionally simple. You sign in with a company Google account, and from a single page you can upload an add-on, trigger a deployment, pin a release, roll back to a previous version, watch pipeline progress in real time, view live server logs, and see an audit trail of who did what and when.
Maretha Ops Dashboard
Under the hood, the system is smaller than it might look: a static frontend, a lightweight API, one serverless function, and infrastructure defined as code. The existing CI pipeline still does the heavy lifting, because that part already worked and we already trusted it. The portal simply turns a collection of specialist-only steps into something the whole team can use without needing to memorize the release process.
The process was less "tell AI what you want" and more like pairing with an extremely fast engineer.
We started where we would normally start: architecture. What are the constraints? What should remain manual? What should be automated? Where are the security boundaries? What are we willing to maintain six months from now?
Once those decisions were made, Claude Code handled a surprising amount of the implementation work, including Terraform, Lambda functions, API wiring, and the deliberately boring frontend. Boring was a feature here. This was operations tooling, not a product demo, and we wanted something predictable more than something impressive.
We kept control of the sensitive parts. Credentials stayed with us. Production access stayed with us. Final decisions stayed with us. Claude generated code, helped debug issues, and accelerated implementation, but we reviewed, validated, and decided.
The initial build took about an hour. Going live took longer, mostly because we deliberately handled account setup and credentials ourselves. Some things are still better done by human hands.
This worked because the team is deeply technical, not because we delegated the technical thinking away. Years of platform experience helped us define the right system. Claude helped us build it faster.
Back to the deploy that did not deploy.
On launch day, the team found four issues. The most interesting one was the deployment that appeared to succeed but changed nothing. You could upload an add-on, the pipeline would run successfully, everything would turn green, and the server would continue running the old build.
After some investigation, the root cause was almost elegant. Deploying the same code produced the same version fingerprint as the version already running. From the cluster's perspective, there was nothing new to deploy, so it did exactly what it had been instructed to do: nothing.
Claude helped trace the issue, and we changed the deployment process so every build now receives a unique stamp. All four launch-day issues were fixed and deployed the following day.
That turnaround is probably the most important outcome of the project. For a small team, polish often gets postponed because the cost of improving something outweighs the immediate benefit. That balance feels different now.
The first version was built in one hour. The operating cost is effectively zero. Four launch-day issues were fixed within 24 hours. Most importantly, the portal replaced a deployment process that previously depended on one specialist knowing exactly what to do.
Historically, the end of a project often included a runbook: a document explaining deployments, troubleshooting steps, escalation paths, and operational procedures.
Runbooks are necessary, but they age quickly. Tools tend to age more gracefully because they encode the process instead of merely describing it. A working deployment portal can enforce the right steps, record what happened, and make rollback visible. A document can only ask someone to be careful.
The same economics that stopped us from building internal tooling also limited what was practical to deliver to clients. That is changing. A small team of experienced engineers can now build operational tooling that previously would have required a dedicated platform team to justify.
When possible, we would rather leave a client with a working tool than a document explaining how to be careful.
We have open-sourced the portal in anonymized form: Maretha Operations Portal.
Today it happens to operate a Nuxeo LTS2025 open-source environment, but the pattern itself is platform-agnostic. If your platform has APIs and a deployment pipeline, you can adapt it. Read it, fork it, and replace the API calls with your own.
And if your deployments still depend on one person knowing exactly which buttons to press, the economics may have changed for you too.
Keep reading
It’s January 2023 so what better time to start setting some good tech resolutions? As always, few of my yearly tech resolutions are to write better code, optimize more, save $ on the infrastructure cost and of course, learn as many new things as possible (Integrate with chatgpt — anyone?). On the topic of writing better code — maybe now it’s an ideal time to refactor/ avoid making some mistakes that could potentially lead to a lot of $ spent on infrastructure and poor performance of your application overall?
Read articleUsers complaining that things take too long in Nuxeo? Many Works land in the default Kafka queue. Here’s how to split them into dedicated queues for better perf.
Read articleWhen I signed on to help build the new website for Maretha Solutions, I knew it was going to be a good project. What I didn't expect was how much the process itself would teach me — not just about web design, but about how I work, how teams work, and how AI tools fit into all of it.
Read articleTell us what you're struggling with, and we'll tell you how we can help you.
Talk to us
