From idea to launch: how we develop and update lynes

I have the privilege of working at a company that develops its own app.

It’s equally exciting and challenging. Every week, I get plenty of ideas for “the next big feature” — some great, some… less so. And trust me, I’m not the only one.

But more on that later.

Let me take you on a little journey — a behind the scenes, or as I like to call it, a behind the lynes — where we’ll take a look at what actually happens during a development sprint.

Let’s lift the hood and dive into:

Planning

Kickoff

Sprint

Testing phase

Release day

The day after release day-day

The grown-ups make plans

Every Friday, a group of very grown-up people meet to discuss our feature requests and roadmap. They review incoming suggestions, product vision, and set priorities.

One of these grown-ups is Johan Åberg (CPO), who holds the heavyweight belt in this arena.

I’m not exactly one of the grown-ups, but from what I can tell, he’s the referee — balancing strong opinions from sales, delivery, finance, and admin (notice how I’ve conveniently left my department out).

And that’s not all — external voices like end users and partners also weigh in.

There’s a saying:

“A product manager’s job is to say no — politely — even when they themselves want to say yes.”

And it’s true. We can’t build everything at once, no matter how much we’d like to.

These meetings end with decisions — features are given different statuses and priorities based on parameters as secret as the Coca-Cola recipe.

But, just like Coca-Cola, I can share the ingredients list:

Decided – Priority, Decided – No Priority, and Later.

Kickoff

Once a new feature gets the green light, we start sketching it out and syncing with stakeholders. The early sketches aren’t pixel-perfect, but they set the foundation.

When everything’s approved, we plan the feature into an upcoming release — maybe the next one, or the one after that, depending on size and complexity.

A few skilled developers are assigned, working closely with David (CTO), who brings deep technical expertise. They discuss things like:

• Scalability
• Security
• The smartest way to solve it

At this point, as Sickan from Jönssonligan would say:

“I’ve got a plan.”

And with that, we move on to the heist — or in our case, the sprint.

Sprint time

The plan is set, and now the real work begins.

Engineering holds daily stand-ups and weekly all-hands to follow progress on ongoing projects within the sprint (which is roughly equivalent to a release cycle).

New code is written — but also rigorously tested.

Automated tests (so-called unit tests) run every time new code is checked in. This prevents unwanted side effects.

Often, the tests are written before the code itself — known as test-driven development.

When enough progress has been made, the responsible developer creates a Pull Request — a request for peers to review and merge the new code.

Every line of code is reviewed and tested by several developers.

This process is iterative — comments, revisions, more reviews — until everything meets standards for performance, security, and readability.

Parallel to code reviews, UX testing happens in the local development environment to ensure the feature feels right and fits seamlessly with the rest of the app.

Once approved, the code is merged into Master, ready for release.

Testing phase

Now things are heating up — it’s testing week.

After a code freeze, all new code is moved into the test environment (we call it Lingon — yes, like the berry).

Everything is tested thoroughly to ensure it works as expected — and that nothing else broke in the process.

Regression testing checks old functionality, while new test cases cover the latest features.

A release can include thousands of new lines of code — plus plenty that’s been rewritten or removed.

Refining old code is just as important as writing new — like keeping the lawn trimmed and weed-free.

Each test case is documented and distributed among developers (and a few guest testers from other teams).

If something fails, a Fix Task is created, corrected, and retested until everything is green across the board.

In release 1.20, for example, we ran about 1,000 regression tests and hundreds of new feature tests — which took roughly two days for the entire team.

Release day

Before the big update, a risk analysis is conducted by the Platform team, with all contributing developers present.

Everything is prepped down to the smallest detail.

The Engineering team splits into Night Crew and Morning Crew. The night team handles the rollout, while the morning team stays fresh and ready to jump in if anything goes sideways.

There’s a task list and a schedule for every step.

Those in the office enjoy the essentials: candy and pizza (family size, loaded with salami, jalapeños, and onions, naturally).

At 22:00, everyone joins our Mission Control Center — a conference in Lingon — and the release goes live.

Services are updated, databases synced, indexes rebuilt.

Finally, the new frontend version is uploaded, verified, and — with a satisfying click on the big button — released to all users.

That’s when you, the user, see the little green toast in the app:

“A new version is available!”

If all goes well, the night wraps up around midnight with a round of high fives — virtual or not.

The day after release day-day

For the night crew, it’s a well-earned slow morning. The first check-in happens around 13:00 — assuming all systems are running smoothly.

The morning team holds the fort, and the rest of us?

We just enjoy all the shiny new features now live in lynes.

So there you have it — that’s what a development sprint looks like behind the lynes.

‍