Open Waters Without a Life Raft

rubyrailsbuilding-in-public

Atlassian announced the end of life for Jira Server back in October 2020. We had over two years to prepare. In theory that’s plenty of time. In practice we spent most of it hoping the problem would solve itself.

We tried Jira Cloud. Twice. Both times the migration failed because our custom workflows didn’t replicate over. We’d spent years building workflows that fit how we actually operate: specific statuses, specific transitions, specific automations tied to how our teams coordinate. Jira Cloud’s workflow engine is different enough from Server’s that our configurations couldn’t come across cleanly. Fields mapped wrong, transitions broke, automations didn’t fire. After the second failed attempt I was done trying to make it work.

February 15th, nine days from now, is when we can no longer renew our Jira Server licenses. After that, no updates, no security patches, and a ticking clock until the whole thing becomes a liability to keep running.

Monday.com was the other obvious option. We evaluated it seriously. It’s slick, the UI is great, the flexibility is impressive. But it’s a general-purpose work tracker that lives in its own world. We wanted references to commits and build statuses on our work items. We wanted integration with Wave CI so a build failure shows up on the story that triggered it. We wanted LDAP sync so users are provisioned from Active Directory without anyone managing accounts. Monday.com doesn’t do any of that. It doesn’t know about our infrastructure and has no way to talk to it.

So here we are. Jira Server dying under us, Jira Cloud unable to take our workflows, Monday.com unable to integrate with our stack. Open waters without a life raft.

Over the weekend I started building. Just a simple proof of concept showing that it could be done.

Meera

The name means “ocean” in Sanskrit. Felt appropriate given the circumstances.

The core idea is simple: take what works from Monday.com (the board/column paradigm, configurable column types, inline editing, drag-and-drop) and what works from Jira (sequential issue IDs, typed status columns, activity audit logs) and put them together in something that runs on our infrastructure and talks to our tools.

Boards with configurable columns. Items organized in color-coded groups. Every board defines its own “entity” name: call your items Tasks, Stories, Deals, Bugs, whatever fits how your team thinks about work.

On day one I had the basic board rendering with fixtures. Day two I switched from Rails partials to ViewComponents and got a 4x rendering speedup. A board with dozens of items and six or seven typed columns means hundreds of component renders per page, and partial lookup overhead adds up fast at that scale.

The ViewComponent decision feels right. Typed attributes, encapsulated rendering, proper slots. It’s a better foundation than partials for a UI-heavy app like this. The whole frontend is server-rendered with Turbo Streams: no React, no state management, just Stimulus controllers for interactivity. Click a cell, edit inline, Turbo Stream updates just that cell.

What’s next

The board core is working. Inline editing for text, numbers, status labels, tags. Drag-and-drop sorting of items within and across groups. The rendering is fast.

Next up: authentication, user profiles, workspace and folder organization, and the JSONB schema for item values so boards can have arbitrary column configurations without database migrations. Then the integrations: LDAP sync, build status from Wave CI, the things that justify building our own instead of buying someone else’s.

Nine days until the license cliff. Time to build fast.