My Business as Code

4 months running a business with plain text

Feb 13, 2026

A year ago, I wrote about an idea: “Company as Code”. Not an idea I was the first to have, but nonetheless an itch I couldn’t find a scratch for.

It started with the frustration of going through an information security compliance audit. I had no issue with the standards - they build trust between organisations. But the process was laborious and irritating.

I just couldn’t understand why it would be so hard to prove that you do as you say, in a software company where every single interaction happens on a SaaS platform.

Why can’t more of this process be automated? The data is right there.

The idea

Working with cloud infra, I was already a fan of Terraform and HCL.

Basically, Terraform lets you declare the infrastructure you want with a domain-specific language (DSL), and then makes it so by building a dependency graph and calling cloud APIs in the right order to create the resources you need.

Could we do a similar thing for work data?

I mean, a structured, declarative representation of a business that’s accessible to both humans and machines.

If you could do that, you’d close the loop that audits close manually today. And probably a lot more.

The experiment

In autumn of 2025, I decided to go my own way with 42futures - a so-called “lifestyle business” focused on building production-ready software pilots.

The context is entirely different as a small business owner. But it was a good time to put my idea into practice. See if there’s anything to it.

I didn’t need it to succeed, but I did need to satisfy my curiosity.

So I built Firm which I describe as a plain-text work management tool. I published it on GitHub and was positively surprised by the amount of interest from technologists out there thinking similar thoughts.

What is Firm?

Firm is a set of tools and libraries to organise a “Business-as-Code”.

Technically, Firm is:

A DSL to define and organise business entities in plain text
A library to build and use graphs of business entities
A CLI for humans and machines to interact with business graphs
An MCP server for chatbots to do the same

The Firm DSL is what makes it code. I like code, because it’s structured, lightweight, automatable, easily stored and easily versioned. As it turns out, AI agents like code, too.

There’s more to say about how Firm works, but I’d rather show how I use it. Here are my experiences from the last 4 months.

How I use Firm

I like to start small and focus on immediate needs. This is a story of how I’ve progressively introduced the “business-as-code” concept in 42futures.

Stage 1: Rolodex

The first thing I needed was a structured way of doing outreach. I wanted to be able to keep track of contacts, early convos and potential leads. Something like a lightweight CRM or a Rolodex.

So I created a git repo and started adding my immediate network into .firm files. I would note a few things about each contact:

contact john_doe {
    name = "John Doe"
    role = "Senior software engineer"
    status = enum"network"
    notes = "We used to build cool stuff together"
}

interaction coffee_chat_with_john {
    interaction_date = 2025-10-02 at 11:00 UTC+1
    initiator_ref = person.daniel_rothmann
    primary_contact_ref = contact.john_doe
    type = enum"in-person meeting"
    
    subject = "Coffee chat"
    outcome = """
        Always nice to connect! 
        John showed me how to set up Rust workspaces.
    """
}

At this point, I’m not much better off than free-form notes. But with references, I build up relationships between entities. And with the Firm CLI, I can quickly recall related data before a meeting:

firm related contact john_doe
> Found 1 relationship for 'contact' entity with ID 'john_doe'

interaction.coffee_chat_with_john

Interaction Date = 2025-10-02 at 11:00 UTC+1
Subject: Coffee chat
<etc...>

Stage 2: Project management

Some of the early conversations presented opportunities, and some project work trickled in. Nice!

Still using the DSL, I evolved my Firm workspace to track opportunities, projects and tasks.

opportunity app_pilot {
    name = "Potential app pilot"
    source_ref = interaction.coffee_chat_with_john
    status = enum"closed won"
    value = 4200 EUR

    notes = """
        Discussed at the coffee meeting. 
        This will be an exciting first project. 
        Thanks John!
    """
}

project app_pilot {
    name = "App pilot"
    status = enum"in progress"
    description = "Build an app to do a thing"
    
    due_date = 2026-01-01 at 12:00 UTC+1
    owner_ref = person.daniel_rothmann
}

task app_pilot_platform {
    name = "Figure out cross-platform or native"
    description = "John wants to know which is better"
    source_ref = project.app_pilot
    assignee_ref = person.daniel_rothmann
    
    is_completed = false
}

My pipeline from contact -> interaction -> opportunity -> project -> work started taking shape. It’s all linked together in the business entity graph.

Here’s what that graph looks like for my workspace:

Every entity is a node. Every reference is an edge. As the workspace grows, so does the graph.

