10 years ago, when I was CEO of a Swedish consultancy, we built a backbone system for a Swedish care company. The lead developer on that project, Brian Madsen, is now my co-founder at Bored Developers.
That system we built made the company operationally effective enough that one of Sweden's largest care providers acquired them and adopted the system.
It worked. But it had a problem.
It was built feature by feature over years. No written requirements. No business architectural vision. Quick fixes piled on quick fixes. Every change cost more than the one before. By the end, even small adjustments were time-consuming and expensive.
We left the consultancy. Started Bored Developers. We're now building Micronomy together.
Not a rebuild
This is the part worth getting straight up front: Micronomy isn't a rebuild of that old system.
It does everything the old system did — better. And then it covers ground the original never touched. The slice that system handled was the right answer for its decade. The next decade asks more: smarter integration, AI woven through operations, domain primitives that simply didn't exist when we shipped the original.
So when I write "rebuilding the backbone," I mean: same problem space, redesigned for what the next decade actually needs.
How a system gets that way
The problem with the old system wasn't a lack of skill on the team. Brian is an experienced architect; the project had craft behind it. The pattern was incremental.
A client request would come in. The team would propose two paths: a quick fix that solved this case, or a deeper fix that addressed the underlying issue. The deeper fix cost more upfront.
Most of the time, the client picked the quick fix.
Stack those choices over years and the system accumulates a kind of technical sediment. Each new column added without a schema rethink. Each new business rule encoded as a special case instead of a refactor. Each new tenant onboarded by extending the existing branch tree instead of generalizing the model.
Then, predictably, the moment arrives where a tiny change is suddenly expensive.
Changing a font — days. Changing a color — days. Adding a new field to a workflow — weeks.
From the client's seat, each individual decision had been rational at the time. From the team's seat, we watched the cost of the next change grow at every quick-fix decision.
This isn't a unique story. Most production systems older than five years carry the same sediment. The customers running them just don't have anyone left who remembers how it got that way.
Why this team
Brian and I have been working together since we left byBrick. Before either of us led teams, we were both hands-on: Brian as a senior architect; me as an integration architect and developer for many years before I took on the CEO role at byBrick Development.
We're co-architects on Micronomy. Brian owns the backend architecture and engineering. I own the frontend and the AI surface. Both of us still write code; both of us still ship.
We've watched the same patterns compound on the same system over the same calendar. That's not theory — it's scar tissue. There's no debate between us about whether quick fixes accumulate. We lived through them.
The difference now: we own the product. Every quick-fix-vs-proper-fix decision is internal. Every architectural primitive gets defended on "this is what should be true in five years," not "this costs less to ship by Friday."
What that looks like in practice
A few load-bearing decisions for Micronomy:
The contract is the data model. A customer's contract — services, rates, OB rules, billing cadence — is structured data the system reads at runtime. Not configuration nested inside code. Not assumptions hardcoded for the largest customer. If you can write the contract, the system can bill it.
Every state change is an event. Audit trail isn't a feature you turn on for compliance. It's the data structure. "Who changed this rate three months ago" has an answer because the answer was emitted at write time.
One record from schedule to invoice. A shift gets scheduled. The same record carries the reported hours. The same record generates the invoice line. No reconciliation between three tables. If the timesheet and invoice disagree, the bug is upstream and immediately findable.
Swedish care domain in the kernel, not bolted on. LSS-specific concepts, kollektivavtal-aware overtime rules, OB handling — these are primitives the rest of the system composes against, not exceptions handled per-feature.
AI where the leverage is real
The architecture treats AI as a first-class primitive, not a feature bolted onto a finished system. Every part of Micronomy can reach for it where the leverage is clear — anomaly detection on time reports before they become billing disputes, contract ingestion straight into the data model, intelligent assistance for schedulers staring at conflict matrices.
We're not deploying AI everywhere because we can. We're deploying it where it earns its keep. The architectural commitment is that nothing structurally prevents us from doing more as the patterns prove themselves.
More on the specifics in later posts. For now: assume AI is a thread running through the system, not a feature in a corner of it.
What's next
MVP ships end of June. Audience: Swedish LSS and care providers, staffing agencies, and the smaller organizations that have been managing scheduling, time, and billing across three disconnected tools for too long.
You can follow Micronomy at micronomy.net — that's where the product lives.
If you've inherited a system like the one I'm describing — or if you're running one — we'd like to compare notes. Not as a sales call. As a conversation between people who've seen the same patterns.
If you run an LSS or care organization and have lived through the "every small change costs a fortune" pain, I'd genuinely like to hear how it feels from your seat.