Fredrik Eklund

Karlstad, Sweden

Hi, I'm Fredrik. I build the tools around the work.

I'm a software developer at Sportality, building sports technology. In my own time I make the things that take friction out of my day: dev environments that start in one command, and agent workflows that turn a problem into a well-documented ticket. I also build websites for clients through Bayville AB.

Email meGitHubLinkedIn
Fredrik Eklund in a navy sweater and white collar, in front of a whitewashed brick wall.

Efficiency

Ideas and tickets get written, fast, with the background attached.

Starting an app is something I do a hundred times a day, so seconds saved there isn't the point. The point is the work that used to feel heavy. Writing up an idea or filing a ticket took real effort. Now it goes fast, and it's better, because the investigation behind a problem comes with it.

  • Turn a finished investigation into a ticket

    5× less

    The evidence is attached, so I don't retype it.

    Before: 15 minNow: 3 min

  • Write up and log the decisions from a session

    Automatic

    It used to be a chore at the end of every session. Now it just happens.

    Before: 5 minNow: automatic

  • An agent finds its bearings in my port-forwards

    ~8× less

    One status call instead of three.

    Before: 1,500 tokensNow: 180 tokens

Starting any of my apps is one command

A tmux session engine in my dotfiles. Each app is a five-line file, and the engine does the rest.

1

Pick an app

A fuzzy list of every app. Filled, half and empty markers say what is running, what died and what is stopped.

sat
2

One small file per app

Directory, commands and optional modes. Nothing to register; it appears in the picker.

dev-sessions/<app>.zsh
3

One shared engine

Builds the tmux session, waits for the backend, starts the frontend, and fails loudly on a stale path.

3

A pane per process

Backend and frontend side by side, in a session that survives the terminal.

--mode debug
4

Logs are files

Read startup output without restarting anything, or restart from wherever you are.

devlog · restart
Fig. A · From a name to a running app An agent can call this

  1. Liveness comes from what each pane is running, not from a port. Ports lie when the real service is forwarded from elsewhere.

  2. Adding an app means copying a file and changing three lines. More than a dozen apps are defined this way.

  3. Modes start the same app another way, for example with a debugger attached, without a second file.

  4. In August, agents started servers by hand 126 times and used these commands zero times. The fix was a manual they can search, and one line in their instructions.

Agents can drive my port‑forwards, so I don't have to

A small macOS app that owns every long-lived port‑forward and renders the matching .env files. A local MCP server lets agents use it.

1

The app

A favourites grid and a selector for environment and site.

2

MCP server

Status, forwards, start and stop, environment preview.

Command line

Reads the same state from the shell.

kpf
3

Local daemon

Tauri and Vue. Keeps what should be on in SQLite, and answers on a token-guarded local API.

4

Port-forwards

Dozens, across several environments, kept alive and reconnected.

.env files

Rendered from templates for whichever environment and site is selected.

Fig. B · One daemon, three ways in An agent can call this

  1. The app stays the daemon. Something has to hold the long-lived processes and survive context switches, so I exposed it rather than rewriting it.

  2. One status call replaced three: an agent now orients in about 180 tokens instead of about 1,500.

  3. What should be on moved out of the UI's own storage into SQLite, so an agent's action is not undone by the next context switch.

  4. It deliberately does not wrap kubectl. It hands the agent the active context and lets it use kubectl directly, which is faster and cheaper.

A bug report that gives the next developer a place to start

Agent skills I wrote so a problem is investigated before it is ticketed, and the ticket carries what was found.

1

Investigate

Evidence first. Ranked hypotheses, and the root cause verified before any fix is proposed.

2

File the ticket

The finding becomes a ticket with the evidence, what was ruled out and where to look.

3

A developer picks it up

They start from the background instead of a one-line description.

4

Decision logged

Written to my notes automatically, dated and never rewritten.

Fig. C · From symptom to a ticket worth picking up An agent can call this

  1. Symptoms go through investigation before anyone touches code. It stops the fix that doesn't fix.

  2. Filing is a skill, so a finished analysis becomes a ticket in minutes instead of a rewrite, with the investigation attached.

  3. Whoever fixes the bug knows what was found, what was ruled out and where to look, so they spend their time on the fix.

  4. Nothing to remember to do: the decision is recorded as part of the session.

More work

Other things I've built

About

Developer, with an eye for how things look

I care about the time between having an idea and seeing it run, and I spend my own time shortening it. Agents have turned out to be the best users of the tools I make, so I build them to be easy for both people and agents to use.

Through Bayville I've made graphics, video, podcasts and web design for clubs and businesses. That is where my eye for how things look on a screen comes from, and I still take on website projects there.

Want to talk?

fredrik@bayville.se

Or find me on GitHub and LinkedIn.