November 6, 2026
AI has fundamentally changed how we build software. But implementation is only one part of the job. Architecture, business knowledge, testing, and understanding real user workflows still require experienced developers.
By Guido Boyke
I’ve been developing software for more than 30 years, including about 20 years with Ruby on Rails.
I’m a full-stack developer: frontend, backend, and everything in between. I’ve worked in startup incubators, helped other startups grow, and been self-employed for many years.
For my client work, I used a ticketing tool to communicate with clients, manage projects, and handle billing. It always felt clunky. Over the years, the software became more expensive without getting significantly better.
Eventually, I decided: I’ll build this myself.
That decision led to Lalabase, which has grown over the past two years into a comprehensive project management platform for agencies working on client projects.
It brings together tickets, time tracking, documentation, meetings, and an AI assistant that can answer questions using information from across a project.
It’s built with Ruby on Rails and Hotwire, without React. Clients have been using it since September 2025. In October 2026, I released the source code on GitHub under the GNU Affero General Public License (AGPL-3.0-only).
That wasn’t an easy decision. Yes, I wrote a lot of the code with AI. But this wasn’t a weekend of vibe coding. Months of work went into it.
So, why give it away?
Before answering that question, I’d like to explain how I actually built it. Many people in the Rails community are still skeptical about AI-assisted development. I understand that. I was, too.
From Autocomplete to Conductor
At the end of 2024, I was still working the traditional way: VS Code, a plugin, and an OpenAI model.
It completed lines, caught the occasional typo, and sometimes scaffolded a class. I wrote everything else myself.
Then the models improved, and Anthropic entered the picture. For the first time, I let an agent execute terminal commands and edit files.
Initially, I was nervous. What should I allow an AI to do on my machine? What shouldn’t I?
But I quickly discovered that an AI with access to the entire project produces much better results than one that can only see the file currently open in the editor.
Then came the phase I think many developers experienced: spec-driven development. Detailed plans, plan mode, and every step documented in advance.
Today, I need that less and less. The job has changed. I’m no longer writing every line or planning every detail. I’m learning to conduct the agents effectively.
What a feature looks like today
I’m a visual person. When a feature involves a screen, I start with the screen.
I sketch it as a small interactive prototype using Claude Design. There’s already a prototype of the entire application, so I simply extend it with the new functionality.
Once I’m happy with the result, I include it in the prompt.
Claude Code generates an implementation plan, usually broken into several steps. I then decide whether the work should be distributed across multiple agents. Most of the time, it shouldn’t.
The implementation runs in a fresh Git worktree and eventually becomes a pull request.
Then another model reviews the changes. Not Opus again, but Codex.
Different models really do find different things. My impression is that the latest Codex digs deeper and is stricter than Opus.
What AI Can’t Do for You
This is where the real time investment happens.
You build a feature, you think it’s great, and then you start using it in your daily work. That’s when you discover that it doesn’t fit your actual workflow. Sometimes, not at all.
An AI can’t take that responsibility away from you.
This is especially true when you’re building something that you can’t simply copy from another application. And even when you do copy an existing solution, there’s no guarantee that the original implementation works particularly well.
The cycle of building, using, throwing away, and building again is where the months go.
AI can accelerate implementation, but it can’t replace the experience of using the software and understanding what actually works.
Building a Project Management Platform with Rails
Lalabase is designed for software agencies, freelancers, and small software companies that work on projects for clients.
The idea is to replace the usual collection of disconnected tools: a ticketing system, a wiki, time-tracking software, meeting notes, chat, and reporting spreadsheets.
The application organizes work around clients, projects, and tickets.
Each client has its own organization and access permissions. Projects can define their own statuses, priorities, and custom fields. Teams can work with tickets as either lists or boards.
Time tracking is tied directly to tickets. Multiple sessions can be recorded against a single ticket, each independently billable, with exports available for invoicing.
Documentation can live inside projects, but there’s also an interesting integration: a folder in a GitHub or GitLab repository can become the project’s documentation.
Meetings bring together transcripts, AI-generated summaries, and the tasks that follow from them.
The AI assistant connects these different sources of information. You can ask questions about an individual ticket or meeting, or query information across tickets, documentation, time entries, and meetings.
Importantly, answers include references to their sources. The goal isn’t simply to generate plausible text, but to make it possible to verify where an answer came from.
The technical foundation
The application is built on a modern Rails stack:
- Ruby 4 and Rails 8.1 as the application foundation.
- PostgreSQL with pgvector for semantic search used by the AI assistant.
- Hotwire, combining Turbo and Stimulus, for the interactive frontend.
- ViewComponent and Tailwind for the UI.
- Solid Queue for background jobs.
- acts_as_tenant for tenant isolation.
- Command objects, called Actors, for non-trivial write operations.
And there’s no React.
Most non-trivial writes go through small command objects in app/services/actors/. There are around 60 of them now.
They keep controllers thin, are easy to test, and give AI a clear, consistent pattern to follow instead of dozens of different implementation styles.
Mess Multiplies
AI learns from the code that’s already there. That’s both its greatest strength and one of its biggest dangers.
If your codebase is messy, the AI will discover that mess, treat it as an example, and reproduce it. Faster than you can say “code review.”
That’s why you need to be careful from the very beginning and clean up regularly. Find duplication and generalize it.
Some of the traditional Clean Code principles matter more than ever. Not all of them, but certainly some.
Guard specs as architectural boundaries
I went one step further. Lalabase has 84 guard specs.
These aren’t tests for individual features. They enforce rules across the entire codebase.
For example:
- No view loads resources from a CDN.
- Every gem must have a permissive license.
- No link uses a rails-ujs option that’s no longer supported under Turbo.
Why be so strict?
Because a rule that only exists in someone’s head or in a prompt will eventually be broken.
Private comments are a good example. The rule governing who can read a private comment existed in one policy, but five other places had simply forgotten to enforce it.
Today, a single method determines whether someone can read a comment. A spec fails as soon as another part of the application accesses comments without going through that method.
That’s where the developer needs to step in: turning implicit knowledge into enforceable rules.
Testing Is My Job Now
One of my main responsibilities today is reviewing tests.
Do we have the right tests? Are they testing the right things?
Good test coverage has become cheap.
Honestly, I enjoy this part more than I used to. Writing the tenth controller by hand was never the fun part. Thinking about what could break is.
AI can generate implementation code and tests quickly, but deciding what deserves to be tested and whether the tests actually protect the application remains an engineering responsibility.
Write Your Code for an AI
This is perhaps the biggest shift in my thinking.
Whatever I write today, I write with the assumption that an AI will read it later.
A comment doesn’t need to explain what a class does. The AI can understand that from the code itself.
But it should explain why the class exists, why a particular decision was made, and how it relates to other parts of the application.
I go further and deliberately put business knowledge into comments.
Here’s an example from our website: a comment explains why we store information about where a visitor came from in the existing Rails session.
The reason is legal. By avoiding a new cookie, we avoid triggering the need for an additional consent banner.
You would never guess that from the implementation alone.
Documentation and the source of truth
I use these comments to let AI generate documentation.
Traditionally, business logic lived in requirements documents, separate from the code. Over time, the two inevitably drifted apart.
Now, they can live together, and the AI can become an expert in the specific business domain.
There’s one important warning, though: you still need documents that represent the actual source of truth.
In Lalabase, that’s the CLAUDE.md file in the repository and six small maps in the directories where they’re needed.
These documents provide a reference point for checking whether the AI is making things up.
You can even maintain a separate repository containing only authoritative information, where the AI can read the content but cannot modify it.
Your Data, Your AI
Another important design decision concerns data ownership and privacy.
The AI assistant is disabled by default. When users decide to enable it, they choose which provider to use.
Lalabase supports OpenAI, Anthropic, Google Gemini through Vertex AI in the EU, Mistral, IONOS, OVHcloud, and any OpenAI-compatible endpoint, including models running inside your own network.
The principle is straightforward: project data should not be sent to an AI provider that the customer hasn’t explicitly chosen.
This matters because project management systems contain sensitive business information: client discussions, technical decisions, meeting transcripts, estimates, and billing details.
The AI should work with that information under the customer’s control.
Connecting external agents through MCP
Lalabase also exposes a REST API and an MCP server.
This makes it possible to connect external AI tools such as Claude and Cursor using a personal access token.
Agents can list, create, and update tickets, add comments, log time, search the knowledge base, read the inbox, and look up information in indexed repository code.
There’s also a separate terminal application, Lalabase CLI, for macOS and Linux.
It allows developers to work through their inbox, read and answer tickets, book time, hand a ticket to Claude Code, and monitor running agents.
This is an interesting extension of the original idea: Lalabase isn’t just a project management application that happens to have an AI assistant. It’s also a structured source of project knowledge that other agents can interact with.
Two Ways to Run It
Lalabase can be self-hosted or used as a managed cloud service.
The self-hosted version is available under AGPL-3.0-only. Customers can run the complete application on their own infrastructure and pay only for the server and its operation.
For those who don’t want to maintain infrastructure, there’s a hosted service operated in Germany.
Both options provide the full feature set. The cloud service handles operation, updates, and backups, while self-hosted installations give customers direct control over their infrastructure.
Installation is designed around Docker Compose. The supplied setup includes the application, a background job worker, PostgreSQL with pgvector, Valkey, and Caddy for TLS certificates.
The documentation also covers configuration, AI providers, backups, and updates.
So, Why Give It Away?
Let’s return to the original question.
The number of software projects is exploding. Everybody can build something now.
That means distribution is becoming almost everything.
Atlassian has a huge customer base, a well-known brand, and a substantial advertising budget. An independent developer has none of those advantages.
What can a small developer do?
Put the code in the open, write good documentation, and offer a SaaS service for people who like the software but don’t want to host and maintain it themselves.
“I like it, but please run it for me for a few euros a month.”
WordPress has demonstrated that this model can work for more than twenty years.
That’s why Lalabase is open source under the AGPL-3.0-only license.
Anyone can run it. Organizations offering modified versions as a network service have obligations under the AGPL to make their corresponding source code available to users. And those who don’t want to deal with servers and updates can use the hosted service.
A project built over two years
Lalabase has been in development since October 2024.
The project has accumulated more than 2,300 commits and approximately 970 pull requests. It has been running in production for customers since September 2025.
The first public repository release is version 2026.10.0.
The earlier development history remains private because it contains customer data and details about the servers. Development continues in the open from the first public release.
This is also a reminder that releasing a mature application as open source doesn’t necessarily mean exposing every part of its development history.
Code got cheap. Finding out what really works, and getting found, did not.
Try Lalabase
There’s a public demo available without registration. The login is available directly on the page, and the environment resets every night, so feel free to experiment.
- Live demo: https://demo.lalabase.com
- Website: https://lalabase.com/en
- GitHub repository: https://github.com/lalabase/lalabase
- Documentation: https://lalabase.com/docs/en/self-hosting/getting-started/overview
- Cloud pricing: https://lalabase.com/en/pricing
- Lalabase CLI: https://github.com/lalabase/lalabase-cli
The README includes Docker installation instructions, and the documentation covers the complete self-hosting process.
I’d be grateful for honest feedback. And a GitHub star helps a small project more than you might think.
Guido Boyke