Stage 3: Query engine

At this point I started using the Firm CLI more to read and write entities instead of editing DSL directly.

With a bigger workspace, wrangling individual entities got annoying. So I added query capabilities.

This query gets my unfinished tasks:

firm query 'from tasks | where assignee_ref == person.me and is_completed == false'

And this query gets new leads indirectly related to tech companies:

firm query 'from organization | where industry == "tech" | related(2) lead | where status == "qualified" | order created_at | limit 10'

With the workspace growing, the query engine enabled me to do more complex searches without trolling through too much data.

Stage 4: Coding agents

AI agents have gotten pretty good at writing code and using tools. The Firm DSL is code. The CLI is a tool. Maybe there’s something there?

So I hooked up Claude Code to my Firm workspace and was positively surprised.

The coding agent was great at taking high-level, ambiguous questions and turning them into concrete queries for the Firm CLI and direct interactions with the Firm DSL.

That felt like a huge unlock! I hooked up MacWhisper on my machine to dictate inputs, and suddenly I found myself more often “talking” to my workspace.

I started to absorb functionality I would previously use other tools for. Just because it was easier this way.

For example, I replaced my time tracker with a custom time_entry entity type. After a billable session, I would tell the agent what I did and for how long. The entries pool on an invoice entity for billing.

Stage 5: MCP on the move

I spend some (yes, some!) time away from my computer. When I get an idea or think of something I need to do, I want to access the Firm workspace.

So I added an MCP server. You run it locally with:

firm mcp

The MCP server provides validation, ensuring changes are valid and safe.

I put it in the cloud and added it as a custom connector in the Claude app. It connects to a remote git repository and makes changes on a dedicated branch. Now I can tell my bot secretary what I need, and it takes care of it.

I can also delegate: “Research potential clients in my area and log them as leads for my review”. Bot secretary does a decent job.

When I’m back at the PC, I review and merge to main. Every change is tracked and versioned.

So… does the idea work?

To be honest, it’s hard to say for a bigger org. I’m trying not to get overly attached. I wanted to try it, iterate on it, and abandon if it turned out a waste of time.

But for me, the tool has progressively provided more value - as the data model expanded, as I customised workflows, and as I layered automations on top.

With scripting and bots, Firm is becoming a backbone of my business.

What I like about it is that this is enough. I don’t need as many tools. Firm enables this sort of “second brain” - from low-level note-taking to a holistic picture of my priorities, readily available to me and my bot.

I should also say: where it is now, Firm is for technologists. It works for me because I like the command line.

But I’ve noticed that as I use MCP more, I’m less often in the terminal and more often just blabbering away. Chat as the interface.

That feels like a sci-fi dream coming true - not because of Firm specifically, but because of where AI is going. Voice transcription is good, language models are good. Tool calling is getting there. Firm fits right into that.

Why it works

Most structured data is machine-friendly but human-opaque. SQL tables, JSON blobs, protocol buffers. You need dashboards to make sense of it.

Most human-friendly formats are the opposite. Notes, documents, scribbles on a napkin. An LLM can parse them, but there’s no structure to verify against. Hard to know if the machine understood it correctly.

Firm sits in a sweet spot. The DSL is structured enough to be verifiable - things can be right or wrong, and agents can self-correct. It’s the same reason that language models are good at coding. Firm brings that property to work management.

But the underlying data is just text. The bot can read it, but so can I. To catch mistakes and provide feedback. Version control gives me safety around automation.

Essentially:

Firm creates a shared surface between bots and humans. Structure and verifiability for machines. Readable plain text and version control for me.

I think it’s the thing that makes this approach work.

What’s next?

I increasingly see Firm as a data layer. I don’t want to add AI features to it. It’s a tool, not a platform. The value is in how it’s used together with other things.

I already log invoices in Firm. Could I integrate that with plain text accounting? I write reports with Typst and track them as file assets in Firm. What else can you connect?

When your business data is right there, structured and queryable, many workflows that usually require monolithic SaaS tools become a script or a prompt away.

I think that’s where this gets exciting: Firm as one tool in the “agentic toolbox”, where the prompt is your interface and structured data keeps the agents honest. Not adding intelligence to the data layer, but letting the intelligence sit on top, and giving it something good to work with.

As for the compliance question that started all of this - I’m working in a different context now, but the itch remains.

A year ago, this was an abstract idea. Now it’s a central component in how I run my business.

It works for me.

42futures

Discussion about this post

Ready for more?