A Technical Co-Founder You Always Wanted.
Buffering Your Brain
Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke
// internal doc, public by default
Same bar for everyone. It doesn't move for tenure, title, or how long you've been in the room.
What Kutsa is, and isn't. Read it like a pull request.
// Approve it or request changes. There's no path where it merges anyway.
The compiler doesn't care.
It doesn't care how long you've been writing code, what your title says, or how confident you sounded in standup. It cares whether it runs.
That's how work gets assigned here. Not by who's senior enough to be handed the interesting problem, but by who's actually the right fit for it, right now, given what the problem needs.
Sometimes that's someone who's been here three years. Sometimes it's someone who joined last month and has shipped this exact kind of system twice before. The problem can't tell the difference, so neither do we.
Most places treat open source as something you do on your own time, if any is left over. We treat it as work, because it is work.
A contribution is judged on what it does: does it fix the bug, does it ship the feature, does it hold up in review. The diff doesn't know your name, your title, or whether you wrote it at 2pm on a Tuesday or 11pm on a Saturday. Neither do we.
If it's real work, it gets paid like real work, including the parts that end up in a public repo instead of a private one.
The diff doesn't know your name.
A block only has to do one job - and still click with the rest.
We design systems the way a good set is designed: distinct pieces, each with one job, that snap together into something bigger. A payments service doesn't need to know how auth works. A queue doesn't care what triggered it. That separation is what lets you swap one piece out at year two without touching the rest of the build.
Scale isn't something we bolt on when the traffic shows up. It's a decision made on day one, in how the pieces are cut - clean interfaces, contracts between services that don't leak, data that stays where it belongs. None of it is the flashy part of the build. All of it decides whether year three is a release or a rewrite.
We follow a plan to get where we're going, but the best connections usually show up mid-build, not in the instructions. Slowing down enough to notice them - and to appreciate the piece you just placed instead of rushing to the next one - is what makes the thing worth building.
/* principles, not vibes */
// results over hours logged. gravity doesn't grade on effort.
// fundamentals before flourish. scales before the song.
// say the hard thing early. a late "this won't work" costs more than an early one.
// default to direct access. no relay race between the client and the builder.
// small team, sharp edges. we'd rather turn down work than dilute the bar.
// ship the thing before you talk about the thing.
// untested code is a guess wearing a suit.
// credit follows the contribution, not the org chart.
If you want the person who answers to be the person who wrote the code, that's us. If you want your work judged on the diff and not the demo, that's also us.
> Chapter one. Still being built.
Let's discuss your project and turn your vision into reality. We're here to help you build something amazing.