How much do we contribute?
We do not just say "we like open source" and leave it at words. Below we leave the numbers, and they should state clearly enough what we are capable of. Please keep in mind that they grow every week.
Lines of code written in total
Over five million lines of code across real projects - from a hosting panel and a messenger, through native desktop and mobile apps, to emulators, game engines and hand-rolled microframeworks. This is not a generator number or rewritten tutorials: every one of those lines backs a working product or a tool we use ourselves every day. We write a lot because we build a lot, and we have done it non-stop since 2020.
Repositories (projects)
Over two hundred repositories across more than 100 projects, all spread across our accounts. There are production platforms, internal tools, experiments, mobile and desktop apps, dashboards, and educational or open-source projects we prepare for other developers. A number like that does not come from a single weekend - it is years of consistent work, where a new idea ends up giving us another opportunity to build the next scalable project.
Stars on projects we have contributed to
It is not only non-technical people who trust us, but developers from all over the world. Millions of people use libraries and tools we have contributed our part to - often without even knowing it, because our code quietly works under the hood of their favourite projects. The stars on those repositories are the pooled trust of a community that values these tools enough to come back to them every day. For us it is the best proof that our work reaches far beyond our own backyard.
Open-source projects with our contributions
Our code has landed in more than 50 external open-source projects. These are not random repos - they are libraries and tools developers use every day: PHPMailer, pydantic, Polly, FluentValidation, Monolog, Serilog, NLog, Ebiten, goquery, Pagefind and CommonMark. We fix things where we rely on them and send the changes back to the community.
Meet our open-source projects
We do not just add commits to other people's repos - we build our own tools and platforms that we use daily and share onward.
Every one of our repositories from a single terminal.
Vulp is our in-house terminal tool: one screen shows the state of every repository, a batch sync pulls and pushes changes at once, and projects, todos, pull requests and statistics sit under keyboard shortcuts. Written in Rust so it stays instant.
View on GitHub
A control plane for AI agents that work on their own.
Gyred keeps a fleet of agents in line: workspaces separate projects, rules say what an agent may do, and loops carry a real stopping condition instead of spinning forever. Leases make sure two agents never grab the same task - one takes it, the rest wait.
View on GitHub
A messenger with accounts, groups and live conversations.
Plazer is a messenger built from scratch: you create an account, add friends, write in direct messages or groups, react and pin what matters. Messages travel over WebSocket, so a conversation happens live, and the same history waits for you in the desktop, phone and browser apps. The backend runs on Go, PostgreSQL and Redis.
View on GitHub
How we add our brick to the wall
Our part in open code does not take one shape. We do it in four different ways - each one feeds the others.
Custom software services
We build software to order: websites, panels, stores and apps. The client owns the code and gets the full commit history, not a locked black box. Many of the patterns and tools we work out here later flow back into our open projects.
Running our own OSS projects
We maintain our own open projects - like vulp - with a real repo, releases and care for quality. These are not abandoned experiments: we watch the issues, write documentation and keep developing them because we use them daily ourselves. Anyone can step in, read the code and build on top of it.
Contributing to other code
When we find a bug or a missing feature in a library we use, we do not patch it quietly on our side - we send the fix upstream. We file issues, open pull requests and help keep alive the tools our own work stands on. It is plain fairness toward the ecosystem we rely on.
Ready-made SaaS platforms
Some of our projects grow into full SaaS platforms where someone can simply sign up and get to work. The core of these platforms often shares code with the open tools, so developing one drives the other. Instead of inventing everything from scratch on every job, we have proven foundations we built ourselves and understand end to end.
We do not stand still
We are not bragging about one good month. On the left, numbers from our whole history in open code; on the right, the activity graph from the last 90 days - dense and without long gaps, because open source is a daily habit for us.
What we build in the open
Open code is not one type of project for us. From terminal tools, through platforms and apps, to emulators and libraries.
Terminal tools we run ourselves every day, the kind that save us hours of clicking. The flagship is vulp - from a single terminal window it manages many repositories at once, syncs them, opens pull requests and gathers statistics. On top of that it enforces guardrails so nothing lands in a bad state. We build them for ourselves first, so they have to be fast and dependable.
Full control planes and platforms that pull many moving parts into one readable dashboard. One such project is Gyred - it runs a whole fleet of AI agents from a single place, shows their state and lets you steer them in real time. In the same spirit we build hosting and client panels where everything important is within reach. The point is that complex infrastructure can be grasped at a glance.
Apps written from scratch, where a single codebase serves web, desktop and phone at once. The flagship is Plazer - a live-chat messenger with end-to-end encryption, so the content of messages stays between the people talking. Instead of snapping ready-made blocks together, we build these apps layer by layer and stay in control of every detail. That way they work equally well on every screen.
We go down to the lowest layers, where every clock cycle counts. We write CPU emulators verified bit for bit - from CHIP-8 to the Game Boy - so they behave exactly like the original chip. On top of that come game engines and renderers built from the ground up, with no ready-made drawing libraries. It is the most demanding part of what we do, and the one we learn the most from.
Small, well-tested libraries and microframeworks that do one thing and do it properly. We build them only on the language standard library, with no heavy dependencies dragging half the internet along. That keeps them light, easy to drop into another project and predictable to maintain. We cover each one with tests before we call it done.
Discord bots, webhook proxies and ops scripts that take over the dull, repetitive work. They take load off the team and watch the infrastructure on their own, reacting before anyone even notices a problem. Instead of clicking through panels by hand, we describe once what should happen automatically and leave it to the machine. They give us more time for the things that cannot be automated.
See how we write - in the open
All of our open source is public: repositories, commit history, releases. Take a look, read the code, clone it and build on top - and if you like what you see, leave a star and follow along.
Follow us on GitHub