How a small team ships something real every week

If you scroll through our changelog, a rhythm jumps out before any single feature does. New things show up week after week: a run button here, version history there, twenty new integrations, a redesigned canvas, a steady drumbeat that doesn't really let up. People sometimes assume that pace means a big team. It's closer to the opposite. It comes from being small, and from a few deliberate choices about how we work. This is a look at those choices.

Small team, short distance from idea to production

Lodol is built by a small group with backgrounds from places like Stanford, Amazon, Orby AI, and Yale. Small is not a phase we're impatient to grow out of. It's a big part of why we can move the way we do.

On a small team, the distance between noticing a problem and shipping the fix is short. There's no relay race of handoffs, no game of telephone between the person who understands the customer and the person writing the code, because they're often the same person. An engineer who architects the execution engine also feels the paper cut when a run page is confusing, and can just go fix it that afternoon. That compression is the whole advantage, and we work to protect it. Every layer you add between a problem and the person who can solve it is a tax on speed, and we'd rather spend that budget shipping.

Ship in small pieces, constantly

We would rather ship a real improvement this week than a grand one next quarter, and the changelog is downstream of that preference. Most entries aren't dramatic on their own. A clearer error message. Indented loop steps. A recently used section in the step picker. But small, steady improvements compound in a way that big-bang releases never do, and they carry far less risk. A week's worth of change is easy to reason about, easy to review, and easy to roll back if it turns out to be wrong.

Shipping constantly also keeps us honest about what "done" means. Done means it's in front of users, not that it works on someone's laptop. A steady cadence forces the last mile, the polish and the edge cases and the dark-mode legibility, because there's always another release coming and nowhere for half-finished work to quietly hide.

Reliability is a habit, not just a feature

We ask a lot of trust from the teams who run payroll and reconciliations on Lodol, and that shapes how we work internally, not only what we build. The principles we talk about publicly, determinism and observability and reversibility, are the ones we hold ourselves to. We build for the second look and the worst day, not for the demo. We put real effort into checkpointing and audit trails that will never headline a release, because the payoff for that work is an absence: the bug that didn't happen, the run that recovered on its own, the outcome nobody had to explain to a customer.

That's an easy value to say out loud and a hard one to keep, because reliability work rarely feels urgent right up until it's the only thing that matters. Keeping it a habit, doing the unglamorous thing every week whether or not anyone's watching, is a real part of the culture here.

Own the outcome, not just the ticket

On a small team you can't hide behind a job title, and we've decided that's a feature. Whoever builds something owns how it lands: whether it's reliable, whether it's clear, whether it actually solved the problem or just closed a ticket. Accountability is a team sport, which means you follow the work all the way through, and when something breaks you go fix it rather than file it and move on.

It's demanding, and it's also the good part. There's a specific satisfaction in watching a thing you built go from a rough idea to something a real team depends on, with nobody in the middle diluting it along the way. That kind of ownership is exactly what we're protecting when we protect being small.

Fast and durable, at the same time

People expect a tradeoff between speed and durability, and it turns out to be mostly false as long as you ship in small pieces and take reliability seriously. Moving fast doesn't have to mean moving carelessly. It means keeping changes small enough that care is cheap, keeping the path to production short, and treating "it works reliably" as part of the definition of done rather than a cleanup for some later sprint.

That's the whole method, and it isn't a secret. Stay small on purpose. Keep the distance from problem to fix short. Ship real things in small pieces, every week. Hold the reliability line even when nobody's watching. Own what you build all the way out to the customer. Do that consistently, and the changelog more or less writes itself.

This is how we work, and we're always looking for people it resonates with.
If shipping real things every week on a small team sounds like your kind of place, we'd love to hear from you.