Where the business meets engineering, one post at a time.
Notes from building sleds: the route and the engine, intake from the people who do not open a tracker, and how it sits next to the tools you already run.
Built elsewhere
When an item is already being built outside the engine, a planned route for it would build it twice. Now a person can say so: the route goes, no engine picks the item up, and it still lands from its PR.
Read itKeyboard shortcuts in the menu bar app
The menu bar app now runs from the keyboard. Number badges reach any item's workspace, PR or details, a key cycles the filters, Cmd+Enter answers or approves what needs you, and ? shows the whole list.
Skipping a parked node closes its park
A node that stopped to ask a question, then got skipped, used to leave its question open and its session's key still working. Now a skip closes the park, and putting the node back gives you a clean one.
Tell the session what its PR still needs, from the item
Once an engine opens a PR, the item used to have no way back to the session that built it. Now you write the change on the item, or press Address this on a finding, and SLEDS hands it to that session. If the session has ended, SLEDS starts a new one on the PR's branch.
The last merge lands the item
A route's last node could merge and leave its item on the sled, with everything waiting on it still blocked. Now the last node's merge lands the item, whoever holds it.
A skip never lands an item
Skipping a node used to close the route, and a route that closed landed its item. Now a skip only steps a node aside: the item stays open, the route says so, and an item that landed by mistake can be put back.
Where it's live, per environment
Is it out? used to take two tools and a hand-made join. Now a release step reports each deploy, and the item's Release tab shows one row per environment: deployed or not, and live for everyone or for some.
A parent lands with its children
An epic could land from its own route while its children were still open. Now an item waits for every child to land, and an item with children takes no route of its own: the order lives in the children's blockedBy.
Where the business meets engineering
The expensive part of software was never the build. It was the distance between the person who needed something and the person who could make it. Here is how a request crosses it now.
The question in the middle of the build
Every feature has a moment where the engineer needs something only the business knows. It used to cost an afternoon. Now it is a card on the item, answered from Slack or Claude, and the build resumes.
A bug's day, from support to the fix and back, without a meeting
Day-to-day bugs are the clearest case for the seam. Here is one ticket's path through support, product and engineering, and the only three moments a person touched it.
Intake is product guidance, not a form
A request filed through sleds has already read the repo, checked the backlog, set an expectation and, often, drawn the screen. The business user did none of that. They described what they wanted.
Orchestration that meets the engineer where they are
An orchestrator should not own the harness, the model or the machine. The same node runs on your Mac, on a coworker's sled, or in the cloud, and the record reads the same either way.
@SLEDS in the channel
The Slack app is where most requests start and where most of them finish. Here is what it does in a thread, and what it deliberately does not.
Approve or Auto, and the other four settings that decide what runs on your machine
The engine's settings panel is short on purpose. Here is each setting, what it defaults to, and why the defaults are conservative.
Your sled, in the menu bar
The engine runs on your Mac. The menu bar app is where you see it: what is running, what is at PR, what needs you, and the one switch that decides whether anything starts without you.
What 3x looks like, and where it was 10x
Connecting the business, and the customer, to product and engineering was the unlock. The gains were not evenly spread, and the uneven part is the interesting part.
sleds and Linear
Linear teams already have a fast board. Keep it. sleds adds the part before the work and the part after it.
The memory problem started solving itself
The labs shipped memory. Ours stopped being the point. What was underneath it was the thing worth building.
sleds and Jira: keep the board, add the part before and after
Most teams keep Jira. What sleds adds around it, how the two stay in step, and what it looks like if you ever want to run on sleds alone.
Why we started sleds
In September 2025 we set out to build a shared context and memory layer between engineers and the product people around them. Here is what we thought the problem was.
New posts, where you already read.
The feed carries every post. Point your reader, or the Slack RSS app, at it.
https://sleds.ai/news/feed.xml